public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "computersforpeace@gmail.com" <computersforpeace@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel@stlinux.com" <kernel@stlinux.com>
Subject: Re: [PATCH 04/47] mtd: nand: adding ST's BCH NAND Controller driver
Date: Fri, 23 May 2014 11:30:01 +0100	[thread overview]
Message-ID: <20140523103001.GU19747@lee--X1> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EAD8267@DBDE04.ent.ti.com>

It's strange that your replies aren't connected to my original patches
in my INBOX.  Is there something wrong with your mailer?

> >First introduction of the driver. Includes the basic device struct
> >(some functionality isn't utilised as of yet) and supplies some of the
> >important resources required for basic running of the Controller.
> >
> >Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >---
> >--- /dev/null
> >+++ b/drivers/mtd/nand/stm_nand_bch.c
> [...]
> >+
> >+	uint32_t		page_shift;	/* Some working variables */
> >+	uint32_t		block_shift;
> 
> I think you don't really need these variables for 2 reasons:
> (1) Wherever you are using these variables, you can derive
>     struct *nand_chip and instead directly use
> 	chip->page_shift;
> 	chip->phys_erase_shift;

Okay, I'll look into that.

> (2) Difference chip-selects might be connected to different
>  NAND devices having different  page-size and erase-size.
>  I'm not sure how that is handled in current generic NAND
>  framework (nand_base.c). But having different types of
>  NAND devices connected to different chip-selects is possible.

It's not a problem for us, as this controller only supports one chip.

> >+	uint32_t		blocks_per_device;
> >+	uint32_t		sectors_per_page;
> >+
> >+	uint8_t			*buf;		/* Some buffers to use */
> >+	uint8_t			*page_buf;
> >+	uint8_t			*oob_buf;
> >+	uint32_t		*buf_list;
> >+
> >+	int			cached_page;	/* page number of page in */
> >+						/* 'page_buf'             */
> >+};
> >+
> >+static int remap_named_resource(struct platform_device *pdev,
> >+				char *name,
> >+				void __iomem **io_ptr)
> >+{
> >+	struct resource *res, *mem;
> >+	resource_size_t size;
> >+	void __iomem *p;
> >+
> >+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
> >+	if (!res)
> >+		return -ENXIO;
> >+
> >+	size = resource_size(res);
> >+
> >+	mem = devm_request_mem_region(&pdev->dev, res->start, size, name);
> >+	if (!mem)
> >+		return -EBUSY;
> >+
> >+	p = devm_ioremap_nocache(&pdev->dev, res->start, size);
> >+	if (!p)
> >+		return -ENOMEM;
> >+
> >+	*io_ptr = p;
> >+
> >+	return 0;
> >+}
> >+
> >+static struct nandi_controller *
> >+nandi_init_resources(struct platform_device *pdev)
> >+{
> >+	struct nandi_controller *nandi;
> >+	int err;
> >+
> >+	nandi = devm_kzalloc(&pdev->dev, sizeof(*nandi), GFP_KERNEL);
> >+	if (!nandi) {
> >+		dev_err(&pdev->dev,
> >+			"failed to allocate NANDi controller data\n");
> 
> Jingoo Han <jg1.han@samsung.com> has been cleaning these driver
> specific OOM messages. So please drop dev_err(..) here. Refer
> 	[Patch] mtd: xxxx: Remove unnecessary OOM messages
> 	The site-specific OOM messages are unnecessary, because they
> 	duplicate the MM subsystem generic OOM message.

I agree.  I don't allow OOM errors through reviews either.  This one
must have slipped through the net.

Will fix.

> >+		return ERR_PTR(-ENOMEM);
> >+	}
> >+
> >+	nandi->dev = &pdev->dev;
> >+
> >+	err = remap_named_resource(pdev, "nand_mem", &nandi->base);
> >+	if (err)
> >+		return ERR_PTR(err);
> >+
> >+	err = remap_named_resource(pdev, "nand_dma", &nandi->dma);
> >+	if (err)
> >+		return ERR_PTR(err);
> >+
> >+	platform_set_drvdata(pdev, nandi);
> >+
> >+	return nandi;
> >+}
> 
> [...]
> 
> >+
> >+struct stm_plat_nand_bch_data {
> >+	struct stm_nand_bank_data *bank;
> >+	enum stm_nand_bch_ecc_config bch_ecc_cfg;
> >+
> >+	/* The threshold at which the number of corrected bit-flips per sector
> >+	 * is deemed to have reached an excessive level (triggers '-EUCLEAN' to
> >+	 * be returned to the caller).  The value should be in the range 1 to
> >+	 * <ecc-strength> where <ecc-strength> is 18 or 30, depending on the BCH
> >+	 * ECC mode in operation.  A value of 0 is interpreted by the driver as
> >+	 * <ecc-strength>.
> >+	 */
> >+	unsigned int bch_bitflip_threshold;
> 
> As discussed in other thread, this is incorrect interpretation for
> bitflip_threshold. As per MTD sub-system bitflips_threshold == 0
> means ECC correction is not implemented.
> @@drivers/mtd/mtdcore.c: mtd_read()
> 		return ret_code >= mtd->bitflip_threshold ? -EUCLEAN : 0;

Fixed.

> >+	bool flashss;
> 
> I could not find the use of this member I current series.
> In your earlier version of patch this was used for DT binding "st,nand-flashss"
> Am I missing something ?

If it's unused now, it won't be soon.  This is the new flash memory
controller which we will have to support.  I'd rather leave it in this
set, at the very least to serve as a reminder.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

       reply	other threads:[~2014-05-23 10:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20980858CB6D3A4BAE95CA194937D5E73EAD8267@DBDE04.ent.ti.com>
2014-05-23 10:30 ` Lee Jones [this message]
2014-05-01  9:56 [PATCH 00/47] mtd: nand: Add new driver supporting ST's BCH h/w Lee Jones
2014-05-01  9:56 ` [PATCH 04/47] mtd: nand: adding ST's BCH NAND Controller driver Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140523103001.GU19747@lee--X1 \
    --to=lee.jones@linaro.org \
    --cc=computersforpeace@gmail.com \
    --cc=kernel@stlinux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=pekon@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox