All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <pure.logic@nexus-software.ie>
To: l.stach@pengutronix.de, peng.fan@nxp.com, shawnguo@kernel.org,
	srinivas.kandagatla@linaro.org, leonard.crestez@nxp.com
Cc: aisheng.dong@nxp.com, abel.vesa@nxp.com, anson.huang@nxp.com,
	linux-imx@nxp.com, kernel@pengutronix.de, fabio.estevam@nxp.com,
	Bryan O'Donoghue <pure.logic@nexus-software.ie>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 0/5]  Add i.MX8MM support
Date: Mon, 22 Apr 2019 16:04:55 +0100	[thread overview]
Message-ID: <20190422150500.11082-1-pure.logic@nexus-software.ie> (raw)

V4:
- Change the RELAX fix to drop subtraction of -1 for all users - Leonard
- Expand register definition from the 60 documented OTP registers to the
  entire 256 registers putatively in the address space*
- Add Reviewed-by as indicated - Leonard
- Added Suggested-by where it made sense - Bryan

* Dumping the expanded address space shows that there are indeed OTP values
  present that can be read back from registers that are not formally
  documented for i.MX8MM eg.

Bank 20
        0x55000801
        0x00014d14
        0xd503201f
        0x55000801
Bank 21
        0x00014d20
        0xd503201f
        0x00000000
        0x00000000

V3:
- Fix commit log for the expanding the ADDR field i.MX6 uses seven not four
  bits, which is why the existing define says 0x7F not 0x0F - bod

V2:
- Rebased to linux-next/master to align with i.8MQ work
- Two patches dropped as a result of rebase
- Added patch to expand OCOTP_CTRL_ADDR to 8 bits for all users - Leonard
- Makes sure nregs = 60 not 64 for i.MX8MM
- Tested imx8mm-evk, imx7s-warp7

V1:
This set adds support for the i.MX8MM.

When adding support for this processor there are two interesting gotchas to
watch for.

#1 We current do not preserve the WAIT field for i.MX6 and since we are
   reusing the i.MX6 set_timing() values, this would also affect i.MX8.
   On the face of it, it appears to be an inocuous error with no real side
   effects.

#2 Secondly the i.MX8MM will calculate a zero value for the RELAX bit-field
   when programming up OTP fuses.
   This is fine for programming the fuses but, it introduces a strange
   failure state with reloading the shadow registers subsequent to blowing
   an OTP fuse.
   The second important patch here then is ensuring the RELAX field is
   non-zero to avoid the failure state.


Bryan O'Donoghue (5):
  nvmem: imx-ocotp: Elongate OCOTP_CTRL ADDR field to eight bits
  nvmem: imx-ocotp: Ensure WAIT bits are preserved when setting timing
  nvmem: imx-ocotp: Ensure the RELAX field is non-zero
  nvmem: imx-ocotp: Add i.MX8MM support
  dt-bindings: imx-ocotp: Add i.MX8MM compatible

 .../devicetree/bindings/nvmem/imx-ocotp.txt        |  1 +
 drivers/nvmem/imx-ocotp.c                          | 14 +++++++++++---
 2 files changed, 12 insertions(+), 3 deletions(-)

-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2019-04-22 15:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-22 15:04 Bryan O'Donoghue [this message]
2019-04-22 15:04 ` [PATCH v4 1/5] nvmem: imx-ocotp: Elongate OCOTP_CTRL ADDR field to eight bits Bryan O'Donoghue
2019-04-22 15:04 ` [PATCH v4 2/5] nvmem: imx-ocotp: Ensure WAIT bits are preserved when setting timing Bryan O'Donoghue
2019-04-22 15:04 ` [PATCH v4 3/5] nvmem: imx-ocotp: Ensure the RELAX field is non-zero Bryan O'Donoghue
2019-04-23  8:48   ` Leonard Crestez
2019-04-23 14:07     ` Bryan O'Donoghue
2019-04-23 14:42       ` Leonard Crestez
2019-04-23 14:58         ` Bryan O'Donoghue
2019-04-22 15:04 ` [PATCH v4 4/5] nvmem: imx-ocotp: Add i.MX8MM support Bryan O'Donoghue
2019-04-22 19:06   ` Leonard Crestez
2019-04-22 15:05 ` [PATCH v4 5/5] dt-bindings: imx-ocotp: Add i.MX8MM compatible Bryan O'Donoghue

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=20190422150500.11082-1-pure.logic@nexus-software.ie \
    --to=pure.logic@nexus-software.ie \
    --cc=abel.vesa@nxp.com \
    --cc=aisheng.dong@nxp.com \
    --cc=anson.huang@nxp.com \
    --cc=fabio.estevam@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=leonard.crestez@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=peng.fan@nxp.com \
    --cc=shawnguo@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    /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.