All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	linux-gpio@vger.kernel.org, kernel@pengutronix.de,
	Shawn Guo <shawnguo@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: i.MX7 pinctrl driver writing to non existent registers
Date: Wed, 8 Feb 2017 23:28:33 +0800	[thread overview]
Message-ID: <9D4713C3-26F1-4041-A227-51A8A2EEB3C1@jcrosoft.com> (raw)
In-Reply-To: <20170208090817.omm2dydhqukdzgqy@pengutronix.de>


> On Feb 8, 2017, at 5:08 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> Hi All,
> 
> The i.MX7 has two pinmux controllers, the LPSR and the regular one. We
> instantiate a driver for each one. Now the driver assumes that the pins
> are completely configured with one iomux controller, but for the LPSR
> pins this is not true: The MUX_CTL and PAD_CTL registers are indeed
> in the LPSR controller, but the SELECT_INPUT registers for the same
> pin are found in the regular controller.
> 
> The result is that with this pin for example:
> 
> #define MX7D_PAD_GPIO1_IO06__UART5_DCE_RX                         0x0018 0x0048 0x0714 0x3 0x4
> 
> The LPSR controller writes to LPSR_BASE + 0x714 where it should really
> be IOMUX_BASE + 0x714.
> 
> I have no idea how to fix this. We could split the LPSR pins into two
> pins, one for each controller. Another possibility would be to create
> some kind of shortcut from one controller to control the other one. Also
> not nice. Also we could simply do nothing, as long as the bootloader
> configures everything correctly we won't even notice ;)
Always expect a bootloader is wrong and do it properly in the kernel
as if you have 2 bootloader they may do different configuration and as the end
found the problem in the kernel on one board and not the other.

Best Regards,
J.

WARNING: multiple messages have this Message-ID (diff)
From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
To: linux-arm-kernel@lists.infradead.org
Subject: i.MX7 pinctrl driver writing to non existent registers
Date: Wed, 8 Feb 2017 23:28:33 +0800	[thread overview]
Message-ID: <9D4713C3-26F1-4041-A227-51A8A2EEB3C1@jcrosoft.com> (raw)
In-Reply-To: <20170208090817.omm2dydhqukdzgqy@pengutronix.de>


> On Feb 8, 2017, at 5:08 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> Hi All,
> 
> The i.MX7 has two pinmux controllers, the LPSR and the regular one. We
> instantiate a driver for each one. Now the driver assumes that the pins
> are completely configured with one iomux controller, but for the LPSR
> pins this is not true: The MUX_CTL and PAD_CTL registers are indeed
> in the LPSR controller, but the SELECT_INPUT registers for the same
> pin are found in the regular controller.
> 
> The result is that with this pin for example:
> 
> #define MX7D_PAD_GPIO1_IO06__UART5_DCE_RX                         0x0018 0x0048 0x0714 0x3 0x4
> 
> The LPSR controller writes to LPSR_BASE + 0x714 where it should really
> be IOMUX_BASE + 0x714.
> 
> I have no idea how to fix this. We could split the LPSR pins into two
> pins, one for each controller. Another possibility would be to create
> some kind of shortcut from one controller to control the other one. Also
> not nice. Also we could simply do nothing, as long as the bootloader
> configures everything correctly we won't even notice ;)
Always expect a bootloader is wrong and do it properly in the kernel
as if you have 2 bootloader they may do different configuration and as the end
found the problem in the kernel on one board and not the other.

Best Regards,
J.

  reply	other threads:[~2017-02-08 15:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-08  9:08 i.MX7 pinctrl driver writing to non existent registers Sascha Hauer
2017-02-08  9:08 ` Sascha Hauer
2017-02-08 15:28 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2017-02-08 15:28   ` Jean-Christophe PLAGNIOL-VILLARD
2017-03-08 13:57 ` Shawn Guo
2017-03-08 13:57   ` Shawn Guo
2017-03-09  7:21   ` Sascha Hauer
2017-03-09  7:21     ` Sascha Hauer

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=9D4713C3-26F1-4041-A227-51A8A2EEB3C1@jcrosoft.com \
    --to=plagnioj@jcrosoft.com \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.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.