From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: <monstr@monstr.eu>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
<michal.simek@xilinx.com>, <s.trumtrar@pengutronix.de>,
<hein_tibosch@yahoo.es>,
Ludovic Desroches <ludovic.desroches@atmel.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
Anirudha Sarangi <anirudh@xilinx.com>
Subject: Re: [PATCH] net/macb: fix ISR clear-on-write behavior only for some SoC
Date: Tue, 14 May 2013 14:30:59 +0200 [thread overview]
Message-ID: <51922E83.2060002@atmel.com> (raw)
In-Reply-To: <5192224A.7090303@monstr.eu>
On 14/05/2013 13:38, Michal Simek :
> On 05/14/2013 11:16 AM, Nicolas Ferre wrote:
>> On 13/05/2013 18:05, Jean-Christophe PLAGNIOL-VILLARD :
>>>
>>> On May 14, 2013, at 12:05 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>>>
>>>> Commit 749a2b6 (net/macb: clear tx/rx completion flags in ISR)
>>>> introduces clear-on-write on ISR register. This behavior is not always
>>>> implemented when using Cadence MACB/GEM and is breaking other platforms.
>>>> We are using a new Device Tree compatibility string and a capability
>>>> property to actually activate this clear-on-write behavior on ISR.
>>>>
>>>> Reported-by: Hein Tibosch <hein_tibosch@yahoo.es>
>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>>
>>> can we detect it via the IP?
>>
>> As said by Hein, we cannot use the IP revision number. *But* we may have the opportunity to read this integration configuration in the Design Configuration Register 1 (DCFG1 already used for determining data bus width).
>>
>> So, Michal or Steffen, can you please tell me the value of:
>> -> bit 23 at register address 0x280: mine is "1" which should mean "IRQ read clear", yours should be "0".
>
> here is the whole reg map for zynq.
> Reg 0x280 is undocumented in our TRM.
> Please decode it not sure if bit 0 is LSB or MSB.
Bit 0 is LSB.
Value of DCFG1 is 0x02500111 so I read '0' for this value which should
be good.
I write a new patch immediately.
> U-Boot-PetaLinux> md e000b000
> e000b000: 0000001c 000e0013 00000006 00000000 ................
> e000b010: 00180704 00000021 3ffba2e4 3ffbd32c ....!......?,..?
> e000b020: 00000003 00000000 00000000 00000000 ................
> e000b030: 07ffffff 63c66f08 00000000 0000ffff .....o.c........
> e000b040: 000003ff 000003ff 00000000 00000000 ................
> e000b050: 00000000 00000000 00000000 00000000 ................
> e000b060: 00000000 00000000 00000000 00000000 ................
> e000b070: 00000000 00000000 00000000 00000000 ................
> e000b080: 00000000 00000000 00350a00 00001c48 ..........5.H...
> e000b090: 00000000 00000000 00000000 00000000 ................
> e000b0a0: 00000000 00000000 00000000 00000000 ................
> e000b0b0: 00000000 00000000 00000000 00000000 ................
> e000b0c0: 00000000 00000000 00000000 00000000 ................
> e000b0d0: 00000000 00000000 00000000 00000000 ................
> e000b0e0: 00000000 00000000 00000000 00000000 ................
> e000b0f0: 00000000 00000000 00000000 00020118 ................
> U-Boot-PetaLinux>
> e000b100: 00014796 00000000 0000051e 00000001 .G..............
> e000b110: 00000000 00000000 0000051d 00000001 ................
> e000b120: 00000000 00000000 00000000 00000000 ................
> e000b130: 00000000 00000000 00000000 00000000 ................
> e000b140: 00000000 00000000 00000000 00000000 ................
> e000b150: 001e58b6 00000000 00000526 00000000 .X......&.......
> e000b160: 00000004 00000000 00000004 00000001 ................
> e000b170: 00000000 00000004 00000000 0000051d ................
> e000b180: 00000000 00000000 00000000 00000000 ................
> e000b190: 00000000 00000000 00000000 00000000 ................
> e000b1a0: 00000038 00000000 00000000 00000000 8...............
> e000b1b0: 00000000 00000000 00000000 00000000 ................
> e000b1c0: 00000000 00000000 00000000 00000000 ................
> e000b1d0: 00000000 00000000 00000000 00000000 ................
> e000b1e0: 00000000 00000000 00000000 00000000 ................
> e000b1f0: 00000000 00000000 00000000 00000000 ................
> U-Boot-PetaLinux>
> e000b200: 00000000 00000000 00000000 00000000 ................
> e000b210: 00000000 00000000 00000000 00000000 ................
> e000b220: 00000000 00000000 00000000 00000000 ................
> e000b230: 00000000 00000000 00000000 00000000 ................
> e000b240: 00000000 00000000 00000000 00000000 ................
> e000b250: 00000000 00000000 00000000 00000000 ................
> e000b260: 00000000 00000000 00000000 00000000 ................
> e000b270: 00000000 00000000 00000000 00000000 ................
> e000b280: 02500111 2ab13fff 00000000 00000000 ..P..?.*........
> e000b290: 002f2145 00000200 00000000 00000000 E!/.............
> e000b2a0: 00000000 00000000 00000000 00000000 ................
> e000b2b0: 00000000 00000000 00000000 00000000 ................
> e000b2c0: 00000000 00000000 00000000 00000000 ................
> e000b2d0: 00000000 00000000 00000000 00000000 ................
> e000b2e0: 00000000 00000000 00000000 00000000 ................
> e000b2f0: 00000000 00000000 00000000 00000000 ................
> U-Boot-PetaLinux>
>
>
>
>>
>> Hein, in case of use of the MACB, we do not have this register included, so I will avoid to run the test when using MACB (we already have this information).
>>
>> If it works, I plan to rewrite the patch but taking this information instead of the device tree compatibility string.
>
> yep. Will be good to detect it instead of new compatible string.
>
> Also is there an option to remove "CONFIG_ARCH_AT91"?
Okay, I have a look at this as-well.
Best regards,
--
Nicolas Ferre
next prev parent reply other threads:[~2013-05-14 12:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-13 16:05 [PATCH] net/macb: fix ISR clear-on-write behavior only for some SoC Nicolas Ferre
2013-05-13 16:05 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-14 0:58 ` Hein Tibosch
2013-05-14 5:52 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-14 7:18 ` Hein Tibosch
2013-05-14 7:22 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-14 7:31 ` Hein Tibosch
2013-05-14 7:49 ` Michal Simek
2013-05-14 8:32 ` Hein Tibosch
2013-06-04 6:15 ` Michal Simek
2013-06-04 6:49 ` Steffen Trumtrar
2013-06-04 6:54 ` Michal Simek
2013-06-04 7:51 ` Nicolas Ferre
2013-06-04 7:57 ` Michal Simek
2013-05-14 9:16 ` Nicolas Ferre
2013-05-14 11:38 ` Michal Simek
2013-05-14 12:30 ` Nicolas Ferre [this message]
2013-05-14 7:01 ` Steffen Trumtrar
2013-05-14 13:00 ` [PATCH v2] " Nicolas Ferre
2013-05-14 13:43 ` Hein Tibosch
2013-05-14 16:24 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-14 20:04 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51922E83.2060002@atmel.com \
--to=nicolas.ferre@atmel.com \
--cc=anirudh@xilinx.com \
--cc=hein_tibosch@yahoo.es \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.desroches@atmel.com \
--cc=michal.simek@xilinx.com \
--cc=monstr@monstr.eu \
--cc=netdev@vger.kernel.org \
--cc=plagnioj@jcrosoft.com \
--cc=s.trumtrar@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox