Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

Hi,

On Tue, May 22, 2018 at 10:33 PM, Rosen Penev  wrote:
> Looks like it's this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39
>
> Please try reverting. Unfortunately I don't have mt7620 hardware so I
> can't test. Based on the comment, the issue should be fixed elsewhere.

I saw that you had already reverted this commit on the master-branch.
After commit 048e41f6496697863cc7d73ab95fa89a6ddf2470, GPIO on my
mt7620 device works fine again. Thanks for figuring this out and
fixing the problem so fast.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Andrey Jr. Melnikov]

In gmane.comp.embedded.lede.devel Kristian Evensen  
wrote:
> On Wed, May 23, 2018 at 4:09 AM, Andrey Jr. Melnikov
>  wrote:
> > In gmane.comp.embedded.lede.devel Rosen Penev  wrote:
> >> On Tue, May 22, 2018 at 7:45 AM, Kristian Evensen
> >>  wrote:
> >> > Hi,
> >> >
> >> > On Tue, May 22, 2018 at 4:33 PM, John Crispin  wrote:
> >> >> what exactly is the issue ? breaking compat means that rosen either 
> >> >> needs to
> >> >> fix the regression or we need to revert the patch.
> >> >
> >> > The issue I saw is that writing to GPIO has no effect. On my device
> >> > (mt7620-based), I can control the power to the two mini-pcie slots by
> >> > writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit
> >> > "ramips: mmc: Sync with
> >> > staging driver", writing to these two files have no effect. I.e., I
> >> > can no longer control the power.
> >> Looks like it's this commit:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39
> >
> >> Please try reverting. Unfortunately I don't have mt7620 hardware so I
> >> can't test. Based on the comment, the issue should be fixed elsewhere.
> > This commit removed programming SDXC_MODE register to GPIO mode and nothing
> > more.
> > So - fix your device dts, add nd_sd to gpio group.

> nd_sd is already part of the gpio group, so then I guess the change
> linked to by Rosen is not relevant in my case.

Relevant. In D240.dts we have

-- cut --
 {
status = "okay";
};
-- cut --

so SD driver loads and reprogram GPIO register ND_SD_GPIO_MODE to ND mode
and you lost GPIO controls. Disable unused sdhci in DTS.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

On Wed, May 23, 2018 at 4:09 AM, Andrey Jr. Melnikov
 wrote:
> In gmane.comp.embedded.lede.devel Rosen Penev  wrote:
>> On Tue, May 22, 2018 at 7:45 AM, Kristian Evensen
>>  wrote:
>> > Hi,
>> >
>> > On Tue, May 22, 2018 at 4:33 PM, John Crispin  wrote:
>> >> what exactly is the issue ? breaking compat means that rosen either needs 
>> >> to
>> >> fix the regression or we need to revert the patch.
>> >
>> > The issue I saw is that writing to GPIO has no effect. On my device
>> > (mt7620-based), I can control the power to the two mini-pcie slots by
>> > writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit
>> > "ramips: mmc: Sync with
>> > staging driver", writing to these two files have no effect. I.e., I
>> > can no longer control the power.
>> Looks like it's this commit:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39
>
>> Please try reverting. Unfortunately I don't have mt7620 hardware so I
>> can't test. Based on the comment, the issue should be fixed elsewhere.
> This commit removed programming SDXC_MODE register to GPIO mode and nothing
> more.
> So - fix your device dts, add nd_sd to gpio group.

nd_sd is already part of the gpio group, so then I guess the change
linked to by Rosen is not relevant in my case.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Andrey Jr. Melnikov]

In gmane.comp.embedded.lede.devel Rosen Penev  wrote:
> On Tue, May 22, 2018 at 7:45 AM, Kristian Evensen
>  wrote:
> > Hi,
> >
> > On Tue, May 22, 2018 at 4:33 PM, John Crispin  wrote:
> >> what exactly is the issue ? breaking compat means that rosen either needs 
> >> to
> >> fix the regression or we need to revert the patch.
> >
> > The issue I saw is that writing to GPIO has no effect. On my device
> > (mt7620-based), I can control the power to the two mini-pcie slots by
> > writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit
> > "ramips: mmc: Sync with
> > staging driver", writing to these two files have no effect. I.e., I
> > can no longer control the power.
> Looks like it's this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39

> Please try reverting. Unfortunately I don't have mt7620 hardware so I
> can't test. Based on the comment, the issue should be fixed elsewhere.
This commit removed programming SDXC_MODE register to GPIO mode and nothing
more.
So - fix your device dts, add nd_sd to gpio group.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

Hi,

On Tue, May 22, 2018 at 1:33 PM, Rosen Penev  wrote:
> Looks like it's this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39
>
> Please try reverting. Unfortunately I don't have mt7620 hardware so I
> can't test. Based on the comment, the issue should be fixed elsewhere.

Unless anyone beats me to it, I can test this on Friday or during the weekend.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Rosen Penev]

On Tue, May 22, 2018 at 7:45 AM, Kristian Evensen
 wrote:
> Hi,
>
> On Tue, May 22, 2018 at 4:33 PM, John Crispin  wrote:
>> what exactly is the issue ? breaking compat means that rosen either needs to
>> fix the regression or we need to revert the patch.
>
> The issue I saw is that writing to GPIO has no effect. On my device
> (mt7620-based), I can control the power to the two mini-pcie slots by
> writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit
> "ramips: mmc: Sync with
> staging driver", writing to these two files have no effect. I.e., I
> can no longer control the power.
Looks like it's this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39

Please try reverting. Unfortunately I don't have mt7620 hardware so I
can't test. Based on the comment, the issue should be fixed elsewhere.
>
> I see I used the wrong has in my original email, the correct sha of
> the commit is fec205f6544a.
>
> BR,
> Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Rosen Penev]

On Tue, May 22, 2018 at 7:33 AM, John Crispin  wrote:
>
>
> On 22/05/18 16:18, Kristian Evensen wrote:
>>
>> On Sun, May 20, 2018 at 10:26 PM, Rosen Penev  wrote:

 Bisecting further is hard, since the
 commit is a combination of (a lot of) clean-up and some functional
 changes.
>>>
>>> Changes can be viewed on the linux-next tree. It should be as simple
>>> as dropping in the relevant files to the files-4.14 directory.
>>>
 Would it be possible to revert the commit and split it in two
 parts (clean-up + functional)? Then it should be easier to figure out
 what is wrong.
>>>
>>> I'm torn on this. The long term solution is to migrate to the mainline
>>> mtk-sd driver (which is just a newer version of this one). The new
>>> 18.06 release does not contain this patch.
>>
>> I agree that using the mainline driver is ideal. This email was meant
>> more as a notification that the commit creates issues for some
>> devices. I didnt test, but I guess that my LEDs are also broken, since
>> some are also controlled using GPIO. For me, reverting the commit
>> locally works fine and I can carry that locally.
>>
>> BR,
>> Kristian
>
>
> what exactly is the issue ? breaking compat means that rosen either needs to
> fix the regression or we need to revert the patch.
I will look into this later today. I'm simultaneously working on
getting the mainline driver up and running on mt7621. Will submit an
RFC for that soon.
>
> John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

Hi,

On Tue, May 22, 2018 at 4:33 PM, John Crispin  wrote:
> what exactly is the issue ? breaking compat means that rosen either needs to
> fix the regression or we need to revert the patch.

The issue I saw is that writing to GPIO has no effect. On my device
(mt7620-based), I can control the power to the two mini-pcie slots by
writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit
"ramips: mmc: Sync with
staging driver", writing to these two files have no effect. I.e., I
can no longer control the power.

I see I used the wrong has in my original email, the correct sha of
the commit is fec205f6544a.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[John Crispin]

On 22/05/18 16:18, Kristian Evensen wrote:

On Sun, May 20, 2018 at 10:26 PM, Rosen Penev  wrote:

Bisecting further is hard, since the
commit is a combination of (a lot of) clean-up and some functional
changes.

Changes can be viewed on the linux-next tree. It should be as simple
as dropping in the relevant files to the files-4.14 directory.


Would it be possible to revert the commit and split it in two
parts (clean-up + functional)? Then it should be easier to figure out
what is wrong.

I'm torn on this. The long term solution is to migrate to the mainline
mtk-sd driver (which is just a newer version of this one). The new
18.06 release does not contain this patch.

I agree that using the mainline driver is ideal. This email was meant
more as a notification that the commit creates issues for some
devices. I didnt test, but I guess that my LEDs are also broken, since
some are also controlled using GPIO. For me, reverting the commit
locally works fine and I can carry that locally.

BR,
Kristian


what exactly is the issue ? breaking compat means that rosen either 
needs to fix the regression or we need to revert the patch.


    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

On Sun, May 20, 2018 at 10:26 PM, Rosen Penev  wrote:
>> Bisecting further is hard, since the
>> commit is a combination of (a lot of) clean-up and some functional
>> changes.
> Changes can be viewed on the linux-next tree. It should be as simple
> as dropping in the relevant files to the files-4.14 directory.
>
>> Would it be possible to revert the commit and split it in two
>> parts (clean-up + functional)? Then it should be easier to figure out
>> what is wrong.
> I'm torn on this. The long term solution is to migrate to the mainline
> mtk-sd driver (which is just a newer version of this one). The new
> 18.06 release does not contain this patch.

I agree that using the mainline driver is ideal. This email was meant
more as a notification that the commit creates issues for some
devices. I didnt test, but I guess that my LEDs are also broken, since
some are also controlled using GPIO. For me, reverting the commit
locally works fine and I can carry that locally.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Rosen Penev]

On Sun, May 20, 2018 at 1:04 PM, Kristian Evensen
 wrote:
> Hello,
>
> When building and testing nightly on an MT7620-device I have (the
> Sanlinking D240), I noticed that changing the state of the two
> exported pins (45 and 46) had no effect. The pins are used to control
> the power to the two mini-PCIe slots on the board, and the devices
> connected to the slots were visible irrespective of if the pin was set
> to high or low.
>
> I bisected the problem to commit 34ca34b32b02 ("ramips: mmc: Sync with
> staging driver"). Reverting the commit makes setting the pins to
> low/high works as expected again.
Hrm unfortunate. I've only tested on mt7621 where it works fine.
> Bisecting further is hard, since the
> commit is a combination of (a lot of) clean-up and some functional
> changes.
Changes can be viewed on the linux-next tree. It should be as simple
as dropping in the relevant files to the files-4.14 directory.

> Would it be possible to revert the commit and split it in two
> parts (clean-up + functional)? Then it should be easier to figure out
> what is wrong.
I'm torn on this. The long term solution is to migrate to the mainline
mtk-sd driver (which is just a newer version of this one). The new
18.06 release does not contain this patch.

I don't really know how hard it would be to port mt7620 to the
mainline driver. mt7621 has been done but has not been upstreamed.
See: 
https://github.com/jonpry/openwrt_mt7688/commit/a85e6d99899f3dc1204cd5bfba944e17bfa6178f

and 
https://github.com/jonpry/openwrt_mt7688/commit/24878467a650d765b747618de1a575e79114b764

The mainline driver probably interferes with NAND as well.
>
> BR,
> Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

Hello,

When building and testing nightly on an MT7620-device I have (the
Sanlinking D240), I noticed that changing the state of the two
exported pins (45 and 46) had no effect. The pins are used to control
the power to the two mini-PCIe slots on the board, and the devices
connected to the slots were visible irrespective of if the pin was set
to high or low.

I bisected the problem to commit 34ca34b32b02 ("ramips: mmc: Sync with
staging driver"). Reverting the commit makes setting the pins to
low/high works as expected again. Bisecting further is hard, since the
commit is a combination of (a lot of) clean-up and some functional
changes. Would it be possible to revert the commit and split it in two
parts (clean-up + functional)? Then it should be easier to figure out
what is wrong.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel