Re: mt7621 GPIO mapping mystery
Hi,
[+cc John Crispin]
On Sat, Jan 21, 2023 at 2:45 PM Arınç ÜNAL wrote:
>
> On 21.01.2023 10:56, Sergio Paracuellos wrote:
> > Hi,
> >
> > On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL wrote:
> >>
> >> Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
> >> GPIO by default. Requesting a gpio by either from devicetree or `echo
> >> 203 > /sys/class/gpio/export` won't change anything. You have to claim
> >> the pin group as gpio on the devicetree.
> >
> > Yes, you have to claim the pin group as gpio on the device tree to
> > make this work. Ralink has the concept of "GPIO mode" but actually is
> > just an electrical configuration for a certain device. So if the mode
> > (function) is not requested as a real GPIO nothing is going to work.
> > So in your board's dts file you have to add something like the
> > following with the groups you want to claim as real gpio function:
> >
> > #include "mt7621.dtsi"
> > ...
> >
> > _default {
> > gpio {
> > groups = "jtag", "uart3", "wdt";
> > function = "gpio";
> > };
> > };
> >
> >>
> >> Quoting my response from [0]:
> >>
> >>> state_default is there to explicitly set the function of a pin group to
> >>> gpio, this is done because the bootloader may have set the function of a
> >>> pin group to something else before booting OpenWrt which would render the
> >>> pins of that group uncontrollable for general purpose aka GPIO.
> >>>
> >>> Actually I think @arinc9 did some work around that.
> >>>
> >>> Not yet, I plan to modify the gpio_request_enable pinmux operation to set
> >>> the pin group as gpio when there's a gpio request for a pin in that pin
> >>> group. gpio_request_enable pinmux operation can only set the function of
> >>> an individual pin currently. Since ralink pinctrl driver can only set the
> >>> function of a group of pins, the operation currently cannot be used.
> >>>
> >>> If we make it work, any GPIO defined on devicetree or exported from
> >>> userspace will automatically have the function of the pin group it's in
> >>> set to gpio, completely getting rid of the need for explicitly defining
> >>> functions of certain pin groups on the devicetree.
> >>
> >> Of course when I said "I plan to modify this code" I actually meant I
> >> was going to talk this through with Sergio but I never had the
> >> opportunity to do so. I guess this thread is a good place to start
> >> talking about this.
> >>
> >> I had this case on a user:
> >>
> >> They got an LED wired to wdt pin. GPIO is already exported on the DT.
> >> However their LED just won't work.
> >>
> >> It turns out the bootloader sets the wdt pin's function to something
> >> other than gpio. And when OpenWrt boots, the pinctrl driver makes no
> >> changes to the pin's function.
> >
> > Bootloader always sets its own configuration for the pinctrl. The
> > linux pinctrl driver sets every single group default mode [0] as it is
> > in the Mediatek's Mt7621 datasheet.
> >
> >>
> >> So we had to specifically claim that pin as gpio to make the LED work.
> >> Now there is already a solution for this which is the
> >> gpio_request_enable pinmux operation but it's not supposed to be used on
> >> pinctrl drivers that cannot control pins individually.
> >>
> >> Sergio, you think we can somehow make this pinmux operation mux a pin
> >> group as gpio instead of a single pin?
> >
> > I am not an expert in pinmux drivers but I think there are strong
> > reasons why only a single pin is allowed to be requested.
> >
> > See kernel doc about this here: [1]
> >
> >>
> >> Or introduce a new pinmux operation that can do this?
> >
> > I think you should send an email to kernel gpio / pinctrl kernel mail
> > list to get feedback from Bart and Linus as gpio and pin control
> > maintainers to properly understand the way to go but I don't really
> > understand what is the problem requesting the group as gpio in the
> > device tree like any other single platform is doing and seems to be
> > the correct way to go. Maybe I am missing something :)
>
> From what I understand, a gpio is requested by exporting a gpio by
> either from devicetree or `echo 203 > /
Re: mt7621 GPIO mapping mystery
Hi, On Sat, Jan 21, 2023 at 1:19 PM Lukas Zeller wrote: > > Hi, > > > On 21 Jan 2023, at 08:56, Sergio Paracuellos > > wrote: > > > > [...] Yes, you have to claim the pin group as gpio on the device tree to > > make this work. > > This revals a underlying problem I tried to ask about back in June 2022 [1] - > what is the state of userland GPIO support in OpenWrt? > > Changing the DT is *not* something an user of an educational/experimental > device based on OpenWrt is able to do, as long as the DT is baked into the > firmware image, and not modifiable from user space. > > Allowing configfs loadable device tree overlays would make that possible, but > that path was decided against (so far) [2]. > > So while I understand that using only the DT mechanisms for configuring GPIO > modes, named gpios and libgpiod instead of /sys/class/gpio etc. is the way to > go, I must also state that without loadable DT overlays, this essentially > makes openwrt unsuitable for experimental/educational devices. Configure the GPIO modes is not something that is expected to be done by a user since all of that belongs to the pinctrl driver space and AFAIK linux kernel people are not thinking in doing pinctrl driver user-space tools. The libgpiod is useful to detect and set to on and off different pins (among other pure GPIO operations) but from the already function GPIO set up in them. I am not doing the rules, I am just saying the things that are now in the kernel and user space as I think they are. As I have already said, I am not an expert in this topic at all but maybe if we want to do such complex things like configuring the mode of a pin from user space some kind of user space drivers need to be provided in some way... So, if openWRT is using linux kernel, at the end they have to also live with kernel people's decisions in some way... > > I could also understand if this was an intentional decision, after all > OpenWrt is a router OS. > > But *is* it intentional? I find OpenWrt highly useful as a base OS for small > networked devices that are not routers, to cover the mostly empty space > between Arduino and RaspberryPi. Useful Linux in 16M flash rather than 32GB, > with no flash wear problems by design... > > [1] http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038912.html > [2] http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html > > Lukas Best regards, Sergio Paracuellos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
Hi,
On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL wrote:
>
> Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
> GPIO by default. Requesting a gpio by either from devicetree or `echo
> 203 > /sys/class/gpio/export` won't change anything. You have to claim
> the pin group as gpio on the devicetree.
Yes, you have to claim the pin group as gpio on the device tree to
make this work. Ralink has the concept of "GPIO mode" but actually is
just an electrical configuration for a certain device. So if the mode
(function) is not requested as a real GPIO nothing is going to work.
So in your board's dts file you have to add something like the
following with the groups you want to claim as real gpio function:
#include "mt7621.dtsi"
...
_default {
gpio {
groups = "jtag", "uart3", "wdt";
function = "gpio";
};
};
>
> Quoting my response from [0]:
>
> > state_default is there to explicitly set the function of a pin group to
> > gpio, this is done because the bootloader may have set the function of a
> > pin group to something else before booting OpenWrt which would render the
> > pins of that group uncontrollable for general purpose aka GPIO.
> >
> > Actually I think @arinc9 did some work around that.
> >
> > Not yet, I plan to modify the gpio_request_enable pinmux operation to set
> > the pin group as gpio when there's a gpio request for a pin in that pin
> > group. gpio_request_enable pinmux operation can only set the function of an
> > individual pin currently. Since ralink pinctrl driver can only set the
> > function of a group of pins, the operation currently cannot be used.
> >
> > If we make it work, any GPIO defined on devicetree or exported from
> > userspace will automatically have the function of the pin group it's in set
> > to gpio, completely getting rid of the need for explicitly defining
> > functions of certain pin groups on the devicetree.
>
> Of course when I said "I plan to modify this code" I actually meant I
> was going to talk this through with Sergio but I never had the
> opportunity to do so. I guess this thread is a good place to start
> talking about this.
>
> I had this case on a user:
>
> They got an LED wired to wdt pin. GPIO is already exported on the DT.
> However their LED just won't work.
>
> It turns out the bootloader sets the wdt pin's function to something
> other than gpio. And when OpenWrt boots, the pinctrl driver makes no
> changes to the pin's function.
Bootloader always sets its own configuration for the pinctrl. The
linux pinctrl driver sets every single group default mode [0] as it is
in the Mediatek's Mt7621 datasheet.
>
> So we had to specifically claim that pin as gpio to make the LED work.
> Now there is already a solution for this which is the
> gpio_request_enable pinmux operation but it's not supposed to be used on
> pinctrl drivers that cannot control pins individually.
>
> Sergio, you think we can somehow make this pinmux operation mux a pin
> group as gpio instead of a single pin?
I am not an expert in pinmux drivers but I think there are strong
reasons why only a single pin is allowed to be requested.
See kernel doc about this here: [1]
>
> Or introduce a new pinmux operation that can do this?
I think you should send an email to kernel gpio / pinctrl kernel mail
list to get feedback from Bart and Linus as gpio and pin control
maintainers to properly understand the way to go but I don't really
understand what is the problem requesting the group as gpio in the
device tree like any other single platform is doing and seems to be
the correct way to go. Maybe I am missing something :)
>
> [0] https://github.com/openwrt/openwrt/pull/4470#issuecomment-1243345944
>
Best regards,
Sergio Paracuellos
[0]:
https://elixir.bootlin.com/linux/v6.2-rc4/source/drivers/pinctrl/ralink/pinctrl-mt7621.c
[1]:
https://www.kernel.org/doc/html/latest/driver-api/pin-control.html#pin-control-interaction-with-the-gpio-subsystem
> Arınç
>
> On 20.01.2023 22:24, Peter Naulls wrote:
> >
> >
> > I posted previously on GPIOs, which caused some debate; this may or may not
> > be relevant, but I'd be remiss to not mention it:
> >
> > http://lists.openwrt.org/pipermail/openwrt-devel/2022-October/039593.html
> >
> > I've been chasing an issue with GPIO mapping in for an mt7621 on the
> > OpenWrt
> > 5.10.161 etc kernels.
> >
> > In short, GPIOS up to at least 17 work, but 22 and beyond do not - 5-17
> > and 22-24 are LEDs, so their operation should be immediately obvious.
> > The are all active high and are all wired as you'd expect.
> >
> > This a
Re: gpio-mt7621 offset fix for 5.10 kernel series
On Wed, Oct 19, 2022 at 6:02 AM Sergio Paracuellos wrote: > > On Wed, Oct 19, 2022 at 1:10 AM Rosen Penev wrote: > > > > On Tue, Oct 18, 2022 at 3:50 PM Peter Naulls wrote: > > > > > > On 10/18/22 17:10, Lukas Zeller wrote: > > > . > > > > > > > > Just not any more - the mt7621 had this too. I currently patch it back > > > > into > > > > 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] > > > > > > > > I can follow the rationale to get rid of legacy GPIOs, but in the > > > > context > > > > of experimenting platforms, where GPIOs are a thing to work with in > > > > user space, there's just no real replacement yet (see details in > > > > [1],[2]). > > > > > > Yes, I see. > > > > > > I have a mix of C and scripted GPIO access in my setup, and certainly I > > > can > > > move to libgpiod for that - or just just access them as files with > > > named GPIOs as setup per the DTS. > > Let's CC Sergio, who upstreamed this driver. > > For kernel developers, setting base in GPIOs is a no go. You have to > let the kernel to assign its numbers so you can handle different GPIO > layouts with multiple chips. > This is the reason we have 'gpio-line-names' property so you can set > up names for your pins and use it together with actual user space > tools libgpiod and gpiod. Any other gpio user space library is > considered deprecated in these days. See Linus comments about base in review: https://marc.info/?l=linux-gpio=152845919029921=1 Thanks, Sergio Paracuellos > > Best regards, > Sergio Paracuellos > > > > > > > I do see the GPIO shell examples in the OpenWrt wiki, but the code needs > > > more work to deal with multiple banks, and it just makes figuring out > > > the GPIO number to use more clunky without any good cause. > > > > > > Now, the numbered GPIOs really are just for debug in my system, the > > > actual code will use the named ones, but still. > > > > > > Is the long-term intent for shell scripting to instead use the libgpiod > > > tools? > > > > > > https://openwrt.org/docs/techref/hardware/port.gpio > > > > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: gpio-mt7621 offset fix for 5.10 kernel series
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On Wed, Oct 19, 2022 at 1:10 AM Rosen Penev wrote: > > On Tue, Oct 18, 2022 at 3:50 PM Peter Naulls wrote: > > > > On 10/18/22 17:10, Lukas Zeller wrote: > > . > > > > > > Just not any more - the mt7621 had this too. I currently patch it back > > > into > > > 22.03's gpio-mt7621.c for my builds and set base in the DTS, see [3] > > > > > > I can follow the rationale to get rid of legacy GPIOs, but in the context > > > of experimenting platforms, where GPIOs are a thing to work with in > > > user space, there's just no real replacement yet (see details in [1],[2]). > > > > Yes, I see. > > > > I have a mix of C and scripted GPIO access in my setup, and certainly I can > > move to libgpiod for that - or just just access them as files with > > named GPIOs as setup per the DTS. > Let's CC Sergio, who upstreamed this driver. For kernel developers, setting base in GPIOs is a no go. You have to let the kernel to assign its numbers so you can handle different GPIO layouts with multiple chips. This is the reason we have 'gpio-line-names' property so you can set up names for your pins and use it together with actual user space tools libgpiod and gpiod. Any other gpio user space library is considered deprecated in these days. Best regards, Sergio Paracuellos > > > > I do see the GPIO shell examples in the OpenWrt wiki, but the code needs > > more work to deal with multiple banks, and it just makes figuring out > > the GPIO number to use more clunky without any good cause. > > > > Now, the numbered GPIOs really are just for debug in my system, the > > actual code will use the named ones, but still. > > > > Is the long-term intent for shell scripting to instead use the libgpiod > > tools? > > > > https://openwrt.org/docs/techref/hardware/port.gpio > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ramips: overwrite reset gpio properties in DIR-860L DTS
On Thu, Feb 18, 2021 at 2:13 PM Stijn Segers wrote: > > As suggested by Sergio, this adds GPIOs 19 and 8 explicitly into the > DIR-860L DTS, so the PCI-E ports get reset and the N radio (radio1) > on PCI-E port 1 comes up reliably. > > Fixes the following error that popped up in dmesg: > > [1.638942] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & > CLK) > > Suggested-by: Sergio Paracuellos > Signed-off-by: Stijn Segers > --- > target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Sergio Paracuellos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: overwrite reset gpio properties in DIR-860L DTS
On Sat, Feb 13, 2021 at 10:51 AM Stijn Segers wrote: > > As suggested by Sergio, this adds GPIOs 19 and 8 explicitly into the > DIR-860L DTS, so the PCI-E ports get reset and the N radio (radio1) > on PCI-E port 1 comes up reliably. > > Fixes the following error that popped up in dmesg: > > [1.638942] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & > CLK) > > Suggested-by: Sergio Paracuellos > Signed-off-by: Stijn Segers > --- > target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts | 6 ++ > 1 file changed, 6 insertions(+) Looks good to me: Reviewed-by: Sergio Paracuellos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
stered pins: 61
> pin 0 (io0)
> pin 1 (io1)
> pin 2 (io2)
> pin 3 (io3)
> pin 4 (io4)
> pin 5 (io5)
> pin 6 (io6)
> pin 7 (io7)
> pin 8 (io8)
> pin 9 (io9)
> pin 10 (io10)
> pin 11 (io11)
> pin 12 (io12)
> pin 13 (io13)
> pin 14 (io14)
> pin 15 (io15)
> pin 16 (io16)
> pin 17 (io17)
> pin 18 (io18)
> pin 19 (io19)
> pin 20 (io20)
> pin 21 (io21)
> pin 22 (io22)
> pin 23 (io23)
> pin 24 (io24)
> pin 25 (io25)
> pin 26 (io26)
> pin 27 (io27)
> pin 28 (io28)
> pin 29 (io29)
> pin 30 (io30)
> pin 31 (io31)
> pin 32 (io32)
> pin 33 (io33)
> pin 34 (io34)
> pin 35 (io35)
> pin 36 (io36)
> pin 37 (io37)
> pin 38 (io38)
> pin 39 (io39)
> pin 40 (io40)
> pin 41 (io41)
> pin 42 (io42)
> pin 43 (io43)
> pin 44 (io44)
> pin 45 (io45)
> pin 46 (io46)
> pin 47 (io47)
> pin 48 (io48)
> pin 49 (io49)
> pin 50 (io50)
> pin 51 (io51)
> pin 52 (io52)
> pin 53 (io53)
> pin 54 (io54)
> pin 55 (io55)
> pin 56 (io56)
> pin 57 (io57)
> pin 58 (io58)
> pin 59 (io59)
> pin 60 (io60)
>
>
> Puh, not easy.
> I do not know how to thank you four your effort!
>
> Kind regards,
>
> André
>
>
[snip]
Let me know if something changes.
Best regards,
Sergio Paracuellos
>
diff --git a/drivers/staging/mt7621-pci/pci-mt7621.c b/drivers/staging/mt7621-pci/pci-mt7621.c
index b9d460a9c041..793bae0abbad 100644
--- a/drivers/staging/mt7621-pci/pci-mt7621.c
+++ b/drivers/staging/mt7621-pci/pci-mt7621.c
@@ -122,6 +122,7 @@ struct mt7621_pcie_port {
* @ports: pointer to PCIe port information
* @resets_inverted: depends on chip revision
* reset lines are inverted.
+ * @link_status: link status of pcie device.
*/
struct mt7621_pcie {
void __iomem *base;
@@ -136,6 +137,7 @@ struct mt7621_pcie {
unsigned long io_map_base;
struct list_head ports;
bool resets_inverted;
+ u32 link_status;
};
static inline u32 pcie_read(struct mt7621_pcie *pcie, u32 reg)
@@ -279,6 +281,29 @@ static void setup_cm_memory_region(struct mt7621_pcie *pcie)
}
}
+static int mt7621_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
+{
+ struct mt7621_pcie *pcie = pdev->bus->sysdata;
+ struct device *dev = pcie->dev;
+ int irq_map[PCIE_P2P_MAX];
+ int irq;
+ int n, i;
+
+ /* Assign IRQs */
+ n = 0;
+ for (i = 0; i < PCIE_P2P_MAX; i++)
+ if (pcie->link_status & BIT(i))
+ irq_map[n++] = of_irq_parse_and_map_pci(pdev, i, pin);
+
+ for (i = n; i < PCIE_P2P_MAX; i++)
+ irq_map[i] = -1;
+
+ irq = irq_map[slot];
+
+ dev_info(dev, "Bus=%d slot=%d irq=%d\n", pdev->bus->number, slot, irq);
+ return irq;
+}
+
static int mt7621_pci_parse_request_of_pci_ranges(struct mt7621_pcie *pcie)
{
struct device *dev = pcie->dev;
@@ -583,29 +608,29 @@ static void mt7621_pcie_enable_ports(struct mt7621_pcie *pcie)
static int mt7621_pcie_init_virtual_bridges(struct mt7621_pcie *pcie)
{
- u32 pcie_link_status = 0;
u32 n;
int i;
u32 p2p_br_devnum[PCIE_P2P_MAX];
struct mt7621_pcie_port *port;
+ pcie->link_status = 0;
list_for_each_entry(port, >ports, list) {
u32 slot = port->slot;
if (port->enabled)
- pcie_link_status |= BIT(slot);
+ pcie->link_status |= BIT(slot);
}
- if (pcie_link_status == 0)
+ if (pcie->link_status == 0)
return -1;
n = 0;
for (i = 0; i < PCIE_P2P_MAX; i++)
- if (pcie_link_status & BIT(i))
+ if (pcie->link_status & BIT(i))
p2p_br_devnum[i] = n++;
for (i = 0; i < PCIE_P2P_MAX; i++)
- if ((pcie_link_status & BIT(i)) == 0)
+ if ((pcie->link_status & BIT(i)) == 0)
p2p_br_devnum[i] = n++;
pcie_rmw(pcie, RALINK_PCI_PCICFG_ADDR,
@@ -638,7 +663,7 @@ static int mt7621_pcie_register_host(struct pci_host_bridge *host,
host->busnr = pcie->busn.start;
host->dev.parent = pcie->dev;
host->ops = _pci_ops;
- host->map_irq = of_irq_parse_and_map_pci;
+ host->map_irq = mt7621_map_irq;
host->swizzle_irq = pci_common_swizzle;
host->sysdata = pcie;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
On Fri, Apr 10, 2020 at 1:36 PM Sergio Paracuellos wrote: > > Hi André, > > On Fri, Apr 10, 2020 at 11:36 AM Andre Valentin wrote: > > > > Hi Sergio, > > > > the device has an onboard LTE modem. Tonight I noticed that the originial > > pci driver > > must have changed some additional GPIO pins. > > After more testing, I found the GPIO and the LTE device now operates again. > > Good! > > > > > But after more testing, I found out that the wifi chip does not fully > > initialize. > > new PCI driver: > > [0.641632] PCI: CLS 0 bytes, default 32 > > [1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie > > [1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for > > 1e14.pcie > > [1.242447] mt7621-pci 1e14.pcie: Parsing DT failed > > [2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie > > [2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for > > 1e14.pcie > > [2.898180] rt2880-pinmux pinctrl: pcie is already enabled > > [2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse > > things back > > [2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > > port = 1) > > [2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of > > node '/pcie@1e14[0]' - status (0) > > [2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > > of node '/pcie@1e14[1]' > > [2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property > > of node '/pcie@1e14[1]' > > [2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > > [2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found > > [2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > > port = 0) > > [2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > > of node '/pcie@1e14[2]' > > [2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property > > of node '/pcie@1e14[2]' > > [2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > > [2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found > > [3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz > > [3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz > > [3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & > > CLK) > > [3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & > > CLK) > > [3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled > > [3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: > > 0x6000, mask/settings: 0xf002 > > [3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 > > [3.244820] pci_bus :00: root bus resource [io > > 0x1e16-0x1e16] > > [3.258527] pci_bus :00: root bus resource [mem > > 0x6000-0x6fff] > > [3.272233] pci_bus :00: root bus resource [bus 00-ff] > > [3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > [3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > > [3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020] > > [3.320294] pci :00:00.0: supports D1 > > [3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot > > [3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > > [3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > > [3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > > limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 > > GT/s x1 link) > > [3.395633] pci :00:00.0: PCI bridge to [bus 01-ff] > > [3.406073] pci :00:00.0: bridge window [io 0x-0x0fff] > > [3.418220] pci :00:00.0: bridge window [mem 0x6000-0x600f] > > [3.431784] pci :00:00.0: bridge window [mem 0x6010-0x601f > > pref] > > [3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > >
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi André, On Fri, Apr 10, 2020 at 11:36 AM Andre Valentin wrote: > > Hi Sergio, > > the device has an onboard LTE modem. Tonight I noticed that the originial pci > driver > must have changed some additional GPIO pins. > After more testing, I found the GPIO and the LTE device now operates again. Good! > > But after more testing, I found out that the wifi chip does not fully > initialize. > new PCI driver: > [0.641632] PCI: CLS 0 bytes, default 32 > [1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie > [1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie > [1.242447] mt7621-pci 1e14.pcie: Parsing DT failed > [2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie > [2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie > [2.898180] rt2880-pinmux pinctrl: pcie is already enabled > [2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse > things back > [2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > port = 1) > [2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of > node '/pcie@1e14[0]' - status (0) > [2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > of node '/pcie@1e14[1]' > [2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of > node '/pcie@1e14[1]' > [2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > port = 0) > [2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > of node '/pcie@1e14[2]' > [2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of > node '/pcie@1e14[2]' > [2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz > [3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz > [3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK) > [3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & CLK) > [3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled > [3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: > 0x6000, mask/settings: 0xf002 > [3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 > [3.244820] pci_bus :00: root bus resource [io 0x1e16-0x1e16] > [3.258527] pci_bus :00: root bus resource [mem 0x6000-0x6fff] > [3.272233] pci_bus :00: root bus resource [bus 00-ff] > [3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > [3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > [3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020] > [3.320294] pci :00:00.0: supports D1 > [3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot > [3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > [3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > [3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited > by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 > link) > [3.395633] pci :00:00.0: PCI bridge to [bus 01-ff] > [3.406073] pci :00:00.0: bridge window [io 0x-0x0fff] > [3.418220] pci :00:00.0: bridge window [mem 0x6000-0x600f] > [3.431784] pci :00:00.0: bridge window [mem 0x6010-0x601f > pref] > [3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > [3.459414] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > [3.472600] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000] > [3.486479] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] > [3.500016] pci :00:00.0: BAR 9: assigned [mem 0x6010-0x601f > pref] > [3.514411] pci :00:00.0: BAR 1: assigned [mem 0x6020-0x6020] > [3.527951] pci :00:00.0: BAR 7: assigned [io 0x1e16-0x1e160fff] > [3.541489] pci :01:0
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Thu, Apr 9, 2020 at 12:19 PM Andre Valentin wrote: > > Am 09.04.20 um 06:48 schrieb Sergio Paracuellos: > > On Thu, Apr 9, 2020 at 6:36 AM Sergio Paracuellos > > wrote: > >> > >> Hi again, > >> > >> On Thu, Apr 9, 2020 at 5:57 AM Sergio Paracuellos > >> wrote: > >>> > >>> Hi Andre, > >>> > >>> On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos > >>> wrote: > >>>> > >>>> Hi André, > >>>> > >>>> > >>>> On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin > >>>> wrote: > >>>>> > >>>>> Hi Sergio! > >>>>> > >>>>> Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > >>>>>> Hi Andre, > >>>>>> > >>>>>> On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin > >>>>>> wrote: > >>>>>>> > >>>>>>> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> [CC Sergio who worked on upstream PCIE driver] > >>>>>>>>> > >>>>>>>>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi! > >>>>>>>>>> > >>>>>>>>>> Currently I'm having some serious problems with the new 5.4 port. > >>>>>>>>>> 1) PCIe > >>>>>>>>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a > >>>>>>>>>> mt7615e connected to second bus on the first phy. > >>>>>>>>>> If booting the device, kernel hangs with a RST message, telling > >>>>>>>>>> the device is not detected. It seems the PCIe bus 1 > >>>>>>>>>> cannot be reseted because nothing is connected to bus 0. > >>>>>>>>>> An upport of the old PCI driver reenables the function. I can > >>>>>>>>>> provide more logs on this if needed. > >>>>>>>> > >>>>>>>> Logs and dmesg traces are always welcome and would be helpful. Both > >>>>>>>> working and not working traces. > >>>>>>> > >>>>>>> Of course, here we go with the old PCIe driver taken from 4.14 > >>>>>>> openwrt kernel: > >>>>>>> [0.485729] pinctrl core: add 0 pinctrl maps > >>>>>>> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > >>>>>>> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > >>>>>>> [0.806088] * Xtal 40MHz * > >>>>>>> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > >>>>>>> [0.823025] Port 0 N_FTS = 1b102800 > >>>>>>> [0.829933] Port 1 N_FTS = 1b105000 > >>>>>>> [0.836849] Port 2 N_FTS = 1b102800 > >>>>>>> [1.995991] PCIE0 no card, disable it(RST) > >>>>>>> [2.004682] PCIE2 no card, disable it(RST) > >>>>>>> [2.013495] -> 20107f2 > >>>>>>> [2.018328] PCIE1 enabled > >>>>>>> [2.023532] PCI host bridge /pcie@1e14 ranges: > >>>>>>> [2.033045] MEM 0x6000..0x6fff > >>>>>>> [2.043401] IO 0x1e16..0x1e16 > >>>>>>> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > >>>>>>> 0x6000 > >>>>>>> [2.091056] PCI host bridge to bus :00 > >>>>>>> [2.099131] pci_bus :00: root bus resource [mem > >>>>>>> 0x6000-0x6fff] > >>>>>>> [2.112734] pci_bus :00: root bus resource [io 0x] > >>>>>>> [2.124486] pci_bus :00: root bus resource [??? 0x > >>>>>>> flags 0x0] > >>>>>>> [2.137962] pci_bus :0
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
On Thu, Apr 9, 2020 at 6:36 AM Sergio Paracuellos wrote: > > Hi again, > > On Thu, Apr 9, 2020 at 5:57 AM Sergio Paracuellos > wrote: > > > > Hi Andre, > > > > On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos > > wrote: > > > > > > Hi André, > > > > > > > > > On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin > > > wrote: > > > > > > > > Hi Sergio! > > > > > > > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > > > > > Hi Andre, > > > > > > > > > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin > > > > > wrote: > > > > >> > > > > >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > > > >>> Hi, > > > > >>> > > > > >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo > > > > >>> wrote: > > > > >>>> > > > > >>>> [CC Sergio who worked on upstream PCIE driver] > > > > >>>> > > > > >>>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > > > > >>>> wrote: > > > > >>>>> > > > > >>>>> Hi! > > > > >>>>> > > > > >>>>> Currently I'm having some serious problems with the new 5.4 port. > > > > >>>>> 1) PCIe > > > > >>>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a > > > > >>>>> mt7615e connected to second bus on the first phy. > > > > >>>>> If booting the device, kernel hangs with a RST message, telling > > > > >>>>> the device is not detected. It seems the PCIe bus 1 > > > > >>>>> cannot be reseted because nothing is connected to bus 0. > > > > >>>>> An upport of the old PCI driver reenables the function. I can > > > > >>>>> provide more logs on this if needed. > > > > >>> > > > > >>> Logs and dmesg traces are always welcome and would be helpful. Both > > > > >>> working and not working traces. > > > > >> > > > > >> Of course, here we go with the old PCIe driver taken from 4.14 > > > > >> openwrt kernel: > > > > >> [0.485729] pinctrl core: add 0 pinctrl maps > > > > >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > > > > >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > > > > >> [0.806088] * Xtal 40MHz * > > > > >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > > > > >> [0.823025] Port 0 N_FTS = 1b102800 > > > > >> [0.829933] Port 1 N_FTS = 1b105000 > > > > >> [0.836849] Port 2 N_FTS = 1b102800 > > > > >> [1.995991] PCIE0 no card, disable it(RST) > > > > >> [2.004682] PCIE2 no card, disable it(RST) > > > > >> [2.013495] -> 20107f2 > > > > >> [2.018328] PCIE1 enabled > > > > >> [2.023532] PCI host bridge /pcie@1e14 ranges: > > > > >> [2.033045] MEM 0x6000..0x6fff > > > > >> [2.043401] IO 0x1e16..0x1e16 > > > > >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > > > > >> 0x6000 > > > > >> [2.091056] PCI host bridge to bus :00 > > > > >> [2.099131] pci_bus :00: root bus resource [mem > > > > >> 0x6000-0x6fff] > > > > >> [2.112734] pci_bus :00: root bus resource [io 0x] > > > > >> [2.124486] pci_bus :00: root bus resource [??? 0x > > > > >> flags 0x0] > > > > >> [2.137962] pci_bus :00: No busn resource found for root bus, > > > > >> will use [bus 00-ff] > > > > >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > > > >> [2.165651] pci :00:00.0: reg 0x10: [mem > > > > >> 0x-0x7fff] > > > > >> [2.178057] pci :00:00.0: reg 0x14: [mem > > > > >> 0x6010-0x6010] > > > > >> [2.190585] pci :00:00.0: supports D1 > > > > >> [2.198439] pci :00:00.0: PME#
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi again, On Thu, Apr 9, 2020 at 5:57 AM Sergio Paracuellos wrote: > > Hi Andre, > > On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos > wrote: > > > > Hi André, > > > > > > On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin wrote: > > > > > > Hi Sergio! > > > > > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > > > > Hi Andre, > > > > > > > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin > > > > wrote: > > > >> > > > >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > > >>> Hi, > > > >>> > > > >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo > > > >>> wrote: > > > >>>> > > > >>>> [CC Sergio who worked on upstream PCIE driver] > > > >>>> > > > >>>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > > > >>>> wrote: > > > >>>>> > > > >>>>> Hi! > > > >>>>> > > > >>>>> Currently I'm having some serious problems with the new 5.4 port. > > > >>>>> 1) PCIe > > > >>>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > > > >>>>> connected to second bus on the first phy. > > > >>>>> If booting the device, kernel hangs with a RST message, telling the > > > >>>>> device is not detected. It seems the PCIe bus 1 > > > >>>>> cannot be reseted because nothing is connected to bus 0. > > > >>>>> An upport of the old PCI driver reenables the function. I can > > > >>>>> provide more logs on this if needed. > > > >>> > > > >>> Logs and dmesg traces are always welcome and would be helpful. Both > > > >>> working and not working traces. > > > >> > > > >> Of course, here we go with the old PCIe driver taken from 4.14 openwrt > > > >> kernel: > > > >> [0.485729] pinctrl core: add 0 pinctrl maps > > > >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > > > >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > > > >> [0.806088] * Xtal 40MHz * > > > >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > > > >> [0.823025] Port 0 N_FTS = 1b102800 > > > >> [0.829933] Port 1 N_FTS = 1b105000 > > > >> [0.836849] Port 2 N_FTS = 1b102800 > > > >> [1.995991] PCIE0 no card, disable it(RST) > > > >> [2.004682] PCIE2 no card, disable it(RST) > > > >> [2.013495] -> 20107f2 > > > >> [2.018328] PCIE1 enabled > > > >> [2.023532] PCI host bridge /pcie@1e14 ranges: > > > >> [2.033045] MEM 0x6000..0x6fff > > > >> [2.043401] IO 0x1e16..0x1e16 > > > >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > > > >> 0x6000 > > > >> [2.091056] PCI host bridge to bus :00 > > > >> [2.099131] pci_bus :00: root bus resource [mem > > > >> 0x6000-0x6fff] > > > >> [2.112734] pci_bus :00: root bus resource [io 0x] > > > >> [2.124486] pci_bus :00: root bus resource [??? 0x > > > >> flags 0x0] > > > >> [2.137962] pci_bus :00: No busn resource found for root bus, > > > >> will use [bus 00-ff] > > > >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > > >> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > > > >> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > > > >> [2.190585] pci :00:00.0: supports D1 > > > >> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > > > >> [2.211463] random: fast init done > > > >> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > > > >> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f > > > >> 64bit] > > > >> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > > > >> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s > > > >> with 5 GT/s x1 lin
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Wed, Apr 8, 2020 at 9:30 AM Sergio Paracuellos wrote: > > Hi André, > > > On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin wrote: > > > > Hi Sergio! > > > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > > > Hi Andre, > > > > > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin > > > wrote: > > >> > > >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > >>> Hi, > > >>> > > >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo > > >>> wrote: > > >>>> > > >>>> [CC Sergio who worked on upstream PCIE driver] > > >>>> > > >>>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > > >>>> wrote: > > >>>>> > > >>>>> Hi! > > >>>>> > > >>>>> Currently I'm having some serious problems with the new 5.4 port. > > >>>>> 1) PCIe > > >>>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > > >>>>> connected to second bus on the first phy. > > >>>>> If booting the device, kernel hangs with a RST message, telling the > > >>>>> device is not detected. It seems the PCIe bus 1 > > >>>>> cannot be reseted because nothing is connected to bus 0. > > >>>>> An upport of the old PCI driver reenables the function. I can provide > > >>>>> more logs on this if needed. > > >>> > > >>> Logs and dmesg traces are always welcome and would be helpful. Both > > >>> working and not working traces. > > >> > > >> Of course, here we go with the old PCIe driver taken from 4.14 openwrt > > >> kernel: > > >> [0.485729] pinctrl core: add 0 pinctrl maps > > >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > > >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > > >> [0.806088] * Xtal 40MHz * > > >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > > >> [0.823025] Port 0 N_FTS = 1b102800 > > >> [0.829933] Port 1 N_FTS = 1b105000 > > >> [0.836849] Port 2 N_FTS = 1b102800 > > >> [1.995991] PCIE0 no card, disable it(RST) > > >> [2.004682] PCIE2 no card, disable it(RST) > > >> [2.013495] -> 20107f2 > > >> [2.018328] PCIE1 enabled > > >> [2.023532] PCI host bridge /pcie@1e14 ranges: > > >> [2.033045] MEM 0x6000..0x6fff > > >> [2.043401] IO 0x1e16..0x1e16 > > >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > > >> 0x6000 > > >> [2.091056] PCI host bridge to bus :00 > > >> [2.099131] pci_bus :00: root bus resource [mem > > >> 0x6000-0x6fff] > > >> [2.112734] pci_bus :00: root bus resource [io 0x] > > >> [2.124486] pci_bus :00: root bus resource [??? 0x flags > > >> 0x0] > > >> [2.137962] pci_bus :00: No busn resource found for root bus, > > >> will use [bus 00-ff] > > >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > >> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > > >> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > > >> [2.190585] pci :00:00.0: supports D1 > > >> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > > >> [2.211463] random: fast init done > > >> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > > >> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f > > >> 64bit] > > >> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > > >> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with > > >> 5 GT/s x1 link) > > >> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to > > >> 01 > > >> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to > > >> 01 > > >> [2.298493] pci :00:00.0: BAR 0: no space for [mem size > > >> 0x8000] > > >> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size > > >> 0x8000] > > >> [2.32
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi André, On Wed, Apr 8, 2020 at 9:13 AM Andre Valentin wrote: > > Hi Sergio! > > Am 08.04.20 um 06:28 schrieb Sergio Paracuellos: > > Hi Andre, > > > > On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin wrote: > >> > >> Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > >>> Hi, > >>> > >>> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > >>>> > >>>> [CC Sergio who worked on upstream PCIE driver] > >>>> > >>>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > >>>> wrote: > >>>>> > >>>>> Hi! > >>>>> > >>>>> Currently I'm having some serious problems with the new 5.4 port. > >>>>> 1) PCIe > >>>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > >>>>> connected to second bus on the first phy. > >>>>> If booting the device, kernel hangs with a RST message, telling the > >>>>> device is not detected. It seems the PCIe bus 1 > >>>>> cannot be reseted because nothing is connected to bus 0. > >>>>> An upport of the old PCI driver reenables the function. I can provide > >>>>> more logs on this if needed. > >>> > >>> Logs and dmesg traces are always welcome and would be helpful. Both > >>> working and not working traces. > >> > >> Of course, here we go with the old PCIe driver taken from 4.14 openwrt > >> kernel: > >> [0.485729] pinctrl core: add 0 pinctrl maps > >> [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > >> [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > >> [0.806088] * Xtal 40MHz * > >> [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > >> [0.823025] Port 0 N_FTS = 1b102800 > >> [0.829933] Port 1 N_FTS = 1b105000 > >> [0.836849] Port 2 N_FTS = 1b102800 > >> [1.995991] PCIE0 no card, disable it(RST) > >> [2.004682] PCIE2 no card, disable it(RST) > >> [2.013495] -> 20107f2 > >> [2.018328] PCIE1 enabled > >> [2.023532] PCI host bridge /pcie@1e14 ranges: > >> [2.033045] MEM 0x6000..0x6fff > >> [2.043401] IO 0x1e16..0x1e16 > >> [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > >> 0x6000 > >> [2.091056] PCI host bridge to bus :00 > >> [2.099131] pci_bus :00: root bus resource [mem > >> 0x6000-0x6fff] > >> [2.112734] pci_bus :00: root bus resource [io 0x] > >> [2.124486] pci_bus :00: root bus resource [??? 0x flags > >> 0x0] > >> [2.137962] pci_bus :00: No busn resource found for root bus, will > >> use [bus 00-ff] > >> [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > >> [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > >> [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > >> [2.190585] pci :00:00.0: supports D1 > >> [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > >> [2.211463] random: fast init done > >> [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > >> [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f > >> 64bit] > >> [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > >> limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 > >> GT/s x1 link) > >> [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > >> [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01 > >> [2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > >> [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size > >> 0x8000] > >> [2.325410] pci :00:00.0: BAR 8: assigned [mem > >> 0x6000-0x600f] > >> [2.33] pci :00:00.0: BAR 1: assigned [mem > >> 0x6010-0x6010] > >> [2.352376] pci :01:00.0: BAR 0: assigned [mem > >> 0x6000-0x600f 64bit] > >> [2.366887] pci :00:00.0: PCI bridge to [bus 01] > >> [2.376728] pci :00:00.0: bridge window [mem > >> 0x6000-0x600f] > >> > >> > >> And this is on 5.4 with the new driver with pcie0 status=disabled:
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin wrote: > > Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > Hi, > > > > On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > >> > >> [CC Sergio who worked on upstream PCIE driver] > >> > >> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > >> wrote: > >>> > >>> Hi! > >>> > >>> Currently I'm having some serious problems with the new 5.4 port. > >>> 1) PCIe > >>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > >>> connected to second bus on the first phy. > >>> If booting the device, kernel hangs with a RST message, telling the > >>> device is not detected. It seems the PCIe bus 1 > >>> cannot be reseted because nothing is connected to bus 0. > >>> An upport of the old PCI driver reenables the function. I can provide > >>> more logs on this if needed. > > > > Logs and dmesg traces are always welcome and would be helpful. Both > > working and not working traces. > > Of course, here we go with the old PCIe driver taken from 4.14 openwrt kernel: > [0.485729] pinctrl core: add 0 pinctrl maps > [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > [0.806088] * Xtal 40MHz * > [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > [0.823025] Port 0 N_FTS = 1b102800 > [0.829933] Port 1 N_FTS = 1b105000 > [0.836849] Port 2 N_FTS = 1b102800 > [1.995991] PCIE0 no card, disable it(RST) > [2.004682] PCIE2 no card, disable it(RST) > [2.013495] -> 20107f2 > [2.018328] PCIE1 enabled > [2.023532] PCI host bridge /pcie@1e14 ranges: > [2.033045] MEM 0x6000..0x6fff > [2.043401] IO 0x1e16..0x1e16 > [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > 0x6000 > [2.091056] PCI host bridge to bus :00 > [2.099131] pci_bus :00: root bus resource [mem 0x6000-0x6fff] > [2.112734] pci_bus :00: root bus resource [io 0x] > [2.124486] pci_bus :00: root bus resource [??? 0x flags 0x0] > [2.137962] pci_bus :00: No busn resource found for root bus, will use > [bus 00-ff] > [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > [2.190585] pci :00:00.0: supports D1 > [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > [2.211463] random: fast init done > [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited > by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 > link) > [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01 > [2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000] > [2.325410] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] > [2.33] pci :00:00.0: BAR 1: assigned [mem 0x6010-0x6010] > [2.352376] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f > 64bit] > [2.366887] pci :00:00.0: PCI bridge to [bus 01] > [2.376728] pci :00:00.0: bridge window [mem 0x6000-0x600f] > > > And this is on 5.4 with the new driver with pcie0 status=disabled: > [ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [ 30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK) > [ 30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual > bridges. Exiting... > booting goes on. > > And with pcie status=enabled: > [ 32.415863] rt2880-pinmux pinctrl: pcie is already enabled > [ 32.426821] mt7621-pci 1e14.pcie: Error applying setting, reverse > things back > [ 32.441900] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > port = 1) > [ 32.456880] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > port = 0) > [ 32.5715
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi, On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > > [CC Sergio who worked on upstream PCIE driver] > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote: > > > > Hi! > > > > Currently I'm having some serious problems with the new 5.4 port. > > 1) PCIe > > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > > connected to second bus on the first phy. > > If booting the device, kernel hangs with a RST message, telling the device > > is not detected. It seems the PCIe bus 1 > > cannot be reseted because nothing is connected to bus 0. > > An upport of the old PCI driver reenables the function. I can provide more > > logs on this if needed. Logs and dmesg traces are always welcome and would be helpful. Both working and not working traces. > > Hi Sergio: > You may want to look into this. > > > 2) DSA > > These are my first experiments with DSA. I've configured 2 bridges: > > lan: lan1 lan2 lan3 lan4 > > dmz: lan1.20 lan2.20 lan3.20 lan4.20 > > > > Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 > > port but does note arrive at the other end. > > > > Should this work with DSA on mediathek? > > It's supposed to work so this may be yet another bug upstream. > > > If not, I can offer that I write a patch for traditional swconfig. > > swconfig is considered deprecated so there's no need to do so. > In fact, this driver under mediatek target also works for mt7621: > target/linux/mediatek/files-5.4/drivers/net/phy/mtk/mt753x > > -- > Regards, > Chuanhong Guo Best regards, Sergio Paracuellos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Does anyone have used Ralink i2s under openwrt?
Hi guys, Hi, once i fixed the codec problem on my unit i will look at the bug. can you help me get one of the rt5350 boards that you have ? can you tell me a link the the board ? John I'm using toplinkst top-ap01-38 with RT5350 and trying to setup a dac codec using i2s. Please, have you got any progress with i2s and alsa soc? Sergio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Does anyone have used Ralink i2s under openwrt?
John Crispin blogic at openwrt.org writes: sorry, been too busy and i doubt i will have time in the near future to look at it :( Oooh! Too bad :)) John, could you teld me some tips on how to progress with it and RT5350 cpu instead MT7620? I've defined a new section in ...target/linux/ramips/modules.mk = in order to create the new module define KernelPackage/sound-rt5350 TITLE:=rt5350 PCM/I2S Alsa Driver DEPENDS:=@TARGET_ramips_rt305x +kmod-sound-soc-core +kmod-regmap KCONFIG:= \ ... Also modified ...linux-3.10.49/sound/soc/ralink/Kconfig config SND_MT7620_SOC_I2S depends on (SOC_MT7620 || SOC_RT305X) SND_SOC select SND_SOC_GENERIC_DMAENGINE_PCM ... So I'm getting bin/ramips/packages/base/kmod-sound-rt5350_3.10.49- 1_ramips_24kec.ipk package, but now I wonder how to add a new card using this modules. Maybe I've to deal with DT? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ssl certificate on https://openwrt.org/
Hello. I'm not sure that this is right place to say this, but. The https certificate will expire the day after tomorrow. On 15th of July. Please don't forget to renew it! -- sergio. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Atheros 8327
Hello. Does atheros 8327 switch chip supported by openwrt or linux at all? -- sergio. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
