* Re: [v2 3/4] regulator: qcom: Add labibb driver
From: Mark Brown @ 2020-05-27 16:39 UTC (permalink / raw)
To: Sumit Semwal
Cc: agross, Bjorn Andersson, lgirdwood, robh+dt, Nisha Kumari,
linux-arm-msm, LKML, devicetree, kgunda, Rajendra Nayak
In-Reply-To: <CAO_48GF0tjZDmTS+Fa4fv+cfH4skFZP_a9A=P7D0b_si4AFj5A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
On Wed, May 27, 2020 at 10:01:27PM +0530, Sumit Semwal wrote:
> On Thu, 14 May 2020 at 16:57, Sumit Semwal <sumit.semwal@linaro.org> wrote:
> > > If this is useful factor it out into a helper or the core, other devices
> > > also have status bits saying if the regulator is enabled. It looks like
> > > this may be mainly trying to open code something like enable_time, with
> > > possibly some issues where the time taken to enable varies a lot.
> > Makes sense; I am not terribly familiar with the regulator core and
> > helpers, so let me look and refactor accordingly.
> Does something like this make sense, or did I misunderstand your
> suggestion completely? I'll send the updated patches accordingly.
I guess.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 06/11] i2c: designware: Add Baytrail sem config DW I2C platform dependency
From: Andy Shevchenko @ 2020-05-27 16:43 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Alexey Malahov,
Thomas Bogendoerfer, Mika Westerberg, Rob Herring, linux-mips,
devicetree, linux-i2c, linux-kernel
In-Reply-To: <20200527160056.rg66gsubwhrwtnwf@mobilestation>
On Wed, May 27, 2020 at 07:00:56PM +0300, Serge Semin wrote:
> On Wed, May 27, 2020 at 06:46:32PM +0300, Andy Shevchenko wrote:
> > On Wed, May 27, 2020 at 05:24:06PM +0300, Serge Semin wrote:
> > > On Wed, May 27, 2020 at 04:42:20PM +0300, Andy Shevchenko wrote:
> > > > On Wed, May 27, 2020 at 03:01:06PM +0300, Serge Semin wrote:
> > > > > Currently Intel Baytrail I2C semaphore is a feature of the DW APB I2C
> > > > > platform driver. It's a bit confusing to see it's config in the menu at
> > > > > some separated place with no reference to the platform code. Let's move the
> > > > > config definition to be below the I2C_DESIGNWARE_PLATFORM config and mark
> > > > > it with "depends on I2C_DESIGNWARE_PLATFORM" statement. By doing so the
> > > > > config menu will display the feature right below the DW I2C platform
> > > > > driver item and will indent it to the right so signifying its belonging.
> >
> > ...
> >
> > > > > config I2C_DESIGNWARE_BAYTRAIL
> > > > > bool "Intel Baytrail I2C semaphore support"
> > > > > depends on ACPI
> > > > > + depends on I2C_DESIGNWARE_PLATFORM
> > > > > depends on (I2C_DESIGNWARE_PLATFORM=m && IOSF_MBI) || \
> > > > > (I2C_DESIGNWARE_PLATFORM=y && IOSF_MBI=y)
> > > >
> > > > I didn't get this. What is broken now with existing dependencies?
> > >
> > > With no explicit "depends on I2C_DESIGNWARE_PLATFORM" the entry isn't right
> > > shifted with respect to the I2C_DESIGNWARE_PLATFORM config entry in the kernel
> > > menuconfig. So it looks like a normal no-yes driver without it.
> >
> > I didn't get. Is there problems with current case? (I don't see it).
> > If there is a problem, it should have a separate patch and commit message.
> >
> > As for now above excerpt seems redundant and unneeded churn.
>
> Please read the commit log more carefully.
>
> Without explicit "depends on I2C_DESIGNWARE_PLATFORM" you'd see the DW
> I2C-related menuconfig as:
> [*] Synopsys DesignWare Platform
> [ ] Intel Baytrail I2C semaphore support
> with that "depends on I2C_DESIGNWARE_PLATFORM" added:
> [*] Synopsys DesignWare Platform
> [ ] Intel Baytrail I2C semaphore support
> The second case presents the Baytrail semaphore as the DW I2C platform
> feature. Otherwise it's just a simple menuentry. As I see it without adding
> the explicit "depends on I2C_DESIGNWARE_PLATFORM" there is no need in moving
> the config at all.
Thanks for explanation, this makes sense.
> So if you think it's a churn. Well, I'll wait for
> Jarkko' comment in this regard.
>
> BTW Jarkko asked in v3 whether it would work with just explicit "depends on"
> without if-endif enclosing the config.
>
> -Sergey
>
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 06/11] i2c: designware: Add Baytrail sem config DW I2C platform dependency
From: Andy Shevchenko @ 2020-05-27 16:44 UTC (permalink / raw)
To: Serge Semin
Cc: Jarkko Nikula, Wolfram Sang, Serge Semin, Alexey Malahov,
Thomas Bogendoerfer, Mika Westerberg, Rob Herring, linux-mips,
devicetree, linux-i2c, linux-kernel
In-Reply-To: <20200527153046.6172-7-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 06:30:41PM +0300, Serge Semin wrote:
> Currently Intel Baytrail I2C semaphore is a feature of the DW APB I2C
> platform driver. It's a bit confusing to see it's config in the menu at
> some separated place with no reference to the platform code. Let's move the
> config definition to be below the I2C_DESIGNWARE_PLATFORM config and mark
> it with "depends on I2C_DESIGNWARE_PLATFORM" statement. By doing so the
> config menu will display the feature right below the DW I2C platform
> driver item and will indent it to the right so signifying its belonging.
After clarification Serge gave, it makes sense.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: devicetree@vger.kernel.org
>
> ---
>
> Changelog v3:
> - Replace if-endif clause around the I2C_DESIGNWARE_BAYTRAIL config
> with "depends on" operator.
> ---
> drivers/i2c/busses/Kconfig | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 7f92f6a96042..7cd279c36898 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -549,20 +549,10 @@ config I2C_DESIGNWARE_PLATFORM
> This driver can also be built as a module. If so, the module
> will be called i2c-designware-platform.
>
> -config I2C_DESIGNWARE_PCI
> - tristate "Synopsys DesignWare PCI"
> - depends on PCI
> - select I2C_DESIGNWARE_CORE
> - help
> - If you say yes to this option, support will be included for the
> - Synopsys DesignWare I2C adapter. Only master mode is supported.
> -
> - This driver can also be built as a module. If so, the module
> - will be called i2c-designware-pci.
> -
> config I2C_DESIGNWARE_BAYTRAIL
> bool "Intel Baytrail I2C semaphore support"
> depends on ACPI
> + depends on I2C_DESIGNWARE_PLATFORM
> depends on (I2C_DESIGNWARE_PLATFORM=m && IOSF_MBI) || \
> (I2C_DESIGNWARE_PLATFORM=y && IOSF_MBI=y)
> help
> @@ -572,6 +562,17 @@ config I2C_DESIGNWARE_BAYTRAIL
> the platform firmware controlling it. You should say Y if running on
> a BayTrail system using the AXP288.
>
> +config I2C_DESIGNWARE_PCI
> + tristate "Synopsys DesignWare PCI"
> + depends on PCI
> + select I2C_DESIGNWARE_CORE
> + help
> + If you say yes to this option, support will be included for the
> + Synopsys DesignWare I2C adapter. Only master mode is supported.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-designware-pci.
> +
> config I2C_DIGICOLOR
> tristate "Conexant Digicolor I2C driver"
> depends on ARCH_DIGICOLOR || COMPILE_TEST
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH net-next v4 0/4] RGMII Internal delay common property
From: Dan Murphy @ 2020-05-27 16:49 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
Hello
The RGMII internal delay is a common setting found in most RGMII capable PHY
devices. It was found that many vendor specific device tree properties exist
to do the same function. This creates a common property to be used for PHY's
that have tunable internal delays for the Rx and Tx paths.
Dan Murphy (4):
dt-bindings: net: Add tx and rx internal delays
net: phy: Add a helper to return the index for of the internal delay
dt-bindings: net: Add RGMII internal delay for DP83869
net: dp83869: Add RGMII internal delay configuration
.../bindings/net/ethernet-controller.yaml | 14 ++++
.../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++
drivers/net/phy/dp83869.c | 82 ++++++++++++++++++-
drivers/net/phy/phy_device.c | 51 ++++++++++++
include/linux/phy.h | 2 +
5 files changed, 162 insertions(+), 3 deletions(-)
--
2.26.2
^ permalink raw reply
* [PATCH net-next v4 1/4] dt-bindings: net: Add tx and rx internal delays
From: Dan Murphy @ 2020-05-27 16:49 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200527164934.28651-1-dmurphy@ti.com>
tx-internal-delays and rx-internal-delays are a common setting for RGMII
capable devices.
These properties are used when the phy-mode or phy-controller is set to
rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
controller that the PHY will add the internal delay for the connection.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../bindings/net/ethernet-controller.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index ac471b60ed6a..70702a4ef5e8 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -143,6 +143,20 @@ properties:
Specifies the PHY management type. If auto is set and fixed-link
is not specified, it uses MDIO for management.
+ rx-internal-delay-ps:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
+ PHY's that have configurable RX internal delays. This property is only
+ used when the phy-mode or phy-connection-type is rgmii-id or rgmii-rxid.
+
+ tx-internal-delay-ps:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description: |
+ RGMII Transmit PHY Clock Delay defined in pico seconds. This is used for
+ PHY's that have configurable TX internal delays. This property is only
+ used when the phy-mode or phy-connection-type is rgmii-id or rgmii-txid.
+
fixed-link:
allOf:
- if:
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v4 2/4] net: phy: Add a helper to return the index for of the internal delay
From: Dan Murphy @ 2020-05-27 16:49 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200527164934.28651-1-dmurphy@ti.com>
Add a helper function that will return the index in the array for the
passed in internal delay value. The helper requires the array, size and
delay value.
The helper will then return the index for the exact match or return the
index for the index to the closest smaller value.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/phy_device.c | 51 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 2 ++
2 files changed, 53 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 6b30d205642f..3f3bd0fea53c 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2661,6 +2661,57 @@ void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause)
}
EXPORT_SYMBOL(phy_get_pause);
+/**
+ * phy_get_delay_index - returns the index of the internal delay
+ * @phydev: phy_device struct
+ * @delay_values: array of delays the PHY supports
+ * @size: the size of the delay array
+ * @int_delay: the internal delay to be looked up
+ *
+ * Returns the index within the array of internal delay passed in.
+ * The array must be in ascending order.
+ * Return errno if the delay is invalid or cannot be found.
+ */
+s32 phy_get_delay_index(struct phy_device *phydev, const int *delay_values,
+ int size, int int_delay)
+{
+ int i;
+
+ if (int_delay < 0)
+ return -EINVAL;
+
+ if (size <= 0)
+ return -EINVAL;
+
+ if (int_delay < delay_values[0] || int_delay > delay_values[size - 1]) {
+ phydev_err(phydev, "Delay %d is out of range\n", int_delay);
+ return -EINVAL;
+ }
+
+ if (int_delay == delay_values[0])
+ return 0;
+
+ for (i = 1; i < size; i++) {
+ if (int_delay == delay_values[i])
+ return i;
+
+ /* Find an approximate index by looking up the table */
+ if (int_delay > delay_values[i - 1] &&
+ int_delay < delay_values[i]) {
+ if (int_delay - delay_values[i - 1] <
+ delay_values[i] - int_delay)
+ return i - 1;
+ else
+ return i;
+ }
+ }
+
+ phydev_err(phydev, "error finding internal delay index for %d\n",
+ int_delay);
+ return -EINVAL;
+}
+EXPORT_SYMBOL(phy_get_delay_index);
+
static bool phy_drv_supports_irq(struct phy_driver *phydrv)
{
return phydrv->config_intr && phydrv->ack_interrupt;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 2bcdf19ed3b4..2058ed11f7dd 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1408,6 +1408,8 @@ void phy_set_asym_pause(struct phy_device *phydev, bool rx, bool tx);
bool phy_validate_pause(struct phy_device *phydev,
struct ethtool_pauseparam *pp);
void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause);
+int phy_get_delay_index(struct phy_device *phydev, const int *delay_values,
+ int size, int delay);
void phy_resolve_pause(unsigned long *local_adv, unsigned long *partner_adv,
bool *tx_pause, bool *rx_pause);
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v4 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-27 16:49 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200527164934.28651-1-dmurphy@ti.com>
Add the internal delay values into the header and update the binding
with the internal delay properties.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
index 5b69ef03bbf7..2971dd3fc039 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
@@ -64,6 +64,20 @@ properties:
Operational mode for the PHY. If this is not set then the operational
mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
+ rx-internal-delay-ps:
+ $ref: "#/properties/rx-internal-delay-ps"
+ description: Delay is in pico seconds
+ enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000 ]
+ default: 2000
+
+ tx-internal-delay-ps:
+ $ref: "#/properties/tx-internal-delay-ps"
+ description: Delay is in pico seconds
+ enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000 ]
+ default: 2000
+
required:
- reg
@@ -80,5 +94,7 @@ examples:
ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
ti,max-output-impedance = "true";
ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_A_RCLK>;
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
};
};
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v4 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-05-27 16:49 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200527164934.28651-1-dmurphy@ti.com>
Add RGMII internal delay configuration for Rx and Tx.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/dp83869.c | 82 +++++++++++++++++++++++++++++++++++++--
1 file changed, 79 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index cfb22a21a2e6..ba1e3d599888 100644
--- a/drivers/net/phy/dp83869.c
+++ b/drivers/net/phy/dp83869.c
@@ -64,6 +64,10 @@
#define DP83869_RGMII_TX_CLK_DELAY_EN BIT(1)
#define DP83869_RGMII_RX_CLK_DELAY_EN BIT(0)
+/* RGMIIDCTL */
+#define DP83869_RGMII_CLK_DELAY_SHIFT 4
+#define DP83869_CLK_DELAY_DEF 7
+
/* STRAP_STS1 bits */
#define DP83869_STRAP_OP_MODE_MASK GENMASK(2, 0)
#define DP83869_STRAP_STS1_RESERVED BIT(11)
@@ -78,9 +82,6 @@
#define DP83869_PHYCR_FIFO_DEPTH_MASK GENMASK(15, 12)
#define DP83869_PHYCR_RESERVED_MASK BIT(11)
-/* RGMIIDCTL bits */
-#define DP83869_RGMII_TX_CLK_DELAY_SHIFT 4
-
/* IO_MUX_CFG bits */
#define DP83869_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
@@ -99,6 +100,10 @@
#define DP83869_OP_MODE_MII BIT(5)
#define DP83869_SGMII_RGMII_BRIDGE BIT(6)
+static const int dp83869_internal_delay[] = {250, 500, 750, 1000, 1250, 1500,
+ 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000};
+
enum {
DP83869_PORT_MIRRORING_KEEP,
DP83869_PORT_MIRRORING_EN,
@@ -108,6 +113,8 @@ enum {
struct dp83869_private {
int tx_fifo_depth;
int rx_fifo_depth;
+ s32 rx_id_delay;
+ s32 tx_id_delay;
int io_impedance;
int port_mirroring;
bool rxctrl_strap_quirk;
@@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device *phydev)
&dp83869->tx_fifo_depth))
dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
+ ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
+ &dp83869->rx_id_delay);
+ if (ret) {
+ dp83869->rx_id_delay =
+ dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
+ ret = 0;
+ }
+
+ ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
+ &dp83869->tx_id_delay);
+ if (ret) {
+ dp83869->tx_id_delay =
+ dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
+ ret = 0;
+ }
+
return ret;
}
#else
@@ -367,10 +390,35 @@ static int dp83869_configure_mode(struct phy_device *phydev,
return ret;
}
+static int dp83869_get_delay(struct phy_device *phydev)
+{
+ struct dp83869_private *dp83869 = phydev->priv;
+ int delay_size = ARRAY_SIZE(dp83869_internal_delay);
+ int tx_delay;
+ int rx_delay;
+
+ tx_delay = phy_get_delay_index(phydev, &dp83869_internal_delay[0],
+ delay_size, dp83869->tx_id_delay);
+ if (tx_delay < 0) {
+ phydev_err(phydev, "Tx internal delay is invalid\n");
+ return tx_delay;
+ }
+
+ rx_delay = phy_get_delay_index(phydev, &dp83869_internal_delay[0],
+ delay_size, dp83869->rx_id_delay);
+ if (rx_delay < 0) {
+ phydev_err(phydev, "Rx internal delay is invalid\n");
+ return rx_delay;
+ }
+
+ return rx_delay | tx_delay << DP83869_RGMII_CLK_DELAY_SHIFT;
+}
+
static int dp83869_config_init(struct phy_device *phydev)
{
struct dp83869_private *dp83869 = phydev->priv;
int ret, val;
+ int delay;
ret = dp83869_configure_mode(phydev, dp83869);
if (ret)
@@ -394,6 +442,34 @@ static int dp83869_config_init(struct phy_device *phydev)
dp83869->clk_output_sel <<
DP83869_IO_MUX_CFG_CLK_O_SEL_SHIFT);
+ if (phy_interface_is_rgmii(phydev)) {
+ delay = dp83869_get_delay(phydev);
+ if (delay < 0)
+ return delay;
+
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIIDCTL,
+ delay);
+ if (ret)
+ return ret;
+
+ val = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL);
+ val &= ~(DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ val |= (DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ val |= DP83869_RGMII_TX_CLK_DELAY_EN;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ val |= DP83869_RGMII_RX_CLK_DELAY_EN;
+
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL,
+ val);
+ }
+
return ret;
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v3 3/3] hwmon: Add Baikal-T1 PVT sensor driver
From: Serge Semin @ 2020-05-27 16:52 UTC (permalink / raw)
To: Guenter Roeck
Cc: Serge Semin, Jean Delvare, Jonathan Corbet, Maxim Kaurkin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, linux-hwmon, linux-doc, linux-kernel
In-Reply-To: <20200527162549.GA225240@roeck-us.net>
On Wed, May 27, 2020 at 09:25:49AM -0700, Guenter Roeck wrote:
> On Tue, May 26, 2020 at 04:38:23PM +0300, Serge Semin wrote:
[nip]
> > +
> > +=============================== ======= =======================================
> > +Name Perm Description
> > +=============================== ======= =======================================
> > +update_interval RW Measurements update interval per
> > + sensor.
> > +temp1_type RO Sensor type (always 1 as CPU embedded
> > + diode).
> > +temp1_label RO CPU Core Temperature sensor.
> > +temp1_input RO Measured temperature in millidegree
> > + Celsius.
> > +temp1_min RW Low limit for temp input.
> > +temp1_max RW High limit for temp input.
> > +temp1_min_alarm RO Temperature input alarm. Returns 1 if
> > + temperature input went below min limit,
> > + 0 otherwise.
> > +temp1_max_alarm RO Temperature input alarm. Returns 1 if
> > + temperature input went above max limit,
> > + 0 otherwise.
> > +temp1_trim RW Temperature sensor trimming factor in
> > + millidegree Celsius. It can be used to
> > + manually adjust the temperature
> > + measurements within 7.130 degrees
> > + Celsius.
>
> vs. standard ABI:
>
> temp[1-*]_offset`
> Temperature offset which is added to the temperature reading
> by the chip.
>
> Unit: millidegree Celsius
>
> If you really think this is necessary, why not use the standard ABI ?
That would have made much more sense.) I'll replace the handwritten temp1_trim
with the standard temp1_offset attribute in v4 shortly today. Thanks for pointing
this out.
-Sergey
>
> Guenter
^ permalink raw reply
* Re: [PATCH v3 3/3] hwmon: Add Baikal-T1 PVT sensor driver
From: Guenter Roeck @ 2020-05-27 16:58 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Jean Delvare, Jonathan Corbet, Maxim Kaurkin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, linux-hwmon, linux-doc, linux-kernel
In-Reply-To: <20200527165205.5krrdahiup3i2oq3@mobilestation>
On 5/27/20 9:52 AM, Serge Semin wrote:
> On Wed, May 27, 2020 at 09:25:49AM -0700, Guenter Roeck wrote:
>> On Tue, May 26, 2020 at 04:38:23PM +0300, Serge Semin wrote:
>
> [nip]
>
>>> +
>>> +=============================== ======= =======================================
>>> +Name Perm Description
>>> +=============================== ======= =======================================
>>> +update_interval RW Measurements update interval per
>>> + sensor.
>>> +temp1_type RO Sensor type (always 1 as CPU embedded
>>> + diode).
>>> +temp1_label RO CPU Core Temperature sensor.
>>> +temp1_input RO Measured temperature in millidegree
>>> + Celsius.
>>> +temp1_min RW Low limit for temp input.
>>> +temp1_max RW High limit for temp input.
>>> +temp1_min_alarm RO Temperature input alarm. Returns 1 if
>>> + temperature input went below min limit,
>>> + 0 otherwise.
>>> +temp1_max_alarm RO Temperature input alarm. Returns 1 if
>>> + temperature input went above max limit,
>>> + 0 otherwise.
>>> +temp1_trim RW Temperature sensor trimming factor in
>>> + millidegree Celsius. It can be used to
>>> + manually adjust the temperature
>>> + measurements within 7.130 degrees
>>> + Celsius.
>>
>> vs. standard ABI:
>>
>> temp[1-*]_offset`
>> Temperature offset which is added to the temperature reading
>> by the chip.
>>
>> Unit: millidegree Celsius
>>
>> If you really think this is necessary, why not use the standard ABI ?
>
> That would have made much more sense.) I'll replace the handwritten temp1_trim
> with the standard temp1_offset attribute in v4 shortly today. Thanks for pointing
> this out.
>
Sorry for not realizing this earlier. The added explanation
made all the difference.
Guenter
^ permalink raw reply
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
From: Nicolas Saenz Julienne @ 2020-05-27 17:01 UTC (permalink / raw)
To: Jim Quinlan
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Rob Herring, Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski,
Robin Murphy, Alan Stern, Oliver Neukum, Rafael J. Wysocki,
Andy Shevchenko, Wolfram Sang, Corey Minyard, Srinivas Kandagatla,
Suzuki K Poulose, Saravana Kannan, Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
In-Reply-To: <CA+-6iNyOKvY-xNfXqDRa5_nJVJuqGKA-oe-ejNuJHUBt6ORu0A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3658 bytes --]
Hi Jim,
On Wed, 2020-05-27 at 11:43 -0400, Jim Quinlan wrote:
> Hi Nicolas,
>
> On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> > Hi Jim,
> > one thing comes to mind, there is a small test suite in
> > drivers/of/unittest.c
> > (specifically of_unittest_pci_dma_ranges()) you could extend it to include
> > your
> > use cases.
> Sure, will check out.
> > On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > > cpu or dma address involved.
> > >
> > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > > ---
> > > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > > drivers/usb/core/message.c | 3 ++
> > > drivers/usb/core/usb.c | 3 ++
> > > include/linux/device.h | 10 +++++-
> > > include/linux/dma-direct.h | 10 ++++--
> > > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > > kernel/dma/Kconfig | 13 ++++++++
> > > 7 files changed, 144 insertions(+), 6 deletions(-)
> > >
> >
> > [...]
> >
> > > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > > device_node *np, u64 *dma_addr,
> > > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > > range.bus_addr, range.cpu_addr, range.size);
> > >
> > > + num_ranges++;
> > > if (dma_offset && range.cpu_addr - range.bus_addr !=
> > > dma_offset)
> > > {
> > > - pr_warn("Can't handle multiple dma-ranges with
> > > different
> > > offsets on node(%pOF)\n", node);
> > > - /* Don't error out as we'd break some existing DTs
> > > */
> > > - continue;
> > > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > > + pr_warn("Can't handle multiple dma-ranges
> > > with
> > > different offsets on node(%pOF)\n", node);
> > > + pr_warn("Perhaps set
> > > DMA_PFN_OFFSET_MAP=y?\n");
> > > + /*
> > > + * Don't error out as we'd break some
> > > existing
> > > + * DTs that are using configs w/o
> > > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > > + */
> > > + continue;
> >
> > dev->bus_dma_limit is set in of_dma_configure(), this function's caller,
> > based
> > on dma_start's value (set after this continue). So you'd be effectively
> > setting
> > the dev->bus_dma_limit to whatever we get from the first dma-range.
> I'm not seeing that at all. On the evaluation of each dma-range,
> dma_start and dma_end are re-evaluated to be the lowest and highest
> bus values of the dma-ranges seen so far. After all dma-ranges are
> examined, dev->bus_dma_limit being set to the highest. In fact, the
> current code -- ie before my commits -- already does this for multiple
> dma-ranges as long as the cpu-bus offset is the same in the
> dma-ranges.
Sorry I got carried away, you're right.
So I understand there is an underlaying assumption that the non DMAble memory
space will always sit on top of the bus memory space, as intertwined as it
might be, so as to every phys_to_dma() call on non DMAble memory to fall above
bus_dma_limit.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add Shanghai Awinic Technology Co., Ltd.
From: Rob Herring @ 2020-05-27 17:04 UTC (permalink / raw)
To: Pavel Machek
Cc: nikitos.tr, Dan Murphy, linux-kernel@vger.kernel.org,
Linux LED Subsystem, devicetree, ~postmarketos/upstreaming
In-Reply-To: <20200525105236.GB27989@amd>
On Mon, May 25, 2020 at 4:52 AM Pavel Machek <pavel@ucw.cz> wrote:
>
> On Mon 2020-05-18 16:14:35, Rob Herring wrote:
> > On Mon, 11 May 2020 16:11:26 +0500, wrote:
> > > From: Nikita Travkin <nikitos.tr@gmail.com>
> > >
> > > Add the "awinic" vendor prefix for Shanghai Awinic Technology Co., Ltd.
> > > Website: https://www.awinic.com/
> > >
> > > Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com>
> > > ---
> > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> I can take 2/ and 3/ of the series, but I believe we'll get conflicts
> if I change vendor-prefixes.yaml in the LED tree. Can you take this
> one?
Okay, applied.
Rob
^ permalink raw reply
* Re: [PATCH v3 3/3] hwmon: Add Baikal-T1 PVT sensor driver
From: Serge Semin @ 2020-05-27 17:05 UTC (permalink / raw)
To: Guenter Roeck
Cc: Serge Semin, Jean Delvare, Jonathan Corbet, Maxim Kaurkin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, linux-hwmon, linux-doc, linux-kernel
In-Reply-To: <14256f0f-2977-4a54-cf01-ae7e684d10c2@roeck-us.net>
On Wed, May 27, 2020 at 09:58:00AM -0700, Guenter Roeck wrote:
> On 5/27/20 9:52 AM, Serge Semin wrote:
> > On Wed, May 27, 2020 at 09:25:49AM -0700, Guenter Roeck wrote:
> >> On Tue, May 26, 2020 at 04:38:23PM +0300, Serge Semin wrote:
> >
> > [nip]
> >
> >>> +
> >>> +=============================== ======= =======================================
> >>> +Name Perm Description
> >>> +=============================== ======= =======================================
> >>> +update_interval RW Measurements update interval per
> >>> + sensor.
> >>> +temp1_type RO Sensor type (always 1 as CPU embedded
> >>> + diode).
> >>> +temp1_label RO CPU Core Temperature sensor.
> >>> +temp1_input RO Measured temperature in millidegree
> >>> + Celsius.
> >>> +temp1_min RW Low limit for temp input.
> >>> +temp1_max RW High limit for temp input.
> >>> +temp1_min_alarm RO Temperature input alarm. Returns 1 if
> >>> + temperature input went below min limit,
> >>> + 0 otherwise.
> >>> +temp1_max_alarm RO Temperature input alarm. Returns 1 if
> >>> + temperature input went above max limit,
> >>> + 0 otherwise.
> >>> +temp1_trim RW Temperature sensor trimming factor in
> >>> + millidegree Celsius. It can be used to
> >>> + manually adjust the temperature
> >>> + measurements within 7.130 degrees
> >>> + Celsius.
> >>
> >> vs. standard ABI:
> >>
> >> temp[1-*]_offset`
> >> Temperature offset which is added to the temperature reading
> >> by the chip.
> >>
> >> Unit: millidegree Celsius
> >>
> >> If you really think this is necessary, why not use the standard ABI ?
> >
> > That would have made much more sense.) I'll replace the handwritten temp1_trim
> > with the standard temp1_offset attribute in v4 shortly today. Thanks for pointing
> > this out.
> >
>
> Sorry for not realizing this earlier. The added explanation
> made all the difference.
No worries. I'll fix it in v4. What about the clk_get_rate() part of the code?
You had a comment regarding it in v2. I responded with justification that we can
leave it as is. If you still disagree, then I create the clock rate caching in the
private data at the probe() stage.
-Sergey
>
> Guenter
^ permalink raw reply
* Re: [PATCH v4 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example
From: Rob Herring @ 2020-05-27 17:12 UTC (permalink / raw)
To: Serge Semin
Cc: Jarkko Nikula, Wolfram Sang, Serge Semin, Alexey Malahov,
Thomas Bogendoerfer, Andy Shevchenko, Mika Westerberg, linux-mips,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20200527120111.5781-3-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 03:01:02PM +0300, Serge Semin wrote:
> dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
> i2c "reg" property. If it is the compiler will print a warning:
>
> Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64: I2C bus unit address format error, expected "40000064"
> Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64:reg: I2C address must be less than 10-bits, got "0x40000064"
>
> In order to silence dtc up let's discard the flag from the DW I2C DT
> binding example for now. Just revert this commit when dtc is fixed.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v3:
> - This is a new patch created as a result of the Rob request to remove
> the EEPROM-slave bit setting in the DT binndings example until the dtc
> is fixed.
> ---
> Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> index 4bd430b2b41d..101d78e8f19d 100644
> --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> @@ -137,7 +137,7 @@ examples:
>
> eeprom@64 {
> compatible = "linux,slave-24c02";
> - reg = <0x40000064>;
> + reg = <0x64>;
But the compatible is a slave, so you need an example with a different
device.
> };
> };
> - |
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v14 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem
From: Rob Herring @ 2020-05-27 17:14 UTC (permalink / raw)
To: Vishal Sagar
Cc: laurent.pinchart, Luca Ceresoli, Jacopo Mondi, Michal Simek,
linux-kernel, Dinesh Kumar, mchehab, robh+dt, linux-arm-kernel,
mark.rutland, devicetree, hans.verkuil, Sandip Kothari,
linux-media, Hyun Kwon
In-Reply-To: <1590587839-129558-2-git-send-email-vishal.sagar@xilinx.com>
On Wed, 27 May 2020 19:27:18 +0530, Vishal Sagar wrote:
> Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
>
> The Xilinx MIPI CSI-2 Rx Subsystem consists of a CSI-2 Rx controller, a
> D-PHY in Rx mode and a Video Format Bridge.
>
> Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> Reviewed-by: Hyun Kwon <hyun.kwon@xilinx.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v14
> - Removed xlnx,csi-pxl-format from required properties
> - Added dependency of xlnx,csi-pxl-format on xlnx,vfb
> - End the yaml file with ...
> - Added Reviewed by Laurent
>
> v13
> - Based on Laurent's suggestions
> - Fixed the datatypes values as minimum and maximum
> - condition added for en-vcx property
>
> v12
> - Moved to yaml format
> - Update CSI-2 and D-PHY
> - Mention that bindings for D-PHY not here
> - reset -> video-reset
>
> v11
> - Modify compatible string from 4.0 to 5.0
>
> v10
> - No changes
>
> v9
> - Fix xlnx,vfb description.
> - s/Optional/Required endpoint property.
> - Move data-lanes description from Ports to endpoint property section.
>
> v8
> - Added reset-gpios optional property to assert video_aresetn
>
> v7
> - Removed the control name from dt bindings
> - Updated the example dt node name to csi2rx
>
> v6
> - Added "control" after V4L2_CID_XILINX_MIPICSISS_ACT_LANES as suggested by Luca
> - Added reviewed by Rob Herring
>
> v5
> - Incorporated comments by Luca Cersoli
> - Removed DPHY clock from description and example
> - Removed bayer pattern from device tree MIPI CSI IP
> doesn't deal with bayer pattern.
>
> v4
> - Added reviewed by Hyun Kwon
>
> v3
> - removed interrupt parent as suggested by Rob
> - removed dphy clock
> - moved vfb to optional properties
> - Added required and optional port properties section
> - Added endpoint property section
>
> v2
> - updated the compatible string to latest version supported
> - removed DPHY related parameters
> - added CSI v2.0 related property (including VCX for supporting upto 16
> virtual channels).
> - modified csi-pxl-format from string to unsigned int type where the value
> is as per the CSI specification
> - Defined port 0 and port 1 as sink and source ports.
> - Removed max-lanes property as suggested by Rob and Sakari
>
> .../bindings/media/xilinx/xlnx,csi2rxss.yaml | 237 +++++++++++++++++++++
> 1 file changed, 237 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: allOf:0:if: None is not of type 'object', 'boolean'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: allOf:1:if: None is not of type 'object', 'boolean'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: allOf:0: 'required' is not one of ['$ref', 'if', 'then', 'else']
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: allOf:1: 'not' is not one of ['$ref', 'if', 'then', 'else']
Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.example.dts' failed
make[1]: *** [Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs....
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: ignoring, error in schema: allOf: 0: if
warning: no schema found in file: ./Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: ignoring, error in schema: allOf: 0: if
warning: no schema found in file: ./Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1298945
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: watchdog: renesas,wdt: Document r8a7742 support
From: Rob Herring @ 2020-05-27 17:15 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Wim Van Sebroeck, devicetree, Guenter Roeck, linux-kernel,
Rob Herring, linux-watchdog
In-Reply-To: <1590596967-22973-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Wed, 27 May 2020 17:29:27 +0100, Lad Prabhakar wrote:
> RZ/G1H (R8A7742) watchdog implementation is compatible with R-Car Gen2,
> therefore add relevant documentation.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Hi,
>
> This patch is part of series [1], as requested by Rob [1] I have
> reabsed my changes on-top json-schema conversion patch.
>
> [1] https://www.spinics.net/lists/netdev/msg653258.html
> [2] https://patchwork.kernel.org/patch/11552335/
>
> Cheers,
> Prabhakar
> ---
> Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v4 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example
From: Serge Semin @ 2020-05-27 17:18 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Alexey Malahov,
Thomas Bogendoerfer, Andy Shevchenko, Mika Westerberg, linux-mips,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20200527171204.GA2348490@bogus>
On Wed, May 27, 2020 at 11:12:04AM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 03:01:02PM +0300, Serge Semin wrote:
> > dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
> > i2c "reg" property. If it is the compiler will print a warning:
> >
> > Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64: I2C bus unit address format error, expected "40000064"
> > Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64:reg: I2C address must be less than 10-bits, got "0x40000064"
> >
> > In order to silence dtc up let's discard the flag from the DW I2C DT
> > binding example for now. Just revert this commit when dtc is fixed.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Cc: linux-mips@vger.kernel.org
> >
> > ---
> >
> > Changelog v3:
> > - This is a new patch created as a result of the Rob request to remove
> > the EEPROM-slave bit setting in the DT binndings example until the dtc
> > is fixed.
> > ---
> > Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > index 4bd430b2b41d..101d78e8f19d 100644
> > --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > @@ -137,7 +137,7 @@ examples:
> >
> > eeprom@64 {
> > compatible = "linux,slave-24c02";
> > - reg = <0x40000064>;
> > + reg = <0x64>;
>
> But the compatible is a slave, so you need an example with a different
> device.
Ok. I'll replace the sub-node with just "atmel,24c02" compatible string then.
-Sergey
>
> > };
> > };
> > - |
> > --
> > 2.26.2
> >
^ permalink raw reply
* Re: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
From: Dan Murphy @ 2020-05-27 17:27 UTC (permalink / raw)
To: Rob Herring; +Cc: jacek.anaszewski, pavel, devicetree, linux-leds, linux-kernel
In-Reply-To: <20200527015905.GA874676@bogus>
Rob
On 5/26/20 8:59 PM, Rob Herring wrote:
> On Tue, May 26, 2020 at 11:46:39AM -0500, Dan Murphy wrote:
>> Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
>> LP5018, LP5012 and LP5009 RGB LED device driver. The LP5036/30/24/18/12/9
>> can control RGB LEDs individually or as part of a control bank group.
>> These devices have the ability to adjust the mixing control for the RGB
>> LEDs to obtain different colors independent of the overall brightness of
>> the LED grouping.
>>
>> Datasheet:
>> http://www.ti.com/lit/ds/symlink/lp5012.pdf
>> http://www.ti.com/lit/ds/symlink/lp5024.pdf
>> http://www.ti.com/lit/ds/symlink/lp5036.pdf
>>
>> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> .../devicetree/bindings/leds/leds-lp50xx.yaml | 180 ++++++++++++++++++
>> 1 file changed, 180 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
>> new file mode 100644
>> index 000000000000..a2ea03e07f6d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
>> @@ -0,0 +1,180 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: LED driver for LP50XX RGB LED from Texas Instruments.
>> +
>> +maintainers:
>> + - Dan Murphy <dmurphy@ti.com>
>> +
>> +description: |
>> + The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into
>> + a LED group or control them individually.
>> +
>> + The difference in these RGB LED drivers is the number of supported RGB
>> + modules.
>> +
>> + For more product information please see the link below:
>> + http://www.ti.com/lit/ds/symlink/lp5012.pdf
>> + http://www.ti.com/lit/ds/symlink/lp5024.pdf
>> + http://www.ti.com/lit/ds/symlink/lp5036.pdf
>> +
>> +properties:
>> + compatible:
>> + oneOf:
>> + - const: ti,lp5009
>> + - const: ti,lp5012
>> + - const: ti,lp5018
>> + - const: ti,lp5024
>> + - const: ti,lp5030
>> + - const: ti,lp5036
> Use enum rather than oneOf+const.
Ok
>
>> +
>> + reg:
>> + maxItems: 1
>> + description:
>> + I2C slave address
>> + lp5009/12 - 0x14, 0x15, 0x16, 0x17
>> + lp5018/24 - 0x28, 0x29, 0x2a, 0x2b
>> + lp5030/36 - 0x30, 0x31, 0x32, 0x33
>> +
>> + enable-gpios:
>> + description: GPIO pin to enable/disable the device.
> How many? (maxItems: 1)
1
>
>> +
>> + vled-supply:
>> + description: LED supply.
>> +
>> + child-node:
> This literally requires a node called 'child-node'. Not what you want.
>
> You need a $ref to the multi-color schema in here and then only define
> what's specific to this chip.
Ok
>
>> + type: object
>> + properties:
>> + reg:
>> + description: This is the LED module number.
> Constraints?
What type of constraints are needed here? They vary based on what LED
device you are using.
>
>> +
>> + color:
>> + description: Must be LED_COLOR_ID_MULTI
>> +
>> + function:
>> + description: see Documentation/devicetree/bindings/leds/common.txt
>> +
>> + ti,led-bank:
>> + description:
>> + This property denotes the LED module numbers that will be controlled as
>> + a single RGB cluster. Each LED module number will be controlled by a
>> + single LED class instance.
>> + There can only be one instance of the ti,led-bank
>> + property for each device node. This is a required node is the LED
>> + modules are to be backed.
>> + $ref: /schemas/types.yaml#definitions/uint32-array
> What is reg then? Some made up index? Can't you do:
>
> reg = <1 2 3>;
> led@1 {};
> led@2 {};
> led@2 {};
reg becomes the first LED module number in the banked LED group.
This chip has the ability to group or bank and control RGB LED clusters
via a single register.
Or the device can control a single RGB LED cluster. The device needs to
be programmed with what LED modules are banked
together. The bank numbers and LED module numbers and output numbers
are not the same. So this property indicates what modules are banked as
in the
multi-led@2 example.
#size-cells = <0>;
+ reg = <2>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STANDBY;
+ ti,led-bank = <2 3 5>;
+
+ led@6 {
+ reg = <0x6>;
+ color = <LED_COLOR_ID_RED>;
+ led-sources = <6 9 15>;
+ };
+
+ led@7 {
+ reg = <0x7>;
+ color = <LED_COLOR_ID_GREEN>;
+ led-sources = <7 10 16>;
+ };
+
+ led@8 {
+ reg = <0x8>;
+ color = <LED_COLOR_ID_BLUE>;
+ led-sources = <8 11 17>;
+ };
+ };
>> +
>> + required:
>> + - reg
>> + - color
>> + - function
>> +
>> + grandchild-node:
> Again, no.
ok
>
>> + type: object
>> + properties:
>> + reg:
>> + description:
>> + A single entry denoting the LED output that controls the monochrome LED.
> Constraints?
Same as above
>> +
>> + color:
>> + description:
>> + see Documentation/devicetree/bindings/leds/common.txt
> Have you read this file recently? Don't add new references to it. (And
> generally freeform references to other files are wrong with schemas).
These patchsets and versions have been around for a very long time.
So this and all references to the common.txt are artifacts prior to the
text file being obsoleted.
I will reference the common.yaml file.
Dan
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Rob Herring @ 2020-05-27 17:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Wei Xu
In-Reply-To: <CAMuHMdXinhY13us9rt9h7EvrT_8zhnQg6tmOBtA0nEQ=1G1O7Q@mail.gmail.com>
On Tue, May 26, 2020 at 1:03 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Laurent,
>
> On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > If we want to be more strict and require the definition of all the
> > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > at them and it's not always clear which regulators to use or if they are
> > > > > even defined.
> > > >
> > > > We can decouple the two though (I think). The bindings should reflect
> > > > what we consider right, and the dts files could be fixed on top.
> > >
> > > Do you have a suggestion on how to do this? If we decouple the two
> > > tasks most of the work would be searching for DTs to fix and finding a
> > > way to fix each one of them, and unless I do this _before_ the binding
> > > conversion I'll get a lot of dtbs_check errors.
> >
> > Rob should answer this question as it will be his decision, but I've
> > personally never considered non-compliant DT sources to be an obstacle
> > to bindings conversion to YAML. The DT sources should be fixed, but I
> > don't see it as a prerequisite (although it's a good practice).
There's currently no requirement that binding schema don't introduce
warnings in dts files. That should change when/if we get to a warning
free state (probably per platform/family). I don't think we're close
on any platform? (If we are, I'd like to start tracking that). It is
good to pay attention to the warnings you get though as the schema may
not be doing what you expect or the binding really doesn't match
reality.
> I do my best to avoid introducing regressions when the binding conversions
> go upstream.
Meaning you fix the dts files or massage the schema to match? If we
just adjust schema to match, what's the point in this effort? We
should find things wrong or ill defined.
Rob
^ permalink raw reply
* Re: [Freedreno] [PATCH 5/6] drm: msm: a6xx: use dev_pm_opp_set_bw to set DDR bandwidth
From: Saravana Kannan @ 2020-05-27 17:31 UTC (permalink / raw)
To: Rob Clark
Cc: Sharat Masetty, freedreno,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
dri-devel, linux-arm-msm, Linux Kernel Mailing List,
Georgi Djakov, Matthias Kaehlcke, Viresh Kumar, Sibi Sankar,
Rajendra Nayak, Jordan Crouse
In-Reply-To: <CAF6AEGvOtgpHMuiw01QgRYGEBB2rp5QOdVMpkTMsi0c-QSSv1Q@mail.gmail.com>
On Wed, May 27, 2020 at 8:38 AM Rob Clark <robdclark@gmail.com> wrote:
>
> On Wed, May 27, 2020 at 1:47 AM Sharat Masetty <smasetty@codeaurora.org> wrote:
> >
> > + more folks
> >
> > On 5/18/2020 9:55 PM, Rob Clark wrote:
> > > On Mon, May 18, 2020 at 7:23 AM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> > >> On Thu, May 14, 2020 at 04:24:18PM +0530, Sharat Masetty wrote:
> > >>> This patches replaces the previously used static DDR vote and uses
> > >>> dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
> > >>> GPU frequency.
> > >>>
> > >>> Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
> > >>> ---
> > >>> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +-----
> > >>> 1 file changed, 1 insertion(+), 5 deletions(-)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > >>> index 2d8124b..79433d3 100644
> > >>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > >>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> > >>> @@ -141,11 +141,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)
> > >>>
> > >>> gmu->freq = gmu->gpu_freqs[perf_index];
> > >>>
> > >>> - /*
> > >>> - * Eventually we will want to scale the path vote with the frequency but
> > >>> - * for now leave it at max so that the performance is nominal.
> > >>> - */
> > >>> - icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
> > >>> + dev_pm_opp_set_bw(&gpu->pdev->dev, opp);
> > >>> }
> > >> This adds an implicit requirement that all targets need bandwidth settings
> > >> defined in the OPP or they won't get a bus vote at all. I would prefer that
> > >> there be an default escape valve but if not you'll need to add
> > >> bandwidth values for the sdm845 OPP that target doesn't regress.
> > >>
> > > it looks like we could maybe do something like:
> > >
> > > ret = dev_pm_opp_set_bw(...);
> > > if (ret) {
> > > dev_warn_once(dev, "no bandwidth settings");
> > > icc_set_bw(...);
> > > }
> > >
> > > ?
> > >
> > > BR,
> > > -R
> >
> > There is a bit of an issue here - Looks like its not possible to two icc
> > handles to the same path. Its causing double enumeration of the paths
> > in the icc core and messing up path votes. With [1] Since opp/core
> > already gets a handle to the icc path as part of table add, drm/msm
> > could do either
Are you sure this is the real issue? I'd be surprised if this is a
real limitation. And if it is, it either needs to be fixed in the ICC
framework or OPP shouldn't be getting path handles by default (and
maybe let the driver set the handles before using OPP APIs to change
BW). I'd lean towards the former.
> > a) Conditionally enumerate gpu->icc_path handle only when pm/opp core
> > has not got the icc path handle. I could use something like [2] to
> > determine if should initialize gpu->icc_path*
This seems like a bandaid. Let's fix it correctly in ICC framework or
OPP framework.
> > b) Add peak-opp-configs in 845 dt and mandate all future versions to use
> > this bindings. With this, I can remove gpu->icc_path from msm/drm
> > completely and only rely on opp/core for bw voting.
I don't know what you mean by "peak-opp-configs" but I guess you are
referring to some kind of DT flag to say if you should vote for BW
directly or use the OPP framework? If so, I'm pretty sure that won't
fly. That's an OS implementation specific flag.
-Saravana
^ permalink raw reply
* Re: [PATCH v11 4/7] dt-bindings: clock: Add X1830 clock bindings.
From: Rob Herring @ 2020-05-27 17:34 UTC (permalink / raw)
To: 周琰杰 (Zhou Yanjie)
Cc: devicetree, sernia.zhou, sboyd, zhenwenjin, mturquette, yanfei.li,
aric.pzqi, paul, dongsheng.qiu, linux-kernel, robh+dt, rick.tyliu,
linux-clk
In-Reply-To: <20200527085449.55573-5-zhouyanjie@wanyeetech.com>
On Wed, 27 May 2020 16:54:46 +0800, 周琰杰 (Zhou Yanjie) wrote:
> Add the clock bindings for the X1830 Soc from Ingenic.
>
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>
> Notes:
> v11:
> New patch, split from [3/6] in v10.
>
> include/dt-bindings/clock/x1830-cgu.h | 55 +++++++++++++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 include/dt-bindings/clock/x1830-cgu.h
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/5] hwmon: lochnagar: Move binding over to dtschema
From: Rob Herring @ 2020-05-27 17:45 UTC (permalink / raw)
To: Charles Keepax
Cc: devicetree, mturquette, broonie, robh+dt, lee.jones, linux-kernel,
sboyd, linux, jdelvare, linus.walleij, patches, lgirdwood
In-Reply-To: <20200512152359.11839-1-ckeepax@opensource.cirrus.com>
On Tue, 12 May 2020 16:23:54 +0100, Charles Keepax wrote:
> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> ---
>
> No changes since v2.
>
> Thanks,
> Charles
>
> .../devicetree/bindings/hwmon/cirrus,lochnagar.txt | 26 ----------------
> .../bindings/hwmon/cirrus,lochnagar.yaml | 35 ++++++++++++++++++++++
> 2 files changed, 35 insertions(+), 26 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.txt
> create mode 100644 Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/5] ASoC: lochnagar: Move binding over to dtschema
From: Rob Herring @ 2020-05-27 17:45 UTC (permalink / raw)
To: Charles Keepax
Cc: linux-kernel, lgirdwood, patches, mturquette, lee.jones,
linus.walleij, devicetree, sboyd, linux, broonie, jdelvare,
robh+dt
In-Reply-To: <20200512152359.11839-2-ckeepax@opensource.cirrus.com>
On Tue, 12 May 2020 16:23:55 +0100, Charles Keepax wrote:
> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> ---
>
> No changes since v2.
>
> Thanks,
> Charles
>
> .../devicetree/bindings/sound/cirrus,lochnagar.txt | 39 ----------------
> .../bindings/sound/cirrus,lochnagar.yaml | 52 ++++++++++++++++++++++
> 2 files changed, 52 insertions(+), 39 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/cirrus,lochnagar.txt
> create mode 100644 Documentation/devicetree/bindings/sound/cirrus,lochnagar.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v3 3/5] pinctrl: lochnagar: Move binding over to dtschema
From: Rob Herring @ 2020-05-27 17:47 UTC (permalink / raw)
To: Charles Keepax
Cc: linus.walleij, robh+dt, lgirdwood, jdelvare, lee.jones, broonie,
patches, sboyd, devicetree, mturquette, linux-kernel, linux
In-Reply-To: <20200512152359.11839-3-ckeepax@opensource.cirrus.com>
On Tue, 12 May 2020 16:23:56 +0100, Charles Keepax wrote:
> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> ---
>
> Changes since v2:
> - Removed description for gpio-controller
> - Force pin node to be called pin-settings
> - Simplify -pins pattern
> - Add additional blank line
>
> Thanks,
> Charles
>
> .../bindings/pinctrl/cirrus,lochnagar.txt | 141 ---------------
> .../bindings/pinctrl/cirrus,lochnagar.yaml | 190 +++++++++++++++++++++
> 2 files changed, 190 insertions(+), 141 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt
> create mode 100644 Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] usb/phy-generic: Add support for OTG VBUS supply control
From: kbuild test robot @ 2020-05-27 17:25 UTC (permalink / raw)
To: Mike Looijmans, linux-usb
Cc: kbuild-all, clang-built-linux, gregkh, robh+dt, balbi, devicetree,
linux-kernel, Mike Looijmans
In-Reply-To: <20200526145051.31520-1-mike.looijmans@topic.nl>
[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]
Hi Mike,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on balbi-usb/testing/next]
[also build test WARNING on usb/usb-testing v5.7-rc7 next-20200526]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Mike-Looijmans/usb-phy-generic-Add-support-for-OTG-VBUS-supply-control/20200526-225304
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git testing/next
config: x86_64-randconfig-a016-20200527 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 3393cc4cebf9969db94dc424b7a2b6195589c33b)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/usb/phy/phy-generic.c:234:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
}
^
1 warning generated.
vim +234 drivers/usb/phy/phy-generic.c
205
206 static int nop_set_vbus(struct usb_otg *otg, bool enabled)
207 {
208 struct usb_phy_generic *nop;
209 int ret;
210
211 if (!otg)
212 return -ENODEV;
213
214 nop = container_of(otg->usb_phy, struct usb_phy_generic, phy);
215
216 if (!nop->vbus_reg)
217 return 0;
218
219 if (enabled) {
220 if (nop->vbus_reg_enabled)
221 return 0;
222 ret = regulator_enable(nop->vbus_reg);
223 if (ret < 0)
224 return ret;
225 nop->vbus_reg_enabled = true;
226 } else {
227 if (!nop->vbus_reg_enabled)
228 return 0;
229 ret = regulator_disable(nop->vbus_reg);
230 if (ret < 0)
231 return ret;
232 nop->vbus_reg_enabled = false;
233 }
> 234 }
235
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 45379 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox