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 res
Hi Mychaela,
On Fri, 10 Jun 2016 14:40:00 +0200
Boris Brezillon wrote:
> On Thu, 9 Jun 2016 21:07:49 -0800
> Mychaela Falconia wrote:
>
> > On 6/9/16, Boris Brezillon wrote:
> > > Hm, I think it's changing now that a lot of SoCs are advertised to be
> > > running Linux. But you're right in
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 res
On Fri, 10 Jun 2016 16:22:38 +0200
Ricard Wanderlof wrote:
> 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 r
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 u
On Fri, 10 Jun 2016 16:40:39 +0200
Ricard Wanderlof wrote:
>
> > > > > +/* Information common to all chips, including the NANDFLASH-CTRL IP
> > > > > */
> > > > > +struct nfc_info {
> > > >
> > > > Should inherit from nand_hw_ctrl (see the sunxi_nand driver)...
> > > >
> > > > > +
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 wit
On Thu, 9 Jun 2016 21:07:49 -0800
Mychaela Falconia wrote:
> On 6/9/16, Boris Brezillon wrote:
> > Hm, I think it's changing now that a lot of SoCs are advertised to be
> > running Linux. But you're right in that existing IPs might not support
> > this low-level mode.
>
> Faraday (the IP vend
On 6/9/16, Boris Brezillon wrote:
> Hm, I think it's changing now that a lot of SoCs are advertised to be
> running Linux. But you're right in that existing IPs might not support
> this low-level mode.
Faraday (the IP vendor in the present case) advertise Linux support as
well, but they never mai
On Thu, 9 Jun 2016 11:35:53 -0800
Mychaela Falconia wrote:
> On 6/9/16, Boris Brezillon wrote:
> > I also agree on this aspect. Though what you consider an evolution with
> > these 'high-level' controllers is in my opinion a regression.
> >
> > By supporting only a subset of what NAND chips actu
On 6/9/16, Boris Brezillon wrote:
> I also agree on this aspect. Though what you consider an evolution with
> these 'high-level' controllers is in my opinion a regression.
>
> By supporting only a subset of what NAND chips actually support, and
> preventing any raw access, you just limit the compa
On Thu, 9 Jun 2016 09:24:19 -0800
Mychaela Falconia wrote:
> On 6/9/16, Ricard Wanderlof wrote:
> > The designers of this IP apparantly did not have Linux in mind when they
> > designed the controller, since it does all the low level stuff
> > autonomously (in the right IP configuration it can e
On 6/9/16, Ricard Wanderlof wrote:
> The designers of this IP apparantly did not have Linux in mind when they
> designed the controller, since it does all the low level stuff
> autonomously (in the right IP configuration it can even remap flash blocks
> transparently), with no way of intervening.
On Thu, 9 Jun 2016 10:19:51 +0200
Ricard Wanderlof wrote:
> 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_nan
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, 1
On Thu, 2 Jun 2016 09:48:32 +0200
Ricard Wanderlof wrote:
> Driver for the Evatronix NANDFLASH-CTRL NAND flash controller IP. This
> controller is used in the Axis ARTPEC-6 SoC.
>
> The driver supports BCH ECC using the controller's hardware, but there is
> also an option to use software BCH ECC
Driver for the Evatronix NANDFLASH-CTRL NAND flash controller IP. This
controller is used in the Axis ARTPEC-6 SoC.
The driver supports BCH ECC using the controller's hardware, but there is
also an option to use software BCH ECC. However, the ECC layouts are not
compatible so it's not possible to
18 matches
Mail list logo
