On Wed, 13 May 2020, Dan Murphy wrote:
> Add a device tree property to configure the PDM sampling edge for each
> digital microphone.
>
> CC: Rob Herring
> Signed-off-by: Dan Murphy
> ---
> .../devicetree/bindings/sound/tlv320adcx140.yaml | 14 ++
> 1 file changed, 14
Sorry for the repost, I relized I stupidly got Greg's email adress wrong
first time around.
> > On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
> > > On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
> > > > On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
> >
> > On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
> > > On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
> > > > On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
> > >
> > > > > > If the DAI format setup fails, there is no valid communication
> > > > > >
On Wed, 28 Aug 2019, Sasha Levin wrote:
> On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
> > On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
> > > On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
> >
> > > > > If the DAI format setup fails, there is no
On Wed, 14 Nov 2018, Clément Péron wrote:
> > > The AK4118A is a digital audio transceiver supporting 8 input channels
> > > at 192kHz and with 24bits resolution.
> > > It converts the S/PDIF signal to I2S format and is configurable over I2C.
> > >
> > > This driver introduce a minimal support
On Wed, 14 Nov 2018, Clément Péron wrote:
> > > The AK4118A is a digital audio transceiver supporting 8 input channels
> > > at 192kHz and with 24bits resolution.
> > > It converts the S/PDIF signal to I2S format and is configurable over I2C.
> > >
> > > This driver introduce a minimal support
On Wed, 14 Nov 2018, Clément Péron wrote:
> From: Adrien Charruel
>
> The AK4118A is a digital audio transceiver supporting 8 input channels
> at 192kHz and with 24bits resolution.
> It converts the S/PDIF signal to I2S format and is configurable over I2C.
>
> This driver introduce a minimal
On Wed, 14 Nov 2018, Clément Péron wrote:
> From: Adrien Charruel
>
> The AK4118A is a digital audio transceiver supporting 8 input channels
> at 192kHz and with 24bits resolution.
> It converts the S/PDIF signal to I2S format and is configurable over I2C.
>
> This driver introduce a minimal
On Mon, 8 May 2017, David Woodhouse wrote:
> > On Mon, 8 May 2017, David Woodhouse wrote:
> > > Our empirical testing trumps your "can never happen" theory :)
> >
> > I'm sure it does. But what is the explanation then? Has anyone analyzed
> > what is going on using an oscilloscope to verify
On Mon, 8 May 2017, David Woodhouse wrote:
> > On Mon, 8 May 2017, David Woodhouse wrote:
> > > Our empirical testing trumps your "can never happen" theory :)
> >
> > I'm sure it does. But what is the explanation then? Has anyone analyzed
> > what is going on using an oscilloscope to verify
On Mon, 8 May 2017, David Woodhouse wrote:
> > I've got a problem with the underlying mechanism. How long does it take to
> > erase a NAND block? A couple of milliseconds. That means that for an erase
> > to be "weak" du to a power fail, the host CPU must issue an erase command,
> > and then
On Mon, 8 May 2017, David Woodhouse wrote:
> > I've got a problem with the underlying mechanism. How long does it take to
> > erase a NAND block? A couple of milliseconds. That means that for an erase
> > to be "weak" du to a power fail, the host CPU must issue an erase command,
> > and then
On Mon, 8 May 2017, David Woodhouse wrote:
> > [Issue is, if you powerdown during erase, you get "weakly erased"
> > page, which will contain expected 0xff's, but you'll get bitflips
> > there quickly. Similar issue exists for writes. It is solveable in
> > software, just hard and slow... and we
On Mon, 8 May 2017, David Woodhouse wrote:
> > [Issue is, if you powerdown during erase, you get "weakly erased"
> > page, which will contain expected 0xff's, but you'll get bitflips
> > there quickly. Similar issue exists for writes. It is solveable in
> > software, just hard and slow... and we
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > Something that I am mildly miffed about is that I've posted this driver
> > twice before on the mtd list (although, admittedly, not directly addressed
> > to any maintainer), first as an RFC and later as a complete patch, without
> > a single
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > Something that I am mildly miffed about is that I've posted this driver
> > twice before on the mtd list (although, admittedly, not directly addressed
> > to any maintainer), first as an RFC and later as a complete patch, without
> > a single
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > Basically, in the general case, the controller can handle a matrix of
> > nand flash chips. There can be a number of banks, each of which can
> > have a number of individual CS lines. For the (in this case academic)
> > case of 3 banks and 4
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > Basically, in the general case, the controller can handle a matrix of
> > nand flash chips. There can be a number of banks, each of which can
> > have a number of individual CS lines. For the (in this case academic)
> > case of 3 banks and 4
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > Something that I am mildly miffed about is that I've posted this driver
> > twice before on the mtd list (although, admittedly, not directly addressed
> > to any maintainer), first as an RFC and later as a complete patch, without
> > a single
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > Something that I am mildly miffed about is that I've posted this driver
> > twice before on the mtd list (although, admittedly, not directly addressed
> > to any maintainer), first as an RFC and later as a complete patch, without
> > a single
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > The use cases as I see are as follows:
> >
> > a) Two identical chips sharing all but the CS lines, in order to implement
> > a seemingly-larger address space. (e.g. two 256 Mbit chips implementing a
> > 4 GB area). In this case, for certain
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> > The use cases as I see are as follows:
> >
> > a) Two identical chips sharing all but the CS lines, in order to implement
> > a seemingly-larger address space. (e.g. two 256 Mbit chips implementing a
> > 4 GB area). In this case, for certain
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> The goal here is to retrieve the controller attached to a given chip in
> order to avoid the global nfc_info variable (and abusing
> nand_get/set_controller_data() to store a pointer to the controller is
> not a good idea either: it's supposed to be
On Fri, 10 Jun 2016, Boris Brezillon wrote:
> The goal here is to retrieve the controller attached to a given chip in
> order to avoid the global nfc_info variable (and abusing
> nand_get/set_controller_data() to store a pointer to the controller is
> not a good idea either: it's supposed to be
On Wed, 8 Jun 2016, Boris Brezillon wrote:
> > > > +Optional properties:
> > > > +- nand-on-flash-bbt: See nand.txt.
> > > > +- #address-cells, #size-cells: See partition.txt.
> > > > +- evatronix,use-bank-select : Use controller bank select function to
> > > > access
> > > > +
On Wed, 8 Jun 2016, Boris Brezillon wrote:
> > > > +Optional properties:
> > > > +- nand-on-flash-bbt: See nand.txt.
> > > > +- #address-cells, #size-cells: See partition.txt.
> > > > +- evatronix,use-bank-select : Use controller bank select function to
> > > > access
> > > > +
On Thu, 9 Jun 2016, Boris Brezillon wrote:
> > > > drivers/mtd/nand/Kconfig |6 +
> > > > drivers/mtd/nand/Makefile |1 +
> > > > drivers/mtd/nand/evatronix_nand.c | 1909
> > > > +
> > > > 3 files changed, 1916 insertions(+)
> > > >
On Thu, 9 Jun 2016, Boris Brezillon wrote:
> > > > drivers/mtd/nand/Kconfig |6 +
> > > > drivers/mtd/nand/Makefile |1 +
> > > > drivers/mtd/nand/evatronix_nand.c | 1909
> > > > +
> > > > 3 files changed, 1916 insertions(+)
> > > >
On Thu, 9 Jun 2016, Boris Brezillon wrote:
> > >
> > > By supporting only a subset of what NAND chips actually support, and
> > > preventing any raw access, you just limit the compatibility of the NAND
> > > controller with rather old NAND chips. For example, your controller
> > > cannot deal
On Thu, 9 Jun 2016, Boris Brezillon wrote:
> > >
> > > By supporting only a subset of what NAND chips actually support, and
> > > preventing any raw access, you just limit the compatibility of the NAND
> > > controller with rather old NAND chips. For example, your controller
> > > cannot deal
Hi Boris,
Again, thanks for reviewing this.
On Fri, 3 Jun 2016, Boris Brezillon wrote:
> > drivers/mtd/nand/Kconfig |6 +
> > drivers/mtd/nand/Makefile |1 +
> > drivers/mtd/nand/evatronix_nand.c | 1909
> > +
> > 3 files changed,
Hi Boris,
Again, thanks for reviewing this.
On Fri, 3 Jun 2016, Boris Brezillon wrote:
> > drivers/mtd/nand/Kconfig |6 +
> > drivers/mtd/nand/Makefile |1 +
> > drivers/mtd/nand/evatronix_nand.c | 1909
> > +
> > 3 files changed,
Hi Boris,
First of all, thanks for reviewing this.
On Fri, 3 Jun 2016, Boris Brezillon wrote:
> > +
> > +Optional properties:
> > +- nand-on-flash-bbt: See nand.txt.
> > +- #address-cells, #size-cells: See partition.txt.
> > +- evatronix,use-bank-select : Use controller bank select function to
Hi Boris,
First of all, thanks for reviewing this.
On Fri, 3 Jun 2016, Boris Brezillon wrote:
> > +
> > +Optional properties:
> > +- nand-on-flash-bbt: See nand.txt.
> > +- #address-cells, #size-cells: See partition.txt.
> > +- evatronix,use-bank-select : Use controller bank select function to
On Mon, 6 Jun 2016, Kamlakant Patel wrote:
> Hi Ricard,
>
> I am using the previous version of your patch on Netlogic XLP MIPS64
> platform with some cleanups, some of them are mentioned by Borris. I can
> send you the patch if you would like to integrate it.
Sure, that would be great!
On Mon, 6 Jun 2016, Kamlakant Patel wrote:
> Hi Ricard,
>
> I am using the previous version of your patch on Netlogic XLP MIPS64
> platform with some cleanups, some of them are mentioned by Borris. I can
> send you the patch if you would like to integrate it.
Sure, that would be great!
On Thu, 2 Jun 2016, Boris Brezillon wrote:
> Hi Ricard,
>
> I was not in Cc of this series, so you're either developing an old
> kernel version, or you didn't check the MAINTAINERS file (or didn't run
> get_maintainer.pl on your series).
The patch is intended to apply to the mtd l2 tree, and I
On Thu, 2 Jun 2016, Boris Brezillon wrote:
> Hi Ricard,
>
> I was not in Cc of this series, so you're either developing an old
> kernel version, or you didn't check the MAINTAINERS file (or didn't run
> get_maintainer.pl on your series).
The patch is intended to apply to the mtd l2 tree, and I
Signed-off-by: Ricard Wanderlof <rica...@axis.com>
---
MAINTAINERS |6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9c567a4..d28b863 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4320,6 +4320,12 @@ F: Documentation/networking/phy.
Signed-off-by: Ricard Wanderlof
---
MAINTAINERS |6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9c567a4..d28b863 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4320,6 +4320,12 @@ F: Documentation/networking/phy.txt
F: drivers/of/of_mdio.c
Add Evatronix NANDFLASH-CTRL NAND flash controller to ARTPEC-6 SoC.
ONFi mode 2 timing has been set as this is compatible also with non-ONFi
SLC NAND flashes, with higher throughput than the default ONFi mode 0.
Signed-off-by: Ricard Wanderlof <rica...@axis.com>
---
arch/arm/boot/dts/a
.
The driver has been extensively tested using hardware ECC on 2 Mbit flash chips,
with 8 bit ECC over 512 bytes ECC blocks.
Signed-off-by: Ricard Wanderlof <rica...@axis.com>
---
drivers/mtd/nand/Kconfig |6 +
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/evatronix_
Add Evatronix NANDFLASH-CTRL NAND flash controller to ARTPEC-6 SoC.
ONFi mode 2 timing has been set as this is compatible also with non-ONFi
SLC NAND flashes, with higher throughput than the default ONFi mode 0.
Signed-off-by: Ricard Wanderlof
---
arch/arm/boot/dts/artpec6.dtsi | 19
.
The driver has been extensively tested using hardware ECC on 2 Mbit flash chips,
with 8 bit ECC over 512 bytes ECC blocks.
Signed-off-by: Ricard Wanderlof
---
drivers/mtd/nand/Kconfig |6 +
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/evatronix_nand.c | 1909
chips are supported, using 4 or 5 address cycles.
The driver has been extensively tested using hardware ECC on 2 Mbit flash chips,
with 8 bit ECC over 512 bytes ECC blocks.
Ricard Wanderlof (4):
of: Add device tree bindings for Evatronix NANDFLASH-CTRL
dts: Add Evatronix NAND flash driver
4 or 5 address cycles.
Signed-off-by: Ricard Wanderlof <rica...@axis.com>
---
.../devicetree/bindings/mtd/evatronix-nand.txt | 44
.../devicetree/bindings/vendor-prefixes.txt|1 +
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devi
chips are supported, using 4 or 5 address cycles.
The driver has been extensively tested using hardware ECC on 2 Mbit flash chips,
with 8 bit ECC over 512 bytes ECC blocks.
Ricard Wanderlof (4):
of: Add device tree bindings for Evatronix NANDFLASH-CTRL
dts: Add Evatronix NAND flash driver
4 or 5 address cycles.
Signed-off-by: Ricard Wanderlof
---
.../devicetree/bindings/mtd/evatronix-nand.txt | 44
.../devicetree/bindings/vendor-prefixes.txt|1 +
2 files changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd
Quoting Mark Brown (2016-02-16 05:42:33)
> On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote:
>
> > As for codecs, tlv320aic3106 is also pretty simple device from the outside,
> > it
> > can receive it's reference clock via:
> > MCLK pin, GPIO2 pin or it can use the BCLK from the
Quoting Mark Brown (2016-02-16 05:42:33)
> On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote:
>
> > As for codecs, tlv320aic3106 is also pretty simple device from the outside,
> > it
> > can receive it's reference clock via:
> > MCLK pin, GPIO2 pin or it can use the BCLK from the
On Tue, 13 Oct 2015, Shunqian Zheng wrote:
> +static const struct of_device_id rk3036_codec_of_match[] = {
> + { .compatible = "rk3036-codec", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, rk3036_codec_of_match);
Isn't a compatible string normally in the form "rockchip,rk3036-codec" ?
On Tue, 13 Oct 2015, Shunqian Zheng wrote:
> +static const struct of_device_id rk3036_codec_of_match[] = {
> + { .compatible = "rk3036-codec", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, rk3036_codec_of_match);
Isn't a compatible string normally in the form "rockchip,rk3036-codec" ?
On Mon, 31 Aug 2015, Stephen Rothwell wrote:
> On Mon, 31 Aug 2015 17:48:42 +1000 Stephen Rothwell
> wrote:
> >
> > On Mon, 31 Aug 2015 09:04:22 +0200 Ricard Wanderlof
> > wrote:
> > >
> > > On Fri, 28 Aug 2015, Mark Brown wrote:
> > >
On Fri, 28 Aug 2015, Mark Brown wrote:
> On Fri, Aug 28, 2015 at 09:40:41AM +0200, Ricard Wanderlof wrote:
> > On Fri, 28 Aug 2015, Stephen Rothwell wrote:
>
> > In fact the exact same construct is used by a handful of other codec
> > drivers which apparently don't fai
On Fri, 28 Aug 2015, Mark Brown wrote:
> On Fri, Aug 28, 2015 at 09:40:41AM +0200, Ricard Wanderlof wrote:
> > On Fri, 28 Aug 2015, Stephen Rothwell wrote:
>
> > In fact the exact same construct is used by a handful of other codec
> > drivers which apparently don't fai
On Mon, 31 Aug 2015, Stephen Rothwell wrote:
> On Mon, 31 Aug 2015 17:48:42 +1000 Stephen Rothwell <s...@canb.auug.org.au>
> wrote:
> >
> > On Mon, 31 Aug 2015 09:04:22 +0200 Ricard Wanderlof
> > <ricard.wander...@axis.com> wrote:
> > >
On Fri, 28 Aug 2015, Stephen Rothwell wrote:
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from sound/soc/codecs/ics43432.c:12:0:
> sound/soc/codecs/ics43432.c:60:25: error: 'ics43432_dt_ids' undeclared here
> (not
On Fri, 28 Aug 2015, Stephen Rothwell wrote:
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from sound/soc/codecs/ics43432.c:12:0:
sound/soc/codecs/ics43432.c:60:25: error: 'ics43432_dt_ids' undeclared here
(not in a
On Thu, 5 Feb 2015, Graham Moore wrote:
> Actually, we made this change to make UBIFS work. So, yes, the driver
> never worked for UBI. Worked fine for JFFS2, raw data.
>
> A customer reported an issue with ECC errors when using UBIFS on NAND
> flash with Altera SoC.
>
> We debugged it and
On Thu, 5 Feb 2015, Graham Moore wrote:
Actually, we made this change to make UBIFS work. So, yes, the driver
never worked for UBI. Worked fine for JFFS2, raw data.
A customer reported an issue with ECC errors when using UBIFS on NAND
flash with Altera SoC.
We debugged it and found
> On 02/02/2015 12:07 AM, Brian Norris wrote:
> >
> > No driver should be calling mtd_device_parse_register() multiple times
> > on the same mtd_info. Under what context do you see this? What driver?
> arch/cris/arch-v32/drivers/axisflashmap.c
Looking at it another way, why should it not be
On 02/02/2015 12:07 AM, Brian Norris wrote:
No driver should be calling mtd_device_parse_register() multiple times
on the same mtd_info. Under what context do you see this? What driver?
arch/cris/arch-v32/drivers/axisflashmap.c
Looking at it another way, why should it not be allowed, if
On Fri, 3 Oct 2014, Artem Bityutskiy wrote:
> I respect checkpatch.pl, and uniformity / consistency, but in this
> particular case I put my maintainer hat on and say that for this kernel
> subsystem it is fine, because the maintainer will be more efficient in
> maintaining this code when the
On Fri, 3 Oct 2014, Artem Bityutskiy wrote:
I respect checkpatch.pl, and uniformity / consistency, but in this
particular case I put my maintainer hat on and say that for this kernel
subsystem it is fine, because the maintainer will be more efficient in
maintaining this code when the code is
From: Ricard Wanderlof
This is a request for comments for a driver for the Evatronix NANDFLASH-CTRL
IP (version 1.15). It is designed to be applied to Linux 3.16 or the current
linux-mtd tree.
Currently, it supports one instance of the NANDFLASH-CTRL IP, with up
to two connected NAND flash
From: Ricard Wanderlof rica...@axis.com
This is a request for comments for a driver for the Evatronix NANDFLASH-CTRL
IP (version 1.15). It is designed to be applied to Linux 3.16 or the current
linux-mtd tree.
Currently, it supports one instance of the NANDFLASH-CTRL IP, with up
to two
On Fri, 1 Mar 2013, Richard Genoud wrote:
From a Micron Nand datasheet :
Micron NAND devices are specified to have a minimum of 2,008 (NVB)
valid blocks out
of every 2,048 total available blocks. This means the devices may have
blocks that are
invalid when they are shipped. An invalid block is
On Fri, 1 Mar 2013, Richard Genoud wrote:
From a Micron Nand datasheet :
Micron NAND devices are specified to have a minimum of 2,008 (NVB)
valid blocks out
of every 2,048 total available blocks. This means the devices may have
blocks that are
invalid when they are shipped. An invalid block is
On Tue, 5 Feb 2013, Huang Shijie wrote:
Add a new module parameter 'pattern'. If it is set to zero, we will use
the 55/AA pattern to torture the nand blocks; if it is set to a non-zero
value, we will use the random data pattern.
Not a big issue in any way, but if you're using a numeric
On Tue, 5 Feb 2013, Huang Shijie wrote:
Add a new module parameter 'pattern'. If it is set to zero, we will use
the 55/AA pattern to torture the nand blocks; if it is set to a non-zero
value, we will use the random data pattern.
Not a big issue in any way, but if you're using a numeric
70 matches
Mail list logo
