* Re: [PATCH 1/1] dt-bindings: rng: Convert OMAP RNG to schema
From: Rob Herring @ 2020-05-28 15:27 UTC (permalink / raw)
To: Tero Kristo; +Cc: linux-crypto, devicetree, mpm, herbert, robh+dt
In-Reply-To: <20200514131947.28094-1-t-kristo@ti.com>
On Thu, 14 May 2020 16:19:47 +0300, Tero Kristo wrote:
> Convert TI OMAP Random number generator bindings to DT schema.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../devicetree/bindings/rng/omap_rng.txt | 38 ---------
> .../devicetree/bindings/rng/ti,omap-rng.yaml | 77 +++++++++++++++++++
> 2 files changed, 77 insertions(+), 38 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/rng/omap_rng.txt
> create mode 100644 Documentation/devicetree/bindings/rng/ti,omap-rng.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 08/10] dmaengine: dw: Add dummy device_caps callback
From: Serge Semin @ 2020-05-28 15:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Vinod Koul, Viresh Kumar, Dan Williams,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200528145303.GU1634618@smile.fi.intel.com>
On Thu, May 28, 2020 at 05:53:03PM +0300, Andy Shevchenko wrote:
> 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.
bikeshadding? There is no any difference whether I add a dummy callback, then
fill it in in a following up patch, or have the callback added together
with some content. Let's see what Vinod thinks of it. Until then I'll stick with
the current solution.
-Sergey
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCHv3 1/7] dt-bindings: crypto: Add TI SA2UL crypto accelerator documentation
From: Rob Herring @ 2020-05-28 15:23 UTC (permalink / raw)
To: Tero Kristo; +Cc: herbert, davem, Keerthy, devicetree, linux-crypto
In-Reply-To: <20200514125005.23641-1-t-kristo@ti.com>
On Thu, 14 May 2020 15:50:05 +0300, Tero Kristo wrote:
> From: Keerthy <j-keerthy@ti.com>
>
> The Security Accelerator Ultra Lite (SA2UL) subsystem provides hardware
> cryptographic acceleration for the following use cases:
>
> * Encryption and authentication for secure boot
> * Encryption and authentication of content in applications
> requiring DRM (digital rights management) and
> content/asset protection
>
> SA2UL provides support for number of different cryptographic algorithms
> including SHA1, SHA256, SHA512, AES, 3DES, and various combinations of
> the previous for AEAD use.
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> [t-kristo@ti.com: converted documentation to yaml]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> v3:
> - fixed a typo in rng child node regex
>
> .../devicetree/bindings/crypto/ti,sa2ul.yaml | 76 +++++++++++++++++++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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: linux-pci, Masahiro Yamada, linux-kernel, devicetree, Jassi Brar,
Rob Herring, Masami Hiramatsu, linux-arm-kernel, Bjorn Helgaas,
Lorenzo Pieralisi
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>
^ permalink raw reply
* Re: [PATCH v3 05/10] dmaengine: Introduce DMA-device device_caps callback
From: Serge Semin @ 2020-05-28 15:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Vinod Koul, Viresh Kumar, Dan Williams,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200528144257.GS1634618@smile.fi.intel.com>
On Thu, May 28, 2020 at 05:42:57PM +0300, Andy Shevchenko wrote:
> 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);
It returns int because dma_get_slave_caps() check parameters and some other
stuff.
Regarding device_caps() callback having a return value. IMO it's redundant.
The only thing what the callback should do is to update the caps and device
is supposed to know it' capabilities, otherwise who else should know? So I
don't see why device_caps would be needed.
-Sergey
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ 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: thierry.reding, linux-pwm, Linux-imx, u.kleine-koenig, festevam,
devicetree, s.hauer, linux-arm-kernel, kernel, robh+dt,
linux-kernel, shawnguo
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!
^ permalink raw reply
* Re: [PATCH] dt-bindings: auxdisplay: hd44780: Convert to json-schema
From: Rob Herring @ 2020-05-28 15:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Miguel Ojeda Sandonis, linux-kernel, devicetree
In-Reply-To: <20200514113003.19067-1-geert@linux-m68k.org>
On Thu, 14 May 2020 13:30:02 +0200, Geert Uytterhoeven wrote:
> Convert the Hitachi HD44780 Character LCD Controller Device Tree binding
> documentation to json-schema.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> .../bindings/auxdisplay/hit,hd44780.txt | 45 ---------
> .../bindings/auxdisplay/hit,hd44780.yaml | 96 +++++++++++++++++++
> 2 files changed, 96 insertions(+), 45 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
> create mode 100644 Documentation/devicetree/bindings/auxdisplay/hit,hd44780.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 6/6] dt-bindings: drm/msm/gpu: Document gpu opp table
From: Rob Herring @ 2020-05-28 15:14 UTC (permalink / raw)
To: Sharat Masetty
Cc: devicetree, mka, linux-arm-msm, linux-kernel, georgi.djakov,
dri-devel, freedreno
In-Reply-To: <1589453659-27581-7-git-send-email-smasetty@codeaurora.org>
On Thu, 14 May 2020 16:24:19 +0530, Sharat Masetty wrote:
> Update documentation to list the gpu opp table bindings including the
> newly added "opp-peak-kBps" needed for GPU-DDR bandwidth scaling.
>
> Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
> ---
> .../devicetree/bindings/display/msm/gpu.txt | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4] dt-bindings: display: anx7814.txt: convert to yaml
From: Rob Herring @ 2020-05-28 15:13 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: devicetree, robh+dt, enric.balletbo, kernel, dri-devel
In-Reply-To: <20200514101235.7290-1-ricardo.canuelo@collabora.com>
On Thu, 14 May 2020 12:12:35 +0200, Ricardo Cañuelo wrote:
> This converts the Analogix ANX7814 bridge DT binding to yaml. Port
> definitions and descriptions were expanded, apart from that it's a
> direct translation from the original binding.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> Changes in v4:
> - Make interrupts and gpios optional (Enric Balletbo)
> - Make hpd-gpios deprecated (Rob Herring)
> - Remove maxItems from dvdd10-supply
>
> Changes in v3 (suggested by Sam Ravnborg):
> - Rename example node i2c0 to i2c.
>
> Changes in v2 (suggested by Enric Balletbo):
> - File name change: use full compatible string.
> - Binding description removed.
> - #address-cells and #size-cells properties removed from ports node.
> - Example node renamed: anx7814 -> bridge.
>
> Tested with:
> make dt_binding_check ARCH=arm64 DT_SCHEMA_FILES=<.../analogix,anx7814.yaml>
> make dtbs_check ARCH=arm64 DT_SCHEMA_FILES=<.../analogix,anx7814.yaml>
>
> .../display/bridge/analogix,anx7814.yaml | 119 ++++++++++++++++++
> .../bindings/display/bridge/anx7814.txt | 42 -------
> 2 files changed, 119 insertions(+), 42 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/anx7814.txt
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v4 0/3] hwmon: Add Baikal-T1 SoC Process, Voltage and Temp sensor support
From: Guenter Roeck @ 2020-05-28 15:08 UTC (permalink / raw)
To: Serge Semin
Cc: Jean Delvare, Serge Semin, Maxim Kaurkin, Alexey Malahov,
Pavel Parkhomenko, Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov,
Alexey Kolotnikov, Thomas Bogendoerfer, Arnd Bergmann,
Rob Herring, linux-mips, linux-hwmon, devicetree, linux-kernel
In-Reply-To: <20200528142805.29115-1-Sergey.Semin@baikalelectronics.ru>
On Thu, May 28, 2020 at 05:28:02PM +0300, Serge Semin wrote:
> In order to keep track of Baikal-T1 SoC power consumption and make sure
> the chip heating is within the normal temperature limits, there is
> a dedicated hardware monitor sensor embedded into the SoC. It is based
> on the Analog Bits PVT sensor but equipped with a vendor-specific control
> wrapper, which ease an access to the sensors functionality. Fist of all it
> provides an accessed to the sampled Temperature, Voltage and
> Low/Standard/High Voltage thresholds. In addition the wrapper generates
> an interrupt in case if one enabled for alarm thresholds or data ready
> event. All of these functionality is implemented in the Baikal-T1 PVT
> driver submitted within this patchset. Naturally there is also a patch,
> which creates a corresponding yaml-based dt-binding file for the sensor.
>
> This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
> base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
> tag: v5.7-rc4
>
Series applied to hwmon-next.
Thanks,
Guenter
> Note new vendor prefix for Baikal-T1 PVT device will be added in the
> framework of the next patchset:
> https://lkml.org/lkml/2020/5/6/1047
>
> Changelog v2:
> - Don't use a multi-arg clock phandle reference in the examples dt-bindings
> property. Thus reundant include pre-processor statement can be removed.
> - Rearrange the SoBs with adding Maxim' co-development tag.
> - Lowercase the node-name in the dt-schema example.
> - Add dual license header to the dt-bindings file.
> - Replace "additionalProperties: false" property with
> "unevaluatedProperties: false".
> - Discard label definition from the binding example.
> - Discard handwritten IO-access wrappers. Use normal readl/writel instead.
> - Use generic FIELD_{GET,PREP} macros instead of handwritten ones.
> - Since the driver depends on the OF config we can remove of_match_ptr()
> macro utilization.
> - Don't print error-message if no platform IRQ found. Just return an error.
> - Remove probe-status info string printout.
> - Our corporate email server doesn't change Message-Id anymore, so the patchset
> is resubmitted being in the cover-letter-threaded format.
>
> Link: https://lore.kernel.org/linux-hwmon/20200510103211.27905-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v3:
> - Add bt1-pvt into the Documentation/hwmon/index.rst file.
> - Discard explicit "default n" from the SENSORS_BT1_PVT_ALARMS config.
> - Use "depends on SENSORS_BT1_PVT" statement instead of if-endif kbuild
> config clause.
> - Alphabetically order the include macro operators.
> - Discard unneeded include macro in the header file.
> - Use new generic interface of the hwmon alarms notifications introduced
> in the first patch (based on hwmon_notify_event()).
> - Add more descriptive information regarding the temp1_trim attribute.
> - Discard setting the platforms device private data by using
> platform_set_drvdata(). It's redundant since unused in the driver.
> - Pass "pvt" hwmon name instead of dev_name(dev) to
> devm_hwmon_device_register_with_info().
> - Add "baikal,pvt-temp-trim-millicelsius" temperature trim DT property
> support.
> - Discard kernel log warnings printed from the ISR when either min or
> max threshold levels are crossed.
> - Discard CONFIG_OF dependency since there is non at compile-time.
>
> Link: https://lore.kernel.org/linux-hwmon/20200526133823.20466-1-Sergey.Semin@baikalelectronics.ru
> Changelog v4:
> - Rename temp1_trim to the temp1_offset and use the standard API to
> expose the attribute.
> - Rename "baikal,pvt-temp-trim-millicelsius" DT property to
> "baikal,pvt-temp-offset-millicelsius".
> - Switch "const static" order to be "static const" where it's applicable.
> - Add missing headers "linux/io.h" and "linux/of.h".
> - Add static qualifier to the pvt_hwmon_write() method, which has been
> missed there by mistake.
>
> Co-developed-by: Maxim Kaurkin <maxim.kaurkin@baikalelectronics.ru>
> Signed-off-by: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
> Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
> Cc: Alexey Kolotnikov <Alexey.Kolotnikov@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: linux-hwmon@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> Guenter Roeck (1):
> hwmon: Add notification support
>
> Serge Semin (2):
> dt-bindings: hwmon: Add Baikal-T1 PVT sensor binding
> hwmon: Add Baikal-T1 PVT sensor driver
>
> .../bindings/hwmon/baikal,bt1-pvt.yaml | 107 ++
> Documentation/hwmon/bt1-pvt.rst | 117 ++
> Documentation/hwmon/index.rst | 1 +
> drivers/hwmon/Kconfig | 25 +
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/bt1-pvt.c | 1146 +++++++++++++++++
> drivers/hwmon/bt1-pvt.h | 244 ++++
> drivers/hwmon/hwmon.c | 69 +-
> include/linux/hwmon.h | 3 +
> 9 files changed, 1710 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
> create mode 100644 Documentation/hwmon/bt1-pvt.rst
> create mode 100644 drivers/hwmon/bt1-pvt.c
> create mode 100644 drivers/hwmon/bt1-pvt.h
>
> --
> 2.26.2
>
^ 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: 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: <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.
^ permalink raw reply
* Re: [PATCH v9 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Ramuthevar, Vadivel MuruganX @ 2020-05-28 15:03 UTC (permalink / raw)
To: Rob Herring
Cc: vigneshr, linux-kernel, arnd, hauke.mehrtens, linux-mips, richard,
qi-ming.wu, tglx, brendanhiggins, linux-mtd, boris.brezillon,
anders.roxell, cheol.yong.kim, devicetree, miquel.raynal,
andriy.shevchenko, robh+dt, masonccyang
In-Reply-To: <20200528140606.GA4173978@bogus>
Hi Rob,
On 28/5/2020 10:06 pm, Rob Herring wrote:
> On Thu, 28 May 2020 13:12:10 +0800, Ramuthevar,Vadivel MuruganX wrote:
>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>
>> Add YAML file for dt-bindings to support NAND Flash Controller
>> on Intel's Lightning Mountain SoC.
>>
>> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>> ---
>> .../devicetree/bindings/mtd/intel,lgm-nand.yaml | 93 ++++++++++++++++++++++
>> 1 file changed, 93 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>>
>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f00000: '#address-cells', '#size-cells' do not match any of the regexes: '^nand@[a-f0-9]+$', 'pinctrl-[0-9]+'
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f00000: nand@0: '#address-cells', '#size-cells', 'nand-on-flash-bbt' do not match any of the regexes: 'pinctrl-[0-9]+'
>
> See https://patchwork.ozlabs.org/patch/1299399
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure dt-schema is up to date:
>
> pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
>
> Please check and re-submit.
Thank you!!!
Oh my bad, used old dtc compiler path and didn't see the error, will fix.
Regards
Vadivel
>
^ permalink raw reply
* Re: [PATCH v3] video: fbdev: ssd1307fb: Added support to Column offset
From: Rob Herring @ 2020-05-28 15:02 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: devicetree, andy.shevchenko, linux-fbdev, linux-kernel,
b.zolnierkie, Rodrigo Rolim Mendes de Alencar
In-Reply-To: <1589395691-8762-1-git-send-email-alencar.fmce@imbel.gov.br>
On Wed, 13 May 2020 15:48:11 -0300, Rodrigo Alencar wrote:
> From: Rodrigo Rolim Mendes de Alencar <alencar.fmce@imbel.gov.br>
>
> This patch provides support for displays like VGM128064B0W10,
> which requires a column offset of 2, i.e., its segments starts
> in SEG2 and ends in SEG129.
>
> Signed-off-by: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>
> ---
> Documentation/devicetree/bindings/display/ssd1307fb.txt | 1 +
> drivers/video/fbdev/ssd1307fb.c | 8 ++++++--
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
Acked-by: Rob Herring <robh@kernel.org>
^ 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, linux-arm-kernel, Mason Yang,
Julien Su
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.
^ 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: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, linux-arm-kernel, Mason Yang,
Julien Su
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.
^ permalink raw reply
* [PATCH v7 3/5] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Jonathan Albrieux @ 2020-05-28 14:59 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Rob Herring, open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
Add reset-gpio support.
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.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/iio/magnetometer/asahi-kasei,ak8975.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
index 55b18784e503..e8af53d60759 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
@@ -47,6 +47,11 @@ properties:
mount-matrix:
description: an optional 3x3 mounting rotation matrix.
+ reset-gpios:
+ description: |
+ an optional pin needed for AK09911 to set the reset state. This should
+ be usually active low
+
required:
- compatible
- reg
@@ -54,6 +59,7 @@ required:
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -64,6 +70,7 @@ examples:
interrupt-parent = <&gpio6>;
interrupts = <15 IRQ_TYPE_EDGE_RISING>;
vdd-supply = <&ldo_3v3_gnss>;
+ reset-gpios = <&msmgpio 111 GPIO_ACTIVE_LOW>;
mount-matrix = "-0.984807753012208", /* x0 */
"0", /* y0 */
"-0.173648177666930", /* z0 */
--
2.17.1
^ permalink raw reply related
* [PATCH v7 2/5] dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add maintainer
From: Jonathan Albrieux @ 2020-05-28 14:58 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Rob Herring, open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
Converts documentation from txt format to yaml.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
.../bindings/iio/magnetometer/ak8975.txt | 37 ---------
.../iio/magnetometer/asahi-kasei,ak8975.yaml | 77 +++++++++++++++++++
2 files changed, 77 insertions(+), 37 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
deleted file mode 100644
index 0576b9df0bf2..000000000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-* AsahiKASEI AK8975 magnetometer sensor
-
-Required properties:
-
- - compatible : should be "asahi-kasei,ak8975".
- - reg : the I2C address of the magnetometer.
-
-Optional properties:
-
- - 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>;
- interrupt-parent = <&gpio6>;
- interrupts = <15 IRQ_TYPE_EDGE_RISING>;
- vdd-supply = <&ldo_3v3_gnss>;
- mount-matrix = "-0.984807753012208", /* x0 */
- "0", /* y0 */
- "-0.173648177666930", /* z0 */
- "0", /* x1 */
- "-1", /* y1 */
- "0", /* z1 */
- "-0.173648177666930", /* x2 */
- "0", /* y2 */
- "0.984807753012208"; /* z2 */
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
new file mode 100644
index 000000000000..55b18784e503
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/asahi-kasei,ak8975.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AsahiKASEI AK8975 magnetometer sensor
+
+maintainers:
+ - Jonathan Albrieux <jonathan.albrieux@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - asahi-kasei,ak8975
+ - asahi-kasei,ak8963
+ - asahi-kasei,ak09911
+ - asahi-kasei,ak09912
+ - enum:
+ - ak8975
+ - ak8963
+ - ak09911
+ - ak09912
+ deprecated: true
+
+ reg:
+ maxItems: 1
+
+ gpios:
+ maxItems: 1
+ description: |
+ 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:
+ maxItems: 1
+ description: interrupt for DRDY pin. Triggered on rising edge.
+
+ vdd-supply:
+ maxItems: 1
+ description: |
+ an optional regulator that needs to be on to provide VDD power to
+ the sensor.
+
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix.
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@c {
+ compatible = "asahi-kasei,ak8975";
+ reg = <0x0c>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 IRQ_TYPE_EDGE_RISING>;
+ vdd-supply = <&ldo_3v3_gnss>;
+ mount-matrix = "-0.984807753012208", /* x0 */
+ "0", /* y0 */
+ "-0.173648177666930", /* z0 */
+ "0", /* x1 */
+ "-1", /* y1 */
+ "0", /* z1 */
+ "-0.173648177666930", /* x2 */
+ "0", /* y2 */
+ "0.984807753012208"; /* z2 */
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [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
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