* Re: [PATCH v3 066/105] drm/vc4: txp: Turn the TXP into a CRTC of its own
From: Emil Velikov @ 2020-05-28 15:51 UTC (permalink / raw)
To: Maxime Ripard
Cc: LAKML, Tim Gover, Dave Stevenson, Linux-Kernel@Vger. Kernel. Org,
ML dri-devel, Eric Anholt, bcm-kernel-feedback-list,
linux-rpi-kernel, Phil Elwell, Nicolas Saenz Julienne
In-Reply-To: <e9bc87e240b62c80617ea7825144121a470a2d44.1590594512.git-series.maxime@cerno.tech>
Hi Maxime,
Have you considered splitting the series into several parts and
focusing on merging one at a time?
IIRC this the longest series _ever_ submitted to dri-devel, plus it
seems to be growing with each revision.
Due to the sheer volume, it's likely to miss various points - large or
small (like below).
On Thu, 28 May 2020 at 08:47, Maxime Ripard <maxime@cerno.tech> wrote:
> +static int vc4_txp_enable_vblank(struct drm_crtc *crtc)
> +{
> + return 0;
> +}
> +
> +static void vc4_txp_disable_vblank(struct drm_crtc *crtc) {}
> +
Core should handle if these are NULL, so the stubs should not be needed.
HTH
Emil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] net: ethernet: mtk-star-emac: use regmap bitops
From: Bartosz Golaszewski @ 2020-05-28 15:45 UTC (permalink / raw)
To: John Crispin, Sean Wang, Mark Lee, David S . Miller,
Jakub Kicinski, Matthias Brugger, Mark Brown
Cc: Stephane Le Provost, Bartosz Golaszewski, netdev, linux-kernel,
Fabien Parent, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
In-Reply-To: <20200528154503.26304-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Shrink the code visually by replacing regmap_update_bits() with
appropriate regmap bit operations where applicable.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/net/ethernet/mediatek/mtk_star_emac.c | 80 ++++++++-----------
1 file changed, 35 insertions(+), 45 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
index 8596ca0e60eb..326ac792a4a0 100644
--- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
+++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
@@ -413,8 +413,8 @@ static void mtk_star_dma_unmap_tx(struct mtk_star_priv *priv,
static void mtk_star_nic_disable_pd(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_MAC_CFG,
- MTK_STAR_BIT_MAC_CFG_NIC_PD, 0);
+ regmap_clear_bits(priv->regs, MTK_STAR_REG_MAC_CFG,
+ MTK_STAR_BIT_MAC_CFG_NIC_PD);
}
/* Unmask the three interrupts we care about, mask all others. */
@@ -434,41 +434,38 @@ static void mtk_star_intr_disable(struct mtk_star_priv *priv)
static void mtk_star_intr_enable_tx(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_INT_MASK,
- MTK_STAR_BIT_INT_STS_TNTC, 0);
+ regmap_clear_bits(priv->regs, MTK_STAR_REG_INT_MASK,
+ MTK_STAR_BIT_INT_STS_TNTC);
}
static void mtk_star_intr_enable_rx(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_INT_MASK,
- MTK_STAR_BIT_INT_STS_FNRC, 0);
+ regmap_clear_bits(priv->regs, MTK_STAR_REG_INT_MASK,
+ MTK_STAR_BIT_INT_STS_FNRC);
}
static void mtk_star_intr_enable_stats(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_INT_MASK,
- MTK_STAR_REG_INT_STS_MIB_CNT_TH, 0);
+ regmap_clear_bits(priv->regs, MTK_STAR_REG_INT_MASK,
+ MTK_STAR_REG_INT_STS_MIB_CNT_TH);
}
static void mtk_star_intr_disable_tx(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_INT_MASK,
- MTK_STAR_BIT_INT_STS_TNTC,
- MTK_STAR_BIT_INT_STS_TNTC);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_INT_MASK,
+ MTK_STAR_BIT_INT_STS_TNTC);
}
static void mtk_star_intr_disable_rx(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_INT_MASK,
- MTK_STAR_BIT_INT_STS_FNRC,
- MTK_STAR_BIT_INT_STS_FNRC);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_INT_MASK,
+ MTK_STAR_BIT_INT_STS_FNRC);
}
static void mtk_star_intr_disable_stats(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_INT_MASK,
- MTK_STAR_REG_INT_STS_MIB_CNT_TH,
- MTK_STAR_REG_INT_STS_MIB_CNT_TH);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_INT_MASK,
+ MTK_STAR_REG_INT_STS_MIB_CNT_TH);
}
static unsigned int mtk_star_intr_read(struct mtk_star_priv *priv)
@@ -524,12 +521,10 @@ static void mtk_star_dma_init(struct mtk_star_priv *priv)
static void mtk_star_dma_start(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_TX_DMA_CTRL,
- MTK_STAR_BIT_TX_DMA_CTRL_START,
- MTK_STAR_BIT_TX_DMA_CTRL_START);
- regmap_update_bits(priv->regs, MTK_STAR_REG_RX_DMA_CTRL,
- MTK_STAR_BIT_RX_DMA_CTRL_START,
- MTK_STAR_BIT_RX_DMA_CTRL_START);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_TX_DMA_CTRL,
+ MTK_STAR_BIT_TX_DMA_CTRL_START);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_RX_DMA_CTRL,
+ MTK_STAR_BIT_RX_DMA_CTRL_START);
}
static void mtk_star_dma_stop(struct mtk_star_priv *priv)
@@ -553,16 +548,14 @@ static void mtk_star_dma_disable(struct mtk_star_priv *priv)
static void mtk_star_dma_resume_rx(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_RX_DMA_CTRL,
- MTK_STAR_BIT_RX_DMA_CTRL_RESUME,
- MTK_STAR_BIT_RX_DMA_CTRL_RESUME);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_RX_DMA_CTRL,
+ MTK_STAR_BIT_RX_DMA_CTRL_RESUME);
}
static void mtk_star_dma_resume_tx(struct mtk_star_priv *priv)
{
- regmap_update_bits(priv->regs, MTK_STAR_REG_TX_DMA_CTRL,
- MTK_STAR_BIT_TX_DMA_CTRL_RESUME,
- MTK_STAR_BIT_TX_DMA_CTRL_RESUME);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_TX_DMA_CTRL,
+ MTK_STAR_BIT_TX_DMA_CTRL_RESUME);
}
static void mtk_star_set_mac_addr(struct net_device *ndev)
@@ -845,8 +838,8 @@ static int mtk_star_hash_wait_ok(struct mtk_star_priv *priv)
return ret;
/* Check the BIST_OK bit. */
- regmap_read(priv->regs, MTK_STAR_REG_HASH_CTRL, &val);
- if (!(val & MTK_STAR_BIT_HASH_CTRL_BIST_OK))
+ if (!regmap_test_bits(priv->regs, MTK_STAR_REG_HASH_CTRL,
+ MTK_STAR_BIT_HASH_CTRL_BIST_OK))
return -EIO;
return 0;
@@ -880,12 +873,10 @@ static int mtk_star_reset_hash_table(struct mtk_star_priv *priv)
if (ret)
return ret;
- regmap_update_bits(priv->regs, MTK_STAR_REG_HASH_CTRL,
- MTK_STAR_BIT_HASH_CTRL_BIST_EN,
- MTK_STAR_BIT_HASH_CTRL_BIST_EN);
- regmap_update_bits(priv->regs, MTK_STAR_REG_TEST1,
- MTK_STAR_BIT_TEST1_RST_HASH_MBIST,
- MTK_STAR_BIT_TEST1_RST_HASH_MBIST);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_HASH_CTRL,
+ MTK_STAR_BIT_HASH_CTRL_BIST_EN);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_TEST1,
+ MTK_STAR_BIT_TEST1_RST_HASH_MBIST);
return mtk_star_hash_wait_ok(priv);
}
@@ -1016,13 +1007,13 @@ static int mtk_star_enable(struct net_device *ndev)
return ret;
/* Setup the hashing algorithm */
- regmap_update_bits(priv->regs, MTK_STAR_REG_ARL_CFG,
- MTK_STAR_BIT_ARL_CFG_HASH_ALG |
- MTK_STAR_BIT_ARL_CFG_MISC_MODE, 0);
+ regmap_clear_bits(priv->regs, MTK_STAR_REG_ARL_CFG,
+ MTK_STAR_BIT_ARL_CFG_HASH_ALG |
+ MTK_STAR_BIT_ARL_CFG_MISC_MODE);
/* Don't strip VLAN tags */
- regmap_update_bits(priv->regs, MTK_STAR_REG_MAC_CFG,
- MTK_STAR_BIT_MAC_CFG_VLAN_STRIP, 0);
+ regmap_clear_bits(priv->regs, MTK_STAR_REG_MAC_CFG,
+ MTK_STAR_BIT_MAC_CFG_VLAN_STRIP);
/* Setup DMA */
mtk_star_dma_init(priv);
@@ -1204,9 +1195,8 @@ static void mtk_star_set_rx_mode(struct net_device *ndev)
int ret;
if (ndev->flags & IFF_PROMISC) {
- regmap_update_bits(priv->regs, MTK_STAR_REG_ARL_CFG,
- MTK_STAR_BIT_ARL_CFG_MISC_MODE,
- MTK_STAR_BIT_ARL_CFG_MISC_MODE);
+ regmap_set_bits(priv->regs, MTK_STAR_REG_ARL_CFG,
+ MTK_STAR_BIT_ARL_CFG_MISC_MODE);
} else if (netdev_mc_count(ndev) > MTK_STAR_HASHTABLE_MC_LIMIT ||
ndev->flags & IFF_ALLMULTI) {
for (i = 0; i < MTK_STAR_HASHTABLE_SIZE_MAX; i++) {
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/2] regmap: provide helpers for simple bit operations
From: Bartosz Golaszewski @ 2020-05-28 15:45 UTC (permalink / raw)
To: John Crispin, Sean Wang, Mark Lee, David S . Miller,
Jakub Kicinski, Matthias Brugger, Mark Brown
Cc: Stephane Le Provost, Bartosz Golaszewski, netdev, linux-kernel,
Fabien Parent, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
In-Reply-To: <20200528154503.26304-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
In many instances regmap_update_bits() is used for simple bit setting
and clearing. In these cases the last argument is redundant and we can
hide it with a static inline function.
This adds three new helpers for simple bit operations: set_bits,
clear_bits and test_bits (the last one defined as a regular function).
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/base/regmap/regmap.c | 22 ++++++++++++++++++++++
include/linux/regmap.h | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 59f911e57719..4ad5c5adc0a3 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2936,6 +2936,28 @@ int regmap_update_bits_base(struct regmap *map, unsigned int reg,
}
EXPORT_SYMBOL_GPL(regmap_update_bits_base);
+/**
+ * regmap_test_bits() - Check if all specified bits are set in a register.
+ *
+ * @map: Register map to operate on
+ * @reg: Register to read from
+ * @bits: Bits to test
+ *
+ * Returns -1 if the underlying regmap_read() fails, 0 if at least one of the
+ * tested bits is not set and 1 if all tested bits are set.
+ */
+int regmap_test_bits(struct regmap *map, unsigned int reg, unsigned int bits)
+{
+ unsigned int val, ret;
+
+ ret = regmap_read(map, reg, &val);
+ if (ret)
+ return ret;
+
+ return (val & bits) == bits;
+}
+EXPORT_SYMBOL_GPL(regmap_test_bits);
+
void regmap_async_complete_cb(struct regmap_async *async, int ret)
{
struct regmap *map = async->map;
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 40b07168fd8e..ddf0baff195d 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -1111,6 +1111,21 @@ bool regmap_reg_in_ranges(unsigned int reg,
const struct regmap_range *ranges,
unsigned int nranges);
+static inline int regmap_set_bits(struct regmap *map,
+ unsigned int reg, unsigned int bits)
+{
+ return regmap_update_bits_base(map, reg, bits, bits,
+ NULL, false, false);
+}
+
+static inline int regmap_clear_bits(struct regmap *map,
+ unsigned int reg, unsigned int bits)
+{
+ return regmap_update_bits_base(map, reg, bits, 0, NULL, false, false);
+}
+
+int regmap_test_bits(struct regmap *map, unsigned int reg, unsigned int bits);
+
/**
* struct reg_field - Description of an register field
*
@@ -1410,6 +1425,27 @@ static inline int regmap_update_bits_base(struct regmap *map, unsigned int reg,
return -EINVAL;
}
+static inline int regmap_set_bits(struct regmap *map,
+ unsigned int reg, unsigned int bits)
+{
+ WARN_ONCE(1, "regmap API is disabled");
+ return -EINVAL;
+}
+
+static inline int regmap_clear_bits(struct regmap *map,
+ unsigned int reg, unsigned int bits)
+{
+ WARN_ONCE(1, "regmap API is disabled");
+ return -EINVAL;
+}
+
+static inline int regmap_test_bits(struct regmap *map,
+ unsigned int reg, unsigned int bits)
+{
+ WARN_ONCE(1, "regmap API is disabled");
+ return -EINVAL;
+}
+
static inline int regmap_field_update_bits_base(struct regmap_field *field,
unsigned int mask, unsigned int val,
bool *change, bool async, bool force)
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/2] regmap: provide simple bitops and use them in a driver
From: Bartosz Golaszewski @ 2020-05-28 15:45 UTC (permalink / raw)
To: John Crispin, Sean Wang, Mark Lee, David S . Miller,
Jakub Kicinski, Matthias Brugger, Mark Brown
Cc: Stephane Le Provost, Bartosz Golaszewski, netdev, linux-kernel,
Fabien Parent, linux-mediatek, Andrew Perepech, Pedro Tsai,
linux-arm-kernel
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
I noticed that oftentimes I use regmap_update_bits() for simple bit
setting or clearing. In this case the fourth argument is superfluous as
it's always 0 or equal to the mask argument.
This series proposes to add simple bit operations for setting, clearing
and testing specific bits with regmap.
The second patch uses all three in a driver that got recently picked into
the net-next tree.
The patches obviously target different trees so - if you're ok with
the change itself - I propose you pick the first one into your regmap
tree for v5.8 and then I'll resend the second patch to add the first
user for these macros for v5.9.
v1 -> v2:
- convert the new macros to static inline functions
v2 -> v3:
- drop unneeded ternary operator
Bartosz Golaszewski (2):
regmap: provide helpers for simple bit operations
net: ethernet: mtk-star-emac: use regmap bitops
drivers/base/regmap/regmap.c | 22 +++++
drivers/net/ethernet/mediatek/mtk_star_emac.c | 80 ++++++++-----------
include/linux/regmap.h | 36 +++++++++
3 files changed, 93 insertions(+), 45 deletions(-)
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: PCI: Add UniPhier PCIe endpoint controller description
From: Rob Herring @ 2020-05-28 15:19 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: devicetree, Lorenzo Pieralisi, Masami Hiramatsu, Masahiro Yamada,
linux-pci, linux-kernel, Jassi Brar, Rob Herring, Bjorn Helgaas,
linux-arm-kernel
In-Reply-To: <1589457801-12796-2-git-send-email-hayashi.kunihiko@socionext.com>
On Thu, 14 May 2020 21:03:20 +0900, Kunihiko Hayashi wrote:
> Add DT bindings for PCIe controller implemented in UniPhier SoCs
> when configured in endpoint mode. This controller is based on
> the DesignWare PCIe core.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> .../bindings/pci/socionext,uniphier-pcie-ep.yaml | 92 ++++++++++++++++++++++
> MAINTAINERS | 2 +-
> 2 files changed, 93 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: pwm: Convert mxs pwm to json-schema
From: Rob Herring @ 2020-05-28 15:17 UTC (permalink / raw)
To: Anson Huang
Cc: linux-pwm, devicetree, shawnguo, s.hauer, linux-kernel, robh+dt,
thierry.reding, Linux-imx, kernel, u.kleine-koenig, festevam,
linux-arm-kernel
In-Reply-To: <1589456470-2658-1-git-send-email-Anson.Huang@nxp.com>
On Thu, 14 May 2020 19:41:10 +0800, Anson Huang wrote:
> Convert the mxs pwm binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Documentation/devicetree/bindings/pwm/mxs-pwm.txt | 17 ---------
> Documentation/devicetree/bindings/pwm/mxs-pwm.yaml | 43 ++++++++++++++++++++++
> 2 files changed, 43 insertions(+), 17 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pwm/mxs-pwm.txt
> create mode 100644 Documentation/devicetree/bindings/pwm/mxs-pwm.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] regmap: provide helpers for simple bit operations
From: Mark Brown @ 2020-05-28 15:05 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Stephane Le Provost, netdev, Bartosz Golaszewski, Sean Wang, LKML,
Mark Lee, Fabien Parent, Pedro Tsai, linux-mediatek,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
David S . Miller, arm-soc
In-Reply-To: <CAMpxmJVB_L+otX2u80qwGjw4TXCJtwOXe=t11O4Daq3miMVk6Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 362 bytes --]
On Thu, May 28, 2020 at 04:49:06PM +0200, Bartosz Golaszewski wrote:
> czw., 28 maj 2020 o 16:45 Mark Brown <broonie@kernel.org> napisał(a):
> > The tenery here is redundant, it's converting a boolean value into a
> > boolean value. Otherwise this looks good.
> Do you mind if I respin it right away? I don't want to spam the list.
Sure, go ahead.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 16/18] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Miquel Raynal @ 2020-05-28 15:04 UTC (permalink / raw)
To: Boris Brezillon
Cc: devicetree, Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, Weijie Gao, Paul Cercueil, Rob Herring,
linux-mtd, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528165217.6582f9aa@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 16:52:17 +0200:
> On Thu, 28 May 2020 16:49:26 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
> > 2020 16:39:07 +0200:
> >
> > > On Thu, 28 May 2020 13:31:11 +0200
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > > Embed a generic NAND ECC high-level object in the nand_device
> > > > structure to carry all the ECC engine configuration/data. Adapt the
> > > > raw NAND and SPI-NAND cores to fit the change.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > > > drivers/mtd/nand/Kconfig | 1 +
> > > > drivers/mtd/nand/raw/atmel/nand-controller.c | 9 +++--
> > > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 ++--
> > > > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 12 +++---
> > > > drivers/mtd/nand/raw/marvell_nand.c | 7 ++--
> > > > drivers/mtd/nand/raw/mtk_nand.c | 4 +-
> > > > drivers/mtd/nand/raw/nand_base.c | 25 ++++++------
> > > > drivers/mtd/nand/raw/nand_esmt.c | 11 +++---
> > > > drivers/mtd/nand/raw/nand_hynix.c | 41 ++++++++++----------
> > > > drivers/mtd/nand/raw/nand_jedec.c | 4 +-
> > > > drivers/mtd/nand/raw/nand_micron.c | 14 ++++---
> > > > drivers/mtd/nand/raw/nand_onfi.c | 8 ++--
> > > > drivers/mtd/nand/raw/nand_samsung.c | 19 ++++-----
> > > > drivers/mtd/nand/raw/nand_toshiba.c | 11 +++---
> > > > drivers/mtd/nand/raw/sunxi_nand.c | 5 ++-
> > > > drivers/mtd/nand/raw/tegra_nand.c | 9 +++--
> > > > drivers/mtd/nand/spi/core.c | 8 ++--
> > > > drivers/mtd/nand/spi/macronix.c | 6 +--
> > > > drivers/mtd/nand/spi/toshiba.c | 6 +--
> > > > include/linux/mtd/nand.h | 8 ++--
> > > > 20 files changed, 115 insertions(+), 100 deletions(-)
> > > >
> > > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > > > index a4478ffa279d..3327d8539a73 100644
> > > > --- a/drivers/mtd/nand/Kconfig
> > > > +++ b/drivers/mtd/nand/Kconfig
> > > > @@ -13,6 +13,7 @@ menu "ECC engine support"
> > > >
> > > > config MTD_NAND_ECC
> > > > bool
> > > > + select MTD_NAND_CORE
> > >
> > > This select looks suspicious. Shouldn't it be a depends on, and more
> > > importantly, I think it should be part of patch 15.
> >
> > Wouldn't we break a lot of users by using depends on?
> >
> > Or maybe we can turn it on by default?
>
> It's a sub-functionality of the NAND core, so it should be a depends on
> in my opinion. Why would that break users. Aren't you selecting
> MTD_NAND_CORE in MTD_RAWNAND now? Those options should really remain
> hidden, and be selected at the SPI/raw NAND framework level.
I remembered we discussed that point already, yes the generic core is
selected by the SPI/raw NAND layers, so it should be fine. I'll move
this as a depends on in the previous patch.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 14/18] mtd: nand: Add more parameters to the nand_ecc_props structure
From: Miquel Raynal @ 2020-05-28 15:02 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Paul Cercueil, Rob Herring,
linux-mtd, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528170022.5cd5b46c@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 17:00:22 +0200:
> On Thu, 28 May 2020 16:57:54 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
> > 2020 16:34:24 +0200:
> >
> > > On Thu, 28 May 2020 13:31:09 +0200
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > > Prepare the migration to the generic ECC framework by adding more
> > > > fields to the nand_ecc_props structure which will be used widely to
> > > > describe different kind of ECC properties.
> > > >
> > > > Doing this imposes to move the engine type, ECC placement and
> > > > algorithm enumerations in a shared place: nand.h.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > > > include/linux/mtd/nand.h | 52 +++++++++++++++++++++++++++++++++++++
> > > > include/linux/mtd/rawnand.h | 44 -------------------------------
> > > > 2 files changed, 52 insertions(+), 44 deletions(-)
> > > >
> > > > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > > > index 6add464fd18b..2e9af24936cd 100644
> > > > --- a/include/linux/mtd/nand.h
> > > > +++ b/include/linux/mtd/nand.h
> > > > @@ -127,14 +127,66 @@ struct nand_page_io_req {
> > > > int mode;
> > > > };
> > > >
> > > > +/**
> > > > + * enum nand_ecc_engine_type - NAND ECC engine type
> > > > + * @NAND_ECC_ENGINE_TYPE_INVALID: Invalid value
> > > > + * @NAND_ECC_ENGINE_TYPE_NONE: No ECC correction
> > > > + * @NAND_ECC_ENGINE_TYPE_SOFT: Software ECC correction
> > > > + * @NAND_ECC_ENGINE_TYPE_ON_HOST: On host hardware ECC correction
> > > > + * @NAND_ECC_ENGINE_TYPE_ON_DIE: On chip hardware ECC correction
> > > > + */
> > > > +enum nand_ecc_engine_type {
> > > > + NAND_ECC_ENGINE_TYPE_INVALID,
> > > > + NAND_ECC_ENGINE_TYPE_NONE,
> > > > + NAND_ECC_ENGINE_TYPE_SOFT,
> > > > + NAND_ECC_ENGINE_TYPE_ON_HOST,
> > > > + NAND_ECC_ENGINE_TYPE_ON_DIE,
> > > > +};
> > > > +
> > > > +/**
> > > > + * enum nand_ecc_placement - NAND ECC bytes placement
> > > > + * @NAND_ECC_PLACEMENT_UNKNOWN: The actual position of the ECC bytes is unknown
> > > > + * @NAND_ECC_PLACEMENT_OOB: The ECC bytes are located in the OOB area
> > > > + * @NAND_ECC_PLACEMENT_INTERLEAVED: Syndrome layout, there are ECC bytes
> > > > + * interleaved with regular data in the main
> > > > + * area
> > > > + */
> > > > +enum nand_ecc_placement {
> > > > + NAND_ECC_PLACEMENT_UNKNOWN,
> > > > + NAND_ECC_PLACEMENT_OOB,
> > > > + NAND_ECC_PLACEMENT_INTERLEAVED,
> > > > +};
> > > > +
> > > > +/**
> > > > + * enum nand_ecc_algo - NAND ECC algorithm
> > > > + * @NAND_ECC_ALGO_UNKNOWN: Unknown algorithm
> > > > + * @NAND_ECC_ALGO_HAMMING: Hamming algorithm
> > > > + * @NAND_ECC_ALGO_BCH: Bose-Chaudhuri-Hocquenghem algorithm
> > > > + * @NAND_ECC_ALGO_RS: Reed-Solomon algorithm
> > > > + */
> > > > +enum nand_ecc_algo {
> > > > + NAND_ECC_ALGO_UNKNOWN,
> > > > + NAND_ECC_ALGO_HAMMING,
> > > > + NAND_ECC_ALGO_BCH,
> > > > + NAND_ECC_ALGO_RS,
> > > > +};
> > > > +
> > > > /**
> > > > * struct nand_ecc_props - NAND ECC properties
> > > > + * @engine_type: ECC engine type
> > > > + * @placement: OOB placement (if relevant)
> > > > + * @algo: ECC algorithm (if relevant)
> > > > * @strength: ECC strength
> > > > * @step_size: Number of bytes per step
> > > > + * @flags: Misc properties
> > >
> > > I'd like to hear more about that one. What is this about? I'd rather
> > > not add a field if it's not needed.
> > >
> >
> > It is used in patch 18/18 to store the NAND_ECC_MAXIMIZE flag. And I
> > expect others to come later...
>
> Then I think it should be introduced in this patch, not here.
I'm fine with that.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 14/18] mtd: nand: Add more parameters to the nand_ecc_props structure
From: Boris Brezillon @ 2020-05-28 15:00 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Paul Cercueil, Rob Herring,
linux-mtd, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528165754.35985b62@xps13>
On Thu, 28 May 2020 16:57:54 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
> 2020 16:34:24 +0200:
>
> > On Thu, 28 May 2020 13:31:09 +0200
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > Prepare the migration to the generic ECC framework by adding more
> > > fields to the nand_ecc_props structure which will be used widely to
> > > describe different kind of ECC properties.
> > >
> > > Doing this imposes to move the engine type, ECC placement and
> > > algorithm enumerations in a shared place: nand.h.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > > include/linux/mtd/nand.h | 52 +++++++++++++++++++++++++++++++++++++
> > > include/linux/mtd/rawnand.h | 44 -------------------------------
> > > 2 files changed, 52 insertions(+), 44 deletions(-)
> > >
> > > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > > index 6add464fd18b..2e9af24936cd 100644
> > > --- a/include/linux/mtd/nand.h
> > > +++ b/include/linux/mtd/nand.h
> > > @@ -127,14 +127,66 @@ struct nand_page_io_req {
> > > int mode;
> > > };
> > >
> > > +/**
> > > + * enum nand_ecc_engine_type - NAND ECC engine type
> > > + * @NAND_ECC_ENGINE_TYPE_INVALID: Invalid value
> > > + * @NAND_ECC_ENGINE_TYPE_NONE: No ECC correction
> > > + * @NAND_ECC_ENGINE_TYPE_SOFT: Software ECC correction
> > > + * @NAND_ECC_ENGINE_TYPE_ON_HOST: On host hardware ECC correction
> > > + * @NAND_ECC_ENGINE_TYPE_ON_DIE: On chip hardware ECC correction
> > > + */
> > > +enum nand_ecc_engine_type {
> > > + NAND_ECC_ENGINE_TYPE_INVALID,
> > > + NAND_ECC_ENGINE_TYPE_NONE,
> > > + NAND_ECC_ENGINE_TYPE_SOFT,
> > > + NAND_ECC_ENGINE_TYPE_ON_HOST,
> > > + NAND_ECC_ENGINE_TYPE_ON_DIE,
> > > +};
> > > +
> > > +/**
> > > + * enum nand_ecc_placement - NAND ECC bytes placement
> > > + * @NAND_ECC_PLACEMENT_UNKNOWN: The actual position of the ECC bytes is unknown
> > > + * @NAND_ECC_PLACEMENT_OOB: The ECC bytes are located in the OOB area
> > > + * @NAND_ECC_PLACEMENT_INTERLEAVED: Syndrome layout, there are ECC bytes
> > > + * interleaved with regular data in the main
> > > + * area
> > > + */
> > > +enum nand_ecc_placement {
> > > + NAND_ECC_PLACEMENT_UNKNOWN,
> > > + NAND_ECC_PLACEMENT_OOB,
> > > + NAND_ECC_PLACEMENT_INTERLEAVED,
> > > +};
> > > +
> > > +/**
> > > + * enum nand_ecc_algo - NAND ECC algorithm
> > > + * @NAND_ECC_ALGO_UNKNOWN: Unknown algorithm
> > > + * @NAND_ECC_ALGO_HAMMING: Hamming algorithm
> > > + * @NAND_ECC_ALGO_BCH: Bose-Chaudhuri-Hocquenghem algorithm
> > > + * @NAND_ECC_ALGO_RS: Reed-Solomon algorithm
> > > + */
> > > +enum nand_ecc_algo {
> > > + NAND_ECC_ALGO_UNKNOWN,
> > > + NAND_ECC_ALGO_HAMMING,
> > > + NAND_ECC_ALGO_BCH,
> > > + NAND_ECC_ALGO_RS,
> > > +};
> > > +
> > > /**
> > > * struct nand_ecc_props - NAND ECC properties
> > > + * @engine_type: ECC engine type
> > > + * @placement: OOB placement (if relevant)
> > > + * @algo: ECC algorithm (if relevant)
> > > * @strength: ECC strength
> > > * @step_size: Number of bytes per step
> > > + * @flags: Misc properties
> >
> > I'd like to hear more about that one. What is this about? I'd rather
> > not add a field if it's not needed.
> >
>
> It is used in patch 18/18 to store the NAND_ECC_MAXIMIZE flag. And I
> expect others to come later...
Then I think it should be introduced in this patch, not here.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 14/18] mtd: nand: Add more parameters to the nand_ecc_props structure
From: Miquel Raynal @ 2020-05-28 14:57 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528163424.6677597c@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 16:34:24 +0200:
> On Thu, 28 May 2020 13:31:09 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Prepare the migration to the generic ECC framework by adding more
> > fields to the nand_ecc_props structure which will be used widely to
> > describe different kind of ECC properties.
> >
> > Doing this imposes to move the engine type, ECC placement and
> > algorithm enumerations in a shared place: nand.h.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > include/linux/mtd/nand.h | 52 +++++++++++++++++++++++++++++++++++++
> > include/linux/mtd/rawnand.h | 44 -------------------------------
> > 2 files changed, 52 insertions(+), 44 deletions(-)
> >
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > index 6add464fd18b..2e9af24936cd 100644
> > --- a/include/linux/mtd/nand.h
> > +++ b/include/linux/mtd/nand.h
> > @@ -127,14 +127,66 @@ struct nand_page_io_req {
> > int mode;
> > };
> >
> > +/**
> > + * enum nand_ecc_engine_type - NAND ECC engine type
> > + * @NAND_ECC_ENGINE_TYPE_INVALID: Invalid value
> > + * @NAND_ECC_ENGINE_TYPE_NONE: No ECC correction
> > + * @NAND_ECC_ENGINE_TYPE_SOFT: Software ECC correction
> > + * @NAND_ECC_ENGINE_TYPE_ON_HOST: On host hardware ECC correction
> > + * @NAND_ECC_ENGINE_TYPE_ON_DIE: On chip hardware ECC correction
> > + */
> > +enum nand_ecc_engine_type {
> > + NAND_ECC_ENGINE_TYPE_INVALID,
> > + NAND_ECC_ENGINE_TYPE_NONE,
> > + NAND_ECC_ENGINE_TYPE_SOFT,
> > + NAND_ECC_ENGINE_TYPE_ON_HOST,
> > + NAND_ECC_ENGINE_TYPE_ON_DIE,
> > +};
> > +
> > +/**
> > + * enum nand_ecc_placement - NAND ECC bytes placement
> > + * @NAND_ECC_PLACEMENT_UNKNOWN: The actual position of the ECC bytes is unknown
> > + * @NAND_ECC_PLACEMENT_OOB: The ECC bytes are located in the OOB area
> > + * @NAND_ECC_PLACEMENT_INTERLEAVED: Syndrome layout, there are ECC bytes
> > + * interleaved with regular data in the main
> > + * area
> > + */
> > +enum nand_ecc_placement {
> > + NAND_ECC_PLACEMENT_UNKNOWN,
> > + NAND_ECC_PLACEMENT_OOB,
> > + NAND_ECC_PLACEMENT_INTERLEAVED,
> > +};
> > +
> > +/**
> > + * enum nand_ecc_algo - NAND ECC algorithm
> > + * @NAND_ECC_ALGO_UNKNOWN: Unknown algorithm
> > + * @NAND_ECC_ALGO_HAMMING: Hamming algorithm
> > + * @NAND_ECC_ALGO_BCH: Bose-Chaudhuri-Hocquenghem algorithm
> > + * @NAND_ECC_ALGO_RS: Reed-Solomon algorithm
> > + */
> > +enum nand_ecc_algo {
> > + NAND_ECC_ALGO_UNKNOWN,
> > + NAND_ECC_ALGO_HAMMING,
> > + NAND_ECC_ALGO_BCH,
> > + NAND_ECC_ALGO_RS,
> > +};
> > +
> > /**
> > * struct nand_ecc_props - NAND ECC properties
> > + * @engine_type: ECC engine type
> > + * @placement: OOB placement (if relevant)
> > + * @algo: ECC algorithm (if relevant)
> > * @strength: ECC strength
> > * @step_size: Number of bytes per step
> > + * @flags: Misc properties
>
> I'd like to hear more about that one. What is this about? I'd rather
> not add a field if it's not needed.
>
It is used in patch 18/18 to store the NAND_ECC_MAXIMIZE flag. And I
expect others to come later...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 17/18] mtd: rawnand: Write a compatibility layer
From: Miquel Raynal @ 2020-05-28 14:53 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528164217.4eec33ae@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 16:42:17 +0200:
> On Thu, 28 May 2020 13:31:12 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > +static enum nand_ecc_engine_type
> > +of_get_rawnand_ecc_engine_type_legacy(struct device_node *np)
> > +{
> > + enum nand_ecc_legacy_mode {
> > + NAND_ECC_INVALID,
> > + NAND_ECC_NONE,
> > + NAND_ECC_SOFT,
> > + NAND_ECC_SOFT_BCH,
> > + NAND_ECC_HW,
> > + NAND_ECC_HW_SYNDROME,
> > + NAND_ECC_ON_DIE,
> > + };
>
> You're redefining an enum, but I don't see the old enum/defines being
> removed, is that expected?
Oh yeah, my desire was to get rid of this public enumeration and mov it
to the single legacy function using it, but indeed I am removing it in
the next patch as part of the global move to nand/core.c. I will do it
in this patch.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 2/2] dt-bindings: arm: coresight: Add support to skip trace unit power up
From: Rob Herring @ 2020-05-28 14:52 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: devicetree, Mathieu Poirier, Suzuki K Poulose, linux-arm-msm,
coresight, linux-kernel, Stephen Boyd, Rob Herring, Tingwei Zhang,
Leo Yan, linux-arm-kernel, Mike Leach
In-Reply-To: <7b69c9752713ce22f04688e83ec78f8aa67c63dc.1589558615.git.saiprakash.ranjan@codeaurora.org>
On Fri, 15 May 2020 21:52:33 +0530, Sai Prakash Ranjan wrote:
> From: Tingwei Zhang <tingwei@codeaurora.org>
>
> Add "qcom,skip-power-up" property to identify systems which can
> skip powering up of trace unit since they share the same power
> domain as their CPU core. This is required to identify such
> systems with hardware errata which stops the CPU watchdog counter
> when the power up bit is set (TRCPDCR.PU).
>
> Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
> Co-developed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---
> Documentation/devicetree/bindings/arm/coresight.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 16/18] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Boris Brezillon @ 2020-05-28 14:52 UTC (permalink / raw)
To: Miquel Raynal
Cc: devicetree, Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, Weijie Gao, Paul Cercueil, Rob Herring,
linux-mtd, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528164926.3b99f848@xps13>
On Thu, 28 May 2020 16:49:26 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
> 2020 16:39:07 +0200:
>
> > On Thu, 28 May 2020 13:31:11 +0200
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > Embed a generic NAND ECC high-level object in the nand_device
> > > structure to carry all the ECC engine configuration/data. Adapt the
> > > raw NAND and SPI-NAND cores to fit the change.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > > drivers/mtd/nand/Kconfig | 1 +
> > > drivers/mtd/nand/raw/atmel/nand-controller.c | 9 +++--
> > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 ++--
> > > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 12 +++---
> > > drivers/mtd/nand/raw/marvell_nand.c | 7 ++--
> > > drivers/mtd/nand/raw/mtk_nand.c | 4 +-
> > > drivers/mtd/nand/raw/nand_base.c | 25 ++++++------
> > > drivers/mtd/nand/raw/nand_esmt.c | 11 +++---
> > > drivers/mtd/nand/raw/nand_hynix.c | 41 ++++++++++----------
> > > drivers/mtd/nand/raw/nand_jedec.c | 4 +-
> > > drivers/mtd/nand/raw/nand_micron.c | 14 ++++---
> > > drivers/mtd/nand/raw/nand_onfi.c | 8 ++--
> > > drivers/mtd/nand/raw/nand_samsung.c | 19 ++++-----
> > > drivers/mtd/nand/raw/nand_toshiba.c | 11 +++---
> > > drivers/mtd/nand/raw/sunxi_nand.c | 5 ++-
> > > drivers/mtd/nand/raw/tegra_nand.c | 9 +++--
> > > drivers/mtd/nand/spi/core.c | 8 ++--
> > > drivers/mtd/nand/spi/macronix.c | 6 +--
> > > drivers/mtd/nand/spi/toshiba.c | 6 +--
> > > include/linux/mtd/nand.h | 8 ++--
> > > 20 files changed, 115 insertions(+), 100 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > > index a4478ffa279d..3327d8539a73 100644
> > > --- a/drivers/mtd/nand/Kconfig
> > > +++ b/drivers/mtd/nand/Kconfig
> > > @@ -13,6 +13,7 @@ menu "ECC engine support"
> > >
> > > config MTD_NAND_ECC
> > > bool
> > > + select MTD_NAND_CORE
> >
> > This select looks suspicious. Shouldn't it be a depends on, and more
> > importantly, I think it should be part of patch 15.
>
> Wouldn't we break a lot of users by using depends on?
>
> Or maybe we can turn it on by default?
It's a sub-functionality of the NAND core, so it should be a depends on
in my opinion. Why would that break users. Aren't you selecting
MTD_NAND_CORE in MTD_RAWNAND now? Those options should really remain
hidden, and be selected at the SPI/raw NAND framework level.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 16/18] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Miquel Raynal @ 2020-05-28 14:49 UTC (permalink / raw)
To: Boris Brezillon
Cc: devicetree, Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, Weijie Gao, Paul Cercueil, Rob Herring,
linux-mtd, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528163907.6539e2a1@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 16:39:07 +0200:
> On Thu, 28 May 2020 13:31:11 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Embed a generic NAND ECC high-level object in the nand_device
> > structure to carry all the ECC engine configuration/data. Adapt the
> > raw NAND and SPI-NAND cores to fit the change.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > drivers/mtd/nand/Kconfig | 1 +
> > drivers/mtd/nand/raw/atmel/nand-controller.c | 9 +++--
> > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 ++--
> > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 12 +++---
> > drivers/mtd/nand/raw/marvell_nand.c | 7 ++--
> > drivers/mtd/nand/raw/mtk_nand.c | 4 +-
> > drivers/mtd/nand/raw/nand_base.c | 25 ++++++------
> > drivers/mtd/nand/raw/nand_esmt.c | 11 +++---
> > drivers/mtd/nand/raw/nand_hynix.c | 41 ++++++++++----------
> > drivers/mtd/nand/raw/nand_jedec.c | 4 +-
> > drivers/mtd/nand/raw/nand_micron.c | 14 ++++---
> > drivers/mtd/nand/raw/nand_onfi.c | 8 ++--
> > drivers/mtd/nand/raw/nand_samsung.c | 19 ++++-----
> > drivers/mtd/nand/raw/nand_toshiba.c | 11 +++---
> > drivers/mtd/nand/raw/sunxi_nand.c | 5 ++-
> > drivers/mtd/nand/raw/tegra_nand.c | 9 +++--
> > drivers/mtd/nand/spi/core.c | 8 ++--
> > drivers/mtd/nand/spi/macronix.c | 6 +--
> > drivers/mtd/nand/spi/toshiba.c | 6 +--
> > include/linux/mtd/nand.h | 8 ++--
> > 20 files changed, 115 insertions(+), 100 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > index a4478ffa279d..3327d8539a73 100644
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -13,6 +13,7 @@ menu "ECC engine support"
> >
> > config MTD_NAND_ECC
> > bool
> > + select MTD_NAND_CORE
>
> This select looks suspicious. Shouldn't it be a depends on, and more
> importantly, I think it should be part of patch 15.
Wouldn't we break a lot of users by using depends on?
Or maybe we can turn it on by default?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] regmap: provide helpers for simple bit operations
From: Bartosz Golaszewski @ 2020-05-28 14:49 UTC (permalink / raw)
To: Mark Brown
Cc: Stephane Le Provost, netdev, Bartosz Golaszewski, Sean Wang, LKML,
Mark Lee, Fabien Parent, Pedro Tsai, linux-mediatek,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
David S . Miller, arm-soc
In-Reply-To: <20200528144456.GG3606@sirena.org.uk>
czw., 28 maj 2020 o 16:45 Mark Brown <broonie@kernel.org> napisał(a):
>
> On Thu, May 28, 2020 at 04:22:40PM +0200, Bartosz Golaszewski wrote:
>
> > + return (val & bits) == bits ? 1 : 0;
>
> The tenery here is redundant, it's converting a boolean value into a
> boolean value. Otherwise this looks good.
Do you mind if I respin it right away? I don't want to spam the list.
Bartosz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv3 0/2] Add support for replicators which loses context on clock removal
From: Rob Herring @ 2020-05-28 14:48 UTC (permalink / raw)
To: Mathieu Poirier
Cc: devicetree, Sai Prakash Ranjan, Suzuki K Poulose, linux-arm-msm,
linux-kernel, Stephen Boyd, linux-arm-kernel, Mike Leach
In-Reply-To: <20200525161553.GA31527@xps15>
On Mon, May 25, 2020 at 10:15:53AM -0600, Mathieu Poirier wrote:
> Hi Sai,
>
> On Sat, May 23, 2020 at 12:06:50AM +0530, Sai Prakash Ranjan wrote:
> > This series is mainly to add support for replicators
> > which lose context on removing AMBA clock like on SC7180
> > SoC where replicator in AOSS domain loses context.
> >
>
> I am good with this set but need a reviewed-by on the DT binding before I can
> add it to my tree. The same goes for your other set[1].
Then why is it already in linux-next?
In any case,
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 18/18] mtd: rawnand: Move generic bits to the ECC framework
From: Boris Brezillon @ 2020-05-28 14:45 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528113113.9166-19-miquel.raynal@bootlin.com>
On Thu, 28 May 2020 13:31:13 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index ce936ffb9f42..1cc6d71c2b45 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -127,6 +127,10 @@ struct nand_page_io_req {
> int mode;
> };
>
> +extern const struct mtd_ooblayout_ops nand_ooblayout_sp_ops;
> +extern const struct mtd_ooblayout_ops nand_ooblayout_lp_ops;
> +extern const struct mtd_ooblayout_ops nand_ooblayout_lp_hamming_ops;
While we move that to the generic NAND layer, can we hide that behind
helpers so we don't have the objects directly exposed?
const struct mtd_ooblayout_ops *nand_get_small_page_layout();
const struct mtd_ooblayout_ops *nand_get_large_page_layout();
const struct mtd_ooblayout_ops *nand_get_large_page_hamming_layout();
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 08/18] mtd: rawnand: Use the new ECC engine type enumeration
From: Miquel Raynal @ 2020-05-28 14:45 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528163150.6ad71fcc@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 16:31:50 +0200:
> On Thu, 28 May 2020 13:31:03 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Mechanical switch from the legacy "mode" enumeration to the new
> > "engine type" enumeration in drivers and board files.
> >
> > The device tree parsing is also updated to return the new enumeration
> > from the old strings.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>
> I didn't check all the changes, but I'm fine with the approach
>
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
>
> > diff --git a/include/linux/platform_data/mtd-davinci.h b/include/linux/platform_data/mtd-davinci.h
> > index 3383101c233b..dd474dd44848 100644
> > --- a/include/linux/platform_data/mtd-davinci.h
> > +++ b/include/linux/platform_data/mtd-davinci.h
> > @@ -60,16 +60,16 @@ struct davinci_nand_pdata { /* platform_data */
> > struct mtd_partition *parts;
> > unsigned nr_parts;
> >
> > - /* none == NAND_ECC_NONE (strongly *not* advised!!)
> > - * soft == NAND_ECC_SOFT
> > - * else == NAND_ECC_HW, according to ecc_bits
> > + /* none == NAND_ECC_ENGINE_TYPE_NONE (strongly *not* advised!!)
> > + * soft == NAND_ECC_ENGINE_TYPE_SOFT
> > + * else == NAND_ECC_ENGINE_TYPE_ON_HOST, according to ecc_bits
> > *
> > * All DaVinci-family chips support 1-bit hardware ECC.
> > * Newer ones also support 4-bit ECC, but are awkward
> > * using it with large page chips.
> > */
> > - enum nand_ecc_mode ecc_mode;
> > - enum nand_ecc_placement ecc_placement;
> > + enum nand_ecc_engine_type engine_type;
> > + enum nand_ecc_placement ecc_placement;
>
> Nitpick: if you want to use a space instead of tab, it should be done in
> patch 3.
Right, fixed!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] regmap: provide helpers for simple bit operations
From: Mark Brown @ 2020-05-28 14:44 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Stephane Le Provost, Bartosz Golaszewski, netdev, Sean Wang,
linux-kernel, Mark Lee, Fabien Parent, Pedro Tsai, linux-mediatek,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
David S . Miller, linux-arm-kernel
In-Reply-To: <20200528142241.20466-2-brgl@bgdev.pl>
[-- Attachment #1.1: Type: text/plain, Size: 224 bytes --]
On Thu, May 28, 2020 at 04:22:40PM +0200, Bartosz Golaszewski wrote:
> + return (val & bits) == bits ? 1 : 0;
The tenery here is redundant, it's converting a boolean value into a
boolean value. Otherwise this looks good.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM: dts: Move watchdog from Kontron i.MX6UL/ULL board to SoM
From: Schrempf Frieder @ 2020-05-28 14:43 UTC (permalink / raw)
To: Fabio Estevam, Schrempf Frieder, Krzysztof Kozlowski,
NXP Linux Team, Pengutronix Kernel Team, Rob Herring,
Sascha Hauer, Shawn Guo
Cc: Rob Herring, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
From: Frieder Schrempf <frieder.schrempf@kontron.de>
The watchdog's WDOG_ANY signal is used to trigger a POR of the SoC,
if a soft reset is issued. As the SoM hardware connects the WDOG_ANY
and the POR signals, the watchdog node itself and the pin
configuration should be part of the common SoM devicetree.
Let's move it from the baseboard's devicetree to its proper place.
Fixes: 1ea4b76cdfde ("ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards")
Cc: stable@vger.kernel.org
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi | 13 -------------
.../boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi | 13 +++++++++++++
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi b/arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi
index f05e91841202..53a25fba34f6 100644
--- a/arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6x1x-s.dtsi
@@ -232,13 +232,6 @@
status = "okay";
};
-&wdog1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_wdog>;
- fsl,ext-reset-output;
- status = "okay";
-};
-
&iomuxc {
pinctrl-0 = <&pinctrl_reset_out &pinctrl_gpio>;
@@ -409,10 +402,4 @@
MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170f9
>;
};
-
- pinctrl_wdog: wdoggrp {
- fsl,pins = <
- MX6UL_PAD_GPIO1_IO09__WDOG1_WDOG_ANY 0x30b0
- >;
- };
};
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi b/arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi
index a17af4d9bfdf..fc316408721d 100644
--- a/arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi
@@ -57,6 +57,13 @@
status = "okay";
};
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_reset_out>;
@@ -106,4 +113,10 @@
MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09 0x1b0b0
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO09__WDOG1_WDOG_ANY 0x30b0
+ >;
+ };
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: Change WDOG_ANY signal from push-pull to open-drain
From: Schrempf Frieder @ 2020-05-28 14:43 UTC (permalink / raw)
To: Fabio Estevam, Schrempf Frieder, Krzysztof Kozlowski,
NXP Linux Team, Pengutronix Kernel Team, Rob Herring,
Sascha Hauer, Shawn Guo
Cc: Rob Herring, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200528144312.25980-1-frieder.schrempf@kontron.de>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
The WDOG_ANY signal is connected to the RESET_IN signal of the SoM
and baseboard. It is currently configured as push-pull, which means
that if some external device like a programmer wants to assert the
RESET_IN signal by pulling it to ground, it drives against the high
level WDOG_ANY output of the SoC.
To fix this we set the WDOG_ANY signal to open-drain configuration.
That way we make sure that the RESET_IN can be asserted by the
watchdog as well as by external devices.
Fixes: 1ea4b76cdfde ("ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards")
Cc: stable@vger.kernel.org
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi b/arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi
index fc316408721d..61ba21a605a8 100644
--- a/arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6x1x-som-common.dtsi
@@ -116,7 +116,7 @@
pinctrl_wdog: wdoggrp {
fsl,pins = <
- MX6UL_PAD_GPIO1_IO09__WDOG1_WDOG_ANY 0x30b0
+ MX6UL_PAD_GPIO1_IO09__WDOG1_WDOG_ANY 0x18b0
>;
};
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 17/18] mtd: rawnand: Write a compatibility layer
From: Boris Brezillon @ 2020-05-28 14:42 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200528113113.9166-18-miquel.raynal@bootlin.com>
On Thu, 28 May 2020 13:31:12 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> +static enum nand_ecc_engine_type
> +of_get_rawnand_ecc_engine_type_legacy(struct device_node *np)
> +{
> + enum nand_ecc_legacy_mode {
> + NAND_ECC_INVALID,
> + NAND_ECC_NONE,
> + NAND_ECC_SOFT,
> + NAND_ECC_SOFT_BCH,
> + NAND_ECC_HW,
> + NAND_ECC_HW_SYNDROME,
> + NAND_ECC_ON_DIE,
> + };
You're redefining an enum, but I don't see the old enum/defines being
removed, is that expected?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 16/18] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Boris Brezillon @ 2020-05-28 14:39 UTC (permalink / raw)
To: Miquel Raynal
Cc: devicetree, Vignesh Raghavendra, Tudor Ambarus, Julien Su,
Richard Weinberger, Weijie Gao, Paul Cercueil, Rob Herring,
linux-mtd, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528113113.9166-17-miquel.raynal@bootlin.com>
On Thu, 28 May 2020 13:31:11 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Embed a generic NAND ECC high-level object in the nand_device
> structure to carry all the ECC engine configuration/data. Adapt the
> raw NAND and SPI-NAND cores to fit the change.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/mtd/nand/Kconfig | 1 +
> drivers/mtd/nand/raw/atmel/nand-controller.c | 9 +++--
> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 ++--
> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 12 +++---
> drivers/mtd/nand/raw/marvell_nand.c | 7 ++--
> drivers/mtd/nand/raw/mtk_nand.c | 4 +-
> drivers/mtd/nand/raw/nand_base.c | 25 ++++++------
> drivers/mtd/nand/raw/nand_esmt.c | 11 +++---
> drivers/mtd/nand/raw/nand_hynix.c | 41 ++++++++++----------
> drivers/mtd/nand/raw/nand_jedec.c | 4 +-
> drivers/mtd/nand/raw/nand_micron.c | 14 ++++---
> drivers/mtd/nand/raw/nand_onfi.c | 8 ++--
> drivers/mtd/nand/raw/nand_samsung.c | 19 ++++-----
> drivers/mtd/nand/raw/nand_toshiba.c | 11 +++---
> drivers/mtd/nand/raw/sunxi_nand.c | 5 ++-
> drivers/mtd/nand/raw/tegra_nand.c | 9 +++--
> drivers/mtd/nand/spi/core.c | 8 ++--
> drivers/mtd/nand/spi/macronix.c | 6 +--
> drivers/mtd/nand/spi/toshiba.c | 6 +--
> include/linux/mtd/nand.h | 8 ++--
> 20 files changed, 115 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index a4478ffa279d..3327d8539a73 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -13,6 +13,7 @@ menu "ECC engine support"
>
> config MTD_NAND_ECC
> bool
> + select MTD_NAND_CORE
This select looks suspicious. Shouldn't it be a depends on, and more
importantly, I think it should be part of patch 15.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 07/21] drm/hisilicon/kirin: Use GEM CMA object functions
From: Emil Velikov @ 2020-05-28 14:34 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: alexandre.belloni, linux-aspeed, Neil Armstrong, Dave Airlie,
Liviu Dudau, ML dri-devel, Paul Cercueil, Laurent Pinchart,
Mihail Atanassov, Sam Ravnborg, Marek Vašut, khilman,
Alexey Brodkin, Xinwei Kong, Xinliang Liu, ludovic.desroches,
Tomi Valkeinen, james qian wang (Arm Technology China),
NXP Linux Team, joel, Alexandre Torgue, Chen Feng, Sascha Hauer,
Alison Wang, Jyri Sarha, Chen-Yu Tsai, Vincent Abriou, LAKML,
Maxime Coquelin, bbrezillon, andrew, Philippe Cornu,
Yannick Fertre, Kieran Bingham, Sascha Hauer, Rongrong Zou,
Shawn Guo
In-Reply-To: <ccee78e2-8930-2de6-0b7c-0f1ad1e636f8@suse.de>
On Mon, 25 May 2020 at 13:41, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi Emil
>
> Am 22.05.20 um 20:11 schrieb Emil Velikov:
> > Hi Thomas,
> >
> > On Fri, 22 May 2020 at 14:53, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> >>
> >> The kirin driver uses the default implementation for CMA functions; except
> >> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> >> these defaults and .dumb_create in struct drm_driver. All remaining
> >> operations are provided by CMA GEM object functions.
> >>
> >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> >> ---
> >> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +-----------
> >> 1 file changed, 1 insertion(+), 11 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> >> index c339e632522a9..b1ffd7d43e562 100644
> >> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> >> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> >> @@ -921,17 +921,7 @@ DEFINE_DRM_GEM_CMA_FOPS(ade_fops);
> >> static struct drm_driver ade_driver = {
> >> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> >> .fops = &ade_fops,
> >> - .gem_free_object_unlocked = drm_gem_cma_free_object,
> >> - .gem_vm_ops = &drm_gem_cma_vm_ops,
> >> - .dumb_create = drm_gem_cma_dumb_create_internal,
> >
> > This doesn't seem right. The _internal documentation explicitly says
> > that this should _not_ be used as .dumb_create. Instead drivers should
> > use it to implement their callback.
> >
> > Since it yields the same result as drm_gem_cma_dumb_create we can use
> > the default macro below.
>
> I noticed this and thought that the driver authors probably had their
> reasons. Changing the driver to the default macro is probably still a
> good idea.
>
To be on the _extra_ safe side might want to keep that separate patch
explicitly CC-ing the author/reviewers of the offending commit.
Although as said before - it's your call, I'm fine either way.
HTH
Emil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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