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)
next prev parent 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).