After 'PCI_IOBASE' is defined for ralink, ranges are properly parsed
using pci generic APIS and there is no need to parse anything
manually. So function 'mt7621_pci_parse_request_of_pci_ranges'
used for this can be enterely removed. Since we have to configure
iocu memory regions and pci io windows resources must be retrieved
accordly from 'bridge->windows' but there is no need to store
anything as driver private data.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210614100617.28753-3-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Function 'mt7621_pcie_enable_port' is calculating an offset
to write some port related registers. Instead of doing that
just make use of already existent 'pcie_write_port' function
and use virtualy mapped base address with registers. This
increase readability and allow us to remove also two defitions
not used else where.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210607120153.24989-7-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Properties 'clocks', 'resets' and 'phys' have been moved from parent
node to the root port children. Hence we have to adapt the way device
tree is parsed in driver code to properly align things and make all
the stuff work.
Note that we moved from using 'devm_reset_control_get_exclusive() to
'of_reset_control_get_exclusive()' so we need to properly call the
'reset_control_put()' function manually in error and remove paths.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210607120153.24989-6-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver does not perform DMA, so it's safe to use the relaxed version
for both readl and writel operations.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210607120153.24989-4-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of define RALINK_PCI_BAR0SETUP_ADDR just use standard
pci defnition for this which is 'PCI_BASE_ADDRESS_0'.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210607120153.24989-3-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Function 'mt7621_pcie_enable_ports' call 'mt7621_pcie_enable_port'
for each available pcie port. Instead of having two for loops
there just move needed initialization. There is one setting
that can be removed which is the set for 'PCI_COMMAND_MASTER'
bit. Pci drivers are in charge of set that bit if is really
needed and should be not a mission of the controller to do that.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210607120153.24989-2-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Custom function for 'map_irq' was introduced in
commit fab6710e4c ("staging: mt7621-pci: fix PCIe interrupt mapping")
After some testing in an adquired device with a similar
pci layout that those that was having problems, I got
into a better way to solve the issue just using device tree
'interrupt-map' and 'interrupt-map-mask' properties. For
this to be possible we must avoid custom configuration of
the virtual bridges registers from driver code. Doing in
this way buses are not reconfigured so we can properly
use bus related bits and mask in device tree to map
correctly the interrupts. Hence remove custom configuration
of the bridges as well as custom 'map_irq' related stuff.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210505121736.6459-8-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Return code after call function 'mt7621_pcie_register_host' is
being checked to give an error message. This function internally
is calling 'pci_host_probe' which if something fails will complain
already. Hence, directly return result of this call making decrease
a bit LOC.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210505121736.6459-7-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are two mdelay calls in driver code located in
'mt7621_pcie_reset_assert' and 'mt7621_pcie_reset_rc_deassert'
functions. Both of them are not called in an interrupt handler
nor holding any spinlock. Hence, the function mdelay in them
can be replaced with msleep, to reduce busy wait.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210505121736.6459-6-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some includes used here are not really necessary for
the code to compile properly. Hence remove them.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210505121736.6459-4-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gpio mode for the pcie pins must be request from device
tree using pinctrl driver. Pinctrl driver is already setting
this pcie pins as GPIO if it is requested. Hence, remove it
from here.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210505121736.6459-3-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MT7621 SoC clock driver has already mainlined in
'commit 48df7a26f4 ("clk: ralink: add clock driver for mt7621 SoC")'
Hence, we can make use of kernel clock apis and avoid to
directly set bits in clock gate related registers for pci.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20210505121736.6459-2-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The logic here was already overriding the erroneous IO addresses
returned from of_pci_range_to_resource, which is the bulk of the logic.
So stop using it altogether and initialize the fields explicitly, as
done in aeba3731b1 ("powerpc/pci: Fix IO space breakage after
of_pci_range_to_resource() change").
Cc: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Link: https://lore.kernel.org/r/20210410173331.57949-1-ilya.lipnitskiy@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Register 'RALINK_PCI_IMBASEBAR0_ADDR' contains internal memory
base address for BAR0. We don't really need to write anything
there at all since its initial value contains always a desired
valid value. Hence remove register definition and related code.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-8-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of getting resources parsing from DT first and remaping
afterwards, this can be done in one step using the kernel function
'devm_platform_ioremap_resource'. Hence, update to use it.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-7-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove 'mt7621_pcie_add_resources' where resources are added to the host
windows moving this code into the function where all the parsing and
preparing code is being done: 'mt7621_pci_parse_request_of_pci_ranges'.
The memory resource has been properly parsed for the PCI APIs so we
only need to retrieve it and use it in those places we need.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-6-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI kernel apis now set some variables related with pci_host_bridge
by default and it is not necessary to setup them in driver code.
Host bridge parent device is set by default to the platform device
and 'swizzle_irq' is also set to its default function. These two
are not necessary to be set here. Hence remove them.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-5-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Because IO_SPACE_LIMIT for mips is 0xFFFF but this platform uses
PĈI IO resource at 0x001e160000. Hence instead of directly use
some more accurate functions from the PCI kernel for this driver
some things must be done in a different way to make things work.
Add this explanation as a comment where the IO resource is parsed
and virtually mapped into memory.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-4-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Offset contains resources size for both io and memory resources.
Those fields are directly initialized to zero and set up using
'pci_add_resource_offset' function. Instead of doing that remove
them and use directly function 'pci_add_resource' where zero is
passed directly to its internal call to 'pci_add_resource_offset'.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201123093637.8300-3-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After upgrading kernel to version 5.9.x the driver was not
working anymore showing the following kernel trace:
...
mt7621-pci 1e140000.pcie: resource collision:
[mem 0x60000000-0x6fffffff] conflicts with pcie@1e140000 [mem 0x60000000-0x6fffffff]
------------[ cut here ]------------
WARNING: CPU: 2 PID: 73 at kernel/resource.c:1400
devm_request_resource+0xfc/0x10c
Modules linked in:
CPU: 2 PID: 73 Comm: kworker/2:1 Not tainted 5.9.2 #0
Workqueue: events deferred_probe_work_func
Stack : 00000000 81590000 807d0a1c 808a0000 8fd49080
807d0000 00000009 808ac820
00000001 808338d0 7fff0001 800839dc 00000049
00000001 8fe51b00 367204ab
00000000 00000000 807d0a1c 807c0000 00000001
80082358 8fe50000 00559000
00000000 8fe519f1 ffffffff 00000005 00000000
00000001 00000000 807d0000
00000009 808ac820 00000001 808338d0 00000001
803bf1b0 00000008 81390008
Call Trace:
[<8000d018>] show_stack+0x30/0x100
[<8032e66c>] dump_stack+0xa4/0xd4
[<8002db1c>] __warn+0xc0/0x134
[<8002dbec>] warn_slowpath_fmt+0x5c/0xac
[<80033b34>] devm_request_resource+0xfc/0x10c
[<80365ff8>] devm_request_pci_bus_resources+0x58/0xdc
[<8048e13c>] mt7621_pci_probe+0x8dc/0xe48
[<803d2140>] platform_drv_probe+0x40/0x94
[<803cfd94>] really_probe+0x108/0x4ec
[<803cd958>] bus_for_each_drv+0x70/0xb0
[<803d0388>] __device_attach+0xec/0x164
[<803cec8c>] bus_probe_device+0xa4/0xc0
[<803cf1c4>] deferred_probe_work_func+0x80/0xc4
[<80048444>] process_one_work+0x260/0x510
[<80048a4c>] worker_thread+0x358/0x5cc
[<8004f7d0>] kthread+0x134/0x13c
[<80007478>] ret_from_kernel_thread+0x14/0x1c
---[ end trace a9dd2e37537510d3 ]---
mt7621-pci 1e140000.pcie: Error requesting resources
mt7621-pci: probe of 1e140000.pcie failed with error -16
...
With commit 669cbc7081 ("PCI: Move DT resource setup into
devm_pci_alloc_host_bridge()"), the DT 'ranges' is parsed and populated
into resources when the host bridge is allocated. The resources are
requested as well, but that happens a 2nd time for this driver in
mt7621_pcie_request_resources(). Hence we should avoid this second
request.
Also, the bus ranges was also populated by default, so we can remove
it from mt7621_pcie_request_resources() to avoid the following trace
if we don't avoid it:
pci_bus 0000:00: busn_res: can not insert [bus 00-ff]
under domain [bus 00-ff] (conflicts with (null) [bus 00-ff])
Function 'mt7621_pcie_request_resources' has been renamed into
'mt7621_pcie_add_resources' which now is a more accurate name
for this function.
Cc: stable@vger.kernel.org #5.9.x-
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20201102202515.19073-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Variable 'n' in 'mt7621_pcie_init_virtual_bridges' function
can be directly initialized when it is declared instead of
doing it before using it first.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200413155018.31921-3-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a comment explaining a bit what is going on in this function.
It would be helfulp for other people for a better understanding
of the code.
Suggested-by: NeilBrown <neil@brown.name>
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200413155018.31921-2-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Definition 'PCIE_P2P_MAX' is '3'. The value here is not a MAXimum.
It is a count or a number. It is how many masks there are.
The masks are numbered 0, 1, 2 so the maximum is 2. Hence rename
variable into 'PCIE_P2P_CNT' which is a more accurate name.
Suggested-by: NeilBrown <neil@brown.name>
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200413155018.31921-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MT7621 has three assigned interrupts for the pcie. This
interrupts should properly being mapped taking into account
which devices are finally connected in which bus according
to link status. So the irq mappings should be as follows
according to link status (three bits indicating which devices
are link up):
* For PCIe Bus 1 slot 0:
- status = 0x2 || status = 0x6 => IRQ = pcie1_irq (24).
- status = 0x4 => IRQ = pcie2_irq (25).
- default => IRQ = pcie0_irq (23).
* For PCIe Bus 2 slot 0:
- status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25).
- default => IRQ = pcie1_irq (24).
* For PCIe Bus 2 slot 1:
- status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25).
- default => IRQ = pcie1_irq (24).
* For PCIe Bus 3 any slot:
- default => IRQ = pcie2_irq (25).
Because of this, the function 'of_irq_parse_and_map_pci' cannot
be used and we need to change device tree information from using
the 'interrupt-map' and 'interrupt-map-mask' properties into an
'interrupts' property to be able to get irq information from the
ports using the 'platform_get_irq' and storing an 'irq-map' into
the pcie driver data node to properly map correct irq using a
new 'mt7621_map_irq' function where this map will be read and the
correct irq returned.
Fixes: 46d093124d ("staging: mt7621-pci: improve interrupt mapping")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200413055942.2714-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pcie phy for pcie0 and pcie1 is shared using a dual ported
one. Current code was assuming that if nothing is connected
in pcie0 it won't be also nothing connected in pcie1. This
assumtion is wrong for some devices such us 'Mikrotik rbm33g'
and 'ZyXEL LTE3301-PLUS' where only connecting a card to the
second bus on the phy is possible. For such devices kernel
hangs in the same point because of the wrong poweroff of the
phy getting the following trace:
mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1)
mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0)
mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
mt7621-pci 1e140000.pcie: pcie0 no card, disable it (RST & CLK)
[hangs]
The wrong assumption is located in the 'mt7621_pcie_init_ports'
function where we are just making a power off of the phy for
slots 0 and 2 if nothing is connected in them. Hence, only
poweroff the phy if nothing is connected in both slot 0 and
slot 1 avoiding the kernel to hang.
Fixes: 5737cfe87a ("staging: mt7621-pci: avoid to poweroff the phy for slot one")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200409111652.30964-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Setting up kernel resource 'iomem_resource' for PCI with
addresses parsed from device tree gots into a conflict within
the usb xhci driver:
xhci-mtk 1e1c0000.xhci: can't request region for resource [mem 0x1e1c0000-0x1e1c0fff]
xhci-mtk: probe of 1e1c0000.xhci failed with error -16
Don't assign it and maintain the default addresses for this
resource seems to fix the problem. Checking legacy driver it
is being only setting the 'ioport_resource'.
Fixes: 09dd629eea ("staging: mt7621-pci: fix io space and properly set resource limits")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200322072128.4454-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Macro builtin_platform_driver can be used for builtin drivers
that don't do anything in driver init. So, use the macro
builtin_platform_driver and remove some boilerplate code.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200321133624.31388-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Making gpio8 and gpio9 vendor specific and putting them
into the specific dts file makes not needed to release
gpios anymore because we are not occupying those pins
in the first place if it is not necessary. When the
device tree is parsed we can also check and return for
the error because we rely in the fact that the related
device for the board is correct.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200321072650.7784-3-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Function 'devm_gpiod_get_index_optional' returns NULL if the
descriptor is invalid and the error associated for the error
pointer is ENOENT. Sometimes if the pin is just assigned the
error associated for the pointer might not be ENOENT but other.
In order to avoid weirds behaviours if this happen set descriptor
to NULL in the driver port structure.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200320110123.9907-6-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We are using the counter to print the slot which has been
enabled. Use the correct associated slot for the port instead.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200320110123.9907-5-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In order to align work with the mt7621-pci-phy part of
the driver and device tree which is now using only two
real phys one of them dual ported properly parse the
device tree and don't call phy initialization for the
slot 1 because is being taking into account when the
phy for the slot 0 is instantiated.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200320110123.9907-4-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In some platforms gpio's are not used for reset but
for other purposes. Because of that when we try to
get them are valid gpio's but are already assigned
to do other function. To avoid those kind of problems
in those platforms just notice the fail in the kernel
but continue doing normal boot.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200319161416.19033-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Instead of being using PCI Configuration and Status Register to
set up virtual bridges we are using CONFIG_ADDR Register which is
wrong. Hence, set the correct value.
Fixes: 9a5e71a68d ("staging: mt7621-pci: simplify 'mt7621_pcie_init_virtual_bridges' function")
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200319095733.1557-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Function 'mt7621_pci_parse_request_of_pci_ranges' is using
'of_pci_range_to_resource' to get both mem and io resources.
Internally this function calls to 'pci_address_to_pio' which
returns -1 if io space address is an address > IO_SPACE_LIMIT
which is 0xFFFF for mips. This mt7621 soc has io space in physical
address 0x1e160000. In order to fix this, overwrite invalid io
0xffffffff with properly values from the device tree and set
mapped address of this resource as io port base memory address
calling 'set_io_port_base' function. There is also need to properly
setup resource limits and io and memory windows with properly
parsed values instead of set them as 'no limit' which it is wrong.
For any reason I don't really know legacy driver sets up mem window
as 0xFFFFFFFF and any other value seems to does not work as expected,
so set up also here with same values.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200318094445.19669-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After review all the resets at the beggining the function
'mt7621_reset_port' is not needed anymore. Hence delete it
and its uses.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200313200913.24321-7-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
R3G's LEDs fail to initialize because one of them uses GPIO8
Hence, release the GPIO resources after PCIe initialization
and properly release also in driver error path.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200313200913.24321-6-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Properly update bindings documentation with added 'reset-gpios'
property. Delete also 'perst-gpio' which is not being used anymore.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200313200913.24321-5-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Value of 'PERST_DELAY_MS' is too high and it is ok just
to set up to 100 ms. Update also define name from
'PERST_DELAY_US' into 'PERST_DELAY_MS'
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200313200913.24321-3-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Original driver code was using three gpio's for reset
asserts and deasserts the pcis. Instead of using that
a general reset control with a perst gpio was introduced
and it seems it is partially working but sometimes there
are some unexpected hangs on boot. This commit make use of
the three original gpios using 'reset-gpios' property of
the device tree and removes the reset line and perst gpio.
According to the mediatek aplication note v0.1 there are
three gpios used for pcie ports reset control: gpio#19,
gpio#8 and gpio#7 for slots 0, 1 and 2 respectively.
This schema can be used separately for mt7621A but in some
boards due to pin share issue, if the PCM and I2S function
are enable at the same time, there are no enough GPIO to
control per-port PCIe reset. In those cases gpio#19 is enought
for reset the three ports together. Because of this we just
try to get the three gpios but if some of them fail we are not
failing in boot process, just prints a kernel notice and take
after into account if the descriptor is or not valid in order
to use it. All of them are set as GPIO output low configuration.
The gpio descriptor's API takes device tree property into account
and invert value if the pin is configured as active low.
So we also have to properly request pins from device tree
and set values correct in assert and deassert functions.
After this changes the order to make all assert and
deassert in the 'probe' process makes more sense:
* Parse device tree.
* make assert of the RC's and EP's before doing anything else.
* make deassert of the RC's before initializing the phy.
* Init the phy.
* make deassert of the EP's before initialize pci ports.
* Normal PCI initialization.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200313200913.24321-2-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The clock related code concerns me from the very beginning because
there are some set ups got from legacy driver that are not documented
anywhere. According to the programming guide 0x7c is 'CPE_ROSC_SEL1'
register and 0x80 is 'CPU_CPE_CN'. I do think this set up is not needed
at all and the proper thing to do is just enable the clock bit for each
pcie port. Hence remove useless code and do the right thing which is
setting up the clock bit for each port enabled.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200310113459.30539-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Function 'mt7621_pcie_init_virtual_bridges' is a bit mess and can be
refactorized properly in a cleaner way. Introduce new 'pcie_rmw' inline
function helper to do clear and set the correct bits this function needs
to work.
Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Link: https://lore.kernel.org/r/20200308091928.17177-1-sergio.paracuellos@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergio Paracuellos