Re: ARC770: "unexpected IRQ trap at vector 00" during boot
On 07/24/2017 01:39 PM, Alexey Brodkin wrote: Hi Alexandru, I'm getting a storm of these messages when trying to boot an in-house ASIC with an ARC770. This only happens with an ethernet cable plugged in. I've learned that the actual interrupt number is 21. The issue is that the irq_find_mapping() in __handle_domain_irq() fails to find a mapping for vector 21, and the remaining logic will brainlessly print out '0' as the interrupt number (which is of course, bass-ackwards). [snip] That's interesting! I saw exactly the same issue with one of our devboards. What happens here is GMAC generates output interrupt because of some condition(s), I'm seeing this when using U-boot to load the kernel over ethernet. I think it's enough to have the PHY link autonegotiated to get the problem, but I didn't verify this. Answering your question why interrupt from GMAC happens before its driver is probed: 1) I need to look at my notes I made when was fighting with the same problem, but for some reason DW GMAC seems to have interrupts enabled on reset which is indeed a bit unexpected and might lead to a behavior you and I saw. I'm curious to know what your notes say. 2) Historically we used to enable all possible core IRQ lines early on boot as opposed to per-line init by request of each particular driver. We have this on our to-do list as one of important improvements but that's not a short-term fix for sure. A work-around that I made and which may recommend to you is to figure out what condition in GMAC leads to generation of interrupt on its out and then resetting it in GMAC in your early platform boot code. I was afraid that might be the only way. I can keep the GMAC logic in reset, but that requires a custom platform early_init(), and a glue driver for snps,dwmac. Let me know if it helps. Yes. I implemented the proof-of-concept today. It's a very "interesting" balancing act on when exactly to release the reset on the GMAC. I'm able to get to boot to a shell with ethernet plugged in. Alex ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer
Hi David, On 07/28/2017 07:01 PM, David Miller wrote: From: Alexandru Gagniuc Date: Fri, 28 Jul 2017 15:07:03 -0700 Before the GMAC on the Anarion chip can be used, the PHY interface selection must be configured with the DWMAC block in reset. This layer covers a block containing only two registers. Although it is possible to model this as a reset controller and use the "resets" property of stmmac, it's much more intuitive to include this in the glue layer instead. At this time only RGMII is supported, because it is the only mode which has been validated hardware-wise. Signed-off-by: Alexandru Gagniuc I don't see how this fits into any patch series at all. If this is part of a series you posted elsewhere, you should keep netdev@ on all such postings so people there can review the change in-context. I used the --cc-cmd option to send-email. I'll be sure to CC netdev@ on [PATCH v2]. Alex ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 5/5] ARC: DTS: Add device-tree for Anarion-based development board
On 07/30/2017 11:32 PM, Vineet Gupta wrote:
On 07/29/2017 03:37 AM, Alexandru Gagniuc wrote:
Signed-off-by: Alexandru Gagniuc
---
arch/arc/boot/dts/adaptrum_anarion.dtsi | 107
arch/arc/boot/dts/adaptrum_anarion_fpga.dts | 49 +
2 files changed, 156 insertions(+)
create mode 100644 arch/arc/boot/dts/adaptrum_anarion.dtsi
create mode 100644 arch/arc/boot/dts/adaptrum_anarion_fpga.dts
So you really need to upstream the fpga dts - if this just for initial
bringup and you will eventually switch to silicon.
The reason I say is every additional file is a maintenance burden so
better to avoid things which are only temporary.
But if you plan to support this config in long run I'm fine !
Looking further it seems first one is a "common" include style dts while
fpga is for actual platform and the SoC one will follow once you get it
running ?
That is correct. the '_fpga.dts' is the tree for the current emulation
board. The plan is to use the fpga platform until the actual silicon
arrives and is brought up. I included the _fpga dts in order to have a
way to verify that the anarion DTSI compiles. I also plan to later
remove the fpga dts once the actual silicon works.
[snip]
+#include "skeleton.dtsi"
Perhaps put a one liner that this is based on SNPS ARC700 cpu !
Staged for [PATCH v2].
Alex
+
+/ {
+compatible = "adaptrum,anarion";
+#address-cells = <1>;
+#size-cells = <1>;
+
+soc {
+compatible = "simple-bus";
+device_type = "soc";
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+interrupt-parent = <&core_intc>;
+
+core_intc: interrupt-controller {
+compatible = "snps,arc700-intc";
+interrupt-controller;
+#interrupt-cells = <1>;
+};
+
+uart0: serial@f2202100 {
+compatible = "ns16550";
+reg = <0xf2202100 0x20>;
+interrupts = <8>;
+reg-shift = <2>;
+reg-io-width = <4>;
+clock-frequency = <19200>;
+status = "disabled";
+};
+
+uart1: serial@f2202200 {
+compatible = "snps,dw-apb-uart";
+reg = <0xf2202200 0x20>;
+interrupts = <8>;
+reg-shift = <2>;
+reg-io-width = <4>;
+clock-frequency = <19200>;
+status = "disabled";
+};
+
+uart2: serial@f2202300 {
+compatible = "snps,dw-apb-uart";
+reg = <0xf2202300 0x20>;
+interrupts = <8>;
+reg-shift = <2>;
+reg-io-width = <4>;
+clock-frequency = <19200>;
+status = "disabled";
+};
+
+uart3: serial@f2202400 {
+compatible = "snps,dw-apb-uart";
+reg = <0xf2202400 0x20>;
+interrupts = <8>;
+reg-shift = <2>;
+reg-io-width = <4>;
+clock-frequency = <19200>;
+status = "disabled";
+};
+
+qspi: qspi@f200f000 {
+compatible = "adaptrum,anarion-qspi";
+reg = <0xf200f000 0x1000>,
+ <0x2000 0x0800>;
+
+interrupts = <10>;
+status = "disabled";
+};
+
+gmac0: ethernet@f201 {
+compatible = "snps,dwmac";
+reg = <0xf201 0x4000>;
+
+interrupt-parent = <&core_intc>;
+interrupts = <20>;
+interrupt-names = "macirq";
+
+clocks = <&core_clk>;
+clock-names = "stmmaceth";
+
+snps,pbl = <32>;
+status = "disabled";
+};
+
+gmac1: ethernet@f2014000 {
+compatible = "adaptrum,anarion-gmac", "snps,dwmac";
+reg = <0xf2014000 0x4000>, <0xf2018100 8>;
+
+interrupt-parent = <&core_intc>;
+interrupts = <21>;
+interrupt-names = "macirq";
+
+clocks = <&core_clk>;
+clock-names = "stmmaceth";
+
+snps,pbl = <32>;
+status = "disabled";
+};
+};
+};
diff --git a/arch/arc/boot/dts/adaptrum_anarion_fpga.dts
b/arch/arc/boot/dts/adaptrum_anarion_fpga.dts
new file mode 100644
index 000..36173b2
--- /dev/null
+++ b/arch/arc/boot/dts/adaptrum_anarion_fpga.dts
@@ -0,0 +1,49 @@
+/*
+ * (C) Copyright 2017 Adaptrum, Inc.
+ * Written by Alexandru Gagniuc for Adaptrum, Inc.
+
snps,dwmac interrupt storm (Was: ARC770: "unexpected IRQ trap at vector 00" during boot)
On 07/25/2017 08:08 PM, Vineet Gupta wrote: Hi Vineet, On 07/26/2017 01:41 AM, Alexey Brodkin wrote: BTW what is your exact kernel version? In the meantime we'll try to revisit rework of ARC's INTC init procedure but I cannot promise anything very soon as I'm on ETO this week but we'll see how it goes. And exactly do we intend to rework - AFAIK nothings really broken at the moment in ARC intc handling ! I have tried the workarouns I mentioned on top of linux 4.9.34, and it works exactly as expected. however, on top of 4.13-rc3 [1], the story is a lot different. As soon as I release the GMAC from reset, the boot stops. I can single-step through JTAG, and see that the GMAC sends an interrupt storm. The kernel doesn't have time to move on with the dwmac initialization and register the interrupt, and that's that. I'd file this under both 'regression' and 'bug' categories. Not sure what changed under the hood from 4.9 to 4.13-rc3 to cause such a drastically different behavior. I can't really do much else as workarounds, since the GMAC registers are not writable while the GMAC is in reset. Alex [1] https://github.com/mrnuke-adaptrum/linux/commits/patch-v2-anarion-wip -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Please pull ARCPGU changes
On Wed, Aug 2, 2017 at 6:16 AM, Alexey Brodkin wrote: > Hi Daniel, > > On Wed, 2017-08-02 at 11:41 +0200, Daniel Vetter wrote: >> On Mon, Jul 31, 2017 at 11:11:06AM +, Alexey Brodkin wrote: >> > >> > Hi Dave, >> > >> > Could you please pull a couple of minor fixes for ARCPGU. >> > These changes are based on today's drm-misc/drm-misc-next. >> >> You can't send Dave a pull based on a random snapshot of drm-misc-next. If >> you want to maintain your driver on top of drm-misc, then become part of >> the group (arcgpu would fit imo). Otherwise you need to base your pulls on >> top of Dave's tree. > > I don't have any specific requirement for "drm-misc-next" to b used as a base. > That said Dave trees are OK for me. Still could you please point me to > his "for-curr" and "for-next" (or equivalent) trees? next: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next fixes: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes Alex > >> Also, your pull is missing the [PULL] tag in the >> subject. > > Sorry for that, will fix it in the next request. > > -Alexey > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] fix double ;;s in code
On Tue, Feb 20, 2018 at 3:03 AM, Jani Nikula wrote: > On Mon, 19 Feb 2018, Pavel Machek wrote: >> On Mon 2018-02-19 16:41:35, Daniel Vetter wrote: >>> Yeah, pls split this into one patch per area, with a suitable patch >>> subject prefix. Look at git log of each file to get a feeling for what's >>> the standard in each area. >> >> Yeah I can spend hour spliting it, and then people will ignore it >> anyway. >> >> If you care about one of the files being modified, please fix the >> bug, ";;" is a clear bug. >> >> If you don't care ... well I don't care either. > > Look, if this causes just one conflict down the line because it touches > the kernel all over the place, then IMO it already wasn't worth > it. Merge conflicts are inevitable, but there's no reason to make life > harder just to cater for a cleanup patch. It's not that important. > > Had it been split up, the drm parts would've been merged already. FWIW, the amdgpu and scheduler changes have already been fixed for -next. Alex > > BR, > Jani. > > -- > Jani Nikula, Intel Open Source Technology Center > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] drm/amdgpu/swsmu: fix ARC build errors
We want to use the dev_* functions here rather than the pr_* variants.
Switch to using dev_warn() which mirrors what we do on other asics.
Fixes the following build errors on ARC:
../drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c: In function
'navi10_fill_i2c_req':
../arch/arc/include/asm/bug.h:24:2: error: implicit declaration of function
'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration]
../drivers/gpu/drm/amd/amdgpu/../powerplay/sienna_cichlid_ppt.c: In function
'sienna_cichlid_fill_i2c_req':
../arch/arc/include/asm/bug.h:24:2: error: implicit declaration of function
'pr_warn'; did you mean 'drm_warn'? [-Werror=implicit-function-declaration]
Reported-by: kernel test robot
Cc: Randy Dunlap
Cc: Evan Quan
Cc: Vineet Gupta
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 14 --
.../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 14 --
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
index 3f1377f28493..8d8081c6bd38 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
@@ -2336,8 +2336,6 @@ static void navi10_fill_i2c_req(SwI2cRequest_t *req,
bool write,
{
int i;
- BUG_ON(numbytes > MAX_SW_I2C_COMMANDS);
-
req->I2CcontrollerPort = 0;
req->I2CSpeed = 2;
req->SlaveAddress = address;
@@ -2375,6 +2373,12 @@ static int navi10_i2c_read_data(struct i2c_adapter
*control,
struct smu_table_context *smu_table = &adev->smu.smu_table;
struct smu_table *table = &smu_table->driver_table;
+ if (numbytes > MAX_SW_I2C_COMMANDS) {
+ dev_err(adev->dev, "numbytes requested %d is over max allowed
%d\n",
+ numbytes, MAX_SW_I2C_COMMANDS);
+ return -EINVAL;
+ }
+
memset(&req, 0, sizeof(req));
navi10_fill_i2c_req(&req, false, address, numbytes, data);
@@ -2411,6 +2415,12 @@ static int navi10_i2c_write_data(struct i2c_adapter
*control,
SwI2cRequest_t req;
struct amdgpu_device *adev = to_amdgpu_device(control);
+ if (numbytes > MAX_SW_I2C_COMMANDS) {
+ dev_err(adev->dev, "numbytes requested %d is over max allowed
%d\n",
+ numbytes, MAX_SW_I2C_COMMANDS);
+ return -EINVAL;
+ }
+
memset(&req, 0, sizeof(req));
navi10_fill_i2c_req(&req, true, address, numbytes, data);
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 3c8732f34b1f..c27806fd07e0 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -2422,8 +2422,6 @@ static void sienna_cichlid_fill_i2c_req(SwI2cRequest_t
*req, bool write,
{
int i;
- BUG_ON(numbytes > MAX_SW_I2C_COMMANDS);
-
req->I2CcontrollerPort = 0;
req->I2CSpeed = 2;
req->SlaveAddress = address;
@@ -2461,6 +2459,12 @@ static int sienna_cichlid_i2c_read_data(struct
i2c_adapter *control,
struct smu_table_context *smu_table = &adev->smu.smu_table;
struct smu_table *table = &smu_table->driver_table;
+ if (numbytes > MAX_SW_I2C_COMMANDS) {
+ dev_err(adev->dev, "numbytes requested %d is over max allowed
%d\n",
+ numbytes, MAX_SW_I2C_COMMANDS);
+ return -EINVAL;
+ }
+
memset(&req, 0, sizeof(req));
sienna_cichlid_fill_i2c_req(&req, false, address, numbytes, data);
@@ -2497,6 +2501,12 @@ static int sienna_cichlid_i2c_write_data(struct
i2c_adapter *control,
SwI2cRequest_t req;
struct amdgpu_device *adev = to_amdgpu_device(control);
+ if (numbytes > MAX_SW_I2C_COMMANDS) {
+ dev_err(adev->dev, "numbytes requested %d is over max allowed
%d\n",
+ numbytes, MAX_SW_I2C_COMMANDS);
+ return -EINVAL;
+ }
+
memset(&req, 0, sizeof(req));
sienna_cichlid_fill_i2c_req(&req, true, address, numbytes, data);
--
2.25.4
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
