linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
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 10:37:32 -0400	[thread overview]
Message-ID: <5731F22C.902@linaro.org> (raw)
In-Reply-To: <20160510141335.442d3d7b@bbrezillon>

On 05/10/2016 08:13 AM, Boris Brezillon wrote:
>> +#define ECC_IDLE_REG(x)		((x) == ECC_ENC ? ECC_ENCIDLE : ECC_DECIDLE)
>> >+#define ECC_IDLE_MASK(x)	((x) == ECC_ENC ? ENC_IDLE : DEC_IDLE)
> No need for this macro, it's always bit0, so just define an ECC_IDLE
> macro and use it for both decoder and encoder.

this was only done for consistency to help people reading the code (same 
for codec_enable, codec_disable).
I suppose I could remove macros and just write 0 and 1 to the registers 
if you prefer that.

>
> There seems to be some kind of pattern in your ENC/DEC registers.
> ENC registers start at 0 and DEC ones at 0x100.
> CNF register is always at 0x4 + mode/dir_offset (ie 0x100 for DEC and
> 0x0 for ENC), ...
> Maybe you should define common macros for those registers, and choose
> the base offset depending on the mode you're operating in (encoding or
> decoding).

Not sure if you are familiar with George Lakoff and his book "Don't 
Think Of An Elephant! Know Your Values And Frame The Debate" but the key 
message is not to engage in a discussion when you disagree with the 
terms used by your counterpart since you wont be able to frame the 
argument (the book is actually very interesting if politics and and the 
political debate is something that interest you)

I explicitly chose not to talk about modes, instead I chose the engine 
driver to talk about the codecs it controls; for me mode is a higher 
level concept that I didn't have a need for since in this case the mode 
is a 1-1 relationship to the codec. So when you tell me about the mode 
the engine is operating in I'd rather say the codec that the ecc engine 
is accessing. I hope it makes sense.

if you want to talk about modes instead of the encoders and decoders 
that is fine since you are the maintainer.
I can rewrite the relevant parts of the driver but I honestly see no value.

why did I wrote these macros? just for readability since they are simple 
conditionals.
So coming back to your second question, I not sure why I would use a 
base offset when I already have the map. I wouldn't.

>
>> >+#define ECC_IRQ_REG(x)		((x) == ECC_ENC ? ECC_ENCIRQ_EN : ECC_DECIRQ_EN)
>> >+#define ECC_IRQ_EN(x)		((x) == ECC_ENC ? ENC_IRQEN : DEC_IRQEN)
>> >+#define ECC_CTL_REG(x)		((x) == ECC_ENC ? ECC_ENCCON : ECC_DECCON)
>> >+#define ECC_CODEC_ENABLE(x)	((x) == ECC_ENC ? ENC_EN : DEC_EN)
>> >+#define ECC_CODEC_DISABLE(x)	((x) == ECC_ENC ? ENC_DE : DEC_DE)

  reply	other threads:[~2016-05-10 14:37 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 [this message]
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
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=5731F22C.902@linaro.org \
    --to=jorge.ramirez-ortiz@linaro.org \
    --cc=blogic@openwrt.org \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=daniel.thompson@linaro.org \
    --cc=dwmw2@infradead.org \
    --cc=erin.lo@mediatek.com \
    --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).