From: Troy Kisky <troy.kisky@boundarydevices.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] nitrogen6x: Fix the PAD settings for the ECSPI chipselect
Date: Sun, 13 Apr 2014 16:21:49 -0700 [thread overview]
Message-ID: <534B1C0D.5080605@boundarydevices.com> (raw)
In-Reply-To: <CAOMZO5Db37LLP-r9v6=y_iRPfcem0jc=m=xsM0iWzrK_rehDWA@mail.gmail.com>
On 4/13/2014 4:01 PM, Fabio Estevam wrote:
> On Sun, Apr 13, 2014 at 7:08 PM, Troy Kisky
> <troy.kisky@boundarydevices.com> wrote:
>
>> NAK. Please don't use NO_PAD_CTRL. What is wrong with
>> SPI_PAD_CTRL. Your commit message doesn't say.
>> It is an SPI pin (even if used as a GPIO,) so
>> why doesn't it make sense.
>
> SPI_PAD_CTRL should be used by the pads that have SPI functionality.
>
> This is not the case for the MX6_PAD_EIM_D19__GPIO3_IO19, which is a
> GPIO, so why SPI_PAD_CTRL?
>
> If we follow your argument then the enet_pads1 array is incorrect and
> we should change all of them to ENET_PAD_CTRL instead.
I would ack that patch. I do believe that all NO_PAD_CTRL should
be replaced with whatever the register actually contains currently.
A "nop" patch that just makes things explicit.
Would you have a problem with that patch?
For your particular example of enet, I see no reason that the
pad settings should change when switching the mux from ENET to
gpio.
Btw, I do appreciate your looking at this board file.
Sorry, if I sounded rude.
Troy
next prev parent reply other threads:[~2014-04-13 23:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-11 20:43 [U-Boot] [PATCH] nitrogen6x: Fix the PAD settings for the ECSPI chipselect Fabio Estevam
2014-04-12 15:04 ` Eric Nelson
2014-04-12 15:32 ` Fabio Estevam
2014-04-12 22:54 ` Eric Nelson
2014-04-13 22:08 ` Troy Kisky
2014-04-13 23:01 ` Fabio Estevam
2014-04-13 23:21 ` Troy Kisky [this message]
2014-04-28 12:04 ` Stefano Babic
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=534B1C0D.5080605@boundarydevices.com \
--to=troy.kisky@boundarydevices.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.