* [PATCH v7 1/5] dt-bindings: iio: magnetometer: ak8975: reword gpios, add interrupts, fix style
From: Jonathan Albrieux @ 2020-05-28 14:56 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hartmut Knaack, Jonathan Cameron, Lars-Peter Clausen,
Linus Walleij, open list:IIO SUBSYSTEM AND DRIVERS,
Peter Meerwald-Stadler, Jonathan Cameron, Rob Herring
In-Reply-To: <20200528145631.11608-1-jonathan.albrieux@gmail.com>
Reword gpios documentation, add interrupt documentation and fix styles.
Update example to use interrupts instead of gpios.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/iio/magnetometer/ak8975.txt | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
index aa67ceb0d4e0..0576b9df0bf2 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
@@ -2,21 +2,28 @@
Required properties:
- - compatible : should be "asahi-kasei,ak8975"
- - reg : the I2C address of the magnetometer
+ - compatible : should be "asahi-kasei,ak8975".
+ - reg : the I2C address of the magnetometer.
Optional properties:
- - gpios : should be device tree identifier of the magnetometer DRDY pin
- - vdd-supply: an optional regulator that needs to be on to provide VDD
- - mount-matrix: an optional 3x3 mounting rotation matrix
+ - gpios : AK8975 has a "Data ready" pin (DRDY) which informs that data
+ is ready to be read and is possible to listen on it. If used,
+ this should be active high. Prefer interrupt over this.
+
+ - interrupts : interrupt for DRDY pin. Triggered on rising edge.
+
+ - vdd-supply: an optional regulator that needs to be on to provide VDD.
+
+ - mount-matrix: an optional 3x3 mounting rotation matrix.
Example:
ak8975@c {
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
- gpios = <&gpj0 7 0>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 IRQ_TYPE_EDGE_RISING>;
vdd-supply = <&ldo_3v3_gnss>;
mount-matrix = "-0.984807753012208", /* x0 */
"0", /* y0 */
--
2.17.1
^ permalink raw reply related
* 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
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...
^ permalink raw reply
* [PATCH v7 0/5] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-28 14:56 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hartmut Knaack, Jonathan Cameron, Lars-Peter Clausen,
Linus Walleij, open list:IIO SUBSYSTEM AND DRIVERS,
Peter Meerwald-Stadler
v7:
- fix documentation style, removing documentation unnecessary parts
v6:
- reword documentation for gpios, add interrupt documentation
https://lore.kernel.org/linux-iio/20200525151117.32540-1-jonathan.albrieux@gmail.com/
v5:
- add maintainer
https://lore.kernel.org/linux-iio/20200520163417.27805-1-jonathan.albrieux@gmail.com/
v4:
- fix some typo
- use gpio's dt-bindings for more clarity in documentation
- set compatible properties without vendor prefix as deprecated
https://lore.kernel.org/linux-iio/20200520073125.30808-1-jonathan.albrieux@gmail.com/
v3:
- fix patch messages style
- align reset gpio comment to kernel doc reccomendation
- introduce changelog
https://lore.kernel.org/linux-iio/20200519124402.26076-1-jonathan.albrieux@gmail.com/
v2:
- rewording of reset gpio comment and patch messages to better clarify
reset gpio behaviour
https://lore.kernel.org/linux-iio/20200518133645.19127-1-jonathan.albrieux@gmail.com/
v1:
- initial patch submission
https://lore.kernel.org/linux-iio/20200519065749.4624-1-jonathan.albrieux@gmail.com/
Convert documentation from txt format to yaml. Add documentation about
reset-gpio.
Deassert reset on ak8975_power_on(), assert reset on ak8975_power_off().
Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.
JonnyMe (5):
dt-bindings: iio: magnetometer: ak8975: reword gpios, add interrupts,
fix style
dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add
maintainer
dt-bindings: iio: magnetometer: ak8975: add gpio reset support
iio: magnetometer: ak8975: Fix typo, uniform measurement unit style
iio: magnetometer: ak8975: Add gpio reset support
.../bindings/iio/magnetometer/ak8975.txt | 30 -------
.../iio/magnetometer/asahi-kasei,ak8975.yaml | 84 +++++++++++++++++++
drivers/iio/magnetometer/ak8975.c | 22 ++++-
3 files changed, 104 insertions(+), 32 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
--
2.17.1
^ permalink raw reply
* Re: [PATCH v3 10/10] dmaengine: dw: Initialize max_sg_nents with nollp flag
From: Andy Shevchenko @ 2020-05-28 14:56 UTC (permalink / raw)
To: Serge Semin
Cc: Vinod Koul, Viresh Kumar, Dan Williams, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200526225022.20405-11-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 01:50:21AM +0300, Serge Semin wrote:
> Multi-block support provides a way to map the kernel-specific SG-table so
> the DW DMA device would handle it as a whole instead of handling the
> SG-list items or so called LLP block items one by one. So if true LLP
> list isn't supported by the DW DMA engine, then soft-LLP mode will be
> utilized to load and execute each LLP-block one by one. The soft-LLP mode
> of the DMA transactions execution might not work well for some DMA
> consumers like SPI due to its Tx and Rx buffers inter-dependency. Let's
> expose the nollp flag indicating the soft-LLP mode by means of the
> max_sg_nents capability, so the DMA consumer would be ready to somehow
> workaround errors caused by such mode being utilized.
>
In principal I agree, one nit below.
If you are okay with it, feel free to add my Rb tag.
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: devicetree@vger.kernel.org
>
> ---
>
> Changelog v3:
> - This is a new patch created as a result of the discussion with Vinud and
> Andy in the framework of DW DMA burst and LLP capabilities.
> ---
> drivers/dma/dw/core.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index 29c4ef08311d..b850eb7fd084 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -1054,6 +1054,15 @@ static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
> struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
>
> caps->max_burst = dwc->max_burst;
> +
> + /*
> + * It might be crucial for some devices to have the hardware
> + * accelerated multi-block transfers supported, aka LLPs in DW DMAC
> + * notation. So if LLPs are supported then max_sg_nents is set to
> + * zero which means unlimited number of SG entries can be handled in a
> + * single DMA transaction, otherwise it's just one SG entry.
> + */
> + caps->max_sg_nents = dwc->nollp;
To be on the safer side I would explicitly do it like
if (dwc->nollp)
/* your nice comment */
= 1;
else
/* Unlimited */
= 0;
type or content of nollp theoretically can be changed and this will affect maximum segments.
> }
>
> int do_dma_probe(struct dw_dma_chip *chip)
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC v3 3/3] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize
From: Rob Herring @ 2020-05-28 14:55 UTC (permalink / raw)
To: Wesley Cheng
Cc: devicetree, agross, linux-usb, linux-arm-msm, balbi, gregkh,
robh+dt, bjorn.andersson, linux-kernel
In-Reply-To: <1590630363-3934-4-git-send-email-wcheng@codeaurora.org>
On Wed, 27 May 2020 18:46:03 -0700, Wesley Cheng wrote:
> Re-introduce the comment for the tx-fifo-resize setting for the DWC3
> controller. This allows for vendors to control if they require the TX FIFO
> resizing logic on their HW, as the default FIFO size configurations may
> already be sufficient.
>
> Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
> ---
> Documentation/devicetree/bindings/usb/dwc3.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
^ 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
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.
^ permalink raw reply
* Re: [PATCH v3 08/10] dmaengine: dw: Add dummy device_caps callback
From: Andy Shevchenko @ 2020-05-28 14:53 UTC (permalink / raw)
To: Serge Semin
Cc: Vinod Koul, Viresh Kumar, Dan Williams, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200526225022.20405-9-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 01:50:19AM +0300, Serge Semin wrote:
> Since some DW DMA controllers (like one installed on Baikal-T1 SoC) may
> have non-uniform DMA capabilities per device channels, let's add
> the DW DMA specific device_caps callback to expose that specifics up to
> the DMA consumer. It's a dummy function for now. We'll fill it in with
> capabilities overrides in the next commits.
I think per se it is not worth to have it separated. Squash into the next one.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 09/10] dmaengine: dw: Introduce max burst length hw config
From: Andy Shevchenko @ 2020-05-28 14:52 UTC (permalink / raw)
To: Serge Semin
Cc: Vinod Koul, Viresh Kumar, Dan Williams, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200526225022.20405-10-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 01:50:20AM +0300, Serge Semin wrote:
> IP core of the DW DMA controller may be synthesized with different
> max burst length of the transfers per each channel. According to Synopsis
> having the fixed maximum burst transactions length may provide some
> performance gain. At the same time setting up the source and destination
> multi size exceeding the max burst length limitation may cause a serious
> problems. In our case the DMA transaction just hangs up. In order to fix
> this lets introduce the max burst length platform config of the DW DMA
> controller device and don't let the DMA channels configuration code
> exceed the burst length hardware limitation.
>
> Note the maximum burst length parameter can be detected either in runtime
> from the DWC parameter registers or from the dedicated DT property.
> Depending on the IP core configuration the maximum value can vary from
> channel to channel so by overriding the channel slave max_burst capability
> we make sure a DMA consumer will get the channel-specific max burst
> length.
...
> static void dwc_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
> {
> + struct dw_dma_chan *dwc = to_dw_dma_chan(chan);
>
Perhaps,
/* DesignWare DMA supports burst value from 0 */
caps->min_burst = 0;
> + caps->max_burst = dwc->max_burst;
> }
...
> + *maxburst = clamp(*maxburst, 0U, dwc->max_burst);
Shouldn't we do the same for iDMA 32-bit? Thus, perhaps do it in the core.c?
> *maxburst = *maxburst > 1 ? fls(*maxburst) - 2 : 0;
> + if (!of_property_read_u32_array(np, "snps,max-burst-len", mb,
> + nr_channels)) {
> + for (tmp = 0; tmp < nr_channels; tmp++)
> + pdata->max_burst[tmp] = mb[tmp];
I think we may read directly to the array. This ugly loops were introduced due
to type mismatch. (See below)
> + } else {
> + for (tmp = 0; tmp < nr_channels; tmp++)
> + pdata->max_burst[tmp] = DW_DMA_MAX_BURST;
> + }
And this will be effectively memset32().
> unsigned char nr_masters;
> unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
> unsigned char multi_block[DW_DMA_MAX_NR_CHANNELS];
> + unsigned int max_burst[DW_DMA_MAX_NR_CHANNELS];
I think we have to stop with this kind of types and use directly what is in the
properties, i.e.
u32 max_burst[...];
--
With Best Regards,
Andy Shevchenko
^ 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: linux-kernel, Suzuki K Poulose, Leo Yan, Tingwei Zhang,
Rob Herring, Mathieu Poirier, linux-arm-msm, coresight,
Mike Leach, linux-arm-kernel, devicetree, Stephen Boyd
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>
^ 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, devicetree, Thomas Petazzoni, Paul Cercueil,
Chuanhong Guo, Weijie Gao, linux-arm-kernel, Mason Yang,
Julien Su
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.
^ 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, devicetree, Thomas Petazzoni, Paul Cercueil,
Chuanhong Guo, Weijie Gao, linux-arm-kernel, Mason Yang,
Julien Su
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?
^ 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: Sai Prakash Ranjan, Suzuki K Poulose, Mike Leach, devicetree,
linux-arm-kernel, linux-kernel, linux-arm-msm, Stephen Boyd
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>
^ permalink raw reply
* [PATCH] dt-bindings: sound: tlv320adcx140: Fix dt-binding-check issue
From: Dan Murphy @ 2020-05-28 14:47 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, robh
Cc: alsa-devel, linux-kernel, devicetree, Dan Murphy
Fix dt-binding-check issue
ti,gpi-config:0:0: 4 is greater than the maximum of 1
ti,gpi-config:0:1: 5 is greater than the maximum of 1
ti,gpi-config:0:2: 6 is greater than the maximum of 1
ti,gpi-config:0:3: 7 is greater than the maximum of 1
Reported-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
Documentation/devicetree/bindings/sound/tlv320adcx140.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
index e8a69b1c7ca9..306ac3d006dc 100644
--- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
+++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml
@@ -109,7 +109,7 @@ properties:
- minItems: 1
maxItems: 4
items:
- maximum: 1
+ maximum: 7
default: [0, 0, 0, 0]
required:
--
2.26.2
^ permalink raw reply related
* 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
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();
^ 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
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!
^ permalink raw reply
* [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: stable@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring
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
^ permalink raw reply related
* [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: stable@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring
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
^ permalink raw reply related
* Re: [PATCH v11 4/4] power: supply: bq25150 introduce the bq25150
From: Andrew F. Davis @ 2020-05-28 14:43 UTC (permalink / raw)
To: Ricardo Rivera-Matos, sre, pali, robh
Cc: dmurphy, linux-pm, linux-kernel, devicetree, sspatil
In-Reply-To: <20200528140546.25260-5-r-rivera-matos@ti.com>
On 5/28/20 10:05 AM, Ricardo Rivera-Matos wrote:
> +static int bq2515x_set_precharge_current(struct bq2515x_device *bq2515x,
> + int val)
> +{
> + int ret;
> + unsigned int pchrgctrl;
> + unsigned int icharge_range;
> + unsigned int precharge_reg_code;
> + u16 precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
> + u16 precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA;
Why u16? looks like it gets promoted everywhere it's used anyway.
> +
> + ret = regmap_read(bq2515x->regmap, BQ2515X_PCHRGCTRL, &pchrgctrl);
> + if (ret)
> + return ret;
> +
> + icharge_range = pchrgctrl & BQ2515X_ICHARGE_RANGE;
> +
> + if (icharge_range) {
> + precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_3750_UA;
> + precharge_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
This is a little hard to read when we have a default value overwritten
in an if, it basically hides the else logic, suggest:
if (icharge_range) {
precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_3750_UA;
precharge_multiplier = BQ2515X_ICHG_RNG_1B1_UA;
} else {
precharge_max_ua = BQ2515X_PRECHRG_ICHRG_RNGE_1875_UA;
precharge_multiplier = BQ2515X_ICHG_RNG_1B0_UA;
}
> + }
> + if (val > precharge_max_ua || val < BQ2515X_ICHG_MIN_UA)
> + return -EINVAL;
> +
> + precharge_reg_code = val / precharge_multiplier;
> +
> + ret = bq2515x_set_charge_disable(bq2515x, 1);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(bq2515x->regmap, BQ2515X_PCHRGCTRL,
> + BQ2515X_PRECHARGE_MASK, precharge_reg_code);
> + if (ret)
> + return ret;
> +
> + return bq2515x_set_charge_disable(bq2515x, 0);
> +}
[snip]
> +
> +static int bq2515x_set_ilim_lvl(struct bq2515x_device *bq2515x, int val)
> +{
> + int i = 0;
> + unsigned int array_size = ARRAY_SIZE(bq2515x_ilim_lvl_values);
> +
> + if (val >= bq2515x_ilim_lvl_values[array_size - 1]) {
Isn't this check the same as is done in first iteration of the below loop?
Andrew
> + i = array_size - 1;
> + } else {
> + for (i = array_size - 1; i > 0; i--) {
> + if (val >= bq2515x_ilim_lvl_values[i])
> + break;
> + }
> + }
> + return regmap_write(bq2515x->regmap, BQ2515X_ILIMCTRL, i);
> +}
> +
^ permalink raw reply
* Re: [PATCH v3 05/10] dmaengine: Introduce DMA-device device_caps callback
From: Andy Shevchenko @ 2020-05-28 14:42 UTC (permalink / raw)
To: Serge Semin
Cc: Vinod Koul, Viresh Kumar, Dan Williams, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200526225022.20405-6-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 01:50:16AM +0300, Serge Semin wrote:
> There are DMA devices (like ours version of Synopsys DW DMAC) which have
> DMA capabilities non-uniformly redistributed amongst the device channels.
> In order to provide a way of exposing the channel-specific parameters to
> the DMA engine consumers, we introduce a new DMA-device callback. In case
> if provided it gets called from the dma_get_slave_caps() method and is
> able to override the generic DMA-device capabilities.
> + if (device->device_caps)
> + device->device_caps(chan, caps);
> +
> return 0;
I dunno why this returns int, but either we get rid of this returned value
(perhaps in the future, b/c it's not directly related to this series), or
something like
if (device->device_caps)
return device->device_caps(chan, caps);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
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?
^ 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, devicetree, Thomas Petazzoni, Paul Cercueil,
Chuanhong Guo, Weijie Gao, linux-arm-kernel, Mason Yang,
Julien Su
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.
^ 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 14:34 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
In-Reply-To: <20200528113113.9166-15-miquel.raynal@bootlin.com>
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.
> */
> struct nand_ecc_props {
> + enum nand_ecc_engine_type engine_type;
> + enum nand_ecc_placement placement;
> + enum nand_ecc_algo algo;
> unsigned int strength;
> unsigned int step_size;
> + unsigned int flags;
> };
>
> #define NAND_ECCREQ(str, stp) { .strength = (str), .step_size = (stp) }
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index c3411a08ce61..8f7f1cce3b4b 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -92,50 +92,6 @@ enum nand_ecc_mode {
> NAND_ECC_ON_DIE,
> };
>
> -/**
> - * 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,
> -};
> -
> /*
> * Constants for Hardware ECC
> */
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: sound: tlv320adcx140: Add GPI config property
From: Rob Herring @ 2020-05-28 14:32 UTC (permalink / raw)
To: Dan Murphy
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
devicetree, Linux-ALSA, linux-kernel@vger.kernel.org
In-Reply-To: <23500301-1076-ac47-327e-f7731525657c@ti.com>
On Thu, May 28, 2020 at 8:20 AM Dan Murphy <dmurphy@ti.com> wrote:
>
> Rob
>
> On 5/28/20 9:05 AM, Rob Herring wrote:
> > On Tue, May 26, 2020 at 03:09:16PM -0500, Dan Murphy wrote:
> >> Add an array property that configures the General Purpose Input (GPI)
> >> register. The device has 4 GPI pins and each pin can be configured in 1
> >> of 7 different ways.
> > Dan seems to have trouble running get_maintainers.pl and Cc'ing the DT
> > list. Running 'make dt_binding_check' also seems to be a problem. Now
> > linux-next has these warnings:
>
> I don't have an issue with doing get_maintainers. All the maintainers
> listed were added to the patch.
>
> And devicetree@vger.kernel.org was cc'd.
Indeed, sorry for my rant. Some reason my search didn't find it.
Not sure why my tester didn't flag this either...
Rob
^ permalink raw reply
* Re: [PATCH v6 08/18] mtd: rawnand: Use the new ECC engine type enumeration
From: Boris Brezillon @ 2020-05-28 14:31 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
In-Reply-To: <20200528113113.9166-9-miquel.raynal@bootlin.com>
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.
^ permalink raw reply
* [PATCH v4 2/3] hwmon: Add notification support
From: Serge Semin @ 2020-05-28 14:28 UTC (permalink / raw)
To: Jean Delvare, Guenter Roeck
Cc: Serge Semin, Serge Semin, Maxim Kaurkin, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, Rob Herring, linux-mips,
devicetree, linux-hwmon, linux-kernel
In-Reply-To: <20200528142805.29115-1-Sergey.Semin@baikalelectronics.ru>
From: Guenter Roeck <linux@roeck-us.net>
For hwmon drivers using the hwmon_device_register_with_info() API, it
is desirable to have a generic notification mechanism available. This
mechanism can be used to notify userspace as well as the thermal
subsystem if the driver experiences any events, such as warning or
critical alarms.
Implement hwmon_notify_event() to provide this mechanism. The function
generates a sysfs event and a udev event. If the device is registered
with the thermal subsystem and the event is associated with a temperature
sensor, also notify the thermal subsystem that a thermal event occurred.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Guenter: I have no plan to push this since there are currently no users
(and thus no means to test the code). However, I want to make sure that
the patch is available if/when needed.
Serge: There is a user now. It's Baikal-T1 PVT driver. So the patch can
be merged in.
Changelog v2: Skipped
Changelog v3:
- Fix merge conflicts found in struct hwmon_thermal_data and in
hwmon_thermal_add_sensors().
- Use hwmon_attr_base() to get the hwmon attribute base index.
- Use the base value to get the sysfs-attribute name.
hwmon_thermal_notify() is supposed to be called with normal index.
---
drivers/hwmon/hwmon.c | 69 +++++++++++++++++++++++++++++++++++++++++--
include/linux/hwmon.h | 3 ++
2 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index 6a30fb453f7a..e9bc33c18a33 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -15,6 +15,7 @@
#include <linux/gfp.h>
#include <linux/hwmon.h>
#include <linux/idr.h>
+#include <linux/list.h>
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/slab.h>
@@ -31,7 +32,7 @@ struct hwmon_device {
const char *name;
struct device dev;
const struct hwmon_chip_info *chip;
-
+ struct list_head tzdata;
struct attribute_group group;
const struct attribute_group **groups;
};
@@ -55,12 +56,12 @@ struct hwmon_device_attribute {
/*
* Thermal zone information
- * In addition to the reference to the hwmon device,
- * also provides the sensor index.
*/
struct hwmon_thermal_data {
+ struct list_head node; /* hwmon tzdata list entry */
struct device *dev; /* Reference to hwmon device */
int index; /* sensor index */
+ struct thermal_zone_device *tzd;/* thermal zone device */
};
static ssize_t
@@ -156,10 +157,17 @@ static const struct thermal_zone_of_device_ops hwmon_thermal_ops = {
.get_temp = hwmon_thermal_get_temp,
};
+static void hwmon_thermal_remove_sensor(void *data)
+{
+ list_del(data);
+}
+
static int hwmon_thermal_add_sensor(struct device *dev, int index)
{
+ struct hwmon_device *hwdev = to_hwmon_device(dev);
struct hwmon_thermal_data *tdata;
struct thermal_zone_device *tzd;
+ int err;
tdata = devm_kzalloc(dev, sizeof(*tdata), GFP_KERNEL);
if (!tdata)
@@ -177,13 +185,37 @@ static int hwmon_thermal_add_sensor(struct device *dev, int index)
if (IS_ERR(tzd) && (PTR_ERR(tzd) != -ENODEV))
return PTR_ERR(tzd);
+ err = devm_add_action(dev, hwmon_thermal_remove_sensor, &tdata->node);
+ if (err)
+ return err;
+
+ tdata->tzd = tzd;
+ list_add(&tdata->node, &hwdev->tzdata);
+
return 0;
}
+
+static void hwmon_thermal_notify(struct device *dev, int index)
+{
+ struct hwmon_device *hwdev = to_hwmon_device(dev);
+ struct hwmon_thermal_data *tzdata;
+
+ list_for_each_entry(tzdata, &hwdev->tzdata, node) {
+ if (tzdata->index == index) {
+ thermal_zone_device_update(tzdata->tzd,
+ THERMAL_EVENT_UNSPECIFIED);
+ }
+ }
+}
+
#else
static int hwmon_thermal_add_sensor(struct device *dev, int index)
{
return 0;
}
+
+static void hwmon_thermal_notify(struct device *dev, int index) { }
+
#endif /* IS_REACHABLE(CONFIG_THERMAL) && ... */
static int hwmon_attr_base(enum hwmon_sensor_types type)
@@ -511,6 +543,35 @@ static const int __templates_size[] = {
[hwmon_intrusion] = ARRAY_SIZE(hwmon_intrusion_attr_templates),
};
+int hwmon_notify_event(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ char sattr[MAX_SYSFS_ATTR_NAME_LENGTH];
+ const char * const *templates;
+ const char *template;
+ int base;
+
+ if (type >= ARRAY_SIZE(__templates))
+ return -EINVAL;
+ if (attr >= __templates_size[type])
+ return -EINVAL;
+
+ templates = __templates[type];
+ template = templates[attr];
+
+ base = hwmon_attr_base(type);
+
+ scnprintf(sattr, MAX_SYSFS_ATTR_NAME_LENGTH, template, base + channel);
+ sysfs_notify(&dev->kobj, NULL, sattr);
+ kobject_uevent(&dev->kobj, KOBJ_CHANGE);
+
+ if (type == hwmon_temp)
+ hwmon_thermal_notify(dev, channel);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(hwmon_notify_event);
+
static int hwmon_num_channel_attrs(const struct hwmon_channel_info *info)
{
int i, n;
@@ -661,6 +722,8 @@ __hwmon_device_register(struct device *dev, const char *name, void *drvdata,
if (err)
goto free_hwmon;
+ INIT_LIST_HEAD(&hwdev->tzdata);
+
if (dev && dev->of_node && chip && chip->ops->read &&
chip->info[0]->type == hwmon_chip &&
(chip->info[0]->config[0] & HWMON_C_REGISTER_TZ)) {
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index 5e609f25878c..363d4a814aa1 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -436,6 +436,9 @@ devm_hwmon_device_register_with_info(struct device *dev,
void hwmon_device_unregister(struct device *dev);
void devm_hwmon_device_unregister(struct device *dev);
+int hwmon_notify_event(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel);
+
/**
* hwmon_is_bad_char - Is the char invalid in a hwmon name
* @ch: the char to be considered
--
2.26.2
^ 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