All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Stach <l.stach@pengutronix.de>
To: Leonard Crestez <leonard.crestez@nxp.com>,
	Richard Zhu <hongxing.zhu@nxp.com>,
	Andrey Smirnov <andrew.smirnov@gmail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-pci@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Dong Aisheng <aisheng.dong@nxp.com>,
	kernel@pengutronix.de, linux-imx@nxp.com
Subject: Re: [PATCH v2 2/3] reset: imx7: Fix always writing bits as 0
Date: Mon, 23 Jul 2018 11:41:05 +0200	[thread overview]
Message-ID: <1532338865.3163.95.camel@pengutronix.de> (raw)
In-Reply-To: <54f436a1d2a11a379af642a3327312367ef95343.1532090446.git.leonard.crestez@nxp.com>

As this doesn't depend on any other patch in this series, I think it
would be fine if Philipp takes this patch through the reset tree.

Regards,
Lucas

Am Freitag, den 20.07.2018, 15:47 +0300 schrieb Leonard Crestez:
> Right now the only user of reset-imx7 is pci-imx6 and the
> reset_control_assert and deassert calls on pciephy_reset don't toggle
> the PCIEPHY_BTN and PCIEPHY_G_RST bits as expected. Fix this by writing
> 1 or 0 respectively.
> 
> The reference manual is not very clear regarding SRC_PCIEPHY_RCR but for
> other registers like MIPIPHY and HSICPHY the bits are explicitly
> documented as "1 means assert, 0 means deassert".
> 
> The values are still reversed for IMX7_RESET_PCIE_CTRL_APPS_EN.
> 
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> > Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
>  drivers/reset/reset-imx7.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
> index 4db177bc89bc..fdeac1946429 100644
> --- a/drivers/reset/reset-imx7.c
> +++ b/drivers/reset/reset-imx7.c
> @@ -78,11 +78,11 @@ static struct imx7_src *to_imx7_src(struct reset_controller_dev *rcdev)
>  static int imx7_reset_set(struct reset_controller_dev *rcdev,
> >  			  unsigned long id, bool assert)
>  {
> >  	struct imx7_src *imx7src = to_imx7_src(rcdev);
> >  	const struct imx7_src_signal *signal = &imx7_src_signals[id];
> > -	unsigned int value = 0;
> > +	unsigned int value = assert ? signal->bit : 0;
>  
> >  	switch (id) {
> >  	case IMX7_RESET_PCIEPHY:
> >  		/*
> >  		 * wait for more than 10us to release phy g_rst and

WARNING: multiple messages have this Message-ID (diff)
From: Lucas Stach <l.stach@pengutronix.de>
To: Leonard Crestez <leonard.crestez@nxp.com>,
	Richard Zhu <hongxing.zhu@nxp.com>,
	Andrey Smirnov <andrew.smirnov@gmail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>
Cc: Dong Aisheng <aisheng.dong@nxp.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	linux-pm@vger.kernel.org, Jingoo Han <jingoohan1@gmail.com>,
	linux-kernel@vger.kernel.org,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	linux-imx@nxp.com, kernel@pengutronix.de,
	linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Shawn Guo <shawnguo@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/3] reset: imx7: Fix always writing bits as 0
Date: Mon, 23 Jul 2018 11:41:05 +0200	[thread overview]
Message-ID: <1532338865.3163.95.camel@pengutronix.de> (raw)
In-Reply-To: <54f436a1d2a11a379af642a3327312367ef95343.1532090446.git.leonard.crestez@nxp.com>

QXMgdGhpcyBkb2Vzbid0IGRlcGVuZCBvbiBhbnkgb3RoZXIgcGF0Y2ggaW4gdGhpcyBzZXJpZXMs
IEkgdGhpbmsgaXQKd291bGQgYmUgZmluZSBpZiBQaGlsaXBwwqB0YWtlcyB0aGlzIHBhdGNoIHRo
cm91Z2ggdGhlIHJlc2V0IHRyZWUuCgpSZWdhcmRzLApMdWNhcwoKQW0gRnJlaXRhZywgZGVuIDIw
LjA3LjIwMTgsIDE1OjQ3ICswMzAwIHNjaHJpZWIgTGVvbmFyZCBDcmVzdGV6Ogo+IFJpZ2h0IG5v
dyB0aGUgb25seSB1c2VyIG9mIHJlc2V0LWlteDcgaXMgcGNpLWlteDYgYW5kIHRoZQo+IHJlc2V0
X2NvbnRyb2xfYXNzZXJ0IGFuZCBkZWFzc2VydCBjYWxscyBvbiBwY2llcGh5X3Jlc2V0IGRvbid0
IHRvZ2dsZQo+IHRoZSBQQ0lFUEhZX0JUTiBhbmQgUENJRVBIWV9HX1JTVCBiaXRzIGFzIGV4cGVj
dGVkLiBGaXggdGhpcyBieSB3cml0aW5nCj4gMSBvciAwIHJlc3BlY3RpdmVseS4KPiAKPiBUaGUg
cmVmZXJlbmNlIG1hbnVhbCBpcyBub3QgdmVyeSBjbGVhciByZWdhcmRpbmcgU1JDX1BDSUVQSFlf
UkNSIGJ1dCBmb3IKPiBvdGhlciByZWdpc3RlcnMgbGlrZSBNSVBJUEhZIGFuZCBIU0lDUEhZIHRo
ZSBiaXRzIGFyZSBleHBsaWNpdGx5Cj4gZG9jdW1lbnRlZCBhcyAiMSBtZWFucyBhc3NlcnQsIDAg
bWVhbnMgZGVhc3NlcnQiLgo+IAo+IFRoZSB2YWx1ZXMgYXJlIHN0aWxsIHJldmVyc2VkIGZvciBJ
TVg3X1JFU0VUX1BDSUVfQ1RSTF9BUFBTX0VOLgo+IAo+ID4gU2lnbmVkLW9mZi1ieTogTGVvbmFy
ZCBDcmVzdGV6IDxsZW9uYXJkLmNyZXN0ZXpAbnhwLmNvbT4KPiA+IFJldmlld2VkLWJ5OiBMdWNh
cyBTdGFjaCA8bC5zdGFjaEBwZW5ndXRyb25peC5kZT4KPiAtLS0KPiDCoGRyaXZlcnMvcmVzZXQv
cmVzZXQtaW14Ny5jIHwgMiArLQo+IMKgMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAx
IGRlbGV0aW9uKC0pCj4gCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvcmVzZXQvcmVzZXQtaW14Ny5j
IGIvZHJpdmVycy9yZXNldC9yZXNldC1pbXg3LmMKPiBpbmRleCA0ZGIxNzdiYzg5YmMuLmZkZWFj
MTk0NjQyOSAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL3Jlc2V0L3Jlc2V0LWlteDcuYwo+ICsrKyBi
L2RyaXZlcnMvcmVzZXQvcmVzZXQtaW14Ny5jCj4gQEAgLTc4LDExICs3OCwxMSBAQCBzdGF0aWMg
c3RydWN0IGlteDdfc3JjICp0b19pbXg3X3NyYyhzdHJ1Y3QgcmVzZXRfY29udHJvbGxlcl9kZXYg
KnJjZGV2KQo+IMKgc3RhdGljIGludCBpbXg3X3Jlc2V0X3NldChzdHJ1Y3QgcmVzZXRfY29udHJv
bGxlcl9kZXYgKnJjZGV2LAo+ID4gwqAJCQnCoMKgdW5zaWduZWQgbG9uZyBpZCwgYm9vbCBhc3Nl
cnQpCj4gwqB7Cj4gPiDCoAlzdHJ1Y3QgaW14N19zcmMgKmlteDdzcmMgPSB0b19pbXg3X3NyYyhy
Y2Rldik7Cj4gPiDCoAljb25zdCBzdHJ1Y3QgaW14N19zcmNfc2lnbmFsICpzaWduYWwgPSAmaW14
N19zcmNfc2lnbmFsc1tpZF07Cj4gPiAtCXVuc2lnbmVkIGludCB2YWx1ZSA9IDA7Cj4gPiArCXVu
c2lnbmVkIGludCB2YWx1ZSA9IGFzc2VydCA/IHNpZ25hbC0+Yml0IDogMDsKPiDCoAo+ID4gwqAJ
c3dpdGNoIChpZCkgewo+ID4gwqAJY2FzZSBJTVg3X1JFU0VUX1BDSUVQSFk6Cj4gPiDCoAkJLyoK
PiA+IMKgCQnCoCogd2FpdCBmb3IgbW9yZSB0aGFuIDEwdXMgdG8gcmVsZWFzZSBwaHkgZ19yc3Qg
YW5kCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51
eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVh
ZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1h
cm0ta2VybmVsCg==

WARNING: multiple messages have this Message-ID (diff)
From: l.stach@pengutronix.de (Lucas Stach)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] reset: imx7: Fix always writing bits as 0
Date: Mon, 23 Jul 2018 11:41:05 +0200	[thread overview]
Message-ID: <1532338865.3163.95.camel@pengutronix.de> (raw)
In-Reply-To: <54f436a1d2a11a379af642a3327312367ef95343.1532090446.git.leonard.crestez@nxp.com>

As this doesn't depend on any other patch in this series, I think it
would be fine if Philipp?takes this patch through the reset tree.

Regards,
Lucas

Am Freitag, den 20.07.2018, 15:47 +0300 schrieb Leonard Crestez:
> Right now the only user of reset-imx7 is pci-imx6 and the
> reset_control_assert and deassert calls on pciephy_reset don't toggle
> the PCIEPHY_BTN and PCIEPHY_G_RST bits as expected. Fix this by writing
> 1 or 0 respectively.
> 
> The reference manual is not very clear regarding SRC_PCIEPHY_RCR but for
> other registers like MIPIPHY and HSICPHY the bits are explicitly
> documented as "1 means assert, 0 means deassert".
> 
> The values are still reversed for IMX7_RESET_PCIE_CTRL_APPS_EN.
> 
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> > Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?drivers/reset/reset-imx7.c | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
> index 4db177bc89bc..fdeac1946429 100644
> --- a/drivers/reset/reset-imx7.c
> +++ b/drivers/reset/reset-imx7.c
> @@ -78,11 +78,11 @@ static struct imx7_src *to_imx7_src(struct reset_controller_dev *rcdev)
> ?static int imx7_reset_set(struct reset_controller_dev *rcdev,
> > ?			??unsigned long id, bool assert)
> ?{
> > ?	struct imx7_src *imx7src = to_imx7_src(rcdev);
> > ?	const struct imx7_src_signal *signal = &imx7_src_signals[id];
> > -	unsigned int value = 0;
> > +	unsigned int value = assert ? signal->bit : 0;
> ?
> > ?	switch (id) {
> > ?	case IMX7_RESET_PCIEPHY:
> > ?		/*
> > ?		?* wait for more than 10us to release phy g_rst and

  reply	other threads:[~2018-07-23  9:41 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20 12:47 [PATCH v2 0/3] PCI: imx: Initial imx7d pm support Leonard Crestez
2018-07-20 12:47 ` Leonard Crestez
2018-07-20 12:47 ` Leonard Crestez
2018-07-20 12:47 ` [PATCH v2 1/3] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping" Leonard Crestez
2018-07-20 12:47   ` Leonard Crestez
2018-07-20 12:47   ` Leonard Crestez
2018-07-20 15:33   ` Andrey Smirnov
2018-07-20 15:33     ` Andrey Smirnov
2018-07-20 15:33     ` Andrey Smirnov
2018-07-23 12:41     ` Leonard Crestez
2018-07-23 12:41       ` Leonard Crestez
2018-07-23 12:41       ` Leonard Crestez
2018-07-23 12:41       ` Leonard Crestez
2018-07-23 18:38       ` Andrey Smirnov
2018-07-23 18:38         ` Andrey Smirnov
2018-07-23 18:38         ` Andrey Smirnov
2018-07-24 11:34         ` Leonard Crestez
2018-07-24 11:34           ` Leonard Crestez
2018-07-24 11:34           ` Leonard Crestez
2018-07-24 11:34           ` Leonard Crestez
2018-07-20 12:47 ` [PATCH v2 2/3] reset: imx7: Fix always writing bits as 0 Leonard Crestez
2018-07-20 12:47   ` Leonard Crestez
2018-07-20 12:47   ` Leonard Crestez
2018-07-23  9:41   ` Lucas Stach [this message]
2018-07-23  9:41     ` Lucas Stach
2018-07-23  9:41     ` Lucas Stach
2018-07-23 11:02     ` Philipp Zabel
2018-07-23 11:02       ` Philipp Zabel
2018-07-23 11:02       ` Philipp Zabel
2018-07-20 12:47 ` [PATCH v2 3/3] PCI: imx: Initial imx7d pm support Leonard Crestez
2018-07-20 12:47   ` Leonard Crestez
2018-07-20 12:47   ` Leonard Crestez
2018-07-20 13:38   ` Fabio Estevam
2018-07-20 13:38     ` Fabio Estevam
2018-07-20 13:38     ` Fabio Estevam
2018-07-20 13:38     ` Fabio Estevam
2018-07-23  9:38   ` Lucas Stach
2018-07-23  9:38     ` Lucas Stach
2018-07-23  9:38     ` Lucas Stach
2018-07-23 12:37     ` Leonard Crestez
2018-07-23 12:37       ` Leonard Crestez
2018-07-23 12:37       ` Leonard Crestez
2018-07-23 12:37       ` Leonard Crestez
2018-07-24 10:09       ` Lucas Stach
2018-07-24 10:09         ` Lucas Stach
2018-07-24 10:09         ` Lucas Stach
2018-07-24 10:09         ` Lucas Stach
2018-07-24 12:04         ` Leonard Crestez
2018-07-24 12:04           ` Leonard Crestez
2018-07-24 12:04           ` Leonard Crestez
2018-07-24 12:04           ` Leonard Crestez
2018-07-24 12:28           ` Lucas Stach
2018-07-24 12:28             ` Lucas Stach
2018-07-24 12:28             ` Lucas Stach
2018-07-24 12:28             ` Lucas Stach

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=1532338865.3163.95.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=Joao.Pinto@synopsys.com \
    --cc=aisheng.dong@nxp.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=fabio.estevam@nxp.com \
    --cc=hongxing.zhu@nxp.com \
    --cc=jingoohan1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=leonard.crestez@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=p.zabel@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.