up that would avoid this issue ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
er reset/reinit of the HW ?
I.e, isn't the firmware fix papering over a bug that should be fixed in
Linux mvpp2 driver anyway ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
e link status. This is achieved using SFP+phylink+PPv2.
>
> And representing the SFP cage in the device tree, although it's a
> "dummy" one, helps describing the hardware.
Just to add to this: the board physically has a SFP cage, and a cable
can be connected to it, or not. So
eginning of this process.
>
> Signed-off-by: Yelena Krivosheev <yel...@marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clem...@bootlin.com>
Acked-by: Thomas Petazzoni <thomas.petazz...@bootlin.com>
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Ele
tric,
with the hw/sw parts split in a similar way for the init and deinit of
both txqs and rxqs, but I agree that dropping the RX packets before
going into suspend involves both HW and SW operations.
Thanks!
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
+
> + if (!pp->neta_armada3700) {
> + spin_lock(>lock);
> + pp->is_stopped = false;
> + spin_unlock(>lock);
> + cpuhp_state_add_instance_nocalls(online_hpstate,
> + >node_online);
> + cpuhp_state_add_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
> + >node_dead);
> + }
> +
> + mvneta_set_rx_mode(dev);
> + mvneta_start_dev(pp);
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
y minor nits below, but otherwise:
Acked-by: Thomas Petazzoni <thomas.petazz...@bootlin.com>
> +/* Create a specified RX queue */
> +static int mvneta_rxq_init(struct mvneta_port *pp,
> +struct mvneta_rx_queue *rxq)
> +
> +{
> + int ret;
&g
GN(X, SMP_CACHE_BYTES)
I don't really see a __max(...) call.
And if this value really expands depending on other values, then it
isn't really a constant, and should be considered as a constant, no?
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
and the other ports ?
>
> This is correct for all ports. All ports can support Jumbo frames.
OK. With your explanation above, I understand better.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
imitation of PPv2.2, and mentioning CP110 in the comment doesn't make
much sense, correct ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
Pv2.2 IP, or of the CP110 ?
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
dev->min_mtu = ETH_MIN_MTU;
> - /* 9676 == 9700 - 20 and rounding to 8 */
> - dev->max_mtu = 9676;
How come we already had a max_mtu of 9676 without Jumbo frame support ?
> + /* 9704 == 9728 - 20 and rounding to 8 */
> + dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;
Is this correct for all ports ? Shouldn't the maximum MTU be different
between port 0 (that supports Jumbo frames) and the other ports ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
mvpp2_pools[MVPP2_BM_LONG].pkt_size = MVPP2_BM_LONG_PKT_SIZE;
> +}
?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
und comparison in operand of ‘|’ [-Wparentheses]
> if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX |
> ^~~~~~~
This is actually a very good warning: it should be a || and not |.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
G_FAST_SH4 layout ?
Note that my patch makes Ethernet work in practice on SH7784, I have
root over NFS working as we speak. This certainly doesn't mean that the
patch is entirely correct, but it definitely means that the
SH_ETH_REG_FAST_SH4 is close enough to what the SH7786 is using :-)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
t a v3 that takes into account this
comment.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
the MAC doesn't support it.
In order to avoid this, we use the recently introduced
phy_set_max_speed() to tell the PHY to not advertise speed higher than
100 MBit/s.
Tested on a SH7786 platform, with a Gigabit PHY.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
Changes
dev->dev);
pm_runtime_put_sync(>pdev->dev);
struct device *dev = >pdev->dev;
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
the MAC doesn't support it.
In order to avoid this, we use the recently introduced
phy_set_max_speed() to tell the PHY to not advertise speed higher than
100 MBit/s.
Tested on a SH7786 platform, with a Gigabit PHY.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
Changes
Hello,
On Mon, 4 Dec 2017 19:56:35 +0300, Sergei Shtylyov wrote:
> On 12/04/2017 05:17 PM, Thomas Petazzoni wrote:
>
> > This commit adds the sh_eth_cpu_data structure that describes the
> > SH7786 variant of the IP.
>
> The manual seems to be unavailable, so I hav
, my
change is based on the assumption that the DMA descriptors are in the
native endianness of the CPU.
Thanks,
Thomas
Thomas Petazzoni (2):
net: sh_eth: add support for SH7786
net: sh_eth: make work on big endian systems
drivers/net/ethernet/renesas/sh_eth.c | 89
This commit adds the sh_eth_cpu_data structure that describes the
SH7786 variant of the IP.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drive
running
big-endian. Therefore, all the endianness conversion needs to be
removed for the sh_eth driver to work.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
Note: I see that Sergei Shtylyov has done some work around endianness
on this driver back in 2015. I am no
ven though the MAC
doesn't support it.
In order to avoid this, we mark phydev->supported if we're running a
non-Gigabit capable hardware.
Tested on a SH7786 platform, with a Gigabit PHY.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/renesas/
Using NULL as argument for the DMA mapping API is bogus, as the DMA
mapping API may use information from the "struct device" to perform
the DMA mapping operation. Therefore, pass the appropriate "struct
device".
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-elec
Hello,
Here are two patches that fix how the sh_eth driver is using the DMA
mapping API: a bogus struct device is used in some places, or a NULL
struct device is used.
Best regards,
Thomas
Thomas Petazzoni (2):
net: sh_eth: use correct "struct device" when calling DMA mapping
uct device" representing the physical device on
its bus.
This commit fixes that by adjusting all calls to the DMA mapping API.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 19 ++-
1 file changed, 1
e5abdfc76ee83e5 ]---
> [ 1344.696733] Kernel panic - not syncing: Fatal exception in interrupt
> [ 1344.703310] SMP: stopping secondary CPUs
> [ 1344.707369] Kernel Offset: disabled
> [ 1344.710613] CPU features: 0x002008
> [ 1344.714294] Memory Limit: none
> [ 1344.717086] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt
>
> I you want more logs or some other details about my setup i'll be
> happy to help :-)
> Also with testing a possible fix.
>
> Thanks,
> Sean Nyekjaer
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
wonder what is happening if
> "txq->pending + frags > MVNETA_TXQ_DEC_SENT_MASK" ? Because IIUC
> mvneta_txq_pend_desc_add() is called anyway. And according to the
> comment inside the function, it assumes there is less than 255
> descriptors to send... It looks suspect.
Tha
y
issues with this patch applied.
Do you think you will have some time to look into this ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
ocus on those 3 commits for the moment.
Assuming you're using Git, to revert a commit just do: "git revert
".
Thanks again!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
c8e1a73bfc616a66b802b90 net: mvneta: add BQL support
2a90f7e1d5d04e4f1060268e0b55a2c702bbd67a net: mvneta: add xmit_more support
Could you try to take mvneta* from Linux 4.10, put that in Linux 4.12,
and see if you can still produce the problem? I'd like to first make
sure the problem really
goto err_gop_clk;
> +
> + priv->axi_clk = devm_clk_get(>dev, "axi_clk");
> + if (IS_ERR(priv->axi_clk)) {
> + err = PTR_ERR(priv->axi_clk);
> + priv->axi_clk = NULL;
You should handle -EPROBE_DEFER here. Indeed, if we have -EPROBE_DEFER,
we shouldn't treat it as "the clock doesn't exist, so let's skip it and
continue", but rather as "the clock exists, but isn't ready to use yet,
let's try later".
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
, and not to the
GIC directly.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
.../devicetree/bindings/net/marvell-pp2.txt| 28 +++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.
of RXQ and
TXQ.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 83 ++--
1 file changed, 41 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/et
, with only one RX interrupt, and TX completion being handled
by an hrtimer.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 275 +++
1 file changed, 246 insertions(+), 29 deletions(-)
diff
nge, it makes sense to change the naming
from MVPP2_MAX_CPUS to MVPP2_MAX_THREADS, and plan for 8 software
threads instead of 4 currently.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 25 +
1 file ch
s a single queue_vector, so there are
no changes in behavior, but it paves the way for additional
queue_vector in the next commits.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 223 ++-
1 f
The RX queue group allocation is anyway re-done later in
mvpp2_port_init(), so resetting it in mvpp2_init() is not very useful,
and will be annoying as we are going to rework the RX queue group
allocation logic.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
d
tree.
Thanks!
Thomas
Thomas Petazzoni (7):
net: mvpp2: fix MVPP21_ISR_RXQ_GROUP_REG definition
net: mvpp2: remove RX queue group reset code
net: mvpp2: introduce per-port nrxqs/ntxqs variables
net: mvpp2: move from cpu-centric naming to "software thread" naming
net: mvpp2:
The MVPP21_ISR_RXQ_GROUP_REG register is not indexed by rxq, but by
port, so we fix the parameter name accordingly. There are no
functional changes.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 ins
consider the RMII and (R)GMII cases.
Have you had the chance to cook a different proposal? Alternatively, do
you have some specific hints to give me to make a new proposal that
would be acceptable for you ?
Thanks a lot,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and
ch series
that contain patches that will be merged by different maintainers.
> don't bother adding them to the series. That way you don't have to
> give me special instructions, and I don't have the possibility of
> making a mistake and applying it accidently.
... but OK, I won't rese
of RXQ and
TXQ.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 83 ++--
1 file changed, 41 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/et
, with only one RX interrupt, and TX completion being handled
by an hrtimer.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 275 +++
1 file changed, 246 insertions(+), 29 deletions(-)
diff
The MVPP21_ISR_RXQ_GROUP_REG register is not indexed by rxq, but by
port, so we fix the parameter name accordingly. There are no
functional changes.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 ins
This commit updates the Marvell Armada 7K/8K Device Tree to describe
the TX interrupts of the Ethernet controllers, in both the master and
slave CP110s.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
Dave: please do *not* apply this patch. It will go through t
nge, it makes sense to change the naming
from MVPP2_MAX_CPUS to MVPP2_MAX_THREADS, and plan for 8 software
threads instead of 4 currently.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 25 +
1 file ch
s a single queue_vector, so there are
no changes in behavior, but it paves the way for additional
queue_vector in the next commits.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 250 +--
1 f
The RX queue group allocation is anyway re-done later in
mvpp2_port_init(), so resetting it in mvpp2_init() is not very useful,
and will be annoying as we are going to rework the RX queue group
allocation logic.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
d
Antoine's.
- Please do not apply the last patch of this series "arm64: dts:
marvell: add TX interrupts for PPv2.2", it will be taken by the ARM
mvebu maintainers.
Thanks!
Thomas
Thomas Petazzoni (8):
net: mvpp2: fix MVPP21_ISR_RXQ_GROUP_REG definition
net: mvpp2: remove RX queue gr
, and not to the
GIC directly.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
.../devicetree/bindings/net/marvell-pp2.txt| 33 +-
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.
path and in the remove path.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Hello Giuseppe,
On Mon, 15 May 2017 16:27:34 +0200, Thomas Petazzoni wrote:
> On Wed, 10 May 2017 09:18:17 +0200, Thomas Petazzoni wrote:
>
> > On Wed, 10 May 2017 09:03:12 +0200, Giuseppe CAVALLARO wrote:
> >
> > > > Please, read again my patch and the des
When all a function does is calling another function with the exact same
arguments, in the exact same order, you know it's time to remove said
function. Which is exactly what this commit does.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/m
David,
Here are a few patches making various small improvements/refactoring
in the mvpp2 driver. They are based on today's net-next.
Thanks!
Thomas
Thomas Petazzoni (3):
net: mvpp2: add comments about smp_processor_id() usage
net: mvpp2: remove unused mvpp2_bm_cookie_pool_set() function
A previous commit modified a number of smp_processor_id() used in
migration-enabled contexts into get_cpu/put_cpu sections. However, a few
smp_processor_id() calls remain in the driver, and this commit adds
comments explaining why they can be kept.
Signed-off-by: Thomas Petazzoni <thomas.pet
This function is not used in the driver, remove it.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/m
the kbuild
report on the first submission.
- Added Tested-by from Marc Zyngier on PATCH 2.
Thanks!
Thomas
Thomas Petazzoni (2):
net: mvpp2: remove mvpp2_bm_cookie_{build,pool_get}
net: mvpp2: use {get,put}_cpu() instead of smp_processor_id()
drivers/net/ethernet/marvell/mv
, this commit replaces the smp_processor_id() in
migration-enabled contexts by the appropriate get_cpu/put_cpu sections.
Reported-by: Marc Zyngier <marc.zyng...@arm.com>
Fixes: a786841df72e ("net: mvpp2: handle register mapping and access for
PPv2.2")
Signed-off-by: Thomas Petazzoni <th
: 3f518509dedc9 ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 47 +++-
1 file changed, 14 insertions(+), 33 deletion
When all a function does is calling another function with the exact same
arguments, in the exact same order, you know it's time to remove said
function. Which is exactly what this commit does.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/m
A previous commit modified a number of smp_processor_id() used in
migration-enabled contexts into get_cpu/put_cpu sections. However, a few
smp_processor_id() calls remain in the driver, and this commit adds
comments explaining why they can be kept.
Signed-off-by: Thomas Petazzoni <thomas.pet
This function is not used in the driver, remove it.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/m
should be pushed to stable.
The last three patches are cleanups and not needed for stable, but
they stack on top of the fixes.
Thanks,
Thomas
Thomas Petazzoni (5):
net: mvpp2: remove mvpp2_bm_cookie_{build,pool_get}
net: mvpp2: use {get,put}_cpu() instead of smp_processor_id()
net: mvpp2
, this commit replaces the smp_processor_id() in
migration-enabled contexts by the appropriate get_cpu/put_cpu sections.
Reported-by: Marc Zyngier <marc.zyng...@arm.com>
Fixes: a786841df72e ("net: mvpp2: handle register mapping and access for
PPv2.2")
Signed-off-by: Thomas Petazzoni <th
: 3f518509dedc9 ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 51 ++--
1 file changed, 14 insertions(+), 37 deletion
> Signed-off-by: Antoine Tenart <antoine.ten...@free-electrons.com>
Please add:
Fixes: 2697582144dd ("net: mvpp2: handle misc PPv2.1/PPv2.2 differences")
with this:
Acked-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
I am wondering if we shouldn't Cc: stabl
Hello Giuseppe,
On Wed, 10 May 2017 09:18:17 +0200, Thomas Petazzoni wrote:
> On Wed, 10 May 2017 09:03:12 +0200, Giuseppe CAVALLARO wrote:
>
> > > Please, read again my patch and the description of the problem that I
> > > have sent. But basically, any solution th
problem
should be designed. I made an initial simple proposal to show what is
needed, but I'm definitely open to suggestions.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
allow to set the
PS bit between asserting the DMA reset bit and polling for it to clear
will not work for MII PHYs.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
l problem).
Am I missing something here?
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
GMII and MII platforms),
but not sure if the implementation is the most appropriate. Let me know
if you have better suggestions.
See: http://marc.info/?l=linux-netdev=149328635210461=2
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
1000 case.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
Cc: <sta...@vger.kernel.org>
---
Do not hesitate to suggest ideas for alternative implementations, I'm
not sure if the current proposal is the one that fits best with the
current design of the driver.
---
d
in through the same pin when in GMII
and MII mode it seems. Does this needs some special configuration?
Any hint/idea would definitely be welcome.
Thanks a lot!
Thomas
On Wed, 12 Apr 2017 15:05:58 +0200, Thomas Petazzoni wrote:
> Hello,
>
> Thanks again for your answer, sorry for the
in, we see the same behavior in U-Boot (DMA reset bit never
clears), but Ethernet does work in U-Boot.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
l variable.
Anyway, I think it's worth investigating a different solution than
blindly converting to a GFP_ATOMIC allocation.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
? Was it on a
SPEAr600 based platform ?
If you tested on SPEAr600, what is the GMAC clock configuration (i.e
the value of the GMAC_CFG_CTR and GMAC_CFG_SYNT registers) ?
Regarding the PHY reset time, our PHY reset pin is not connected to a
GPIO, but to the system reset logic, so Linux cannot reset the
Hello,
On Thu, 9 Mar 2017 15:56:31 +0100, Giuseppe CAVALLARO wrote:
> On 3/9/2017 10:32 AM, Thomas Petazzoni wrote:
>
> > OK, I'll have a look. However, I'm still confused by this DMA_RESET bit
> > that never clears, contrary to what the datasheet says. Are there some
>
I'm still confused by this DMA_RESET bit
that never clears, contrary to what the datasheet says. Are there some
erratas?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
is very possible).
In terms of Device Tree, I'm simply using spear600.dtsi, and enabling
the gmac node, nothing else.
Has the stmmac driver been recently used/tested on spear600 ?
Thanks,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free
coherent allocation will not span a
4G boundary?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Now that the mvpp2 driver has been modified to accommodate the support
for PPv2.2, we can finally advertise this support by adding the
appropriate compatible string.
At the same time, we update the Kconfig description of the MVPP2 driver.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@f
cpu_write() are new accessors added to
access the registers for which the CPU window does matter, which is why
they take a "cpu" as argument.
The driver is then changed to use mvpp2_percpu_read() and
mvpp2_percpu_write() where it matters.
Signed-off-by: Thomas Petazzoni <thomas.peta
The PPv2.2 unit is connected to an AXI bus on Armada 7K/8K, so this
commit adds the necessary initialization of the AXI bridge.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 85
1 file c
This register is no longer used since commit edc660fa09e2 ("net: mvpp2:
replace TX coalescing interrupts with hrtimer").
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 3 ---
1 file changed, 3 deletions(-)
diff
n MVPP2_TXQ_THRESH_REG
net: mvpp2: remove mvpp2_txq_pend_desc_num_get() function
- Fix a number of checkpatch warnings.
Changes between v1 and v2:
- Made a separate series from the set of patches doing preparation
changes/fixes to the mvpp2 driver.
- Rebased on top of v4.10-rc1.
- Upd
This commit adjusts how the MVPP2_ISR_RXQ_GROUP_REG register is
configured, since it changed between PPv2.1 and PPv2.2.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 46
1 file chang
y used in only one place.
- In mvpp2_port_probe(), the calculation of port->first_rxq is adjusted
to cope with the different allocation strategy between PPv2.1 and
PPv2.2. Due to this change, the 'next_first_rxq' argument of this
function is no longer needed and is removed.
Signed-off
The PPv2.2 variant of the network controller needs an additional
clock, the "MG clock" in order for the IP block to operate
properly. This commit adds support for this additional clock to the
driver, reworking as needed the error handling path.
Signed-off-by: Thomas Petazzoni <
Therefore, this functionality is completely unused, and the
code can be removed, and we should never get a descriptor with bit
MVPP2_RXD_BUF_HDR set.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 77
oduce more changes
where the distinction between physical address and DMA address will be
key.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 148 +--
1 file changed, 74 insertions(+), 74 d
to describe PPv2.2 hardware.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
.../devicetree/bindings/net/marvell-pp2.txt| 62 ++
1 file changed, 51 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.
of
mvpp22_port_mii_set().
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 85
1 file changed, 67 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drive
address, which means all BM pools must be allocated in
the same 4GB memory area.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp
be accessed and modified through the accessor
functions. A follow-up commit will add the descriptor definitions for
PPv2.2.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 45 +---
1 file chang
In PPv2.2, the MVPP2_RXQ_DESC_ADDR_REG and MVPP2_TXQ_DESC_ADDR_REG
registers have a slightly different layout, because they need to contain
a 64-bit address for the RX and TX descriptor arrays. This commit
adjusts those functions accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@f
The MVPP2_RXQ_CONFIG_REG register has a slightly different layout
between PPv2.1 and PPv2.2, so this commit adapts the functions modifying
this register to accommodate for both the PPv2.1 and PPv2.2 cases.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drive
mportant to realize that the DMA address and physical
address are two different things, which is why we store both in the RX
descriptors. While those addresses may be identical in some situations,
it remains two distinct concepts, and both addresses should be handled
separately.
Signed-off-by:
This commit adds the definition of the PPv2.2 HW descriptors, adjusts
the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts
the accessors to work on both PPv2.1 and PPv2.2.
Signed-off-by: Thomas Petazzoni <thomas.petazz...@free-electrons.com>
---
drivers/net/ethernet/m
1 - 100 of 277 matches
Mail list logo
