* Re: [RFC PATCH 7/7 v2] ppc: add dynamic dma window support
From: Nishanth Aravamudan @ 2010-12-09 19:09 UTC (permalink / raw)
To: sonnyrao, miltonm, Benjamin Herrenschmidt, Paul Mackerras,
Grant Likely, Anton Blanchard, linuxppc-dev
In-Reply-To: <1288150518-4026-8-git-send-email-nacc@us.ibm.com>
On 26.10.2010 [20:35:17 -0700], Nishanth Aravamudan wrote:
> If firmware allows us to map all of a partition's memory for DMA on a
> particular bridge, create a 1:1 mapping of that memory. Add hooks for
> dealing with hotplug events. Dyanmic DMA windows can use larger than the
> default page size, and we use the largest one possible.
>
> Not-yet-signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
>
> ---
>
> I've tested this briefly on a machine with suitable firmware/hardware.
> Things seem to work well, but I want to do more exhaustive I/O testing
> before asking for upstream merging. I would really appreciate any
> feedback on the updated approach.
>
> Specific questions:
>
> Ben, did I hook into the dma_set_mask() platform callback as you
> expected? Anything I can do better or which perhaps might lead to
> gotchas later?
>
> I've added a disable_ddw option, but perhaps it would be better to
> just disable the feature if iommu=force?
So for the final version, I probably should document this option in
kernel-parameters.txt w/ the patch, right?
<snip>
> +static int tce_clearrange_multi_pSeriesLP(unsigned long start_pfn,
> + unsigned long num_pfn, const void *arg)
> +{
> + const struct dynamic_dma_window_prop *maprange = arg;
> + int rc;
> + u64 tce_size, num_tce, dma_offset, next;
> + u32 tce_shift;
> + long limit;
> +
> + tce_shift = be32_to_cpu(maprange->tce_shift);
> + tce_size = 1ULL << tce_shift;
> + next = start_pfn << PAGE_SHIFT;
> + num_tce = num_pfn << PAGE_SHIFT;
> +
> + /* round back to the beginning of the tce page size */
> + num_tce += next & (tce_size - 1);
> + next &= ~(tce_size - 1);
> +
> + /* covert to number of tces */
> + num_tce |= tce_size - 1;
> + num_tce >>= tce_shift;
> +
> + do {
> + /*
> + * Set up the page with TCE data, looping through and setting
> + * the values.
> + */
> + limit = min_t(long, num_tce, 512);
> + dma_offset = next + be64_to_cpu(maprange->dma_base);
> +
> + rc = plpar_tce_stuff(be64_to_cpu(maprange->liobn),
> + (u64)dma_offset,
> + 0, limit);
> + num_tce -= limit;
> + } while (num_tce > 0 && !rc);
> +
> + return rc;
> +}
There is a bit of a typo here, the liobn is a 32-bit value. I've fixed
this is up locally and will update it when I send out the final version
of this patch.
I'm finding that on dlpar remove of adapters running in slots supporting
64-bit DMA, that the plpar_tce_stuff is failing. Can you think of a
reason why? It looks basically the same as the put_indirect below...
> +static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,
> + unsigned long num_pfn, const void *arg)
> +{
> + const struct dynamic_dma_window_prop *maprange = arg;
> + u64 *tcep, tce_size, num_tce, dma_offset, next, proto_tce, liobn;
> + u32 tce_shift;
> + u64 rc = 0;
> + long l, limit;
> +
> + local_irq_disable(); /* to protect tcep and the page behind it */
> + tcep = __get_cpu_var(tce_page);
> +
> + if (!tcep) {
> + tcep = (u64 *)__get_free_page(GFP_ATOMIC);
> + if (!tcep) {
> + local_irq_enable();
> + return -ENOMEM;
> + }
> + __get_cpu_var(tce_page) = tcep;
> + }
> +
> + proto_tce = TCE_PCI_READ | TCE_PCI_WRITE;
> +
> + liobn = (u64)be32_to_cpu(maprange->liobn);
> + tce_shift = be32_to_cpu(maprange->tce_shift);
> + tce_size = 1ULL << tce_shift;
> + next = start_pfn << PAGE_SHIFT;
> + num_tce = num_pfn << PAGE_SHIFT;
> +
> + /* round back to the beginning of the tce page size */
> + num_tce += next & (tce_size - 1);
> + next &= ~(tce_size - 1);
> +
> + /* covert to number of tces */
> + num_tce |= tce_size - 1;
> + num_tce >>= tce_shift;
> +
> + /* We can map max one pageful of TCEs at a time */
> + do {
> + /*
> + * Set up the page with TCE data, looping through and setting
> + * the values.
> + */
> + limit = min_t(long, num_tce, 4096/TCE_ENTRY_SIZE);
> + dma_offset = next + be64_to_cpu(maprange->dma_base);
> +
> + for (l = 0; l < limit; l++) {
> + tcep[l] = proto_tce | next;
> + next += tce_size;
> + }
> +
> + rc = plpar_tce_put_indirect(liobn,
> + (u64)dma_offset,
> + (u64)virt_to_abs(tcep),
> + limit);
> +
> + num_tce -= limit;
> + } while (num_tce > 0 && !rc);
> + printk("plpar_tce_put_indirect for offset 0x%llx and tcep[0] 0x%llx returned %llu\n",
> + (u64)dma_offset, tcep[0], rc);
> +
I'll cleanup the debugging on the final version too.
<snip>
> +static void remove_ddw(struct device_node *np)
> +{
> + struct dynamic_dma_window_prop *dwp;
> + struct property *win64;
> + const u32 *ddr_avail;
> + u64 liobn;
> + int len, ret;
> +
> + ddr_avail = of_get_property(np, "ibm,ddw-applicable", &len);
> + win64 = of_find_property(np, DIRECT64_PROPNAME, NULL);
> + if (!win64 || !ddr_avail || len < 3 * sizeof(u32))
> + return;
> +
> + dwp = win64->value;
> + liobn = (u64)be32_to_cpu(dwp->liobn);
> +
> + /* clear the whole window, note the arg is in kernel pages */
> + ret = tce_clearrange_multi_pSeriesLP(0,
> + 1ULL << (be32_to_cpu(dwp->window_shift) - PAGE_SHIFT), dwp);
> + if (ret)
> + pr_warning("%s failed to clear tces in window.\n",
> + np->full_name);
> + else
> + pr_warning("%s successfully cleared tces in window.\n",
> + np->full_name);
> +
> + ret = rtas_call(ddr_avail[2], 1, 1, NULL, liobn);
> + if (ret)
> + pr_warning("%s: failed to remove direct window: rtas returned "
> + "%d to ibm,remove-pe-dma-window(%x) %llx\n",
> + np->full_name, ret, ddr_avail[2], liobn);
> + else
> + pr_warning("%s: successfully removed direct window: rtas returned "
> + "%d to ibm,remove-pe-dma-window(%x) %llx\n",
> + np->full_name, ret, ddr_avail[2], liobn);
> +
> + ret = prom_remove_property(np, win64);
> + if (ret)
> + pr_warning("%s: failed to remove direct window property (%i)\n",
> + np->full_name, ret);
> + else
> + pr_warning("%s: successfully removed direct window property (%i)\n",
> + np->full_name, ret);
> +}
When this function gets called on dlpar remove of an adapter, it throws
a proc warning because the property has already been removed from
/proc/device-tree (but not the kernel representation) before the
notifiers get called:
static int pSeries_reconfig_remove_node(struct device_node *np)
{
struct device_node *parent, *child;
parent = of_get_parent(np);
if (!parent)
return -EINVAL;
if ((child = of_get_next_child(np, NULL))) {
of_node_put(child);
of_node_put(parent);
return -EBUSY;
}
remove_node_proc_entries(np);
blocking_notifier_call_chain(&pSeries_reconfig_chain,
PSERIES_RECONFIG_REMOVE, np);
of_detach_node(np);
of_node_put(parent);
of_node_put(np); /* Must decrement the refcount */
return 0;
}
Am I reading that correctly? Should I add a paramter to remove_ddw that
specifies if it is being called from the reconfig notifier (or perhaps
just whether it needs to remove the property)?
Also, just so I understand, it doesn't seem like dlpar provides an
option for the notifier chain to indicate failure (e.g., the tce stuff
failing above) and prevent the dlpar operation. AFAICT after discussing
with the firmware folks, it's actually non-fatal for the TCEs not to be
cleared during the dlpar remove, but seems like it might indicate an
issue if it happens in the field?
Otherwise, I've hit no problems testing this series under load. Once I
get some feedback on these questions, I'll roll out a new version,
hopefully tomorrow, that can be accepted.
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Mark Pearson @ 2010-12-09 20:45 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3872 bytes --]
I have a curious problem. This is on a MPC8636 based platform with
36-bit address space (that may or may not be important).
I have a very simple driver that registers for one of the external IRQs
with a trivial interrupt handler. It works great when built in as part
of the kernel.
However, if I make it a loadable module I get the crash shown below
(blade_irq is my IRQ handler).
-----Console capture ----------------------------------------
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0xf31200f8
Oops: Kernel access of bad area, sig: 11 [#1]
COMPASS
Modules linked in: blade_pnic blade_irq_drv blade_cpld_mmap_drv
NIP: f31200f8 LR: c006a26c CTR: f31200f8
REGS: c057bdd0 TRAP: 0400 Not tainted (2.6.32.12-131)
MSR: 00029000 <EE,ME,CE> CR: 24024048 XER: 00000000
TASK = c0544318[0] 'swapper' THREAD: c057a000
GPR00: 00000000 c057be80 c0544318 00000012 00000000 08f9cac0 c058177c
ef820000
GPR08: 00000200 c04a0000 f31200f8 c058a368 2dc6c000 1012b250 3ffbd200
00000000
GPR16: 3ff91140 3ffb22f8 00000000 00000000 00000000 00000000 00000000
00000000
GPR24: 00000000 00000000 00001600 c049fe4c 00000000 00000000 00000012
ea7975c0
NIP [f31200f8] blade_irq+0x0/0x110 [blade_irq_drv]
LR [c006a26c] handle_IRQ_event+0x64/0x13c
Call Trace:
[c057be80] [c0547b80] 0xc0547b80 (unreliable)
[c057bea0] [c006c41c] handle_fasteoi_irq+0x68/0xf4
[c057beb0] [c0004da0] do_IRQ+0x98/0xb4
[c057bed0] [c000fe0c] ret_from_except+0x0/0x18
[c057bf90] [c0008168] cpu_idle+0x50/0xd8
[c057bfb0] [c000237c] rest_init+0x5c/0x70
[c057bfc0] [c0516850] start_kernel+0x238/0x2c4
[c057bff0] [c000039c] skpinv+0x2b4/0x2f0
Instruction dump:
7d6903a6 4e800420 3d60c007 396bb59c 7d6903a6 4e800420 38000000 38600000
90040068 4e800020 38600000 4e800020 <9421fff0> 7c0802a6 3d20f312
bfc10008
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..
----- End of Console capture --------------------------------
I've done a few things
- Verified the symbol address and the NIP match. They seem
correct
- Removed all code from the IRQ handler and just return
IRQ_HANDLED. Still crashes
- Put an infinite loop at the start of the IRQ handler - loop
isn't hit and still crashes so I assume the handler itself is never run.
- I'm able to call my IRQ handler from the module init code and
it runs successfully. The problem is only when running in an interrupt
context.
- I also as a somewhat stupid test passed the physical address
rather than the virtual address when registering the handler. Still
crashes (not sure if that's a valid thing to do to be honest, but I
figured it might be a virtual memory paging issue...grasping at
straws.....).
I do have a ticket in with Freescale support but they suggested I post
here for quicker and wider responses and if there are any ideas out
there I'd really appreciate them. Any chance anyone else has hit this
and knows a workaround or solution? Are there any examples of working
driver modules that use interrupts on the 8536 out there in case I've
done something really goofy in my code? Any suggestions of things to
try?
Thanks in advance
Mark
Confidentiality Notice: This message and any attachments may contain privileged and confidential information. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this information to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. Please contact the sender immediately by reply mail and destroy all copies of the original message.
[-- Attachment #2: Type: text/html, Size: 10961 bytes --]
^ permalink raw reply
* Re: Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Michael Ellerman @ 2010-12-09 23:33 UTC (permalink / raw)
To: Mark Pearson; +Cc: linuxppc-dev
In-Reply-To: <11BA25866A2E3A45A797B469B2344B3901554D3D@blademail.bladenetwork.net>
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
On Thu, 2010-12-09 at 12:45 -0800, Mark Pearson wrote:
> I have a curious problem. This is on a MPC8636 based platform with
> 36-bit address space (that may or may not be important).
>
>
>
> I have a very simple driver that registers for one of the external
> IRQs with a trivial interrupt handler. It works great when built in as
> part of the kernel.
>
>
>
> However, if I make it a loadable module I get the crash shown below
> (blade_irq is my IRQ handler).
>
>
>
> -----Console capture ----------------------------------------
>
> Unable to handle kernel paging request for instruction fetch
^^^^^^^^^^^^^^^^^
Your interrupt handler isn't mapped executable? Something wrong with
module loading?
Do you need 78e2e68a2b79f394b7cd61e07987a8a89af907f7 ?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Mark Pearson @ 2010-12-10 1:20 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1291937594.3523.20.camel@concordia>
TWFnaWNhbCAtIHRoYW5rIHlvdSB2ZXJ5IHZlcnkgbXVjaC4gVGhlIHBhdGNoIGZpeGVzIHRoZSBw
cm9ibGVtDQoNClJlYWxseSBhcHByZWNpYXRlIHRoZSBxdWljayByZXNwb25zZSAtIGFuZCBJIHdv
dWxkIG5ldmVyIGhhdmUgZm91bmQgdGhhdCBpbiBhIG1pbGxpb24geWVhcnMuDQoNCk1hcmsNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwgRWxsZXJtYW4gW21haWx0
bzptaWNoYWVsQGVsbGVybWFuLmlkLmF1XSANClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwOSwg
MjAxMCA2OjMzIFBNDQpUbzogTWFyayBQZWFyc29uDQpDYzogbGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcNClN1YmplY3Q6IFJlOiBQcm9ibGVtIHdpdGggTVBDODUzNiBhbmQgZXh0ZXJuYWwg
SVJRcyB3aGVuIHVzaW5nIGEgbG9hZGFibGUga2VybmVsIG1vZHVsZQ0KDQpPbiBUaHUsIDIwMTAt
MTItMDkgYXQgMTI6NDUgLTA4MDAsIE1hcmsgUGVhcnNvbiB3cm90ZToNCj4gSSBoYXZlIGEgY3Vy
aW91cyBwcm9ibGVtLiBUaGlzIGlzIG9uIGEgTVBDODYzNiBiYXNlZCBwbGF0Zm9ybSB3aXRoIA0K
PiAzNi1iaXQgYWRkcmVzcyBzcGFjZSAodGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBpbXBvcnRhbnQp
Lg0KPiANCj4gIA0KPiANCj4gSSBoYXZlIGEgdmVyeSBzaW1wbGUgZHJpdmVyIHRoYXQgcmVnaXN0
ZXJzIGZvciBvbmUgb2YgdGhlIGV4dGVybmFsIA0KPiBJUlFzIHdpdGggYSB0cml2aWFsIGludGVy
cnVwdCBoYW5kbGVyLiBJdCB3b3JrcyBncmVhdCB3aGVuIGJ1aWx0IGluIGFzIA0KPiBwYXJ0IG9m
IHRoZSBrZXJuZWwuDQo+IA0KPiAgDQo+IA0KPiBIb3dldmVyLCBpZiBJIG1ha2UgaXQgYSBsb2Fk
YWJsZSBtb2R1bGUgSSBnZXQgdGhlIGNyYXNoIHNob3duIGJlbG93IA0KPiAoYmxhZGVfaXJxIGlz
IG15IElSUSBoYW5kbGVyKS4NCj4gDQo+ICANCj4gDQo+IC0tLS0tQ29uc29sZSBjYXB0dXJlIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFVuYWJsZSB0byBo
YW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGZvciBpbnN0cnVjdGlvbiBmZXRjaA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeXl5eXl5eXl5eXl5eXl5eXg0K
DQpZb3VyIGludGVycnVwdCBoYW5kbGVyIGlzbid0IG1hcHBlZCBleGVjdXRhYmxlPyBTb21ldGhp
bmcgd3Jvbmcgd2l0aCBtb2R1bGUgbG9hZGluZz8NCg0KRG8geW91IG5lZWQgNzhlMmU2OGEyYjc5
ZjM5NGI3Y2Q2MWUwNzk4N2E4YTg5YWY5MDdmNyA/DQoNCmNoZWVycw0KDQoNCgpDb25maWRlbnRp
YWxpdHkgTm90aWNlOiBUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBtYXkgY29udGFp
biAgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgaGF2ZSBy
ZWFzb24gdG8gYmVsaWV2ZSB0aGF0IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQg
b3IgYSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhpcyBpbmZvcm1hdGlvbiB0
byBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55
IHJldmlldywgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBjb3B5aW5nIG9mIHRoaXMg
bWVzc2FnZSBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBQbGVhc2UgY29udGFjdCB0aGUgc2VuZGVy
IGltbWVkaWF0ZWx5IGJ5IHJlcGx5IG1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUg
b3JpZ2luYWwgbWVzc2FnZS4K
^ permalink raw reply
* RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Michael Ellerman @ 2010-12-10 3:07 UTC (permalink / raw)
To: Mark Pearson; +Cc: b24347, linuxppc-dev
In-Reply-To: <11BA25866A2E3A45A797B469B2344B3901554D94@blademail.bladenetwork.net>
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]
On Thu, 2010-12-09 at 17:20 -0800, Mark Pearson wrote:
> Magical - thank you very very much. The patch fixes the problem
>
> Really appreciate the quick response - and I would never have found that in a million years.
No worries.
Looks like someone should send 78e2e68a2b to the stable crew. FSL guys?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Alexander Gordeev @ 2010-12-10 4:52 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev
In-Reply-To: <1291854539-23879-1-git-send-email-tmarri@apm.com>
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
Hi,
В Wed, 8 Dec 2010 16:28:59 -0800
tmarri at apm.com (tmarri at apm.com) пишет:
> From: Tirumala Marri <tmarri at apm.com>
>
> v6:
> 1. Replaced register definitions and bit fields with macros.
> 2. Replace printks with dev_dbg or dev_err functions.
> 3. Cleanup some assignments.
> 4. Remove chip specific selections in Kconfig file.
Thanks for the update!
I'm currently working on USB support for Ralink RT3050 (mipsel) boards
which have the same USB OTG controller. I've based my work on the
previous version of your patchset. The were several arch-specific issues
that I'd like to be fixed here before it hits mainline (BTW, is it going
to be mainlined?). I'll reply to the subsequent e-mails about the
specific issues. Is this ok?
Also I'd like to note that s3c-hsotg driver that is already in the
kernel seems to be quite similar from the register definitions at least.
It handles gadget mode only and the code looks different. I think it
should be replaced somehow by this new driver (which is based on the
"official" driver).
--
Alexander
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Tirumala Marri @ 2010-12-10 6:21 UTC (permalink / raw)
To: Alexander Gordeev; +Cc: linuxppc-dev
In-Reply-To: <20101210075256.296752e2@apollo.gnet>
On Thu, Dec 9, 2010 at 8:52 PM, Alexander Gordeev <lasaine@lvk.cs.msu.su> w=
rote:
> Hi,
>
> =D0=92 Wed, =C2=A08 Dec 2010 16:28:59 -0800
> tmarri at apm.com (tmarri at apm.com) =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>
>> From: Tirumala Marri <tmarri at apm.com>
>>
>> v6:
>> =C2=A01. Replaced register definitions and bit fields with macros.
>> =C2=A02. Replace printks with dev_dbg or dev_err functions.
>> =C2=A03. Cleanup some assignments.
>> =C2=A04. Remove chip specific selections in Kconfig file.
>
> Thanks for the update!
>
> I'm currently working on USB support for Ralink RT3050 (mipsel) boards
> which have the same USB OTG controller. I've based my work on the
> previous version of your patchset. The were several arch-specific issues
> that I'd like to be fixed here before it hits mainline (BTW, is it going
> to be mainlined?). I'll reply to the subsequent e-mails about the
> specific issues. Is this ok?
Yes the idea is to push into main line. I am not sure if it is good idea
to push all the changes in one go. I would wait for this patch to be acce=
pted
first and add your changes on top of that.
>
> Also I'd like to note that s3c-hsotg driver that is already in the
> kernel seems to be quite similar from the register definitions at least.
> It handles gadget mode only and the code looks different. I think it
> should be replaced somehow by this new driver (which is based on the
> "official" driver).
It sound similar to gadget portion of this OTG driver. After this patch acc=
epted
I will take a look and see if we can completely eliminate s3c-hsotg .
Thanks,
Marri
^ permalink raw reply
* RE: Problem with MPC8536 and external IRQs when using a loadable kernel module
From: Li Yang-R58472 @ 2010-12-10 8:03 UTC (permalink / raw)
To: michael, Mark Pearson; +Cc: Jin Qing-B24347, linuxppc-dev
In-Reply-To: <1291950448.3574.5.camel@concordia>
Pk9uIFRodSwgMjAxMC0xMi0wOSBhdCAxNzoyMCAtMDgwMCwgTWFyayBQZWFyc29uIHdyb3RlOg0K
Pj4gTWFnaWNhbCAtIHRoYW5rIHlvdSB2ZXJ5IHZlcnkgbXVjaC4gVGhlIHBhdGNoIGZpeGVzIHRo
ZSBwcm9ibGVtDQo+Pg0KPj4gUmVhbGx5IGFwcHJlY2lhdGUgdGhlIHF1aWNrIHJlc3BvbnNlIC0g
YW5kIEkgd291bGQgbmV2ZXIgaGF2ZSBmb3VuZCB0aGF0DQo+aW4gYSBtaWxsaW9uIHllYXJzLg0K
Pg0KPk5vIHdvcnJpZXMuDQo+DQo+TG9va3MgbGlrZSBzb21lb25lIHNob3VsZCBzZW5kIDc4ZTJl
NjhhMmIgdG8gdGhlIHN0YWJsZSBjcmV3LiBGU0wgZ3V5cz8NCg0KSSB0aGluayBpdCBoYXMgYWxy
ZWFkeSBiZWVuIHNlbnQgdG8gdGhlIHN0YWJsZUBrZXJuZWwub3JnLiAgTm90IHN1cmUgaWYgaXQg
aGFzIGJlZW4gaW5jbHVkZWQgdGhvdWdoLg0KDQotIExlbw0KDQo=
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Andre Schwarz @ 2010-12-10 8:47 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101208160531.393bedf1@udp111988uds.am.freescale.net>
Scott,
do you think this issue also applies to MPC8377 ?
I'm in the middle of a small redesign for series production and would
like not to miss a thing.
We have Nand, Nor and MRAM connected to LBC.
Since RFS is running from NAND and we use the MRAM as a non-volatile
SRAM I'd like to avoid being hit by this issue.
Any comments from your side ?
Regards,
André
> On Wed, 8 Dec 2010 22:26:59 +0100
> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
>
>> Scott Wood<scottwood@freescale.com> wrote on 2010/12/08 21:25:51:
>>> On Wed, 8 Dec 2010 21:11:08 +0100
>>> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
>>>
>>>> Scott Wood<scottwood@freescale.com> wrote on 2010/12/08 20:59:28:
>>>>> On Wed, 8 Dec 2010 20:57:03 +0100
>>>>> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
>>>>>
>>>>>> Can you think of any workaround such as not connecting the BUSY pin at all?
>>>>> Maybe connect the busy pin to a gpio?
>>>> Is BUSY required for sane operation or it an optimization?
>>> You could probably get away without it by inserting delays if you know
>>> the chip specs well enough.
>> Urgh, that does not feel like a good solution.
> No, but you asked if it could be done, and if it was just a
> performance issue. :-)
>
>>>> Is there any risk that the NAND device will drive the LB and corrupt
>>>> the bus for other devices?
>>> I think the only thing the NAND chip should be driving is the busy pin,
>> OK, good. What function is actually lost if one uses an GPIO instead of
>> BUSY?
> Not much, if you enable interrupts on the GPIO pin. The driver would
> have to be reworked a bit, of course.
>
>> You think Freescale could test and validate a GPIO solution? I don't
>> think we will be very happy to design our board around an unproven
>> workaround.
> Ask your sales/support contacts.
>
>> An even better workaround would be if one could add logic between the
>> NAND and the CPU which would compensate for this defect without needing
>> special SW fixes.
> The problem with that is when would you assert the chipselect again to
> check if it's done? Current SW depends on being able to tell the LBC
> to interrupt (or take other action) when busy goes away.
>
> I suppose you could poll with status reads, which could at least be
> preempted if you've got something higher priority to do with the LBC.
>
> -Scott
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-10 8:56 UTC (permalink / raw)
To: Andre Schwarz; +Cc: Mark Mason, Scott Wood, linuxppc-dev
In-Reply-To: <4D01E90E.8070404@matrix-vision.de>
Andre Schwarz <andre.schwarz@matrix-vision.de> wrote on 2010/12/10 09:4=
7:10:
>
> Scott,
>
> do you think this issue also applies to MPC8377 ?
Probably, I think this is so for all eLBC controllers.
>
> I'm in the middle of a small redesign for series production and would=
> like not to miss a thing.
> We have Nand, Nor and MRAM connected to LBC.
>
> Since RFS is running from NAND and we use the MRAM as a non-volatile
> SRAM I'd like to avoid being hit by this issue.
Please report back, I really want to know if this works and if there
are any drawbacks.
>
> Any comments from your side ?
>
> Regards,
> Andr=E9
>
> > On Wed, 8 Dec 2010 22:26:59 +0100
> > Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
> >
> >> Scott Wood<scottwood@freescale.com> wrote on 2010/12/08 21:25:51:=
> >>> On Wed, 8 Dec 2010 21:11:08 +0100
> >>> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
> >>>
> >>>> Scott Wood<scottwood@freescale.com> wrote on 2010/12/08 20:59:2=
8:
> >>>>> On Wed, 8 Dec 2010 20:57:03 +0100
> >>>>> Joakim Tjernlund<joakim.tjernlund@transmode.se> wrote:
> >>>>>
> >>>>>> Can you think of any workaround such as not connecting the BUS=
Y pin at all?
> >>>>> Maybe connect the busy pin to a gpio?
> >>>> Is BUSY required for sane operation or it an optimization?
> >>> You could probably get away without it by inserting delays if you=
know
> >>> the chip specs well enough.
> >> Urgh, that does not feel like a good solution.
> > No, but you asked if it could be done, and if it was just a
> > performance issue. :-)
> >
> >>>> Is there any risk that the NAND device will drive the LB and cor=
rupt
> >>>> the bus for other devices?
> >>> I think the only thing the NAND chip should be driving is the bus=
y pin,
> >> OK, good. What function is actually lost if one uses an GPIO inste=
ad of
> >> BUSY?
> > Not much, if you enable interrupts on the GPIO pin. The driver wou=
ld
> > have to be reworked a bit, of course.
> >
> >> You think Freescale could test and validate a GPIO solution? I don=
't
> >> think we will be very happy to design our board around an unproven=
> >> workaround.
> > Ask your sales/support contacts.
> >
> >> An even better workaround would be if one could add logic between =
the
> >> NAND and the CPU which would compensate for this defect without ne=
eding
> >> special SW fixes.
> > The problem with that is when would you assert the chipselect again=
to
> > check if it's done? Current SW depends on being able to tell the L=
BC
> > to interrupt (or take other action) when busy goes away.
> >
> > I suppose you could poll with status reads, which could at least be=
> > preempted if you've got something higher priority to do with the LB=
C.
> >
> > -Scott
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner=
^ permalink raw reply
* [PATCH 1/3 v2] edac: Use ccsr_pci structure instead of hardcoded define
From: Lan Chunhe @ 2010-12-10 10:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lan Chunhe, Kai.Jiang, dougthompson, akpm
There are some differences of register offset and definition between
pci and pcie error management registers. While, some other pci/pcie
error management registers are nearly the same.
To merge pci and pcie edac code into one, it is easier to use ccsr_pci
structure than the hardcoded define. So remove the hardcoded define and
add pci/pcie error management register in ccsr_pci structure.
Signed-off-by: Kai.Jiang <Kai.Jiang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Lan Chunhe <b25806@freescale.com>
---
arch/powerpc/sysdev/fsl_pci.h | 54 +++++++++++++++++++++++++++++++---------
drivers/edac/mpc85xx_edac.c | 8 ------
drivers/edac/mpc85xx_edac.h | 21 +++++++--------
3 files changed, 52 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index 8ad72a1..796985b 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -1,7 +1,7 @@
/*
* MPC85xx/86xx PCI Express structure define
*
- * Copyright 2007 Freescale Semiconductor, Inc
+ * Copyright 2007, 2010 Freescale Semiconductor, Inc
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -14,6 +14,8 @@
#ifndef __POWERPC_FSL_PCI_H
#define __POWERPC_FSL_PCI_H
+#include <asm/pci-bridge.h>
+
#define PCIE_LTSSM 0x0404 /* PCIE Link Training and Status */
#define PCIE_LTSSM_L0 0x16 /* L0 state */
#define PIWAR_EN 0x80000000 /* Enable */
@@ -71,18 +73,46 @@ struct ccsr_pci {
*/
struct pci_inbound_window_regs piw[3];
- __be32 pex_err_dr; /* 0x.e00 - PCI/PCIE error detect register */
- u8 res21[4];
- __be32 pex_err_en; /* 0x.e08 - PCI/PCIE error interrupt enable register */
- u8 res22[4];
- __be32 pex_err_disr; /* 0x.e10 - PCI/PCIE error disable register */
- u8 res23[12];
- __be32 pex_err_cap_stat; /* 0x.e20 - PCI/PCIE error capture status register */
+/* Merge PCI/PCI Express error management registers */
+ __be32 pex_err_dr; /* 0x.e00
+ * - PCI/PCIE error detect register
+ */
+ __be32 pex_err_cap_dr; /* 0x.e04
+ * - PCI error capture disabled register
+ * - PCIE has no this register
+ */
+ __be32 pex_err_en; /* 0x.e08
+ * - PCI/PCIE error interrupt enable register
+ */
+ __be32 pex_err_attrib; /* 0x.e0c
+ * - PCI error attributes capture register
+ * - PCIE has no this register
+ */
+ __be32 pex_err_disr; /* 0x.e10
+ * - PCI error address capture register
+ * - PCIE error disable register
+ */
+ __be32 pex_err_ext_addr; /* 0x.e14
+ * - PCI error extended addr capture register
+ * - PCIE has no this register
+ */
+ __be32 pex_err_dl; /* 0x.e18
+ * - PCI error data low capture register
+ * - PCIE has no this register
+ */
+ __be32 pex_err_dh; /* 0x.e1c
+ * - PCI error data high capture register
+ * - PCIE has no this register
+ */
+ __be32 pex_err_cap_stat; /* 0x.e20
+ * - PCI gasket timer register
+ * - PCIE error capture status register
+ */
u8 res24[4];
- __be32 pex_err_cap_r0; /* 0x.e28 - PCIE error capture register 0 */
- __be32 pex_err_cap_r1; /* 0x.e2c - PCIE error capture register 0 */
- __be32 pex_err_cap_r2; /* 0x.e30 - PCIE error capture register 0 */
- __be32 pex_err_cap_r3; /* 0x.e34 - PCIE error capture register 0 */
+ __be32 pex_err_cap_r0; /* 0x.e28 - PCIE error capture register 0 */
+ __be32 pex_err_cap_r1; /* 0x.e2c - PCIE error capture register 1 */
+ __be32 pex_err_cap_r2; /* 0x.e30 - PCIE error capture register 2 */
+ __be32 pex_err_cap_r3; /* 0x.e34 - PCIE error capture register 3 */
};
extern int fsl_add_bridge(struct device_node *dev, int is_primary);
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b123bb3..4bdf384 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -34,14 +34,6 @@ static int edac_mc_idx;
static u32 orig_ddr_err_disable;
static u32 orig_ddr_err_sbe;
-/*
- * PCI Err defines
- */
-#ifdef CONFIG_PCI
-static u32 orig_pci_err_cap_dr;
-static u32 orig_pci_err_en;
-#endif
-
static u32 orig_l2_err_disable;
#ifdef CONFIG_FSL_SOC_BOOKE
static u32 orig_hid1[2];
diff --git a/drivers/edac/mpc85xx_edac.h b/drivers/edac/mpc85xx_edac.h
index cb24df8..c258161 100644
--- a/drivers/edac/mpc85xx_edac.h
+++ b/drivers/edac/mpc85xx_edac.h
@@ -1,5 +1,8 @@
/*
* Freescale MPC85xx Memory Controller kenel module
+ *
+ * Copyright (c) 2010 Freescale Semiconductor, Inc.
+ *
* Author: Dave Jiang <djiang@mvista.com>
*
* 2006-2007 (c) MontaVista Software, Inc. This file is licensed under
@@ -131,16 +134,9 @@
#define PCI_EDE_PERR_MASK (PCI_EDE_TGT_PERR | PCI_EDE_MST_PERR | \
PCI_EDE_ADDR_PERR)
-#define MPC85XX_PCI_ERR_DR 0x0000
-#define MPC85XX_PCI_ERR_CAP_DR 0x0004
-#define MPC85XX_PCI_ERR_EN 0x0008
-#define MPC85XX_PCI_ERR_ATTRIB 0x000c
-#define MPC85XX_PCI_ERR_ADDR 0x0010
-#define MPC85XX_PCI_ERR_EXT_ADDR 0x0014
-#define MPC85XX_PCI_ERR_DL 0x0018
-#define MPC85XX_PCI_ERR_DH 0x001c
-#define MPC85XX_PCI_GAS_TIMR 0x0020
-#define MPC85XX_PCI_PCIX_TIMR 0x0024
+#define PCI_ERR_CAP_DR_DIS_MST 0x0040
+#define PCI_ERR_EN_DIS_MST (~PCI_ERR_CAP_DR_DIS_MST)
+#define MPC85XX_MPIC_EIMR0 0x3910
struct mpc85xx_mc_pdata {
char *name;
@@ -159,7 +155,10 @@ struct mpc85xx_l2_pdata {
struct mpc85xx_pci_pdata {
char *name;
int edac_idx;
- void __iomem *pci_vbase;
+ struct ccsr_pci *pci_reg;
+ u32 orig_pci_err_cap_dr;
+ u32 orig_pci_err_en;
+ u8 pcie_flag;
int irq;
};
--
1.5.4.5
^ permalink raw reply related
* [PATCH 2/3 v2] edac/85xx: PCI/PCIE error interrupt edac support
From: Lan Chunhe @ 2010-12-10 10:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lan Chunhe, Kai.Jiang, dougthompson, akpm
Add pcie error interrupt edac support for mpc85xx and p4080.
mpc85xx uses the legacy interrupt report mechanism - the error
interrupts are reported directly to mpic. While, p4080 attaches
most of error interrupts to interrupt 0. And report error interrupt
to mpic via interrupt 0. This patch can handle both of them.
Signed-off-by: Kai.Jiang <Kai.Jiang@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Lan Chunhe <b25806@freescale.com>
---
drivers/edac/mpc85xx_edac.c | 240 +++++++++++++++++++++++++++++++++---------
1 files changed, 188 insertions(+), 52 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 4bdf384..793d605 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1,6 +1,8 @@
/*
* Freescale MPC85xx Memory Controller kenel module
*
+ * Copyright (c) 2010 Freescale Semiconductor, Inc.
+ *
* Author: Dave Jiang <djiang@mvista.com>
*
* 2006-2007 (c) MontaVista Software, Inc. This file is licensed under
@@ -21,6 +23,7 @@
#include <linux/of_platform.h>
#include <linux/of_device.h>
+#include <sysdev/fsl_pci.h>
#include "edac_module.h"
#include "edac_core.h"
#include "mpc85xx_edac.h"
@@ -35,7 +38,7 @@ static u32 orig_ddr_err_disable;
static u32 orig_ddr_err_sbe;
static u32 orig_l2_err_disable;
-#ifdef CONFIG_FSL_SOC_BOOKE
+#if defined(CONFIG_FSL_SOC_BOOKE) && !defined(CONFIG_PPC_E500MC)
static u32 orig_hid1[2];
#endif
@@ -143,37 +146,52 @@ static void mpc85xx_pci_check(struct edac_pci_ctl_info *pci)
{
struct mpc85xx_pci_pdata *pdata = pci->pvt_info;
u32 err_detect;
+ struct ccsr_pci *reg = pdata->pci_reg;
+
+ err_detect = in_be32(&pdata->pci_reg->pex_err_dr);
+
+ if (pdata->pcie_flag) {
+ printk(KERN_ERR "PCIE error(s) detected\n");
+ printk(KERN_ERR "PCIE ERR_DR register: 0x%08x\n", err_detect);
+ printk(KERN_ERR "PCIE ERR_CAP_STAT register: 0x%08x\n",
+ in_be32(®->pex_err_cap_stat));
+ printk(KERN_ERR "PCIE ERR_CAP_R0 register: 0x%08x\n",
+ in_be32(®->pex_err_cap_r0));
+ printk(KERN_ERR "PCIE ERR_CAP_R1 register: 0x%08x\n",
+ in_be32(®->pex_err_cap_r1));
+ printk(KERN_ERR "PCIE ERR_CAP_R2 register: 0x%08x\n",
+ in_be32(®->pex_err_cap_r2));
+ printk(KERN_ERR "PCIE ERR_CAP_R3 register: 0x%08x\n",
+ in_be32(®->pex_err_cap_r3));
+ } else {
+ /* master aborts can happen during PCI config cycles */
+ if (!(err_detect & ~(PCI_EDE_MULTI_ERR | PCI_EDE_MST_ABRT))) {
+ out_be32(®->pex_err_dr, err_detect);
+ return;
+ }
- err_detect = in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR);
-
- /* master aborts can happen during PCI config cycles */
- if (!(err_detect & ~(PCI_EDE_MULTI_ERR | PCI_EDE_MST_ABRT))) {
- out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR, err_detect);
- return;
+ printk(KERN_ERR "PCI error(s) detected\n");
+ printk(KERN_ERR "PCI/X ERR_DR register: 0x%08x\n", err_detect);
+ printk(KERN_ERR "PCI/X ERR_ATTRIB register: 0x%08x\n",
+ in_be32(®->pex_err_attrib));
+ printk(KERN_ERR "PCI/X ERR_ADDR register: 0x%08x\n",
+ in_be32(®->pex_err_disr));
+ printk(KERN_ERR "PCI/X ERR_EXT_ADDR register: 0x%08x\n",
+ in_be32(®->pex_err_ext_addr));
+ printk(KERN_ERR "PCI/X ERR_DL register: 0x%08x\n",
+ in_be32(®->pex_err_dl));
+ printk(KERN_ERR "PCI/X ERR_DH register: 0x%08x\n",
+ in_be32(®->pex_err_dh));
+
+ if (err_detect & PCI_EDE_PERR_MASK)
+ edac_pci_handle_pe(pci, pci->ctl_name);
+
+ if (err_detect & ~(PCI_EDE_MULTI_ERR | PCI_EDE_PERR_MASK))
+ edac_pci_handle_npe(pci, pci->ctl_name);
}
- printk(KERN_ERR "PCI error(s) detected\n");
- printk(KERN_ERR "PCI/X ERR_DR register: %#08x\n", err_detect);
-
- printk(KERN_ERR "PCI/X ERR_ATTRIB register: %#08x\n",
- in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ATTRIB));
- printk(KERN_ERR "PCI/X ERR_ADDR register: %#08x\n",
- in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_ADDR));
- printk(KERN_ERR "PCI/X ERR_EXT_ADDR register: %#08x\n",
- in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EXT_ADDR));
- printk(KERN_ERR "PCI/X ERR_DL register: %#08x\n",
- in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DL));
- printk(KERN_ERR "PCI/X ERR_DH register: %#08x\n",
- in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DH));
-
/* clear error bits */
- out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR, err_detect);
-
- if (err_detect & PCI_EDE_PERR_MASK)
- edac_pci_handle_pe(pci, pci->ctl_name);
-
- if ((err_detect & ~PCI_EDE_MULTI_ERR) & ~PCI_EDE_PERR_MASK)
- edac_pci_handle_npe(pci, pci->ctl_name);
+ out_be32(®->pex_err_dr, err_detect);
}
static irqreturn_t mpc85xx_pci_isr(int irq, void *dev_id)
@@ -182,7 +200,7 @@ static irqreturn_t mpc85xx_pci_isr(int irq, void *dev_id)
struct mpc85xx_pci_pdata *pdata = pci->pvt_info;
u32 err_detect;
- err_detect = in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR);
+ err_detect = in_be32(&pdata->pci_reg->pex_err_dr);
if (!err_detect)
return IRQ_NONE;
@@ -192,12 +210,103 @@ static irqreturn_t mpc85xx_pci_isr(int irq, void *dev_id)
return IRQ_HANDLED;
}
+/**
+ * This function is for error interrupt ORed mechanism.
+ * This mechanism attaches most functions' error interrupts to interrupt 0.
+ * And report error interrupt to mpic via interrupt 0.
+ * EIMR0 - Error Interrupt Mask Register 0.
+ *
+ * This function check whether the device support error interrupt ORed
+ * mechanism via device tree. If supported, umask pcie error interrupt
+ * bit in EIMR0.
+ */
+static int mpc85xx_err_int_en(struct platform_device *op)
+{
+ u32 *int_cell;
+ struct device_node *np;
+ void __iomem *mpic_base;
+ u32 reg_tmp;
+ u32 int_len;
+ struct resource r;
+ int res;
+
+ if (!op->dev.of_node)
+ return -EINVAL;
+
+ /*
+ * Unmask pcie error interrupt bit in EIMR0.
+ * Extend interrupt specifier has 4 cells.
+ * For the 3rd cell:
+ * 0 -- normal interrupt;
+ * 1 -- error interrupt.
+ */
+ int_cell = (u32 *)of_get_property(op->dev.of_node, "interrupts",
+ &int_len);
+ if ((int_len/sizeof(u32)) == 4) {
+ /* soc has error interrupt integration handling mechanism */
+ if (*(int_cell + 2) == 1) {
+ np = of_find_node_by_type(NULL, "open-pic");
+
+ if (of_address_to_resource(np, 0, &r)) {
+ printk(KERN_ERR "%s: Failed to map mpic regs\n",
+ __func__);
+ of_node_put(np);
+ res = -ENOMEM;
+ goto err;
+ }
+
+ if (!request_mem_region(r.start, r.end - r.start + 1,
+ "mpic")) {
+ printk(KERN_ERR "%s: Error while requesting "
+ "mem region\n", __func__);
+ res = -EBUSY;
+ goto err;
+ }
+
+ mpic_base = ioremap(r.start, r.end - r.start + 1);
+ if (!mpic_base) {
+ printk(KERN_ERR "%s: Unable to map mpic regs\n",
+ __func__);
+ res = -ENOMEM;
+ goto err_ioremap;
+ }
+
+ reg_tmp = in_be32(mpic_base + MPC85XX_MPIC_EIMR0);
+ out_be32(mpic_base + MPC85XX_MPIC_EIMR0,
+ reg_tmp & ~(1 << (31 - *(int_cell + 3))));
+ iounmap(mpic_base);
+ release_mem_region(r.start, r.end - r.start + 1);
+ of_node_put(np);
+ }
+ }
+
+ return 0;
+
+err_ioremap:
+ release_mem_region(r.start, r.end - r.start + 1);
+err:
+ return res;
+}
+
+static int mpc85xx_pcie_find_capability(struct device_node *np)
+{
+ struct pci_controller *hose;
+
+ if (!np)
+ return -EINVAL;
+
+ hose = pci_find_hose_for_OF_device(np);
+ return early_find_capability(hose, hose->bus->number, 0,
+ PCI_CAP_ID_EXP);
+}
+
static int __devinit mpc85xx_pci_err_probe(struct platform_device *op,
const struct of_device_id *match)
{
struct edac_pci_ctl_info *pci;
struct mpc85xx_pci_pdata *pdata;
struct resource r;
+ struct ccsr_pci *reg;
int res = 0;
if (!devres_open_group(&op->dev, mpc85xx_pci_err_probe, GFP_KERNEL))
@@ -210,6 +319,9 @@ static int __devinit mpc85xx_pci_err_probe(struct platform_device *op,
pdata = pci->pvt_info;
pdata->name = "mpc85xx_pci_err";
pdata->irq = NO_IRQ;
+ if (mpc85xx_pcie_find_capability(op->dev.of_node) > 0)
+ pdata->pcie_flag = 1;
+
dev_set_drvdata(&op->dev, pci);
pci->dev = &op->dev;
pci->mod_name = EDAC_MOD_STR;
@@ -228,9 +340,6 @@ static int __devinit mpc85xx_pci_err_probe(struct platform_device *op,
goto err;
}
- /* we only need the error registers */
- r.start += 0xe00;
-
if (!devm_request_mem_region(&op->dev, r.start, resource_size(&r),
pdata->name)) {
printk(KERN_ERR "%s: Error while requesting mem region\n",
@@ -239,26 +348,32 @@ static int __devinit mpc85xx_pci_err_probe(struct platform_device *op,
goto err;
}
- pdata->pci_vbase = devm_ioremap(&op->dev, r.start, resource_size(&r));
- if (!pdata->pci_vbase) {
+ pdata->pci_reg = devm_ioremap(&op->dev, r.start, resource_size(&r));
+ if (!pdata->pci_reg) {
printk(KERN_ERR "%s: Unable to setup PCI err regs\n", __func__);
res = -ENOMEM;
goto err;
}
- orig_pci_err_cap_dr =
- in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_CAP_DR);
-
- /* PCI master abort is expected during config cycles */
- out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_CAP_DR, 0x40);
+ if (mpc85xx_err_int_en(op) < 0)
+ goto err;
- orig_pci_err_en = in_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN);
+ reg = pdata->pci_reg;
+ /* disable pci/pcie error detect */
+ if (pdata->pcie_flag) {
+ pdata->orig_pci_err_cap_dr = in_be32(®->pex_err_disr);
+ out_be32(®->pex_err_disr, ~0);
+ } else {
+ pdata->orig_pci_err_cap_dr = in_be32(®->pex_err_cap_dr);
+ out_be32(®->pex_err_cap_dr, ~0);
+ }
- /* disable master abort reporting */
- out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN, ~0x40);
+ /* disable all pcie error interrupt */
+ pdata->orig_pci_err_en = in_be32(®->pex_err_en);
+ out_be32(®->pex_err_en, 0);
- /* clear error bits */
- out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_DR, ~0);
+ /* clear all error bits */
+ out_be32(®->pex_err_dr, ~0);
if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
debugf3("%s(): failed edac_pci_add_device()\n", __func__);
@@ -268,7 +383,7 @@ static int __devinit mpc85xx_pci_err_probe(struct platform_device *op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->dev.of_node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_pci_isr, IRQF_DISABLED,
+ mpc85xx_pci_isr, IRQF_SHARED,
"[EDAC] PCI err", pci);
if (res < 0) {
printk(KERN_ERR
@@ -283,6 +398,17 @@ static int __devinit mpc85xx_pci_err_probe(struct platform_device *op,
pdata->irq);
}
+ if (pdata->pcie_flag) {
+ /* enable all pcie error interrupt & error detect */
+ out_be32(®->pex_err_en, ~0);
+ out_be32(®->pex_err_disr, 0);
+ } else {
+ /* PCI master abort is expected during config cycles */
+ out_be32(®->pex_err_cap_dr, PCI_ERR_CAP_DR_DIS_MST);
+ /* disable master abort reporting */
+ out_be32(®->pex_err_en, PCI_ERR_EN_DIS_MST);
+ }
+
devres_remove_group(&op->dev, mpc85xx_pci_err_probe);
debugf3("%s(): success\n", __func__);
printk(KERN_INFO EDAC_MOD_STR " PCI err registered\n");
@@ -304,10 +430,14 @@ static int mpc85xx_pci_err_remove(struct platform_device *op)
debugf0("%s()\n", __func__);
- out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_CAP_DR,
- orig_pci_err_cap_dr);
+ if (pdata->pcie_flag)
+ out_be32(&pdata->pci_reg->pex_err_disr,
+ pdata->orig_pci_err_cap_dr);
+ else
+ out_be32(&pdata->pci_reg->pex_err_cap_dr,
+ pdata->orig_pci_err_cap_dr);
- out_be32(pdata->pci_vbase + MPC85XX_PCI_ERR_EN, orig_pci_err_en);
+ out_be32(&pdata->pci_reg->pex_err_en, pdata->orig_pci_err_en);
edac_pci_del_device(pci->dev);
@@ -326,6 +456,12 @@ static struct of_device_id mpc85xx_pci_err_of_match[] = {
{
.compatible = "fsl,mpc8540-pci",
},
+ {
+ .compatible = "fsl,mpc8548-pcie",
+ },
+ {
+ .compatible = "fsl,p4080-pcie",
+ },
{},
};
MODULE_DEVICE_TABLE(of, mpc85xx_pci_err_of_match);
@@ -1138,7 +1274,7 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
-#ifdef CONFIG_FSL_SOC_BOOKE
+#if defined(CONFIG_FSL_SOC_BOOKE) && !defined(CONFIG_PPC_E500MC)
static void __init mpc85xx_mc_clear_rfxe(void *data)
{
orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
@@ -1177,7 +1313,7 @@ static int __init mpc85xx_mc_init(void)
printk(KERN_WARNING EDAC_MOD_STR "PCI fails to register\n");
#endif
-#ifdef CONFIG_FSL_SOC_BOOKE
+#if defined(CONFIG_FSL_SOC_BOOKE) && !defined(CONFIG_PPC_E500MC)
/*
* need to clear HID1[RFXE] to disable machine check int
* so we can catch it
@@ -1191,7 +1327,7 @@ static int __init mpc85xx_mc_init(void)
module_init(mpc85xx_mc_init);
-#ifdef CONFIG_FSL_SOC_BOOKE
+#if defined(CONFIG_FSL_SOC_BOOKE) && !defined(CONFIG_PPC_E500MC)
static void __exit mpc85xx_mc_restore_hid1(void *data)
{
mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
@@ -1200,7 +1336,7 @@ static void __exit mpc85xx_mc_restore_hid1(void *data)
static void __exit mpc85xx_mc_exit(void)
{
-#ifdef CONFIG_FSL_SOC_BOOKE
+#if defined(CONFIG_FSL_SOC_BOOKE) && !defined(CONFIG_PPC_E500MC)
on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
#endif
#ifdef CONFIG_PCI
--
1.5.4.5
^ permalink raw reply related
* [PATCH 3/3 v2] of/device: Register children with a compatible value in of_platform_bus_probe()
From: Lan Chunhe @ 2010-12-10 10:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lan Chunhe, akpm, dougthompson
Currently, of_platform_bus_probe() completely skips nodes which do not
explicitly match the 'matches' table passed in. Or, if the root node
matches, then it registers all the children unconditionally. However,
there are situations, such as registering devices from the root node,
when it is desirable to register child nodes, but only if they actually
represent devices. For example, the root node may contain both a local
bus and a PCI device, but it also contains the chosen, aliases and cpus
nodes which don't represent real devices.
This patch changes of_platform_bus_probe() to register all nodes at the
top level if they either match the matches table (the current behaviour),
or if they have a 'compatible' value (indicating it represents a device).
Signed-off-by: Lan Chunhe <b25806@freescale.com>
---
drivers/of/platform.c | 28 +++++++++++++++++++++++-----
1 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 5b4a07f..02755ab 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -714,6 +714,8 @@ int of_platform_bus_probe(struct device_node *root,
struct device_node *child;
struct platform_device *dev;
int rc = 0;
+ const void *compat;
+ const struct of_device_id *match;
if (WARN_ON(!matches || matches == OF_NO_DEEP_PROBE))
return -EINVAL;
@@ -741,16 +743,32 @@ int of_platform_bus_probe(struct device_node *root,
rc = of_platform_bus_create(root, matches, &dev->dev);
goto bail;
}
+
+ /*
+ * Register each child node if either:
+ * a) it has a 'compatible' value indicating they are a device, or
+ * b) it is specified by the 'matches' table (by name or device_type)
+ * If a node is specified in the matches table, then all its children
+ * also get registered.
+ */
for_each_child_of_node(root, child) {
- if (!of_match_node(matches, child))
+ compat = of_get_property(child, "compatible", NULL);
+ match = of_match_node(matches, child);
+ if (!compat && !match)
continue;
- pr_debug(" match: %s\n", child->full_name);
+ pr_debug(" register device: %s\n", child->full_name);
dev = of_platform_device_create(child, NULL, parent);
- if (dev == NULL)
+ if (!dev) {
rc = -ENOMEM;
- else
- rc = of_platform_bus_create(child, matches, &dev->dev);
+ of_node_put(child);
+ break;
+ }
+ if (!match)
+ continue;
+
+ pr_debug(" register children of: %s\n", child->full_name);
+ rc = of_platform_bus_create(child, matches, &dev->dev);
if (rc) {
of_node_put(child);
break;
--
1.5.4.5
^ permalink raw reply related
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-10 12:39 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <20101208162559.26e40cf2@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 23:25:59:
>
> On Wed, 8 Dec 2010 17:02:45 -0500
> Mark Mason <mason@postdiluvian.org> wrote:
>
> > I don't think that using a software NAND controller instead of the LBC
> > FCM mode is all that bad. Again, I haven't actually done it, so check
> > the MTD docs, but I'm pretty sure the software is meant to do that, so
> > it doesn't even really constitute a "fix". Assuming that it is
> > supported then I doubt that configuring the NAND layer to use your
> > setup would be any harder than configuring the FCM.
>
> The MTD layer supports some really simple NAND controllers, but what do
> you mean by not having a controller at all? Hooking everything up to
> GPIO? Using UPM?
>
> There is already a UPM NAND driver, BTW.
>
> You would lose hardware ECC and the ability to be interrupt-driven (the
> latter should be possible with SW changes, using GPIO interrupts).
hmm, you think it would be possible to use one of the IRQ pins instead?
^ permalink raw reply
* Re: [PATCH v5] ppc44x:PHY fixup for USB on canyonlands board
From: Josh Boyer @ 2010-12-10 13:39 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linuxppc-dev, rsarmah, linux-kernel
In-Reply-To: <201012090424.oB94O1DV006463@amcc.com>
On Thu, Dec 09, 2010 at 09:54:01AM +0530, Rupjyoti Sarmah wrote:
A few error path issues, plus one leak in the good case. I'll wait to
see if there are any more comments for a couple of days.
>+static int __init ppc460ex_canyonlands_fixup(void)
>+{
>+ u8 __iomem *bcsr ;
>+ void __iomem *vaddr;
>+ struct device_node *np;
>+ int ret = 0;
>+
>+ np = of_find_compatible_node(NULL, NULL, "amcc,ppc460ex-bcsr");
>+ if (!np) {
>+ printk(KERN_ERR "failed did not find amcc, ppc460ex bcsr node\n");
>+ return -ENODEV;
>+ }
>+
>+ bcsr = of_iomap(np, 0);
>+ of_node_put(np);
>+
>+ if (!bcsr) {
>+ printk(KERN_CRIT "Could not remap bcsr\n");
>+ ret = -ENODEV;
>+ }
>+
>+ np = of_find_compatible_node(NULL, NULL, "ibm,ppc4xx-gpio");
This can fail if you boot a new kernel on a board with an old FDT that
lacks the gpio node. Calling of_iomap with a NULL np seems like it
would work without crashing anything, so maybe that's not a huge issue.
>+ vaddr = of_iomap(np, 0);
>+ if (!vaddr) {
>+ printk(KERN_CRIT "Could not get gpio node address\n");
>+ ret = -ENODEV;
>+ goto err_bcsr;
>+ }
A reference count is leaked for the node in this error case because
of_node_put isn't called for the gpio node. Also, iounmap is never
called on vaddr.
>+ /* Disable USB, through the BCSR7 bits */
>+ setbits8(&bcsr[7], BCSR_USB_EN);
>+
>+ /* Wait for a while after reset */
>+ msleep(100);
>+
>+ /* Enable USB here */
>+ clrbits8(&bcsr[7], BCSR_USB_EN);
>+
>+ /*
>+ * Configure multiplexed gpio16 and gpio19 as alternate1 output
>+ * source after USB reset. In this configuration gpio16 will be
>+ * USB2HStop and gpio19 will be USB2DStop. For more details refer to
>+ * table 34-7 of PPC460EX user manual.
>+ */
>+ setbits32((vaddr + GPIO0_OSRH), 0x42000000);
>+ setbits32((vaddr + GPIO0_TSRH), 0x42000000);
>+ of_node_put(np);
>+err_bcsr:
>+ iounmap(bcsr);
>+ return ret;
>+}
>+machine_device_initcall(canyonlands, ppc460ex_canyonlands_fixup);
josh
^ permalink raw reply
* ucc_geth: transmit queue timeout at half-duplex mode
From: Schmitz, Andreas @ 2010-12-10 13:52 UTC (permalink / raw)
To: leoli@freescale.com; +Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
[-- Attachment #1.1: Type: text/plain, Size: 1227 bytes --]
Hi all,
on my MPC8321E with linux-2.6.36 I get this netdev watchdog warning "NETDEV WATCHDOG: eth0 (of:ucc_geth): transmit queue 0 timed out" if the link mode is half-duplex.
The warning is caused, because all Tx BDs are full and packet transmission is stopped with netif_stop_queue() in ucc_geth_start_xmit().
You can reproduce the bug in the following way:
- Connect to a switch, that supports only 10baseT, or set the mode manually with "mii-diag -F 10baseT".
- Open a telnet session to the target. Generate higher traffic with executing maybe "cat /proc/interrupts" many times.
- After some tries the ethernet connection will be down, then again after approx. 30s seconds the netdev watchdog will dump the warning.
It is unclear to me why the TxBDs get full. Due to missing "Tx buffer sent" interrupts, it seems that the QE stops the transmission.
I found some issue in the errata: "QE_ENET20: UEC may stop transmitting after late collision". But UCCE[TXE] is never set in this case.
Thank you for your help in advance and best regards,
Andreas Schmitz
Software Engineer
_______________________________________
RIEDEL
Communications GmbH & Co. KG
Uellendahler Str. 353
42109 Wuppertal
Germany
[-- Attachment #1.2: Type: text/html, Size: 2213 bytes --]
[-- Attachment #2: ucc_geth_half_duplex_netdev_watchdog.txt --]
[-- Type: text/plain, Size: 13531 bytes --]
PHY: mdio@e0102320:01 - Link is Up - 10/Half
NETDEV WATCHDOG: eth0 (of:ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:258
Modules linked in: gpio
NIP: c01887c0 LR: c01887c0 CTR: c012b8d4
REGS: c3ffbe30 TRAP: 0700 Not tainted (2.6.36)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 44022084 XER: 20000000
TASK = c07f6410[0] 'swapper' THREAD: c080e000
GPR00: c01887c0 c3ffbee0 c07f6410 00000046 00001848 ffffffff c012c2b0 2074696d
GPR08: 00001808 c3ffa000 c0817eb8 00000004 00000000 1007d144 03fff000 c07f94e4
GPR16: 00200200 c020dcd4 00000000 00000001 c0837fc0 c08381ec c083826c c08382ec
GPR24: c083836c 00000002 ffffffff 00000000 c3ffa03c c2607fa0 00000000 c2583000
NIP [c01887c0] dev_watchdog+0x198/0x28c
LR [c01887c0] dev_watchdog+0x198/0x28c
Call Trace:
[c3ffbee0] [c01887c0] dev_watchdog+0x198/0x28c (unreliable)
[c3ffbf50] [c003c9b0] run_timer_softirq+0x1b0/0x250
[c3ffbfb0] [c0036d18] __do_softirq+0xa8/0x124
[c3ffbff0] [c000e5dc] call_do_softirq+0x14/0x24
[c080fe70] [c0005e38] do_softirq+0x6c/0x8c
[c080fe90] [c00367b4] irq_exit+0x3c/0x54
[c080fea0] [c0005fec] do_IRQ+0x128/0x144
[c080fec0] [c000f2ac] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0x94/0xe4
LR = cpu_idle+0x94/0xe4
[c080ff80] [c00090c4] cpu_idle+0xe0/0xe4 (unreliable)
[c080ffa0] [c0003e50] rest_init+0xa8/0xd8
[c080ffc0] [c023e80c] start_kernel+0x2b8/0x2cc
[c080fff0] [00003438] 0x3438
Instruction dump:
2f800000 40be003c 38810008 7fe3fb78 38a00040 4bfeb799 7fc6f378 7fe4fb78
7c651b78 3c60c022 386316b0 4804f631 <0fe00000> 38000001 3d20c085 9809aa6c
---[ end trace 0cbe1c7362251e03 ]---
UCC2 Fast registers:
Base address: 0xc91c6200
gumr : addr=0xc91c6200, val=0x0000003c
upsmr : addr=0xc91c6204, val=0x02002000
utodr : addr=0xc91c6208, val=0x0000
udsr : addr=0xc91c620c, val=0x7e7e
ucce : addr=0xc91c6210, val=0x00000000
uccm : addr=0xc91c6214, val=0x5fff00ff
uccs : addr=0xc91c6218, val=0x00
urfb : addr=0xc91c6220, val=0x00001780
urfs : addr=0xc91c6224, val=0x0200
urfet : addr=0xc91c6228, val=0x0100
urfset: addr=0xc91c622a, val=0x0180
utfb : addr=0xc91c622c, val=0x00001580
utfs : addr=0xc91c6230, val=0x0200
utfet : addr=0xc91c6234, val=0x0100
utftt : addr=0xc91c6238, val=0x0200
utpt : addr=0xc91c623c, val=0x0100
urtry : addr=0xc91c6240, val=0x00000000
guemr : addr=0xc91c6290, val=0x13
UCC3 Geth registers:
Base address: 0xc91ca200
maccfg1 : addr - 0xc91ca300, val - 0x0000003f
maccfg2 : addr - 0xc91ca304, val - 0x00007124
ipgifg : addr - 0xc91ca308, val - 0x40605060
hafdup : addr - 0xc91ca30c, val - 0x00a1f037
ifctl : addr - 0xc91ca338, val - 0x01000000
ifstat : addr - 0xc91ca33c, val - 0x00000008
macstnaddr1: addr - 0xc91ca340, val - 0x4708007c
macstnaddr2: addr - 0xc91ca344, val - 0x19000000
uempr : addr - 0xc91ca350, val - 0x00000000
utbipar : addr - 0xc91ca354, val - 0x00000020
uescr : addr - 0xc91ca358, val - 0x0804
tx64 : addr - 0xc91ca380, val - 0x00000005
tx127 : addr - 0xc91ca384, val - 0x00000046
tx255 : addr - 0xc91ca388, val - 0x00000121
rx64 : addr - 0xc91ca38c, val - 0x00000002
rx127 : addr - 0xc91ca390, val - 0x00000078
rx255 : addr - 0xc91ca394, val - 0x00000139
txok : addr - 0xc91ca398, val - 0x0001294f
txcf : addr - 0xc91ca39c, val - 0x0000
tmca : addr - 0xc91ca3a0, val - 0x00000000
tbca : addr - 0xc91ca3a4, val - 0x00000002
rxfok : addr - 0xc91ca3a8, val - 0x000001a8
rxbok : addr - 0xc91ca3ac, val - 0x0001563d
rbyt : addr - 0xc91ca3b0, val - 0x0001843b
rmca : addr - 0xc91ca3b4, val - 0x00000000
rbca : addr - 0xc91ca3b8, val - 0x00000004
scar : addr - 0xc91ca3bc, val - 0x00000000
scam : addr - 0xc91ca3c0, val - 0xfffe0000
Thread data TXs:
Base address: 0xfdefbb00
Thread data TX[0]:
Base address: 0xfdefbb00
0xfdefbb00: 18000000 188000ca 18000000 18800044
0xfdefbb10: 18000000 1880005e 0260e130 18800044
0xfdefbb20: 02000318 202490c5 00181204 0c00800e
0xfdefbb30: 69fdf7fe b6a7fa9f eddffeaf bb7fff77
0xfdefbb40: 800016e0 b2000080 0260e138 02179876
0xfdefbb50: 80001580 b0000080 0260e138 021798f6
0xfdefbb60: 80001608 b0000080
Thread data RX:
Base address: 0xfdefbd00
Thread data RX[0]:
Base address: 0xfdefbd00
0xfdefbd00: 00000000 08c01055 00000000 02003000
0xfdefbd10: 00000000 08c01055 00000000 02003000
0xfdefbd20: 00001f00 00000005
TX global param:
Base address: 0xfdefba00
temoder : addr - 0xfdefba00, val - 0x0110
sqptr : addr - 0xfdefba38, val - 0x000019a0
schedulerbasepointer: addr - 0xfdefba3c, val - 0x00000000
txrmonbaseptr: addr - 0xfdefba40, val - 0x00001a80
tstate : addr - 0xfdefba44, val - 0x30000000
iphoffset[0] : addr - 0xfdefba48, val - 0x00
iphoffset[1] : addr - 0xfdefba49, val - 0x00
iphoffset[2] : addr - 0xfdefba4a, val - 0x00
iphoffset[3] : addr - 0xfdefba4b, val - 0x00
iphoffset[4] : addr - 0xfdefba4c, val - 0x00
iphoffset[5] : addr - 0xfdefba4d, val - 0x00
iphoffset[6] : addr - 0xfdefba4e, val - 0x00
iphoffset[7] : addr - 0xfdefba4f, val - 0x00
vtagtable[0] : addr - 0xfdefba50, val - 0x00000000
vtagtable[1] : addr - 0xfdefba54, val - 0x00000000
vtagtable[2] : addr - 0xfdefba58, val - 0x00000000
vtagtable[3] : addr - 0xfdefba5c, val - 0x00000000
vtagtable[4] : addr - 0xfdefba60, val - 0x00000000
vtagtable[5] : addr - 0xfdefba64, val - 0x00000000
vtagtable[6] : addr - 0xfdefba68, val - 0x00000000
vtagtable[7] : addr - 0xfdefba6c, val - 0x00000000
tqptr : addr - 0xfdefba70, val - 0x00001b00
RX global param:
Base address: 0xfdefbc00
remoder : addr - 0xfdefbc00, val - 0x00001000
rqptr : addr - 0xfdefbc04, val - 0x00001d00
typeorlen : addr - 0xfdefbc20, val - 0x0c00
rxgstpack : addr - 0xfdefbc23, val - 0x00
rxrmonbaseptr : addr - 0xfdefbc24, val - 0x00001e00
intcoalescingptr: addr - 0xfdefbc30, val - 0x00001ac0
rstate : addr - 0xfdefbc36, val - 0x30
mrblr : addr - 0xfdefbc46, val - 0x0600
rbdqptr : addr - 0xfdefbc48, val - 0x00001e60
mflr : addr - 0xfdefbc4c, val - 0x05ee
minflr : addr - 0xfdefbc4e, val - 0x0040
maxd1 : addr - 0xfdefbc50, val - 0x05f0
maxd2 : addr - 0xfdefbc52, val - 0x05f0
ecamptr : addr - 0xfdefbc54, val - 0x00000000
l2qt : addr - 0xfdefbc58, val - 0x00000000
l3qt[0] : addr - 0xfdefbc5c, val - 0x00000000
l3qt[1] : addr - 0xfdefbc60, val - 0x00000000
l3qt[2] : addr - 0xfdefbc64, val - 0x00000000
l3qt[3] : addr - 0xfdefbc68, val - 0x00000000
l3qt[4] : addr - 0xfdefbc6c, val - 0x00000000
l3qt[5] : addr - 0xfdefbc70, val - 0x00000000
l3qt[6] : addr - 0xfdefbc74, val - 0x00000000
l3qt[7] : addr - 0xfdefbc78, val - 0x00000000
vlantype : addr - 0xfdefbc7c, val - 0x8100
vlantci : addr - 0xfdefbc7e, val - 0x0000
addressfiltering[0]: addr - 0xfdefbc80, val - 0x00
addressfiltering[1]: addr - 0xfdefbc81, val - 0x00
addressfiltering[2]: addr - 0xfdefbc82, val - 0x00
addressfiltering[3]: addr - 0xfdefbc83, val - 0x00
addressfiltering[4]: addr - 0xfdefbc84, val - 0x00
addressfiltering[5]: addr - 0xfdefbc85, val - 0x00
addressfiltering[6]: addr - 0xfdefbc86, val - 0x00
addressfiltering[7]: addr - 0xfdefbc87, val - 0x00
addressfiltering[8]: addr - 0xfdefbc88, val - 0x00
addressfiltering[9]: addr - 0xfdefbc89, val - 0x00
addressfiltering[10]: addr - 0xfdefbc8a, val - 0x00
addressfiltering[11]: addr - 0xfdefbc8b, val - 0x01
addressfiltering[12]: addr - 0xfdefbc8c, val - 0x00
addressfiltering[13]: addr - 0xfdefbc8d, val - 0x00
addressfiltering[14]: addr - 0xfdefbc8e, val - 0x00
addressfiltering[15]: addr - 0xfdefbc8f, val - 0x00
addressfiltering[16]: addr - 0xfdefbc90, val - 0x00
addressfiltering[17]: addr - 0xfdefbc91, val - 0x00
addressfiltering[18]: addr - 0xfdefbc92, val - 0x01
addressfiltering[19]: addr - 0xfdefbc93, val - 0x00
addressfiltering[20]: addr - 0xfdefbc94, val - 0x00
addressfiltering[21]: addr - 0xfdefbc95, val - 0x5e
addressfiltering[22]: addr - 0xfdefbc96, val - 0x00
addressfiltering[23]: addr - 0xfdefbc97, val - 0x01
addressfiltering[24]: addr - 0xfdefbc98, val - 0x00
addressfiltering[25]: addr - 0xfdefbc99, val - 0x00
addressfiltering[26]: addr - 0xfdefbc9a, val - 0xff
addressfiltering[27]: addr - 0xfdefbc9b, val - 0xff
addressfiltering[28]: addr - 0xfdefbc9c, val - 0xff
addressfiltering[29]: addr - 0xfdefbc9d, val - 0xff
addressfiltering[30]: addr - 0xfdefbc9e, val - 0xff
addressfiltering[31]: addr - 0xfdefbc9f, val - 0xff
addressfiltering[32]: addr - 0xfdefbca0, val - 0x00
addressfiltering[33]: addr - 0xfdefbca1, val - 0x00
addressfiltering[34]: addr - 0xfdefbca2, val - 0xff
addressfiltering[35]: addr - 0xfdefbca3, val - 0xff
addressfiltering[36]: addr - 0xfdefbca4, val - 0xff
addressfiltering[37]: addr - 0xfdefbca5, val - 0xff
addressfiltering[38]: addr - 0xfdefbca6, val - 0xff
addressfiltering[39]: addr - 0xfdefbca7, val - 0xff
addressfiltering[40]: addr - 0xfdefbca8, val - 0x00
addressfiltering[41]: addr - 0xfdefbca9, val - 0x00
addressfiltering[42]: addr - 0xfdefbcaa, val - 0xff
addressfiltering[43]: addr - 0xfdefbcab, val - 0xff
addressfiltering[44]: addr - 0xfdefbcac, val - 0xff
addressfiltering[45]: addr - 0xfdefbcad, val - 0xff
addressfiltering[46]: addr - 0xfdefbcae, val - 0xff
addressfiltering[47]: addr - 0xfdefbcaf, val - 0xff
addressfiltering[48]: addr - 0xfdefbcb0, val - 0x00
addressfiltering[49]: addr - 0xfdefbcb1, val - 0x00
addressfiltering[50]: addr - 0xfdefbcb2, val - 0xff
addressfiltering[51]: addr - 0xfdefbcb3, val - 0xff
addressfiltering[52]: addr - 0xfdefbcb4, val - 0xff
addressfiltering[53]: addr - 0xfdefbcb5, val - 0xff
addressfiltering[54]: addr - 0xfdefbcb6, val - 0xff
addressfiltering[55]: addr - 0xfdefbcb7, val - 0xff
addressfiltering[56]: addr - 0xfdefbcb8, val - 0x81
addressfiltering[57]: addr - 0xfdefbcb9, val - 0x00
addressfiltering[58]: addr - 0xfdefbcba, val - 0x00
addressfiltering[59]: addr - 0xfdefbcbb, val - 0x00
addressfiltering[60]: addr - 0xfdefbcbc, val - 0x00
addressfiltering[61]: addr - 0xfdefbcbd, val - 0x00
addressfiltering[62]: addr - 0xfdefbcbe, val - 0x00
addressfiltering[63]: addr - 0xfdefbcbf, val - 0x00
exfGlobalParam : addr - 0xfdefbcc0, val - 0x00000000
Send Q memory registers:
Base address: 0xfdefb9a0
SQQD[0]:
Base address: 0xfdefb9a0
0xfdefb9a0: 0260e0c0 000019c0 0260e0c0 0260e128
0xfdefb9b0: b73b3fff 0260e128 0260e0c0 0260e138
0xfdefb9c0: 180000cb 02158076 18000213 02175876
0xfdefb9d0: 18000044 02158076 1800005e 02203876
TX FW statistics pram:
Base address: 0xfdefba80
0xfdefba80: 00000000 00000000 00000000 00000000
0xfdefba90: 00000000 00000033 0000015b 00000000
0xfdefbaa0: 00000015 0000000c 00000002 00000000
RX FW statistics pram:
Base address: 0xfdefbe00
0xfdefbe00: 00000032 00000000 00000000 00000000
0xfdefbe10: 00000000 00000001 00000000 00000000
0xfdefbe20: 00000000 00000000 00000000 00000000
0xfdefbe30: 00000000 0000000c 00000013 00000007
0xfdefbe40: 00000000 00000000 00000000 00000000
0xfdefbe50: 00000000 00000000 00000000
RX IRQ coalescing tables:
Base address: 0xfdefbac0
RX IRQ coalescing table entry[0]:
Base address: 0xfdefbac0
interruptcoalescingmaxvalue: addr - 0xfdefbac0, val - 0x00000001
interruptcoalescingcounter : addr - 0xfdefbac4, val - 0x00000001
RX BD QS tables:
Base address: 0xfdefbe60
RX BD QS table[0]:
Base address: 0xfdefbe60
bdbaseptr : addr - 0xfdefbe60, val - 0x00001e70
bdptr : addr - 0xfdefbe64, val - 0x00001e70
externalbdbaseptr: addr - 0xfdefbe68, val - 0x0260e180
externalbdptr : addr - 0xfdefbe6c, val - 0x0260e1c0
ucode RX Prefetched BDs:
Base address: 0xfdefbe70
0xfdefbe70: 90000000 0215b040 90000000 02157040
0xfdefbe80: 90000000 0220d040 90000000 02179040
Init enet param shadow:
Base address: 0xc209ccc0
0xc209ccc0: 0630ff00 04000000 11001c03 04000003
0xc209ccd0: 05001f03 00000000 00000000 00000000
0xc209cce0: 00000000 00000000 00000000 00000000
0xc209ccf0: 00000000 00000000 00001a03 0c001ec3
0xc209cd00: 00000000 00000000 00000000 00000000
0xc209cd10: 00000000 00000000 00000000 00
Init enet entry 0:
Base address: 0xfdefbec0
0xfdefbec0: 40001a00 86001b70 80000000 0000000c
0xfdefbed0: a4e3ff7f e27eff3f df196bd9 33fffc2f
0xfdefbee0: 10904802 00000020 06001b60 06001b60
0xfdefbef0: 67bdf7ed 1aebfcba 35fbeddb ff799df6
Init enet entry 1:
Base address: 0xfdefbf00
0xfdefbf00: 00001c00 00000000 80201000 30000001
0xfdefbf10: 8ebffdbf df001ec0 020031fe 08c01055
0xfdefbf20: 1cc00056 0215b840 05f00000 00001e60
0xfdefbf30: 021588c0 00bf2d7e 00000000 ebc77fc7
0xfdefbf40: 00060402 00016482 ca1c80c6 9810e8c3
0xfdefbf50: a7e195b7 0260e1b8 00000005 00000005
0xfdefbf60: 00001000 81000000 8f040182 30069982
0xfdefbf70: affc77bf f1e3eeff 00000580 00000056
TX BDs[0]
0xc260e0c0: 980001b4 02083876 980001b4 0215a076
0xc260e0d0: 980001b4 02159076 98000042 0216a25e
0xc260e0e0: 9800004e 02079452 9800004e 0216aa52
0xc260e0f0: 980001b4 02158076 9800004e 0216ac52
0xc260e100: 9800004e 0216a052 980001b4 0260c076
0xc260e110: 9800004e 02625e52 980001b4 02161876
0xc260e120: 9800004e 02625052 980001b4 02161076
0xc260e130: 98000044 02175876 b80001b4 02179876
RX BDs[0]
0xc260e180: 90000000 02154840 90000000 0220d840
0xc260e190: 90000000 02158840 90000000 02154040
0xc260e1a0: 90000000 02159840 90000000 02175040
0xc260e1b0: 90000000 02203840 90000000 0215b840
0xc260e1c0: 90000000 0215b040 90000000 02157040
0xc260e1d0: 90000000 0220d040 90000000 02179040
0xc260e1e0: 90000000 02083040 90000000 0215a840
0xc260e1f0: 90000000 02157840 b0000000 0260c840
PHY: mdio@e0102320:01 - Link is Up - 10/Half
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-10 16:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291854156.14490.32.camel@concordia>
Hello all,
> Are you sure that you want to have the chrdev registration here (the
> following code)?
It was commented out in my lastest attempts after reading Michael's
explainations.
> Such stuff typically goes into the probe() function. The modules's
> init() just registers the driver. Furthermore your global variables
> prohibit having more than one device instance using the driver.
Only one such device will ever be build, so don't expect a mainline kernel
patch from me anytime soon ! C;-)
> Also turn on CONFIG_DEBUG_DRIVER and see if that gives you anything
> interesting.
I see an unset CONFIG_DEBUG_KERNEL but no CONFIG_DEBUG_DRIVER in the .config of
my current kernel.
Does it need to be changed in the .config with a full kernel recompilation, or
can I still benefit from it in my module only by doing a #define at the begining
of my code ? Some #defines like DEBUG seem to work locally on things like
dev_dbg but I doubt the CONFIG_* work the same...
> Er. Not sure sorry. I can't see anything obviously wrong. Maybe post
> your driver code again.
Err... I ran it again this morning and it worked farther. I now get into the
probe function and can now register my interrupt, yeah!, but I don't see the
ISR being called. I'm currently checking if it can be a hardware problem
before coming back here for more questions !
BTW, is errno/strerror used within the kernel ?
Thanks all.
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-10 17:56 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, linuxppc-dev
In-Reply-To: <OF260A956E.E4DC084C-ONC12577F5.00456569-C12577F5.00457DC0@transmode.se>
On Fri, 10 Dec 2010 13:39:01 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2010/12/08 23:25:59:
> >
> > On Wed, 8 Dec 2010 17:02:45 -0500
> > Mark Mason <mason@postdiluvian.org> wrote:
> >
> > > I don't think that using a software NAND controller instead of the LBC
> > > FCM mode is all that bad. Again, I haven't actually done it, so check
> > > the MTD docs, but I'm pretty sure the software is meant to do that, so
> > > it doesn't even really constitute a "fix". Assuming that it is
> > > supported then I doubt that configuring the NAND layer to use your
> > > setup would be any harder than configuring the FCM.
> >
> > The MTD layer supports some really simple NAND controllers, but what do
> > you mean by not having a controller at all? Hooking everything up to
> > GPIO? Using UPM?
> >
> > There is already a UPM NAND driver, BTW.
> >
> > You would lose hardware ECC and the ability to be interrupt-driven (the
> > latter should be possible with SW changes, using GPIO interrupts).
>
> hmm, you think it would be possible to use one of the IRQ pins instead?
GPIO should be fine, software just needs to be changed to use the
interrupt functionality.
An external IRQ line would let you limit interrupts to rising edges
rather than all edges, though you'd lose the ability to directly read
the line status.
-Scott
^ permalink raw reply
* [PATCH -mm 2/4] RapidIO: Add device object linking into discovery
From: Alexandre Bounine @ 2010-12-10 20:38 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
In-Reply-To: <1292013498-31406-1-git-send-email-alexandre.bounine@idt.com>
Add setting links between rio_dev objects into the discovery process.
This needed to report device connections on agent (non-host) processors
that perform RIO discovery. Originally, these links have been introduced
for enumerating host only to support error management.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Cc: Micha Nelissen <micha@neli.hopto.org>
---
drivers/rapidio/rio-scan.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c
index 45d14cd..e655756 100644
--- a/drivers/rapidio/rio-scan.c
+++ b/drivers/rapidio/rio-scan.c
@@ -947,7 +947,7 @@ static int rio_enum_complete(struct rio_mport *port)
*/
static int __devinit
rio_disc_peer(struct rio_net *net, struct rio_mport *port, u16 destid,
- u8 hopcount)
+ u8 hopcount, struct rio_dev *prev, int prev_port)
{
u8 port_num, route_port;
struct rio_dev *rdev;
@@ -957,6 +957,9 @@ rio_disc_peer(struct rio_net *net, struct rio_mport *port, u16 destid,
if ((rdev = rio_setup_device(net, port, destid, hopcount, 0))) {
/* Add device to the global and bus/net specific list. */
list_add_tail(&rdev->net_list, &net->devices);
+ rdev->prev = prev;
+ if (prev && rio_is_switch(prev))
+ prev->rswitch->nextdev[prev_port] = rdev;
} else
return -1;
@@ -998,8 +1001,8 @@ rio_disc_peer(struct rio_net *net, struct rio_mport *port, u16 destid,
if (ndestid == RIO_ANY_DESTID(port->sys_size))
continue;
rio_unlock_device(port, destid, hopcount);
- if (rio_disc_peer
- (net, port, ndestid, hopcount + 1) < 0)
+ if (rio_disc_peer(net, port, ndestid,
+ hopcount + 1, rdev, port_num) < 0)
return -1;
}
}
@@ -1291,7 +1294,7 @@ int __devinit rio_disc_mport(struct rio_mport *mport)
mport->host_deviceid);
if (rio_disc_peer(net, mport, RIO_ANY_DESTID(mport->sys_size),
- 0) < 0) {
+ 0, NULL, 0) < 0) {
printk(KERN_INFO
"RIO: master port %d device has failed discovery\n",
mport->id);
--
1.7.3.1
^ permalink raw reply related
* [PATCH -mm 4/4] RapidIO: Add new sysfs attributes
From: Alexandre Bounine @ 2010-12-10 20:38 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
In-Reply-To: <1292013498-31406-1-git-send-email-alexandre.bounine@idt.com>
Add new sysfs attributes.
1. Routing information required to to reach the RIO device:
destid - device destination ID (real for for endpoint, route for switch)
hopcount - hopcount for maintenance requests (switches only)
2. device linking information:
lprev - name of device that precedes the given device in the enumeration
or discovery order (displayed along with of the port to which it
is attached).
lnext - names of devices (with corresponding port numbers) that are
attached to the given device as next in the enumeration or
discovery order (switches only)
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Cc: Micha Nelissen <micha@neli.hopto.org>
---
drivers/rapidio/rio-sysfs.c | 39 ++++++++++++++++++++++++++++++++++++++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/drivers/rapidio/rio-sysfs.c b/drivers/rapidio/rio-sysfs.c
index 76b4185..b8d9eaf 100644
--- a/drivers/rapidio/rio-sysfs.c
+++ b/drivers/rapidio/rio-sysfs.c
@@ -33,6 +33,8 @@ rio_config_attr(device_rev, "0x%08x\n");
rio_config_attr(asm_did, "0x%04x\n");
rio_config_attr(asm_vid, "0x%04x\n");
rio_config_attr(asm_rev, "0x%04x\n");
+rio_config_attr(destid, "0x%04x\n");
+rio_config_attr(hopcount, "0x%02x\n");
static ssize_t routes_show(struct device *dev, struct device_attribute *attr, char *buf)
{
@@ -52,6 +54,33 @@ static ssize_t routes_show(struct device *dev, struct device_attribute *attr, ch
return (str - buf);
}
+static ssize_t lprev_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct rio_dev *rdev = to_rio_dev(dev);
+
+ return sprintf(buf, "%02d %s\n", RIO_GET_PORT_NUM(rdev->swpinfo),
+ (rdev->prev) ? rio_name(rdev->prev) : "host");
+}
+
+static ssize_t lnext_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct rio_dev *rdev = to_rio_dev(dev);
+ char *str = buf;
+ int i;
+
+ if (rdev->pef & RIO_PEF_SWITCH) {
+ for (i = 0; i < RIO_GET_TOTAL_PORTS(rdev->swpinfo); i++) {
+ if (rdev->rswitch->nextdev[i])
+ str += sprintf(str, "%02d %s\n", i,
+ rio_name(rdev->rswitch->nextdev[i]));
+ }
+ }
+
+ return str - buf;
+}
+
struct device_attribute rio_dev_attrs[] = {
__ATTR_RO(did),
__ATTR_RO(vid),
@@ -59,10 +88,14 @@ struct device_attribute rio_dev_attrs[] = {
__ATTR_RO(asm_did),
__ATTR_RO(asm_vid),
__ATTR_RO(asm_rev),
+ __ATTR_RO(lprev),
+ __ATTR_RO(destid),
__ATTR_NULL,
};
static DEVICE_ATTR(routes, S_IRUGO, routes_show, NULL);
+static DEVICE_ATTR(lnext, S_IRUGO, lnext_show, NULL);
+static DEVICE_ATTR(hopcount, S_IRUGO, hopcount_show, NULL);
static ssize_t
rio_read_config(struct file *filp, struct kobject *kobj,
@@ -218,7 +251,9 @@ int rio_create_sysfs_dev_files(struct rio_dev *rdev)
err = device_create_bin_file(&rdev->dev, &rio_config_attr);
if (!err && (rdev->pef & RIO_PEF_SWITCH)) {
- err = device_create_file(&rdev->dev, &dev_attr_routes);
+ err |= device_create_file(&rdev->dev, &dev_attr_routes);
+ err |= device_create_file(&rdev->dev, &dev_attr_lnext);
+ err |= device_create_file(&rdev->dev, &dev_attr_hopcount);
if (!err && rdev->rswitch->sw_sysfs)
err = rdev->rswitch->sw_sysfs(rdev, RIO_SW_SYSFS_CREATE);
}
@@ -241,6 +276,8 @@ void rio_remove_sysfs_dev_files(struct rio_dev *rdev)
device_remove_bin_file(&rdev->dev, &rio_config_attr);
if (rdev->pef & RIO_PEF_SWITCH) {
device_remove_file(&rdev->dev, &dev_attr_routes);
+ device_remove_file(&rdev->dev, &dev_attr_lnext);
+ device_remove_file(&rdev->dev, &dev_attr_hopcount);
if (rdev->rswitch->sw_sysfs)
rdev->rswitch->sw_sysfs(rdev, RIO_SW_SYSFS_REMOVE);
}
--
1.7.3.1
^ permalink raw reply related
* [PATCH -mm 0/4] RapidIO: Misc updates
From: Alexandre Bounine @ 2010-12-10 20:38 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
The following four patches are follow-up to two RapidIO patches
that are in the -mm tree now.
Alexandre Bounine (4):
RapidIO: Add definitions of Component Tag fields
RapidIO: Add device object linking into discovery
RapidIO: Use Component Tag for unified switch identification
RapidIO: Add new sysfs attributes
drivers/rapidio/rio-scan.c | 21 ++++++++++++---------
drivers/rapidio/rio-sysfs.c | 39 ++++++++++++++++++++++++++++++++++++++-
drivers/rapidio/rio.c | 2 +-
include/linux/rio.h | 10 ++++++++++
4 files changed, 61 insertions(+), 11 deletions(-)
--
1.7.3.1
^ permalink raw reply
* [PATCH -mm 1/4] RapidIO: Add definitions of Component Tag fields
From: Alexandre Bounine @ 2010-12-10 20:38 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
In-Reply-To: <1292013498-31406-1-git-send-email-alexandre.bounine@idt.com>
Add definition of the unique device identifier field in the component tag.
RIO_CTAG_UDEVID does not take all 32 bits of the component tag value to
allow future extensions to the component tag use.
Selected size of the RIO_CTAG_UDEVID field (17 bits) is sufficient to accommodate
maximum number of endpoints in large RIO network (16-bit id) plus switches.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Cc: Micha Nelissen <micha@neli.hopto.org>
---
drivers/rapidio/rio.c | 2 +-
include/linux/rio.h | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index c13289e..cc2a3b7 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -710,7 +710,7 @@ int rio_inb_pwrite_handler(union rio_pw_msg *pw_msg)
u32 err_status, em_perrdet, em_ltlerrdet;
int rc, portnum;
- rdev = rio_get_comptag(pw_msg->em.comptag, NULL);
+ rdev = rio_get_comptag((pw_msg->em.comptag & RIO_CTAG_UDEVID), NULL);
if (rdev == NULL) {
/* Device removed or enumeration error */
pr_debug("RIO: %s No matching device for CTag 0x%08x\n",
diff --git a/include/linux/rio.h b/include/linux/rio.h
index 9b55885..ff681eb 100644
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -66,6 +66,16 @@
#define RIO_PW_MSG_SIZE 64
+/*
+ * A component tag value (stored in the component tag CSR) is used as device's
+ * unique identifier assigned during enumeration. Besides being used for
+ * identifying switches (which do not have device ID register), it also is used
+ * by error management notification and therefore has to be assigned
+ * to endpoints as well.
+ */
+#define RIO_CTAG_RESRVD 0xfffe0000 /* Reserved */
+#define RIO_CTAG_UDEVID 0x0001ffff /* Unique device identifier */
+
extern struct bus_type rio_bus_type;
extern struct device rio_bus;
extern struct list_head rio_devices; /* list of all devices */
--
1.7.3.1
^ permalink raw reply related
* [PATCH -mm 3/4] RapidIO: Use Component Tag for unified switch identification
From: Alexandre Bounine @ 2010-12-10 20:38 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
In-Reply-To: <1292013498-31406-1-git-send-email-alexandre.bounine@idt.com>
Change the way how switchid value is set. Local counter variable does not
provide unified way to identify switch devices in a system with multiple
processors. Using local counter leads to the situation when the same RIO
switch has different switch ID for each processor. Replacing local counter
with unique portion of the Component Tag provides unified reference to the
switch by every processor in the system.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Cc: Micha Nelissen <micha@neli.hopto.org>
---
drivers/rapidio/rio-scan.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c
index e655756..467e82b 100644
--- a/drivers/rapidio/rio-scan.c
+++ b/drivers/rapidio/rio-scan.c
@@ -46,7 +46,6 @@ static void rio_init_em(struct rio_dev *rdev);
DEFINE_SPINLOCK(rio_global_list_lock);
static int next_destid = 0;
-static int next_switchid = 0;
static int next_net = 0;
static int next_comptag = 1;
@@ -438,6 +437,10 @@ static struct rio_dev __devinit *rio_setup_device(struct rio_net *net,
rio_mport_write_config_32(port, destid, hopcount,
RIO_COMPONENT_TAG_CSR, next_comptag);
rdev->comp_tag = next_comptag++;
+ } else {
+ rio_mport_read_config_32(port, destid, hopcount,
+ RIO_COMPONENT_TAG_CSR,
+ &rdev->comp_tag);
}
if (rio_device_has_destid(port, rdev->src_ops, rdev->dst_ops)) {
@@ -461,7 +464,7 @@ static struct rio_dev __devinit *rio_setup_device(struct rio_net *net,
/* If a PE has both switch and other functions, show it as a switch */
if (rio_is_switch(rdev)) {
rswitch = rdev->rswitch;
- rswitch->switchid = next_switchid;
+ rswitch->switchid = rdev->comp_tag & RIO_CTAG_UDEVID;
rswitch->port_ok = 0;
rswitch->route_table = kzalloc(sizeof(u8)*
RIO_MAX_ROUTE_ENTRIES(port->sys_size),
@@ -816,7 +819,6 @@ static int __devinit rio_enum_peer(struct rio_net *net, struct rio_mport *port,
return -1;
if (rio_is_switch(rdev)) {
- next_switchid++;
sw_inport = RIO_GET_PORT_NUM(rdev->swpinfo);
rio_route_add_entry(rdev, RIO_GLOBAL_TABLE,
port->host_deviceid, sw_inport, 0);
@@ -964,8 +966,6 @@ rio_disc_peer(struct rio_net *net, struct rio_mport *port, u16 destid,
return -1;
if (rio_is_switch(rdev)) {
- next_switchid++;
-
/* Associated destid is how we accessed this switch */
rdev->destid = destid;
--
1.7.3.1
^ permalink raw reply related
* [PATCH] RapidIO: Add new IDT sRIO switches
From: Alexandre Bounine @ 2010-12-10 21:52 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev; +Cc: Alexandre Bounine, Thomas Moll
Add new sRIO switch device IDs and enable a basic support for them.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Cc: Micha Nelissen <micha@neli.hopto.org>
---
drivers/rapidio/switches/idt_gen2.c | 2 ++
include/linux/rio_ids.h | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/rapidio/switches/idt_gen2.c b/drivers/rapidio/switches/idt_gen2.c
index dd4b2b7..095016a 100644
--- a/drivers/rapidio/switches/idt_gen2.c
+++ b/drivers/rapidio/switches/idt_gen2.c
@@ -416,3 +416,5 @@ static int idtg2_switch_init(struct rio_dev *rdev, int do_enum)
DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1848, idtg2_switch_init);
DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1616, idtg2_switch_init);
+DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTVPS1616, idtg2_switch_init);
+DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTSPS1616, idtg2_switch_init);
diff --git a/include/linux/rio_ids.h b/include/linux/rio_ids.h
index ee7b6ad..7410d33 100644
--- a/include/linux/rio_ids.h
+++ b/include/linux/rio_ids.h
@@ -36,5 +36,7 @@
#define RIO_DID_IDTCPS10Q 0x035e
#define RIO_DID_IDTCPS1848 0x0374
#define RIO_DID_IDTCPS1616 0x0379
+#define RIO_DID_IDTVPS1616 0x0377
+#define RIO_DID_IDTSPS1616 0x0378
#endif /* LINUX_RIO_IDS_H */
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH V6 09/10] USB/ppc4xx:Synopsys DWC OTG driver enable gadget support
From: Greg KH @ 2010-12-10 22:13 UTC (permalink / raw)
To: Tirumala Marri
Cc: Mark Miesfeld, linux-usb, linuxppc-dev, Fushen Chen,
Sergei Shtylyov
In-Reply-To: <AANLkTimp8iF2PxApA2kXF64TM47_EeGM9BZrfi1uEVJj@mail.gmail.com>
On Thu, Dec 09, 2010 at 08:52:45AM -0800, Tirumala Marri wrote:
> On Thu, Dec 9, 2010 at 5:24 AM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> > Hello.
> >
> > On 09-12-2010 3:32, tmarri@apm.com wrote:
> >
> >> From: Tirumala Marri<tmarri@apm.com>
> >
> >> Enable gadget support
> >
> >> Signed-off-by: Tirumala R Marri<tmarri@apm.com>
> >> Signed-off-by: Fushen Chen<fchen@apm.com>
> >> Signed-off-by: Mark Miesfeld<mmiesfeld@apm.com>
> >
> > [...]
> >
> >> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> >> index 747b0d3..b2bcc4e 100644
> >> --- a/drivers/usb/gadget/Kconfig
> >> +++ b/drivers/usb/gadget/Kconfig
> >> @@ -365,6 +365,28 @@ config USB_GADGET_MUSB_HDRC
> >
> > [...]
> >>
> >> +config USB_OTG
> >> + boolean "OTG Support"
> >
> > This symbol is already defined in drivers/usb/core/Kconfig.
> >
> > WBR, Sergei
> >
> Sure I will fix that.
Other than this minor thing, the patches look good. I'll go apply
patches 1-8 for now, care to resend 9 and 10 with this change made?
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox