* [PATCH net-next v3 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200526174716.14116-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 | 91 +++++++++++++++++++++++++++++++++++++--
1 file changed, 88 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index cfb22a21a2e6..1c440e0c0d64 100644
--- a/drivers/net/phy/dp83869.c
+++ b/drivers/net/phy/dp83869.c
@@ -64,6 +64,9 @@
#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
+
/* STRAP_STS1 bits */
#define DP83869_STRAP_OP_MODE_MASK GENMASK(2, 0)
#define DP83869_STRAP_STS1_RESERVED BIT(11)
@@ -78,9 +81,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 +99,10 @@
#define DP83869_OP_MODE_MII BIT(5)
#define DP83869_SGMII_RGMII_BRIDGE BIT(6)
+static 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 +112,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;
@@ -218,6 +224,7 @@ static int dp83869_of_init(struct phy_device *phydev)
ret = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_STRAP_STS1);
if (ret < 0)
return ret;
+
if (ret & DP83869_STRAP_MIRROR_ENABLED)
dp83869->port_mirroring = DP83869_PORT_MIRRORING_EN;
else
@@ -232,6 +239,20 @@ 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 = ret;
+ ret = 0;
+ }
+
+ ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
+ &dp83869->tx_id_delay);
+ if (ret) {
+ dp83869->tx_id_delay = ret;
+ ret = 0;
+ }
+
return ret;
}
#else
@@ -367,10 +388,45 @@ 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 = 0;
+ int rx_delay = 0;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
+ tx_delay = phy_get_delay_index(phydev,
+ &dp83869_internal_delay[0],
+ delay_size, dp83869->tx_id_delay,
+ false);
+ if (tx_delay < 0) {
+ phydev_err(phydev, "Tx internal delay is invalid\n");
+ return tx_delay;
+ }
+ }
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
+ phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
+ rx_delay = phy_get_delay_index(phydev,
+ &dp83869_internal_delay[0],
+ delay_size, dp83869->rx_id_delay,
+ false);
+ 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 +450,35 @@ 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)) {
+ ret = dp83869_get_delay(phydev);
+ if (ret < 0)
+ return ret;
+
+ delay = ret;
+ 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
* [PATCH net-next v3 2/4] net: phy: Add a helper to return the index for of the internal delay
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200526174716.14116-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 | 94 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 2 +
2 files changed, 96 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 6b30d205642f..667b510c8810 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2661,6 +2661,100 @@ void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause)
}
EXPORT_SYMBOL(phy_get_pause);
+static int phy_find_descending_delay(struct phy_device *phydev,
+ int *delay_values, int size, int int_delay)
+{
+ int i;
+
+ 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;
+}
+
+static int phy_find_ascending_delay(struct phy_device *phydev,
+ int *delay_values, int size, int int_delay)
+{
+ int i;
+
+ 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;
+}
+
+/**
+ * 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
+ * @descending: if the delay array is in descending order
+ *
+ * Returns the index within the array of internal delay passed in.
+ * Return errno if the delay is invalid or cannot be found.
+ */
+s32 phy_get_delay_index(struct phy_device *phydev, int *delay_values, int size,
+ int int_delay, bool descending)
+{
+ if (int_delay < 0)
+ return -EINVAL;
+
+ if (size <= 0)
+ return -EINVAL;
+
+ if (descending)
+ return phy_find_descending_delay(phydev, delay_values, size,
+ int_delay);
+
+ return phy_find_ascending_delay(phydev, delay_values, size, int_delay);
+}
+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..1ba2c132b635 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, int *delay_values,
+ int size, int delay, bool descending);
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 v3 1/4] dt-bindings: net: Add tx and rx internal delays
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200526174716.14116-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 v3 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-26 17:47 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200526174716.14116-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] ASoC: tlv320adcx140: Fix warnings when using W=1
From: Dan Murphy @ 2020-05-26 17:52 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai
Cc: alsa-devel, linux-kernel, devicetree, Dan Murphy,
kbuild test robot
Fix the warnings when using the W=1 compiler flag.
sound/soc/codecs/tlv320adcx140.c: In function ‘adcx140_reset’:
sound/soc/codecs/tlv320adcx140.c:570:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
570 | int ret = 0;
| ^~~
This was set but only used in case where the reset GPIO is not defined.
Have the function return the value of ret.
sound/soc/codecs/tlv320adcx140.c: In function ‘adcx140_codec_probe’:
sound/soc/codecs/tlv320adcx140.c:778:18: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
778 | if (bias_source < ADCX140_MIC_BIAS_VAL_VREF ||
| ^
sound/soc/codecs/tlv320adcx140.c:789:18: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
789 | if (vref_source < ADCX140_MIC_BIAS_VREF_275V ||
This condition will not occur since if the dt property is not set then
the *_source variable is set to the default value. So there is no way
that *_source can be less then 0. Which is what each #define is set to.
The code just needs to make sure that the dt property is not out of the
upper bounds.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
sound/soc/codecs/tlv320adcx140.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/tlv320adcx140.c b/sound/soc/codecs/tlv320adcx140.c
index 472d759ba8a3..2fe0df3b7550 100644
--- a/sound/soc/codecs/tlv320adcx140.c
+++ b/sound/soc/codecs/tlv320adcx140.c
@@ -582,7 +582,7 @@ static int adcx140_reset(struct adcx140_priv *adcx140)
/* 8.4.2: wait >= 10 ms after entering sleep mode. */
usleep_range(10000, 100000);
- return 0;
+ return ret;
}
static int adcx140_hw_params(struct snd_pcm_substream *substream,
@@ -772,8 +772,7 @@ static int adcx140_codec_probe(struct snd_soc_component *component)
if (ret)
bias_source = ADCX140_MIC_BIAS_VAL_VREF;
- if (bias_source < ADCX140_MIC_BIAS_VAL_VREF ||
- bias_source > ADCX140_MIC_BIAS_VAL_AVDD) {
+ if (bias_source > ADCX140_MIC_BIAS_VAL_AVDD) {
dev_err(adcx140->dev, "Mic Bias source value is invalid\n");
return -EINVAL;
}
@@ -783,8 +782,7 @@ static int adcx140_codec_probe(struct snd_soc_component *component)
if (ret)
vref_source = ADCX140_MIC_BIAS_VREF_275V;
- if (vref_source < ADCX140_MIC_BIAS_VREF_275V ||
- vref_source > ADCX140_MIC_BIAS_VREF_1375V) {
+ if (vref_source > ADCX140_MIC_BIAS_VREF_1375V) {
dev_err(adcx140->dev, "Mic Bias source value is invalid\n");
return -EINVAL;
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v15 01/11] dt-bindings: mediatek: Add property to mt8183 smi-common
From: Rob Herring @ 2020-05-26 18:02 UTC (permalink / raw)
To: Weiyi Lu
Cc: Matthias Brugger, devicetree, linux-kernel, Enric Balletbo Serra,
Nicolas Boichat, linux-mediatek, Fan Chen, linux-arm-kernel,
Sascha Hauer, srv_heupstream, James Liao
In-Reply-To: <1590051985-29149-2-git-send-email-weiyi.lu@mediatek.com>
On Thu, 21 May 2020 17:06:14 +0800, Weiyi Lu wrote:
> For scpsys driver using regmap based syscon driver API.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> .../devicetree/bindings/memory-controllers/mediatek,smi-common.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v15 02/11] dt-bindings: soc: Add MT8183 power dt-bindings
From: Rob Herring @ 2020-05-26 18:03 UTC (permalink / raw)
To: Weiyi Lu
Cc: Matthias Brugger, srv_heupstream, Fan Chen, linux-kernel,
Enric Balletbo Serra, linux-mediatek, linux-arm-kernel,
Sascha Hauer, Nicolas Boichat, devicetree, James Liao
In-Reply-To: <1590051985-29149-3-git-send-email-weiyi.lu@mediatek.com>
On Thu, 21 May 2020 17:06:15 +0800, Weiyi Lu wrote:
> Add power dt-bindings of MT8183 and introduces "BASIC" and
> "SUBSYS" clock types in binding document.
> The "BASIC" type is compatible to the original power control with
> clock name [a-z]+[0-9]*, e.g. mm, vpu1.
> The "SUBSYS" type is used for bus protection control with clock
> name [a-z]+-[0-9]+, e.g. isp-0, cam-1.
> And add an optional "mediatek,smi" property for phandle to smi-common
> node.
>
> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> ---
> .../devicetree/bindings/soc/mediatek/scpsys.txt | 21 ++++++++++++++---
> include/dt-bindings/power/mt8183-power.h | 26 ++++++++++++++++++++++
> 2 files changed, 44 insertions(+), 3 deletions(-)
> create mode 100644 include/dt-bindings/power/mt8183-power.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v15 2/2] i2c: core: support bus regulator controlling in adapter
From: Grygorii Strashko @ 2020-05-26 18:03 UTC (permalink / raw)
To: Tomasz Figa
Cc: Bibby Hsieh, Wolfram Sang, Bartosz Golaszewski, linux-i2c,
Nicolas Boichat, srv_heupstream, Rob Herring, Mark Rutland,
linux-devicetree, Rafael J . Wysocki
In-Reply-To: <CAAFQd5Bx=zgsUAg7fA2jfsV_yFyPmnotTWEBEr2V3Nn5HO8qQQ@mail.gmail.com>
On 25/05/2020 14:34, Tomasz Figa wrote:
> Hi Grygorii,
>
> On Fri, May 22, 2020 at 7:59 PM Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>>
>>
>>
>> On 19/05/2020 10:27, Bibby Hsieh wrote:
>>> Although in the most platforms, the bus power of i2c
>>> are alway on, some platforms disable the i2c bus power
>>> in order to meet low power request.
>>>
>>> We get and enable bulk regulator in i2c adapter device.
>>>
>>> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
>>> ---
>>> drivers/i2c/i2c-core-base.c | 84 +++++++++++++++++++++++++++++++++++++
>>> include/linux/i2c.h | 2 +
>>> 2 files changed, 86 insertions(+)
>>>
>>> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
>>> index 5cc0b0ec5570..e1cc8d46bc51 100644
>>> --- a/drivers/i2c/i2c-core-base.c
>>> +++ b/drivers/i2c/i2c-core-base.c
>>> @@ -313,12 +313,14 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client)
>>> static int i2c_device_probe(struct device *dev)
>>> {
>>> struct i2c_client *client = i2c_verify_client(dev);
>>> + struct i2c_adapter *adap;
>>> struct i2c_driver *driver;
>>> int status;
>>>
>>> if (!client)
>>> return 0;
>>>
>>> + adap = client->adapter;
>>> driver = to_i2c_driver(dev->driver);
>>>
>>> client->irq = client->init_irq;
>>> @@ -378,6 +380,12 @@ static int i2c_device_probe(struct device *dev)
>>>
>>> dev_dbg(dev, "probe\n");
>>>
>>> + status = regulator_enable(adap->bus_regulator);
>>> + if (status < 0) {
>>> + dev_err(&adap->dev, "Failed to enable power regulator\n");
>>> + goto err_clear_wakeup_irq;
>>> + }
>>> +
>>> status = of_clk_set_defaults(dev->of_node, false);
>>> if (status < 0)
>>> goto err_clear_wakeup_irq;
>>> @@ -414,12 +422,14 @@ static int i2c_device_probe(struct device *dev)
>>> static int i2c_device_remove(struct device *dev)
>>> {
>>> struct i2c_client *client = i2c_verify_client(dev);
>>> + struct i2c_adapter *adap;
>>> struct i2c_driver *driver;
>>> int status = 0;
>>>
>>> if (!client || !dev->driver)
>>> return 0;
>>>
>>> + adap = client->adapter;
>>> driver = to_i2c_driver(dev->driver);
>>> if (driver->remove) {
>>> dev_dbg(dev, "remove\n");
>>> @@ -427,6 +437,8 @@ static int i2c_device_remove(struct device *dev)
>>> }
>>>
>>> dev_pm_domain_detach(&client->dev, true);
>>> + if (!pm_runtime_status_suspended(&client->dev))
>>> + regulator_disable(adap->bus_regulator);
>>
>> Not sure this check is correct.
>>
>> i2c_device_probe()
>> - regulator_enable - 1
>>
>> pm_runtime_get()
>> - regulator_enable - 2
>>
>
> I believe regulator_enable() wouldn't be called again, because the
> device was already active in probe. However, I've been having
> difficulties keeping track of runtime PM semantics under various
> circumstances (e.g. ACPI vs DT), so can't tell for sure anymore.
True.
I've found pretty useful:
- CONFIG_PM_ADVANCED_DEBUG
- bind/unbind
for such testing.
for regulators - num_users\x02 can be checked.
>
>> i2c_device_remove()
>> - pm_runtime_status_suspended() flase
>> - regulator_disable() - 1 --> still active?
>>
>> Sorry, I probably missing smth.
>>
>>>
>>> dev_pm_clear_wake_irq(&client->dev);
>>> device_init_wakeup(&client->dev, false);
>>> @@ -438,6 +450,72 @@ static int i2c_device_remove(struct device *dev)
>>> return status;
>>> }
>>>
>>
>> [...]
>>
>> --
>> Best regards,
>> grygorii
--
Best regards,
grygorii
^ permalink raw reply
* Re: [PATCH v11 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema
From: Rob Herring @ 2020-05-26 18:04 UTC (permalink / raw)
To: Xin Ji
Cc: devel, Dan Carpenter, Sam Ravnborg, Jernej Skrabec,
Nicolas Boichat, linux-kernel, Laurent Pinchart, Nicolas Boichat,
Pi-Hsun Shih, devicetree, Sheng Pan, David Airlie, Jonas Karlman,
dri-devel, Neil Armstrong, Andrzej Hajda
In-Reply-To: <393386c0a18753cb4b3f695348fe506a192ea82a.1589511894.git.xji@analogixsemi.com>
On Fri, 15 May 2020 13:49:20 +0800, Xin Ji wrote:
> anx7625: MIPI to DP transmitter DT schema
>
> Signed-off-by: Xin Ji <xji@analogixsemi.com>
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 95 ++++++++++++++++++++++
> 1 file changed, 95 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 08/10] dt-bindings: ufs: Add DT binding documentation for ufs
From: Rob Herring @ 2020-05-26 18:08 UTC (permalink / raw)
To: Alim Akhtar
Cc: devicetree, linux-scsi, krzk, avri.altman, martin.petersen,
kwmad.kim, stanley.chu, cang, linux-samsung-soc, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200514003914.26052-9-alim.akhtar@samsung.com>
On Thu, May 14, 2020 at 06:09:12AM +0530, Alim Akhtar wrote:
> This patch adds DT binding for samsung ufs hci
Subject should indicate this is for Samsung in some way.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
> .../bindings/ufs/samsung,exynos-ufs.yaml | 91 +++++++++++++++++++
> 1 file changed, 91 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
>
> diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
> new file mode 100644
> index 000000000000..eaa64cc32d52
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/ufs/samsung,exynos-ufs.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung SoC series UFS host controller Device Tree Bindings
> +
> +maintainers:
> + - Alim Akhtar <alim.akhtar@samsung.com>
> +
> +description: |
> + Each Samsung UFS host controller instance should have its own node.
> + This binding define Samsung specific binding other then what is used
> + in the common ufshcd bindings
> + [1] Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> +
> +properties:
> +
> + compatible:
> + enum:
> + - samsung,exynos7-ufs
> +
> + reg:
> + items:
> + - description: HCI register
> + - description: vendor specific register
> + - description: unipro register
> + - description: UFS protector register
> +
> + reg-names:
> + items:
> + - const: hci
> + - const: vs_hci
> + - const: unipro
> + - const: ufsp
> +
> + clocks:
> + maxItems: 2
maxItems is redundant.
> + items:
> + - description: ufs link core clock
> + - description: unipro main clock
> +
> + clock-names:
> + maxItems: 2
Here too.
> + items:
> + - const: core_clk
> + - const: sclk_unipro_main
> +
> + interrupts:
> + maxItems: 1
> +
> + phys:
> + maxItems: 1
> +
> + phy-names:
> + maxItems: 1
What's the name? (Though a name is kind of pointless when there is only
1.)
With those fixed,
Reviewed-by: Rob Herring <robh@kernel.org>
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - phys
> + - phy-names
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/exynos7-clk.h>
> +
> + ufs: ufs@15570000 {
> + compatible = "samsung,exynos7-ufs";
> + reg = <0x15570000 0x100>,
> + <0x15570100 0x100>,
> + <0x15571000 0x200>,
> + <0x15572000 0x300>;
> + reg-names = "hci", "vs_hci", "unipro", "ufsp";
> + interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clock_fsys1 ACLK_UFS20_LINK>,
> + <&clock_fsys1 SCLK_UFSUNIPRO20_USER>;
> + clock-names = "core_clk", "sclk_unipro_main";
> + pinctrl-names = "default";
> + pinctrl-0 = <&ufs_rst_n &ufs_refclk_out>;
> + phys = <&ufs_phy>;
> + phy-names = "ufs-phy";
> + };
> +...
> --
> 2.17.1
>
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Rob Herring @ 2020-05-26 18:28 UTC (permalink / raw)
To: Dongchun Zhu
Cc: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko,
mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
bingbu.cao, srv_heupstream, linux-mediatek, linux-arm-kernel,
sj.huang, linux-media, devicetree, louis.kuo, shengnan.wang
In-Reply-To: <20200523084103.31276-2-dongchun.zhu@mediatek.com>
On Sat, May 23, 2020 at 04:41:02PM +0800, Dongchun Zhu wrote:
> Add DT bindings documentation for Omnivision OV02A10 image sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../bindings/media/i2c/ovti,ov02a10.yaml | 172 +++++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 179 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> new file mode 100644
> index 0000000..56f31b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> @@ -0,0 +1,172 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> +
> +maintainers:
> + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> +
> +description: |-
> + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> + image sensor, which is the latest production derived from Omnivision's CMOS
> + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> + sensor output is available via CSI-2 serial data output.
> +
> +properties:
> + compatible:
> + const: ovti,ov02a10
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: top mux camtg clock
> + - description: divider clock
> +
> + clock-names:
> + items:
> + - const: eclk
> + - const: freq_mux
> +
> + clock-frequency:
> + description:
> + Frequency of the eclk clock in Hertz.
> +
> + dovdd-supply:
> + description:
> + Definition of the regulator used as Digital I/O voltage supply.
> +
> + avdd-supply:
> + description:
> + Definition of the regulator used as Analog voltage supply.
> +
> + dvdd-supply:
> + description:
> + Definition of the regulator used as Digital core voltage supply.
> +
> + powerdown-gpios:
> + description:
> + Must be the device tree identifier of the GPIO connected to the
> + PD_PAD pin. This pin is used to place the OV02A10 into Standby mode
> + or Shutdown mode. As the line is active low, it should be
> + marked GPIO_ACTIVE_LOW.
Need to define how many GPIOs ('maxItems: 1')
> +
> + reset-gpios:
> + description:
> + Must be the device tree identifier of the GPIO connected to the
> + RST_PD pin. If specified, it will be asserted during driver probe.
> + As the line is active high, it should be marked GPIO_ACTIVE_HIGH.
Here too.
> +
> + rotation:
> + description:
> + Definition of the sensor's placement.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # Sensor Mounted Upright
> + - 180 # Sensor Mounted Upside Down
> + default: 0
> +
> + ovti,mipi-tx-speed:
> + description:
> + Indication of MIPI transmission speed select, which is to control D-PHY
> + timing setting by adjusting MIPI clock voltage to improve the clock
> + driver capability.
> + allOf:
> + - $ref: "/schemas/types.yaml#/definitions/uint32"
> + - enum:
> + - 0 # 20MHz - 30MHz
> + - 1 # 30MHz - 50MHz
> + - 2 # 50MHz - 75MHz
> + - 3 # 75MHz - 100MHz
> + - 4 # 100MHz - 130MHz
> + default: 3
> +
> + # See ../video-interfaces.txt for details
> + port:
> + type: object
> + additionalProperties: false
Should have a description of what data the port has.
> +
> + properties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + data-lanes:
> + maxItems: 1
> +
> + link-frequencies: true
> + remote-endpoint: true
> +
> + required:
> + - data-lanes
> + - link-frequencies
> + - remote-endpoint
> +
> + required:
> + - endpoint
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - clock-frequency
> + - dovdd-supply
> + - avdd-supply
> + - dvdd-supply
> + - powerdown-gpios
> + - reset-gpios
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "eclk", "freq_mux";
> + clock-frequency = <24000000>;
> +
> + rotation = <180>;
> + ovti,mipi-tx-speed = <4>;
> +
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> +
> + powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + wcam_out: endpoint {
> + data-lanes = <1>;
> + link-frequencies = /bits/ 64 <390000000>;
> + remote-endpoint = <&mipi_in_wcam>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e64e5db..63a2335 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12389,6 +12389,13 @@ M: Harald Welte <laforge@gnumonks.org>
> S: Maintained
> F: drivers/char/pcmcia/cm4040_cs.*
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> +
> OMNIVISION OV13858 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
> L: linux-media@vger.kernel.org
> --
> 2.9.2
^ permalink raw reply
* Re: [PATCH v9 7/8] tpm: Add YAML schema for TPM TIS I2C options
From: Rob Herring @ 2020-05-26 18:31 UTC (permalink / raw)
To: amirmizi6
Cc: amir.mizinski, robh+dt, shmulik.hager, arnd, linux-kernel,
tmaimon77, christophe-h.richard, linux-integrity, Eyal.Cohen,
gcwilson, oshri.alkoby, oren.tanami, oshrialkoby85, jgg,
peterhuewe, kgoldman, Dan.Morav, gregkh, jarkko.sakkinen,
alexander.steffen, devicetree
In-Reply-To: <20200526141658.157801-8-amirmizi6@gmail.com>
On Tue, 26 May 2020 17:16:57 +0300, amirmizi6@gmail.com wrote:
> From: Amir Mizinski <amirmizi6@gmail.com>
>
> Added a YAML schema to support tpm tis i2c related dt-bindings for the I2c
> PTP based physical layer.
>
> This patch adds the documentation for corresponding device tree bindings of
> I2C based Physical TPM.
> Refer to the 'I2C Interface Definition' section in
> 'TCG PC Client PlatformTPMProfile(PTP) Specification' publication
> for specification.
>
> Signed-off-by: Amir Mizinski <amirmizi6@gmail.com>
> ---
> .../bindings/security/tpm/tpm-tis-i2c.yaml | 50 ++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm-tis-i2c.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 1/3] dt-bindings: phy: Add DT bindings for Xilinx ZynqMP PSGTR PHY
From: Rob Herring @ 2020-05-26 18:32 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Michal Simek, devicetree, Kishon Vijay Abraham I,
Anurag Kumar Vulisha, linux-kernel, Vinod Koul
In-Reply-To: <20200513172239.26444-2-laurent.pinchart@ideasonboard.com>
On Wed, 13 May 2020 20:22:37 +0300, Laurent Pinchart wrote:
> From: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
>
> Add DT bindings for the Xilinx ZynqMP PHY. ZynqMP SoCs have a High Speed
> Processing System Gigabit Transceiver which provides PHY capabilities to
> USB, SATA, PCIE, Display Port and Ehernet SGMII controllers.
>
> Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Changes since v7:
>
> - Switch to GPL-2.0-only OR BSD-2-Clause
>
> Changes since v6:
>
> - Fixed specification of compatible-dependent xlnx,tx-termination-fix
> property
> - Dropped status property from example
> - Use 4 spaces to indent example
>
> Changes since v5:
>
> - Document clocks and clock-names properties
> - Document resets and reset-names properties
> - Replace subnodes with an additional entry in the PHY cells
> - Drop lane frequency PHY cell, replaced by reference clock phandle
> - Convert bindings to YAML
> - Reword the subject line
> - Drop Rob's R-b as the bindings have significantly changed
> - Drop resets and reset-names properties
> ---
> .../bindings/phy/xlnx,zynqmp-psgtr.yaml | 105 ++++++++++++++++++
> include/dt-bindings/phy/phy.h | 1 +
> 2 files changed, 106 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 2/2] Device tree bindings for TI HDC20x0 humidity and temperature sensors
From: Rob Herring @ 2020-05-26 18:35 UTC (permalink / raw)
To: Eugene Zalkonnikov
Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
development@norphonic.com, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, Mark Rutland
In-Reply-To: <3309CDF6-5DED-44E4-972B-6D741ABE541E@norphonic.com>
On Mon, May 18, 2020 at 07:22:54PM +0000, Eugene Zalkonnikov wrote:
> Device tree bindings for HDC2010/HDC2080 driver.
Bindings are for h/w devices, not drivers.
Run 'git log --oneline <path>' and follow convention for $subject lines.
(Hint: dt-bindings: iio: ...)
>
>
> Signed-off-by: Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com>
>
> diff -uprN linux-5.3.8/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml linux-5.3.8_docs/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml
> --- linux-5.3.8/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml 1970-01-01 01:00:00.000000000 +0100
> +++ linux-5.3.8_docs/Documentation/devicetree/bindings/iio/humidity/ti,hdc2010.yaml 2020-04-24 17:50:58.213007228 +0200
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
GPL-2.0-only, not or-later please.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/humidity/ti,hdc2010.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HDC2010/HDC2080 humidity and temperature iio sensors
> +
> +maintainers:
> + - Eugene Zaikonnikov <eugene.zaikonnikov@norophonic.com>
> +
> +description: |
> + Relative humidity and tempereature sensors on I2C bus
> +
> + Datasheets are available at:
> + http://www.ti.com/product/HDC2010/datasheet
> + http://www.ti.com/product/HDC2080/datasheet
> +
> +properties:
> + compatible:
> + enum:
> + - ti,hdc2010
> + - ti,hdc2080
> +
> + vdd-supply:
> + maxItems: 1
> +
> +required:
> + - compatible
> +
> +examples:
> + - |
> + i2c0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + humidity@40 {
> + compatible = "ti,hdc2010";
> + reg = <0x40>;
Not documented.
> + };
> + };
>
^ permalink raw reply
* Re: [PATCH v2 07/12] i2c: designware: Move Baytrail sem config to the platform if-clause
From: Serge Semin @ 2020-05-26 18:40 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Serge Semin, Alexey Malahov, Thomas Bogendoerfer, Paul Burton,
Ralf Baechle, Andy Shevchenko, Mika Westerberg, Wolfram Sang,
Rob Herring, Frank Rowand, linux-mips, devicetree, Wolfram Sang,
Jean Delvare, Krzysztof Kozlowski, Max Staudt, Stefan Roese,
linux-i2c, linux-kernel
In-Reply-To: <f01b3082-082c-8ce9-d0f7-f9ff952a37bf@linux.intel.com>
On Mon, May 25, 2020 at 04:01:26PM +0300, Jarkko Nikula wrote:
> On 5/21/20 5:22 AM, Serge Semin wrote:
> > On Wed, May 20, 2020 at 03:16:14PM +0300, Jarkko Nikula wrote:
> > > On 5/10/20 12:50 PM, 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. Lets move the
> > > > config definition under the if-I2C_DESIGNWARE_PLATFORM clause. 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.
> > > >
> > > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > > > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > > > Cc: Paul Burton <paulburton@kernel.org>
> > > > Cc: Ralf Baechle <ralf@linux-mips.org>
> > > > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > Cc: Wolfram Sang <wsa@the-dreams.de>
> > > > Cc: Rob Herring <robh+dt@kernel.org>
> > > > Cc: Frank Rowand <frowand.list@gmail.com>
> > > > Cc: linux-mips@vger.kernel.org
> > > > Cc: devicetree@vger.kernel.org
> > > > ---
> > > > drivers/i2c/busses/Kconfig | 30 +++++++++++++++++-------------
> > > > 1 file changed, 17 insertions(+), 13 deletions(-)
> > > >
> > > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > > > index 368aa64e9266..ed6927c4c540 100644
> > > > --- a/drivers/i2c/busses/Kconfig
> > > > +++ b/drivers/i2c/busses/Kconfig
> > > > @@ -530,8 +530,8 @@ config I2C_DESIGNWARE_CORE
> > > > config I2C_DESIGNWARE_PLATFORM
> > > > tristate "Synopsys DesignWare Platform"
> > > > - select I2C_DESIGNWARE_CORE
> > > > depends on (ACPI && COMMON_CLK) || !ACPI
> > > > + select I2C_DESIGNWARE_CORE
> > > > help
> > > > If you say yes to this option, support will be included for the
> > > > Synopsys DesignWare I2C adapter.
> > > > @@ -539,6 +539,22 @@ config I2C_DESIGNWARE_PLATFORM
> > > > This driver can also be built as a module. If so, the module
> > > > will be called i2c-designware-platform.
> > > > +if I2C_DESIGNWARE_PLATFORM
> > > > +
> > > > +config I2C_DESIGNWARE_BAYTRAIL
> > > > + bool "Intel Baytrail I2C semaphore support"
> > > > + depends on ACPI
> > > > + depends on (I2C_DESIGNWARE_PLATFORM=m && IOSF_MBI) || \
> > > > + (I2C_DESIGNWARE_PLATFORM=y && IOSF_MBI=y)
> > > > + help
> > > > + This driver enables managed host access to the PMIC I2C bus on select
> > > > + Intel BayTrail platforms using the X-Powers AXP288 PMIC. It allows
> > > > + the host to request uninterrupted access to the PMIC's I2C bus from
> > > > + the platform firmware controlling it. You should say Y if running on
> > > > + a BayTrail system using the AXP288.
> > > > +
> > > > +endif # I2C_DESIGNWARE_PLATFORM
> > > > +
> > >
> > > Is the added "if I2C_DESIGNWARE_PLATFORM" needed here? Should the "depends
> > > on" be enough?
> >
> > The idea was to add if-endif clause here for features possibly added sometime
> > in future. But using normal "depends on I2C_DESIGNWARE_PLATFORM" shall make
> > the config depicted as an indented sub-config as well. Would you like me to
> > remove the if-clause and use the depends on operator instead?
> >
> Yes, please remove it from this patch. Keeps this patch simpler and if some
> future feature needs it then that patch(set) is the right place to add it.
Agreed. I'll do this in v3.
-Sergey
>
> Jarkko
^ permalink raw reply
* [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Alan Stern, Andy Shevchenko, Corey Minyard, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
Greg Kroah-Hartman, Heikki Krogerus,
open list:DMA MAPPING HELPERS, Julien Grall,
moderated list:ARM PORT,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:USB SUBSYSTEM, Mark Brown, Oliver Neukum,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Saravana Kannan,
Stefano Stabellini, Suzuki K Poulose, Ulf Hansson, Wolfram Sang
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev->dma_pfn_map => dev->dma_pfn_offset_map
o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
o In device.h: s/const void */const struct dma_pfn_offset_region */
o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
dev->dma_pfn_offset_map is copied as well.
o Merged two of the DMA commits into one (Christoph).
Commit "arm: dma-mapping: Invoke dma offset func if needed":
o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
Other commits' changes:
o Removed need for carrying of_id var in priv (Nicolas)
o Commit message rewordings (Bjorn)
o Commit log messages filled to 75 chars (Bjorn)
o devm_reset_control_get_shared())
=> devm_reset_control_get_optional_shared (Philipp)
o Add call to reset_control_assert() in PCIe remove routines (Philipp)
v1:
This patchset expands the usefulness of the Broadcom Settop Box PCIe
controller by building upon the PCIe driver used currently by the
Raspbery Pi. Other forms of this patchset were submitted by me years
ago and not accepted; the major sticking point was the code required
for the DMA remapping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host controller. This is required for proper functionality
of the BrcmSTB PCIe controller and possibly some other devices.
[1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/
Jim Quinlan (14):
PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
ata: ahci_brcm: Fix use of BCM7216 reset controller
dt-bindings: PCI: Add bindings for more Brcmstb chips
PCI: brcmstb: Add bcm7278 reigister info
PCI: brcmstb: Add suspend and resume pm_ops
PCI: brcmstb: Add bcm7278 PERST support
PCI: brcmstb: Add control of rescal reset
of: Include a dev param in of_dma_get_range()
device core: Add ability to handle multiple dma offsets
arm: dma-mapping: Invoke dma offset func if needed
PCI: brcmstb: Set internal memory viewport sizes
PCI: brcmstb: Accommodate MSI for older chips
PCI: brcmstb: Set bus max burst size by chip type
PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list
.../bindings/pci/brcm,stb-pcie.yaml | 40 +-
arch/arm/include/asm/dma-mapping.h | 13 +-
drivers/ata/ahci_brcm.c | 14 +-
drivers/of/address.c | 69 ++-
drivers/of/device.c | 2 +-
drivers/of/of_private.h | 8 +-
drivers/pci/controller/Kconfig | 3 +-
drivers/pci/controller/pcie-brcmstb.c | 408 +++++++++++++++---
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 +
14 files changed, 559 insertions(+), 83 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v2 08/14] of: Include a dev param in of_dma_get_range()
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <20200526191303.1492-1-james.quinlan@broadcom.com>
Currently there is only one caller of of_dma_get_range(). A struct device
*dev param is needed For implementing multiple dma offsets. This function
will still work if dev == NULL.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/of/address.c | 4 +++-
drivers/of/device.c | 2 +-
drivers/of/of_private.h | 8 ++++----
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8eea3f6e29a4..96d8cfb14a60 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -920,6 +920,7 @@ EXPORT_SYMBOL(of_io_request_and_map);
/**
* of_dma_get_range - Get DMA range info
+ * @dev: device pointer; only needed for a corner case.
* @np: device node to get DMA range info
* @dma_addr: pointer to store initial DMA address of DMA range
* @paddr: pointer to store initial CPU address of DMA range
@@ -935,7 +936,8 @@ EXPORT_SYMBOL(of_io_request_and_map);
* It returns -ENODEV if "dma-ranges" property was not found
* for this device in DT.
*/
-int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
+ u64 *paddr, u64 *size)
{
struct device_node *node = of_node_get(np);
const __be32 *ranges = NULL;
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 27203bfd0b22..ef6a741f9f0b 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -95,7 +95,7 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
const struct iommu_ops *iommu;
u64 mask, end;
- ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ ret = of_dma_get_range(dev, np, &dma_addr, &paddr, &size);
if (ret < 0) {
/*
* For legacy reasons, we have to assume some devices need
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index edc682249c00..7a83d3a81ab6 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -158,11 +158,11 @@ extern int of_bus_n_addr_cells(struct device_node *np);
extern int of_bus_n_size_cells(struct device_node *np);
#ifdef CONFIG_OF_ADDRESS
-extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size);
+extern int of_dma_get_range(struct device *dev, struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size);
#else
-static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size)
+static inline int of_dma_get_range(struct device *dev, struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size)
{
return -ENODEV;
}
--
2.17.1
^ permalink raw reply related
* [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: 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: <20200526191303.1492-1-james.quinlan@broadcom.com>
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(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 96d8cfb14a60..a01afffcde7d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -918,6 +918,47 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
}
EXPORT_SYMBOL(of_io_request_and_map);
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+static int attach_dma_pfn_offset_map(struct device *dev,
+ struct device_node *node, int num_ranges)
+{
+ struct of_range_parser parser;
+ struct of_range range;
+ size_t r_size = (num_ranges + 1)
+ * sizeof(struct dma_pfn_offset_region);
+ struct dma_pfn_offset_region *r;
+
+ r = devm_kzalloc(dev, r_size, GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+ dev->dma_pfn_offset_map = r;
+ of_dma_range_parser_init(&parser, node);
+
+ /*
+ * Record all info for DMA ranges array. We could
+ * just use the of_range struct, but if we did that it
+ * would require more calculations for phys_to_dma and
+ * dma_to_phys conversions.
+ */
+ for_each_of_range(&parser, &range) {
+ r->cpu_beg = range.cpu_addr;
+ r->cpu_end = r->cpu_beg + range.size;
+ r->dma_beg = range.bus_addr;
+ r->dma_end = r->dma_beg + range.size;
+ r->pfn_offset = PFN_DOWN(range.cpu_addr)
+ - PFN_DOWN(range.bus_addr);
+ r++;
+ }
+ return 0;
+}
+#else
+static int attach_dma_pfn_offset_map(struct device *dev,
+ struct device_node *node, int num_ranges)
+{
+ return 0;
+}
+#endif
+
/**
* of_dma_get_range - Get DMA range info
* @dev: device pointer; only needed for a corner case.
@@ -947,6 +988,8 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
struct of_range_parser parser;
struct of_range range;
u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
+ bool dma_multi_pfn_offset = false;
+ int num_ranges = 0;
while (node) {
ranges = of_get_property(node, "dma-ranges", &len);
@@ -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;
+ }
+ dma_multi_pfn_offset = true;
}
dma_offset = range.cpu_addr - range.bus_addr;
@@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
dma_end = range.bus_addr + range.size;
}
+ if (dma_multi_pfn_offset) {
+ dma_offset = 0;
+ ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
+ if (ret)
+ return ret;
+ }
+
if (dma_start >= dma_end) {
ret = -EINVAL;
pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 6197938dcc2d..aaa3e58f5eb4 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int configuration)
*/
intf->dev.dma_mask = dev->dev.dma_mask;
intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
+#endif
INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
intf->minor = -1;
device_initialize(&intf->dev);
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index f16c26dc079d..d2ed4d90e56e 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
*/
dev->dev.dma_mask = bus->sysdev->dma_mask;
dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
+#endif
set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
dev->state = USB_STATE_ATTACHED;
dev->lpm_disable_count = 1;
diff --git a/include/linux/device.h b/include/linux/device.h
index ac8e37cd716a..67a240ad4fc5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -493,6 +493,8 @@ struct dev_links_info {
* @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
* DMA limit than the device itself supports.
* @dma_pfn_offset: offset of DMA memory range relatively of RAM
+ * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are multiple
+ * pfn offsets for multiple dma-ranges.
* @dma_parms: A low level driver may set these to teach IOMMU code about
* segment limitations.
* @dma_pools: Dma pools (if dma'ble device).
@@ -578,7 +580,13 @@ struct device {
allocations such descriptors. */
u64 bus_dma_limit; /* upstream dma constraint */
unsigned long dma_pfn_offset;
-
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ const struct dma_pfn_offset_region *dma_pfn_offset_map;
+ /* Like dma_pfn_offset, but for
+ * the unlikely case of multiple
+ * offsets. If non-null, dma_pfn_offset
+ * will be set to 0. */
+#endif
struct device_dma_parameters *dma_parms;
struct list_head dma_pools; /* dma pools (if dma'ble) */
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 24b8684aa21d..03110a57eabc 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -14,15 +14,21 @@ extern unsigned int zone_dma_bits;
static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
{
dma_addr_t dev_addr = (dma_addr_t)paddr;
+ /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
+ unsigned long dma_pfn_offset = dev->dma_pfn_offset
+ + dma_pfn_offset_from_phys_addr(dev, paddr);
- return dev_addr - ((dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
+ return dev_addr - ((dma_addr_t)dma_pfn_offset << PAGE_SHIFT);
}
static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
{
phys_addr_t paddr = (phys_addr_t)dev_addr;
+ /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
+ unsigned long dma_pfn_offset = dev->dma_pfn_offset
+ + dma_pfn_offset_from_dma_addr(dev, paddr);
- return paddr + ((phys_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
+ return paddr + ((phys_addr_t)dma_pfn_offset << PAGE_SHIFT);
}
#endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 330ad58fbf4d..91940bba2229 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -256,6 +256,52 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
size_t dma_direct_max_mapping_size(struct device *dev);
#ifdef CONFIG_HAS_DMA
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+struct dma_pfn_offset_region {
+ phys_addr_t cpu_beg;
+ phys_addr_t cpu_end;
+ dma_addr_t dma_beg;
+ dma_addr_t dma_end;
+ unsigned long pfn_offset;
+};
+
+static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
+ dma_addr_t dma_addr)
+{
+ const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
+
+ if (m)
+ for (; m->cpu_end; m++)
+ if (dma_addr >= m->dma_beg && dma_addr < m->dma_end)
+ return m->pfn_offset;
+ return 0;
+}
+
+static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
+ phys_addr_t paddr)
+{
+ const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
+
+ if (m)
+ for (; m->cpu_end; m++)
+ if (paddr >= m->cpu_beg && paddr < m->cpu_end)
+ return m->pfn_offset;
+ return 0;
+}
+#else /* CONFIG_DMA_PFN_OFFSET_MAP */
+static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
+ dma_addr_t dma_addr)
+{
+ return 0;
+}
+
+static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
+ phys_addr_t paddr)
+{
+ return 0;
+}
+#endif /* CONFIG_DMA_PFN_OFFSET_MAP */
+
#include <asm/dma-mapping.h>
static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 4c103a24e380..ceb7e5e8f501 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -195,3 +195,16 @@ config DMA_API_DEBUG_SG
is technically out-of-spec.
If unsure, say N.
+
+config DMA_PFN_OFFSET_MAP
+ bool "Uses a DMA range map to calculate PFN offset"
+ depends on PCIE_BRCMSTB
+ default n
+ help
+ Some devices have a dma-range that gets converted to
+ a dev->dma_pfn_offset value. This option is for the
+ atypical case of there being multiple dma-ranges requiring
+ multiple pfn offsets, which are selected from when
+ converting to phys to dma and vice versa.
+
+ If unsure, say N.
--
2.17.1
^ permalink raw reply related
* [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Florian Fainelli, Bjorn Helgaas, Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20200526191303.1492-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
- Add compatible strings for three more Broadcom STB chips: 7278, 7216,
7211 (STB version of RPi4).
- add new property 'brcm,scb-sizes'
- add new property 'resets'
- add new property 'reset-names'
- allow 'ranges' and 'dma-ranges' to have more than one item and update
the example to show this.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
.../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 8680a0f86c5a..66a7df45983d 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -14,7 +14,13 @@ allOf:
properties:
compatible:
- const: brcm,bcm2711-pcie # The Raspberry Pi 4
+ items:
+ - enum:
+ - brcm,bcm2711-pcie # The Raspberry Pi 4
+ - brcm,bcm7211-pcie # Broadcom STB version of RPi4
+ - brcm,bcm7278-pcie # Broadcom 7278 Arm
+ - brcm,bcm7216-pcie # Broadcom 7216 Arm
+ - brcm,bcm7445-pcie # Broadcom 7445 Arm
reg:
maxItems: 1
@@ -34,10 +40,12 @@ properties:
- const: msi
ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
dma-ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 6
clocks:
maxItems: 1
@@ -58,8 +66,30 @@ properties:
aspm-no-l0s: true
+ resets:
+ description: for "brcm,bcm7216-pcie", must be a valid reset
+ phandle pointing to the RESCAL reset controller provider node.
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ reset-names:
+ items:
+ - const: rescal
+
+ brcm,scb-sizes:
+ description: (u32, u32) tuple giving the 64bit PCIe memory
+ viewport size of a memory controller. There may be up to
+ three controllers, and each size must be a power of two
+ with a size greater or equal to the amount of memory the
+ controller supports.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - items:
+ minItems: 2
+ maxItems: 6
+
required:
- reg
+ - ranges
- dma-ranges
- "#interrupt-cells"
- interrupts
@@ -93,7 +123,9 @@ examples:
msi-parent = <&pcie0>;
msi-controller;
ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
- dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
+ dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
+ <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
brcm,enable-ssc;
+ brcm,scb-sizes = <0x0 0x80000000 0x0 0x80000000>;
};
};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 1/1] dt-bindings: MIPS: Document Ingenic SoCs binding.
From: Paul Cercueil @ 2020-05-26 19:10 UTC (permalink / raw)
To: 周琰杰
Cc: linux-mips, linux-kernel, devicetree, robh+dt, tsbogend, hns,
paul, dongsheng.qiu, aric.pzqi, sernia.zhou, zhenwenjin
In-Reply-To: <20200526170722.17206-2-zhouyanjie@wanyeetech.com>
Hi Zhou,
Le mer. 27 mai 2020 à 1:07, 周琰杰 (Zhou Yanjie)
<zhouyanjie@wanyeetech.com> a écrit :
> Document the available properties for the SoC root node and the
> CPU nodes of the devicetree for the Ingenic XBurst SoCs.
>
> Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
> Tested-by: Paul Boddie <paul@boddie.org.uk>
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
> .../bindings/mips/ingenic/ingenic,cpu.yaml | 57
> ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
> b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
> new file mode 100644
> index 000000000000..afb02071a756
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mips/ingenic/ingenic,cpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bindings for Ingenic XBurst family CPUs
> +
> +maintainers:
> + - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> +
> +description:
> + Ingenic XBurst family CPUs shall have the following properties.
> +
> +properties:
> + compatible:
> + oneOf:
> +
> + - description: Ingenic XBurst®1 CPU Cores
> + items:
Strip the 'items', put the enum directly.
> + enum:
> + - ingenic,xburst-mxu1.0
> + - ingenic,xburst-fpu1.0-mxu1.1
> + - ingenic,xburst-fpu2.0-mxu2.0
> +
> + - description: Ingenic XBurst®2 CPU Cores
> + items:
Same here.
> + enum:
> + - ingenic,xburst2-fpu2.1-mxu2.1-smt
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - device_type
> + - compatible
> + - reg
device_type is not in the list of your properties.
Also, I think you need a clock in there.
-Paul
> +
> +examples:
> + - |
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "ingenic,xburst-fpu1.0-mxu1.1";
> + reg = <0>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "ingenic,xburst-fpu1.0-mxu1.1";
> + reg = <1>;
> + };
> + };
> +...
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v8 4/6] dt-bindings: MIPS: Document Ingenic SoCs binding.
From: Rob Herring @ 2020-05-26 19:29 UTC (permalink / raw)
To: 周琰杰 (Zhou Yanjie)
Cc: linux-mips, linux-kernel, devicetree, tsbogend, paulburton,
jiaxun.yang, chenhc, tglx, daniel.lezcano, keescook, paul, krzk,
hns, ebiederm, dongsheng.qiu, yanfei.li, rick.tyliu, sernia.zhou,
zhenwenjin
In-Reply-To: <1589898923-60048-6-git-send-email-zhouyanjie@wanyeetech.com>
On Tue, May 19, 2020 at 10:35:21PM +0800, 周琰杰 (Zhou Yanjie) wrote:
> Document the available properties for the SoC root node and the
> CPU nodes of the devicetree for the Ingenic XBurst SoCs.
>
> Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
> Tested-by: Paul Boddie <paul@boddie.org.uk>
> Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> ---
>
> Notes:
> v1->v2:
> Change the two Document from txt to yaml.
>
> v2->v3:
> Fix formatting errors.
>
> v3->v4:
> Fix bugs in the two yaml files.
>
> v4->v5:
> No change.
>
> v5->v6:
> Rewrite the two yaml files.
>
> v6->v7:
> 1.Update compatible strings in "ingenic,cpu.yaml".
> 2.Fix formatting errors, and enum for compatible strings.
> 3.Remove unnecessary "ingenic,soc.yaml".
>
> v7->v8:
> No change.
>
> .../bindings/mips/ingenic/ingenic,cpu.yaml | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
>
> diff --git a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
> new file mode 100644
> index 00000000..afb0207
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml
> @@ -0,0 +1,57 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mips/ingenic/ingenic,cpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bindings for Ingenic XBurst family CPUs
> +
> +maintainers:
> + - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
> +
> +description:
> + Ingenic XBurst family CPUs shall have the following properties.
> +
> +properties:
> + compatible:
> + oneOf:
> +
> + - description: Ingenic XBurst®1 CPU Cores
> + items:
This is a single compatible string, right? If so, drop items.
> + enum:
> + - ingenic,xburst-mxu1.0
> + - ingenic,xburst-fpu1.0-mxu1.1
> + - ingenic,xburst-fpu2.0-mxu2.0
> +
> + - description: Ingenic XBurst®2 CPU Cores
> + items:
> + enum:
> + - ingenic,xburst2-fpu2.1-mxu2.1-smt
Just: const: ingenic,xburst2-fpu2.1-mxu2.1-smt
Continuing to append CPU features isn't going to scale well. Does
'xburst2' imply certain features? If so, not really any need to have
them be explicit.
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - device_type
> + - compatible
> + - reg
> +
> +examples:
> + - |
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "ingenic,xburst-fpu1.0-mxu1.1";
> + reg = <0>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "ingenic,xburst-fpu1.0-mxu1.1";
> + reg = <1>;
> + };
> + };
> +...
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Ezequiel Garcia @ 2020-05-26 19:45 UTC (permalink / raw)
To: Geert Uytterhoeven, Laurent Pinchart
Cc: Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Rob Herring, Wei Xu
In-Reply-To: <CAMuHMdUV+qHpfLfbYwQwPXAUsh7HXvonUNWNh-SeTC-RpHwrog@mail.gmail.com>
On Tue, 2020-05-26 at 12:39 +0200, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Tue, May 26, 2020 at 12:12 PM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart 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).
> > >
> > > I do my best to avoid introducing regressions when the binding conversions
> > > go upstream.
> >
> > Please note that we're not talking about runtime regressions, as drivers
> > are not updated. It's "only" dtbs_check that would produce new errors.
>
> Exactly. I was talking about "make dtbs_check" regressions, too.
>
A "make dtbs_check" failure, due to some foo.dts that fails the check
due to a correct YAML conversion, can't be considered a regression.
I strongly agree with Laurent here, we want to convert the bindings
to YAML and we can't consider non-compliant DT sources to prevent them.
Regards,
Ezequiel
^ permalink raw reply
* [RESEND v5 01/21] mtd: Fix typo in mtd_ooblayout_set_databytes() description
From: Miquel Raynal @ 2020-05-26 19:56 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Rob Herring, Mark Rutland, devicetree, Boris Brezillon,
Miquel Raynal
In-Reply-To: <20200526195633.11543-1-miquel.raynal@bootlin.com>
Fix a probable copy/paste error: the function works like
mtd_ooblayout_set_bytes(), not *_get_bytes().
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
drivers/mtd/mtdcore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 50437b4ffe76..8c4dcfa49e35 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1800,7 +1800,7 @@ EXPORT_SYMBOL_GPL(mtd_ooblayout_get_databytes);
* @start: first ECC byte to set
* @nbytes: number of ECC bytes to set
*
- * Works like mtd_ooblayout_get_bytes(), except it acts on free bytes.
+ * Works like mtd_ooblayout_set_bytes(), except it acts on free bytes.
*
* Returns zero on success, a negative error code otherwise.
*/
--
2.20.1
^ permalink raw reply related
* [RESEND v5 00/21] Introduce the generic ECC engine abstraction
From: Miquel Raynal @ 2020-05-26 19:56 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Rob Herring, Mark Rutland, devicetree, Boris Brezillon,
Miquel Raynal
RESENDING: I forgot to add Rob/the DT ML in copy while I was expecting
his ack.
As of today, only raw NAND controllers used to feature an integrated
ECC engine and so controller drivers always embedded some code to
enable/disable the correction.
This statement is no longer correct as SPI-NAND devices might not
embed an on-die ECC engine and must make use of an external ECC
engine. We figured there are three possible situations for (generic)
NAND devices: either the engine is 'on-die' (most of the SPI-NANDs, a
few raw NANDs), or the engine is part of the host controller (most raw
NANDs), or the engine may be external (SPI controllers might feature
an hardware ECC engine, otherwise software correction can also be
used).
To solve this situation, this is a proposal on how to make things
work. We want to create an ECC engine object which has simple
callbacks:
* init/cleanup its context
* prepare an I/O operation
* finish an I/O operation
Details about what is going to happen in these callbacks is described
in drivers/mtd/nand/ecc/engine.c.
The logic in this series is:
1/ Use the generic NAND core for all NAND devices (raw and SPI).
2/ Create the ECC engine interface in drivers/mtd/nand/ecc.c
3/ Move code in driver/mtd/nand/ecc.c
4/ Make both software engines (Hamming and BCH) generic, move them in
the ecc/ directory, clean them a bit and instantiate ECC
engines. Write raw NAND helpers to use these two new engines.
5/ Isolate SPI-NAND on-die ECC engine in its own driver.
6/ Make use from the SPI-NAND layer of all the ECC engines listed
above (on user request, people can now make use of soft BCH if they
don't have an ECC-engine).
7/ Extend the logic to hardware external engines. A proposal of a
driver for Macronix external ECC engine will follow in another
series.
This work is now almost ready, the next steps are:
1/ Migrate the raw NAND core to make a proper use of these ECC
engines.
2/ Deprecate in the raw NAND subsystem the interfaces used until now
(I expect we should get rid of a lot of boilerplate).
Thanks,
Miquèl
Changes in v5
=============
* Rebased on top of nand/next
* Avoided a fallthrough situation in commit:
mtd: rawnand: Separate the ECC engine type and the OOB placement
* Fixed an of_dev_put() build issue due to a missing dummy helper.
* Extracted a patch that deserved to be merged quickly.
* Fixed a few issues reported by robots.
Changes in v4
=============
* Rebased on top of a recent kernel version.
* Added Boris' reviewed-by.
* Added Maxime's Acked-by tag.
* Added the missing of_device.h header to ecc.c.
* Corrected a 'minimum' comparison by using min_t.
* Updated the new Macronix raw NAND controller driver by using the new
(ECC related) function names.
* Fixed a function call in ndfc.c.
* Update brcmnand.c file to fit new enumerations and structures (due
to recent Kamal's changes).
* Force sm_ftl to depends on the Hamming engine, because by just
selecting it the ECC code would be embedded in the NAND core and the
NAND core might not be compiled in with sm_ftl.
* Fixed a structure field name that I previously added in davinci
platform data.
* Moved the oob_first placement scheme to Davinci driver. Removed any
occurence of it out of the driver (unused).
* Simplify structure names as proposed by Boris.
* Change enumeration/string names about ECC engine
providers/placements.
* Change the logic in the of_get_nand_ecc_* helpers to ensure backward
compatibility.
* Use enums intead of unsigned integers in the core when referring to
ECC engine type, placement and algorithm.
* Add nand-ecc-placement DT property.
* Deprecate hw_syndrome.
* Deprecate nand-ecc-mode in favor of nand-ecc-provider.
* Fixed a typo in the Macronix ECC driver, where I made a copy/paste
error which I haven't spotted because it is located in a macro only
compiled when building the driver as a module (name of the of_ids
was prefixed marvell_nfc instead of mxic_ecc).
* Simplified the ECC engine API by dropping the useless oobbuf
parameter. Instead, ECC engine drivers are supposed to provide a
spare OOB buffer if none is provided. Updated the three existing
engines.
* Fixed BCH software engine with the help of Mason from Macronix.
* Added a mechanism called "tweaking req" to change the SPI-NAND
requests and ensure they always contain the right amount of data/OOB
needed for the ECC engine to work properly.
Changes in v3
=============
* Added Boris' Reviewed-by tags.
* Added a kernel doc header on the nand_page_io_req enumeration.
* Added support for HW engines.
* Droped the patch clarifying the value of the first entry in
enumerations (which is always 0).
* Rename the nand_ecc_conf structure as nand_ecc_props because the
_conf suffix implies that it is possible to edit it, while in some
cases (eg. on-die ECC) there is nothing to tweak.
* Smoother introduction of the ECC engine abstraction.
* Renamed the ECC engine module nand_ecc_engine.ko.
* Moved all the ECC files into drivers/mtd/nand/. Forgot the ecc/
subdirectory.
* Added a new series to drop the ECC mode enumeration wich mixes the
provider (none, hw, sw, on-die) and the OOB placement (first,
syndrome).
* Various typos fixed.
* Added a few patches to fix bugs found in SPI-NAND/mtdchar.c.
* Introduced the external hardware ECC engine boilerplate.
Changes in v2
=============
* SPDX license identifiers for soft BCH and Hamming: the license macro
was right, "GPL" means "GPLv2 or higher", so do not change this
portion. Also update the commit messages to fit the actual change.
* Do not compile-in the NAND core by default, do it only for raw
NAND. Remove the dependencies on CONFIG_MTD in a different
patch. Also, keep an extra level of hierarchy in Kconfig for the
NAND bits by adding a menu instead of a config.
* Moved the standard OOB layouts in the ecc/engine.c driver instead of
in the NAND core.
* Used the nand_ecc_ prefix in most of the engines functions instead
of just ecc_, which is now reserved for bare helpers. Get rid of the
__ecc prefix.
* In the sunxi NAND controller driver: moved the ECC structure from
sunxi_nfc to sunxi_nand_chip as the ECC engine is per-chip and not
per controller.
* Software Hamming ECC engine is only enabled by default if raw NAND
is also enabled. NDFC now selects the software Hamming ECC engine
(instead of depending on it).
* Mention in software BCH and Hamming Kconfig entries that booting
from NAND is very likely to fail if the user selects these symbols
as modules.
* Added Boris Reviewed-by tag on the SPI-NAND typo fixing patch.
* Renamed the "mode" into a "provider" entry in the ECC configuration
structures.
* Moved the "total" entry of the ECC configuration directly in the
context structure (should probably not be public but let's keep it
as is for now).
* Split the generic ECC engine introduction into smaller patches to do
some renaming aside.
* Drop the "maximize" entry in the ECC engine configuration structure,
keep using a flag like before.
* Canceled the move of the SPI-NAND specific ECC engine out of the
core file.
* Amended the root ECC structures to have three nand_ecc_conf
structures: one for the defaults, one for the chip requirements, one
for the user desires.
* Created a *ondie_engine pointer in the nand_ecc structure to save
the on-die ECC engine, if any. For instance, saving a reference to
this engine is done by the SPI-NAND core.
* Dropped the SPI-NAND flag that was used to distinguish between NAND
flavors from the NAND core, it should not be needed anymore.
* Added an helper in the NAND core to put a reference on an ECC
engine. This will be used by the hardware engines only.
* Renamed the files ecc/sw-{bch,hamming}.c and their headers
include/linux/mtd/nand-ecc-sw-{bch,hamming}-engine.h.
* Created a MTD_NAND_ECC invisible Kconfig symbol.
* Added plenty of missing EXPORT_SYMBOL{,_GPL}().
* Minor modifications so that everything still compiles even when
modules and built-in drivers are mixed in Kconfig in the whole NAND
directory.
Miquel Raynal (21):
mtd: Fix typo in mtd_ooblayout_set_databytes() description
mtd: rawnand: Avoid a typedef
mtd: rawnand: Drop OOB_FIRST placement scheme
dt-bindings: mtd: Deprecate OOB_FIRST mode
mtd: rawnand: Return an enum from of_get_nand_ecc_algo()
mtd: rawnand: Add an invalid ECC mode to discriminate with valid ones
mtd: rawnand: Create a new enumeration to describe OOB placement
mtd: rawnand: Separate the ECC engine type and the OOB placement
mtd: rawnand: Create a new enumeration to describe properly ECC types
mtd: rawnand: Create a helper to retrieve the ECC placement
mtd: rawnand: Use the new ECC engine type enumeration
mtd: rawnand: Deprecate nand-ecc-mode in favor of nand-ecc-provider
mtd: rawnand: Drop the legacy ECC type enumeration
dt-bindings: mtd: Add the nand-ecc-placement property
dt-bindings: mtd: Deprecate hw_syndrome from the ECC modes
dt-bindings: mtd: Deprecate the nand-ecc-mode property
mtd: nand: Move nand_device forward declaration to the top
mtd: nand: Add an extra level in the Kconfig hierarchy
mtd: nand: Drop useless 'depends on' in Kconfig
mtd: nand: Add a NAND page I/O request type
mtd: nand: Rename a core structure
.../devicetree/bindings/mtd/atmel-nand.txt | 3 +-
.../bindings/mtd/nand-controller.yaml | 27 +-
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
arch/arm/mach-davinci/board-da850-evm.c | 2 +-
arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
arch/arm/mach-davinci/board-dm355-leopard.c | 3 +-
arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-davinci/board-mityomapl138.c | 2 +-
arch/arm/mach-davinci/board-neuros-osd2.c | 2 +-
arch/arm/mach-davinci/board-omapl138-hawk.c | 2 +-
arch/arm/mach-s3c24xx/common-smdk.c | 2 +-
arch/arm/mach-s3c24xx/mach-anubis.c | 2 +-
arch/arm/mach-s3c24xx/mach-at2440evb.c | 2 +-
arch/arm/mach-s3c24xx/mach-bast.c | 2 +-
arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
arch/arm/mach-s3c24xx/mach-mini2440.c | 2 +-
arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
arch/arm/mach-s3c24xx/mach-qt2410.c | 2 +-
arch/arm/mach-s3c24xx/mach-rx1950.c | 2 +-
arch/arm/mach-s3c24xx/mach-rx3715.c | 2 +-
arch/arm/mach-s3c24xx/mach-vstms.c | 2 +-
arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
arch/arm/mach-s3c64xx/mach-mini6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-real6410.c | 2 +-
drivers/mtd/mtdcore.c | 2 +-
drivers/mtd/nand/Kconfig | 5 +
drivers/mtd/nand/onenand/Kconfig | 1 -
drivers/mtd/nand/raw/Kconfig | 1 -
drivers/mtd/nand/raw/ams-delta.c | 2 +-
drivers/mtd/nand/raw/atmel/nand-controller.c | 14 +-
drivers/mtd/nand/raw/au1550nd.c | 2 +-
.../mtd/nand/raw/bcm47xxnflash/ops_bcm4706.c | 3 +-
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 8 +-
.../mtd/nand/raw/cadence-nand-controller.c | 4 +-
drivers/mtd/nand/raw/cafe_nand.c | 3 +-
drivers/mtd/nand/raw/cs553x_nand.c | 2 +-
drivers/mtd/nand/raw/davinci_nand.c | 153 +++++---
drivers/mtd/nand/raw/denali.c | 3 +-
drivers/mtd/nand/raw/diskonchip.c | 3 +-
drivers/mtd/nand/raw/fsl_elbc_nand.c | 18 +-
drivers/mtd/nand/raw/fsl_ifc_nand.c | 10 +-
drivers/mtd/nand/raw/fsl_upm.c | 2 +-
drivers/mtd/nand/raw/fsmc_nand.c | 12 +-
drivers/mtd/nand/raw/gpio.c | 2 +-
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 2 +-
drivers/mtd/nand/raw/hisi504_nand.c | 6 +-
.../mtd/nand/raw/ingenic/ingenic_nand_drv.c | 14 +-
drivers/mtd/nand/raw/lpc32xx_mlc.c | 2 +-
drivers/mtd/nand/raw/lpc32xx_slc.c | 3 +-
drivers/mtd/nand/raw/marvell_nand.c | 17 +-
drivers/mtd/nand/raw/meson_nand.c | 2 +-
drivers/mtd/nand/raw/mpc5121_nfc.c | 2 +-
drivers/mtd/nand/raw/mtk_nand.c | 6 +-
drivers/mtd/nand/raw/mxc_nand.c | 23 +-
drivers/mtd/nand/raw/nand_base.c | 336 ++++++++----------
drivers/mtd/nand/raw/nand_micron.c | 4 +-
drivers/mtd/nand/raw/nand_toshiba.c | 3 +-
drivers/mtd/nand/raw/nandsim.c | 4 +-
drivers/mtd/nand/raw/ndfc.c | 2 +-
drivers/mtd/nand/raw/omap2.c | 20 +-
drivers/mtd/nand/raw/orion_nand.c | 2 +-
drivers/mtd/nand/raw/pasemi_nand.c | 2 +-
drivers/mtd/nand/raw/plat_nand.c | 2 +-
drivers/mtd/nand/raw/qcom_nandc.c | 2 +-
drivers/mtd/nand/raw/r852.c | 3 +-
drivers/mtd/nand/raw/s3c2410.c | 16 +-
drivers/mtd/nand/raw/sh_flctl.c | 4 +-
drivers/mtd/nand/raw/sharpsl.c | 2 +-
drivers/mtd/nand/raw/socrates_nand.c | 3 +-
drivers/mtd/nand/raw/stm32_fmc2_nand.c | 9 +-
drivers/mtd/nand/raw/sunxi_nand.c | 18 +-
drivers/mtd/nand/raw/tango_nand.c | 2 +-
drivers/mtd/nand/raw/tegra_nand.c | 2 +-
drivers/mtd/nand/raw/tmio_nand.c | 2 +-
drivers/mtd/nand/raw/txx9ndfmc.c | 2 +-
drivers/mtd/nand/raw/vf610_nfc.c | 4 +-
drivers/mtd/nand/raw/xway_nand.c | 2 +-
drivers/mtd/nand/spi/core.c | 4 +-
include/linux/mtd/nand.h | 30 +-
include/linux/mtd/rawnand.h | 46 ++-
include/linux/mtd/spinand.h | 2 +-
include/linux/platform_data/mtd-davinci.h | 9 +-
.../linux/platform_data/mtd-nand-s3c2410.h | 2 +-
86 files changed, 528 insertions(+), 419 deletions(-)
--
2.20.1
^ permalink raw reply
* [RESEND v5 02/21] mtd: rawnand: Avoid a typedef
From: Miquel Raynal @ 2020-05-26 19:56 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd
Cc: Rob Herring, Mark Rutland, devicetree, Boris Brezillon,
Miquel Raynal
In-Reply-To: <20200526195633.11543-1-miquel.raynal@bootlin.com>
In new code, the use of typedef is discouraged. Turn this one in the
raw NAND core into a regular enumeration.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
---
drivers/mtd/nand/raw/nand_base.c | 4 ++--
include/linux/mtd/rawnand.h | 6 +++---
include/linux/platform_data/mtd-davinci.h | 2 +-
include/linux/platform_data/mtd-nand-s3c2410.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 384a9b2d1610..e2cdfbb45923 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5104,8 +5104,8 @@ static int of_get_nand_ecc_mode(struct device_node *np)
/*
* For backward compatibility we support few obsoleted values that don't
- * have their mappings into nand_ecc_modes_t anymore (they were merged
- * with other enums).
+ * have their mappings into the nand_ecc_mode enum anymore (they were
+ * merged with other enums).
*/
if (!strcasecmp(pm, "soft_bch"))
return NAND_ECC_SOFT;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 2804c13e5662..0911e845cced 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -83,14 +83,14 @@ struct nand_chip;
/*
* Constants for ECC_MODES
*/
-typedef enum {
+enum nand_ecc_mode {
NAND_ECC_NONE,
NAND_ECC_SOFT,
NAND_ECC_HW,
NAND_ECC_HW_SYNDROME,
NAND_ECC_HW_OOB_FIRST,
NAND_ECC_ON_DIE,
-} nand_ecc_modes_t;
+};
enum nand_ecc_algo {
NAND_ECC_UNKNOWN,
@@ -362,7 +362,7 @@ static const struct nand_ecc_caps __name = { \
* @write_oob: function to write chip OOB data
*/
struct nand_ecc_ctrl {
- nand_ecc_modes_t mode;
+ enum nand_ecc_mode mode;
enum nand_ecc_algo algo;
int steps;
int size;
diff --git a/include/linux/platform_data/mtd-davinci.h b/include/linux/platform_data/mtd-davinci.h
index 08e639e047e5..03e92c71b3fa 100644
--- a/include/linux/platform_data/mtd-davinci.h
+++ b/include/linux/platform_data/mtd-davinci.h
@@ -68,7 +68,7 @@ struct davinci_nand_pdata { /* platform_data */
* Newer ones also support 4-bit ECC, but are awkward
* using it with large page chips.
*/
- nand_ecc_modes_t ecc_mode;
+ enum nand_ecc_mode ecc_mode;
u8 ecc_bits;
/* e.g. NAND_BUSWIDTH_16 */
diff --git a/include/linux/platform_data/mtd-nand-s3c2410.h b/include/linux/platform_data/mtd-nand-s3c2410.h
index deb849bcf0ec..08675b16f9e1 100644
--- a/include/linux/platform_data/mtd-nand-s3c2410.h
+++ b/include/linux/platform_data/mtd-nand-s3c2410.h
@@ -49,7 +49,7 @@ struct s3c2410_platform_nand {
unsigned int ignore_unset_ecc:1;
- nand_ecc_modes_t ecc_mode;
+ enum nand_ecc_mode ecc_mode;
int nr_sets;
struct s3c2410_nand_set *sets;
--
2.20.1
^ permalink raw reply related
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