linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Cc: computersforpeace@gmail.com, dwmw2@infradead.org,
	matthias.bgg@gmail.com, robh@kernel.org,
	linux-mtd@lists.infradead.org, xiaolei.li@mediatek.com,
	linux-mediatek@lists.infradead.org, erin.lo@mediatek.com,
	daniel.thompson@linaro.org, blogic@openwrt.org
Subject: Re: [PATCH v4 2/2] mtd: mediatek: driver for MTK Smart Device Gen1 NAND
Date: Tue, 10 May 2016 20:19:09 +0200	[thread overview]
Message-ID: <20160510201909.5ee62b48@bbrezillon> (raw)
In-Reply-To: <573224F5.4030003@linaro.org>

On Tue, 10 May 2016 14:14:13 -0400
Jorge Ramirez <jorge.ramirez-ortiz@linaro.org> wrote:

> On 05/10/2016 10:53 AM, Jorge Ramirez wrote:
> > On 05/10/2016 08:13 AM, Boris Brezillon wrote:  
> >>> +  
> >>> >+void mtk_ecc_disable(struct mtk_ecc *ecc, struct mtk_ecc_config   
> >>> *config)  
> >> If you save the mode somewhere in mtk_ecc (or just write in both ENC
> >> and DEC registers), you won't need this extra config arg here.  
> >
> > ok.   
> 
> actually as I was implementing this change (and it is a simple change to 
> do) I am not sure that it is a good idea to store the state of the 
> engine in the ecc_driver (ie: codec_x active sort of flag). And writing 
> to both set of registers looks ugly to me.
> 
> the way the nand driver is written, it is the nand driver the one that 
> controls the ecc engine 'states' (init, enable_x,disable_x). Why do we 
> want the ecc engine to remember that it was running the encoder or the 
> decoder? I think keeping the parameter in this function makes more 
> sense, that way the ecc driver itself completely stateless.
> 
> however let me see if there is a register I can poke to find out the 
> active codec (then I could remove the config parameter that you pointed 
> out without having to store state). I should be able to just read the 
> ECC control register to determine this.
> 
> 

Ok, that's not so important either. It's just that it's more common to
have an enable/config() function that takes some argument to let the
driver know how it should operate and the disable() function that just
disables everything, no matter what config you previously passed. If
it's really inconvenient for you, then let's just keep it as it is
right now. 

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2016-05-10 18:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 16:17 [PATCH v4 0/2] MTK Smart Device Gen1 NAND Driver Jorge Ramirez-Ortiz
2016-04-29 16:17 ` [PATCH v4 1/2] mtd: mediatek: device tree docs for MTK Smart Device Gen1 NAND Jorge Ramirez-Ortiz
2016-05-06 13:38   ` Boris Brezillon
2016-05-10 11:57     ` Jorge Ramirez
2016-05-10 12:22       ` Boris Brezillon
2016-04-29 16:17 ` [PATCH v4 2/2] mtd: mediatek: driver " Jorge Ramirez-Ortiz
2016-05-01  7:32   ` John Crispin
     [not found]     ` <1462165406.8414.196.camel@mhfsdcap03>
2016-05-02  6:13       ` John Crispin
2016-05-02 11:38         ` Jorge Ramirez
2016-05-02 17:43           ` John Crispin
2016-05-10 12:13   ` Boris Brezillon
2016-05-10 14:37     ` Jorge Ramirez
2016-05-10 14:55       ` Boris Brezillon
2016-05-10 14:45     ` Jorge Ramirez
2016-05-10 14:59       ` Boris Brezillon
2016-05-10 15:18         ` Jorge Ramirez
2016-05-10 14:50     ` Jorge Ramirez
2016-05-10 15:13       ` Boris Brezillon
2016-05-10 15:37         ` Jorge Ramirez
2016-05-10 14:53     ` Jorge Ramirez
2016-05-10 18:14       ` Jorge Ramirez
2016-05-10 18:19         ` Boris Brezillon [this message]
2016-05-10 14:53     ` Jorge Ramirez

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=20160510201909.5ee62b48@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=blogic@openwrt.org \
    --cc=computersforpeace@gmail.com \
    --cc=daniel.thompson@linaro.org \
    --cc=dwmw2@infradead.org \
    --cc=erin.lo@mediatek.com \
    --cc=jorge.ramirez-ortiz@linaro.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh@kernel.org \
    --cc=xiaolei.li@mediatek.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;
as well as URLs for NNTP newsgroup(s).