* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2011-01-05 21:58 UTC (permalink / raw)
To: Scott Wood; +Cc: Blanchard, Hollis, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110103135120.32aeb60d@udp111988uds.am.freescale.net>
On 01/03/2011 01:51 PM, Scott Wood wrote:
> On Thu, 23 Dec 2010 15:33:25 -0700
> Grant Likely<grant.likely@secretlab.ca> wrote:
>
>> On Thu, Dec 23, 2010 at 03:49:54PM -0600, Meador Inge wrote:
>>> How do you
>>> see this working in terms of processing the data? It seems like we
>>> are going to have to be aware of N values instead of 1, which seems
>>> worse.
>>
>> This argument has been rehashed many times, but it basically comes
>> down to compatible values should ideally be anchored to a real
>> implemented device, not to a family of devices, or to an unversioned
>> specification.
>
> Freescale MPICs do have version numbers (version registers, even). We
> should put that version (possibly along with a compatible version) in
> the compatible, though, for blocks such as this which don't include the
> main MPIC registers and thus the version registers.
I like that better than claiming compatibility with other chips. I will
incorporate that idea. Thanks.
>> In practise, the implementation doesn't actually look any different
>> except that the 'reference' version specifies a specific
>> implementation instead of a generic name. To use a concrete example,
>> if there are two parts using this MPIC, like the freescale p2040 and
>> p4080, and say for argument that the p2040 was implemented first, then
>> the compatible values would look like:
>>
>> for the p2040: compatible = "fsl,p2040-msgr";
>> for the p4080: compatible = "fsl,p4080-msgr", "fsl,p2040-msgr";
>
> While I don't think it affected the message unit, p4080 rev 1 has a
> different version of the MPIC from p4080 rev 2 (4.0 versus 4.1, IIRC).
>
> I don't think "mpic-" should be dropped, whether a specific chip is
> added or not. "msgr" just seems too generic, and "mpic-" tells the
> reader where in the chip manual they can find information about it.
Agreed.
>>>> ? This needs some more explanation. cell-index often gets abused as
>>>> a way to enumerate devices. Typically, the address of the device
>>>> itself is sufficient to identify the device.
>>>
>>> The message registers typically come in blocks of four memory mapped
>>> registers and may not be in contiguous memory (example [3]). The
>>> intent of 'cell-index' is to put an ordering on the blocks (so, yes,
>>> enumeration). We could order them by address as well I suppose.
>>> One less property to worry about :)
>
> But why do we care about ordering them? What's important is just that
> you use the same one on both the sending partition and the receiving
> partition.
We need some sort of mapping between a message register and a message
register number so that the message registers can be referenced through
some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that would
be by putting an order on the registers. Maybe there is a better way,
though ...
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2011-01-05 21:19 UTC (permalink / raw)
To: Scott Wood; +Cc: Blanchard, Hollis, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110104181346.2a9ab036@udp111988uds.am.freescale.net>
On 01/04/2011 06:13 PM, Scott Wood wrote:
> On Tue, 4 Jan 2011 17:52:38 -0600
> Meador Inge<meador_inge@mentor.com> wrote:
>
>> Thanks for the feedback Scott.
>>
>> On 01/03/2011 02:22 PM, Scott Wood wrote:
>>> On Wed, 22 Dec 2010 23:58:09 -0600
>>> These nodes cannot go under the mpic node, because interrupt
>>> controllers need #address-cells =<0>.
>>
>> Good point. Do they actually need it or is that just the way it
>> currently is? [1] mandates it, I didn't see anything in [2] and I can't
>> access [3].
>
> It's because of the way interrupt maps work -- a full interrupt
> specifier includes the node's reg address as well as the values in the
> interrupts property. This is useful for things like PCI controllers,
> but normal interrupt controllers won't have any use for it.
>
> In theory, I suppose you could have a non-zero #address-cells in an
> interrupt controller, but then you'd have to pad the parent interrupt
> specifiers in any interrupt map entries that point at the MPIC node with
> that many don't-care cells.
>
> Better to just avoid the issue.
Agreed, it would be nasty to have padding for this.
>> However, AFAIK '#address-cells' is taken directly from the parent node
>> and is not inherited from ancestors higher in the tree. So another
>> option would be to do something like:
>>
>> mpic: pic@40000 {
>> ...
>> message-registers@0 {
>> #address-cells =<1>;
>> #size-cells =<1>;
>>
>> msgr@1400 {
>> compatible = "fsl,mpic-v3.0-msgr";
>> reg =<0x1400 0x200>;
>> interrupts =<0xb0 0x2 0xb1 0x2 0xb2 0x2 0xb3 0x2>;
>> };
>>
>> msgr@2400 {
>> compatible = "fsl,mpic-v3.0-msgr";
>> reg =<0x2400 0x200>;
>> interrupts =<0xb4 0x2 0xb5 0x2 0xb6 0x2 0xb7 0x2>;
>> };
>> };
>> };
>
> Won't work, the reg addresses need to be translatable through ranges all
> the way up to the root.
Ah, I see. This is because we would have to add 'ranges' on
'message-registers' and 'pic', but 'pic' needs to have '#address-cells'
> 0 to interpret 'ranges'. Fun :) I will hoist the message registers
nodes out of the MPIC node.
>> I like the nesting as it models the physical relationship closer and
>> creates a clean namespace.
>
> Sure, if it weren't for the #address-cells issue I'd agree.
>
>>> It would be nice if the binding provided some way of partitioning
>>> up individual message interrupts within a block.
>>>
>>> Interrupt generation could be exported as a "service", similar to
>>> (inbound) interrupts and gpios.
>>>
>>> Perhaps a something like this, with "doorbell" being a new standard
>>> hw-independent service with its own binding:
>>
>> I need to think about this proposal more, but our original intent was to
>> just have a simple description of the message registers in the device
>> tree and the policy for how those message registers are used is in
>> software (not necessarily an exact API use case, but you get the point):
>
> That may be fine for your use case (just as some people may be happy
> to hardcode device knowledge into their kernel), but in the general case
> inter-partition protocols are effectively a non-probeable part of the
> "hardware" the partition runs on. It's good to have a standard way of
> labelling what goes where. The details of the protocol would still be
> in software, referenced by the compatible string on the protocol node.
>
>> /* Core 0 */
>> mpic_msgr_reserve(0);
>> mpic_msgr_reserve(1);
>>
>> /* Send message to Core 1 */
>> mpic_msgr_write(3, 13);
>>
>> /* Read a value */
>> u32 value;
>> mpic_msgr_read(0,&value);
>>
>> /* Free the register */
>> mpic_msgr_release(0);
>> ...
>>
>> /* Core 1 */
>> mpic_msgr_reserve(3);
>> mpic_msgr_reserve(4);
>>
>> /* Send message to Core 0 */
>> mpic_msgr_write(0, 1);
>
> You're hardcoding into software that core 0 gets msg0 and msg1, and
> core 1 gets msg3 and msg4, etc. Not much different than hardcoding that
> core 0 gets enet0 and core 1 gets enet1 and enet2.
>
>> Note that a "reservation" is still isolated to a particular core, e.g.
>> 'mpic_msgr_reserve(0)' on core 0 will not cause 'mpic_msgr_reserve(0)'
>> to fail on another core. Where as two invocations of
>> 'mpic_msgr_reserve(0)' on the same core without an interleaved
>> 'mpic_msgr_release(0)' would, of course, fail.
>
> So basically, you're assigning the resource to both partitions, and
> relying on dynamic cooperation. That's fine, in that case both
> partitions would see the resource in their device tree, hopefully along
> with something to indicate what the situation is. But dedicated
> ownership is common enough, and similar enough to the question of
> whether the hardware exists at all, that it's nice to be able to express
> it in the device tree. It also makes it easier to deal with situations
> where you later want to plug in different hardware (or possibly a
> virtualized interface) underneath the protocol.
I agree that it would be nice to have some elements of the protocol
represented in the device tree. I would just like to do this in small
steps. We are going to need the data in the device tree for the message
registers no matter what. We are also going to need a simple API for
interfacing with the registers. The bottom layer so to speak. These
building blocks can be utilized later by a higher-level protocol if need
be. For now I would just like to propose the MPIC bindings, the initial
message register bindings, and the message registers API. Sound good?
> I'm not sure how much practical benefit there is to dynamically
> allocating message registers across partitions, though -- you'd have
> to have some way of communicating to the other end the result of the
> allocation, so it knows which one to send a message on. And if you
> only have 2 cores, and unhypervised AMP, you'll be able to dedicate 4
> message registers to each partition...
Hollis and I discussed that a bit already. The problem with our use
case (and presumably others) is that we are using the message registers
to aid in communicating over shared memory. If we go into dynamic
allocation of message registers across partitions, then we need to
coordinate between the partitions across shared memory. So you need
shared memory communication to setup shared memory communication. Also,
if we just get the basic pieces in place with the message register API
('reserve', 'release', 'read', 'write', etc...) we can perhaps figure
out a way to build a dynamically allocator on top of those services
later, if need be.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-05 18:23 UTC (permalink / raw)
To: Rafael Beims; +Cc: linuxppc-dev
In-Reply-To: <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1758 bytes --]
Hi
On 01/05/2011 07:09 PM, Rafael Beims wrote:
> Hello all,
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.
> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).
> Monitoring the network packets, I can see that the nfs protocol is exchanged
> just fine, but at some time it simply stops, starting again with a request
> from the board several seconds later.
> I'm thinking that the processor is running (something, I don't know what)
> for all this time before I can see requests coming from the board again. I
> pinged the board from the PC and during all this I can see the packets being
> answered.
>
Can you try this patch?
> My question to all is, did anyone see something like this already? Besides
> that, what is the status of the linux kernel support for the 8xx platform?
> Is it being actively tested / used today? I ask this because it seems that
> all the information on the internet very aged (forum discussions from 2005
> and below mostly).
>
> Is there something that I can do to try to narrow the cause of the problem?
>
> Anyway, any help would be truly appreciated. Please excuse me if this is not
> the right place to ask this too.
>
> Thanks and best regards,
> Rafael Beims
> rbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #1.2: Type: text/html, Size: 2624 bytes --]
[-- Attachment #2: slowdown.patch --]
[-- Type: text/x-diff, Size: 2703 bytes --]
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index dd5ea95..cb67076 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -32,7 +32,7 @@
#define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
#define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
-#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
+#define _PAGE_SPECIAL 0x0000 /* SW entry, forced to 0 by the TLB miss */
/* These five software bits must be masked out when the entry is loaded
* into the TLB.
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index f2b3701..3b88376 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -176,5 +176,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
#define HAVE_PAGE_AGP
/* Advertise support for _PAGE_SPECIAL */
+#if _PAGE_SPECIAL != 0
#define __HAVE_ARCH_PTE_SPECIAL
+#endif
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 5304093..1da03a8 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
if (pte_looks_normal(pte) && !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
cpu_has_feature(CPU_FTR_NOEXECUTE))) {
- struct page *pg = maybe_pte_to_page(pte);
- if (!pg)
+ unsigned long pfn = pte_pfn(pte);
+ struct page *pg;
+
+ if (unlikely(!pfn_valid(pfn)))
return pte;
- if (!test_bit(PG_arch_1, &pg->flags)) {
+
+ pg = pfn_to_page(pfn);
#ifdef CONFIG_8xx
- /* On 8xx, cache control instructions (particularly
- * "dcbst" from flush_dcache_icache) fault as write
- * operation if there is an unpopulated TLB entry
- * for the address in question. To workaround that,
- * we invalidate the TLB here, thus avoiding dcbst
- * misbehaviour.
- */
- /* 8xx doesn't care about PID, size or ind args */
- _tlbil_va(addr, 0, 0, 0);
+ /* On 8xx, cache control instructions (particularly
+ * "dcbst" from flush_dcache_icache) fault as write
+ * operation if there is an unpopulated TLB entry
+ * for the address in question. To workaround that,
+ * we invalidate the TLB here, thus avoiding dcbst
+ * misbehaviour.
+ */
+ /* 8xx doesn't care about PID, size or ind args */
+ _tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */
+
+ if (!pg)
+ return pte;
+
+ if (!PageReserved(pg) && !test_bit(PG_arch_1, &pg->flags)) {
flush_dcache_icache_page(pg);
set_bit(PG_arch_1, &pg->flags);
}
^ permalink raw reply related
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-05 19:22 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Rafael Beims, linuxppc-dev
In-Reply-To: <20110105183506.07BB815243A@gemini.denx.de>
Hi
On 01/05/2011 07:35 PM, Wolfgang Denk wrote:
> Dear Rafael Beims,
>
> In message<AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com> you wrote:
>> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
>> some work, I could get the kernel up and running, mounting a rootfs via
>> NFS.
> 2.6.32 is pretty old. Is there any specific reason for not using a
> recent kernel version?
>
I think that all the kernel version has the same problem
>> The problem that I'm facing now is that when I try to run any process (may
>> be an ls, cat, or whatever), the response of the process is *very* slow
>> (something like 10 to 20 seconds for a ls).
> This sounds as if only the output to the (serial ?) console port was
> slow - typically this happens when there is a problem with interrupt
> assignment, and you receive charatcers only after each of these times
> out.
>
It is not a serial/console/interrupt problem
>> My question to all is, did anyone see something like this already? Besides
> We have seen this many times in the past, when interrupts were not
> working correctly. I recommend to check youyr device tree settings
> for these.
>
> [It would have helped if you had included a log of your kernel's boot
> messages.]
>
>> that, what is the status of the linux kernel support for the 8xx platform?
> It is working and actively maintained, but 8xx is a platform that is
> more or less hopelessly obsoleted - nobody uses it in new designs any
> more, so there is little work going on with it in recent kernel
> versions (at least compared with other architectures).
>
agree, this architecture is basically dead
>> Is it being actively tested / used today? I ask this because it seems that
> Yes, it is.
>
>> all the information on the internet very aged (forum discussions from 2005
>> and below mostly).
>> Is there something that I can do to try to narrow the cause of the problem?
> Check your interrupts.
>
> Best regards,
>
> Wolfgang Denk
>
Michael Trimarchi
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-05 19:13 UTC (permalink / raw)
To: Rafael Beims; +Cc: LinuxPPC-Dev
In-Reply-To: <AANLkTi=uvunJ-ZFVGHZZExgBaNL9Sh0uZ3OiiCrcPnx=@mail.gmail.com>
Hi
On 01/05/2011 07:43 PM, Rafael Beims wrote:
> Wow! That was fast!
> I applied the patch and it worked very well. Now I can use the commands
> normally.
> I will be doing more tests in the next days, but it seems that my problem is
> solved.
>
> Is this patch already mainstream in newer kernel versions?
>
Not yet, because I was moved to another project
Michael Trimarchi
> Thanks again,
> Rafael Beims
> rbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
> On Wed, Jan 5, 2011 at 4:23 PM, michael<michael@evidence.eu.com> wrote:
>
>> Hi
>>
>> On 01/05/2011 07:09 PM, Rafael Beims wrote:
>>
>> Hello all,
>> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
>> some work, I could get the kernel up and running, mounting a rootfs via
>> NFS.
>> The problem that I'm facing now is that when I try to run any process (may
>> be an ls, cat, or whatever), the response of the process is *very* slow
>> (something like 10 to 20 seconds for a ls).
>> Monitoring the network packets, I can see that the nfs protocol is exchanged
>> just fine, but at some time it simply stops, starting again with a request
>> from the board several seconds later.
>> I'm thinking that the processor is running (something, I don't know what)
>> for all this time before I can see requests coming from the board again. I
>> pinged the board from the PC and during all this I can see the packets being
>> answered.
>>
>>
>> Can you try this patch?
>>
>> My question to all is, did anyone see something like this already? Besides
>> that, what is the status of the linux kernel support for the 8xx platform?
>> Is it being actively tested / used today? I ask this because it seems that
>> all the information on the internet very aged (forum discussions from 2005
>> and below mostly).
>>
>> Is there something that I can do to try to narrow the cause of the problem?
>>
>> Anyway, any help would be truly appreciated. Please excuse me if this is not
>> the right place to ask this too.
>>
>> Thanks and best regards,
>> Rafael Beimsrbeims@gmail.com
>> (41) 8873-7565
>> "What I hear, I forget. What I see, I remember. And what I do, I
>> understand."
>> - Chinese Proverb
>>
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-05 18:50 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20110105183506.07BB815243A@gemini.denx.de>
Hello Mr. Denk
As I already posted, the patch that was posted before seems to have
solved the problem. Anyway, some answers follow:
On Wed, Jan 5, 2011 at 4:35 PM, Wolfgang Denk <wd@denx.de> wrote:
>
> Dear Rafael Beims,
>
> In message <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com>=
you wrote:
> >
> > I'm working with an MPC880 board that is supposed to run linux-2.6.32. =
After
> > some work, I could get the kernel up and running, mounting a rootfs via
> > NFS.
>
> 2.6.32 is pretty old. =A0Is there any specific reason for not using a
> recent kernel version?
>
The company that I work for uses some kernel versions in favor of
others... Maybe with time we can change that, but for now I need to
use this version.
> > The problem that I'm facing now is that when I try to run any process (=
may
> > be an ls, cat, or whatever), the response of the process is *very* slow
> > (something like 10 to 20 seconds for a ls).
>
> This sounds as if only the output to the (serial ?) console port was
> slow - typically this happens when there is a problem with interrupt
> assignment, and you receive charatcers only after each of these times
> out.
>
> > My question to all is, did anyone see something like this already? Besi=
des
>
> We have seen this many times in the past, when interrupts were not
> working correctly. =A0I recommend to check youyr device tree settings
> for these.
>
> [It would have helped if you had included a log of your kernel's boot
> messages.]
>
> > that, what is the status of the linux kernel support for the 8xx platfo=
rm?
>
> It is working and actively maintained, but 8xx is a platform that is
> more or less hopelessly obsoleted - nobody uses it in new designs any
> more, so there is little work going on with it in recent kernel
> versions (at least compared with other architectures).
>
> > Is it being actively tested / used today? I ask this because it seems t=
hat
>
> Yes, it is.
This is very nice, because this way we can be more confident that
everything will work as it should.
>
> > all the information on the internet very aged (forum discussions from 2=
005
> > and below mostly).
>
> > Is there something that I can do to try to narrow the cause of the prob=
lem?
>
> Check your interrupts.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> Never underestimate the power of human stupidity =A0when =A0it =A0comes =
=A0to
> using technology they don't understand.
Thank you very much for the answers!
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I understand=
."
- Chinese Proverb
^ permalink raw reply
* Fwd: mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-05 18:45 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTi=uvunJ-ZFVGHZZExgBaNL9Sh0uZ3OiiCrcPnx=@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2494 bytes --]
I forgot to copy the list, sorry...
---------- Forwarded message ----------
From: Rafael Beims <rbeims@gmail.com>
Date: Wed, Jan 5, 2011 at 4:43 PM
Subject: Re: mpc880 linux-2.6.32 slow running processes
To: michael <michael@evidence.eu.com>
Wow! That was fast!
I applied the patch and it worked very well. Now I can use the commands
normally.
I will be doing more tests in the next days, but it seems that my problem is
solved.
Is this patch already mainstream in newer kernel versions?
Thanks again,
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I
understand."
- Chinese Proverb
On Wed, Jan 5, 2011 at 4:23 PM, michael <michael@evidence.eu.com> wrote:
> Hi
>
> On 01/05/2011 07:09 PM, Rafael Beims wrote:
>
> Hello all,
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.
> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).
> Monitoring the network packets, I can see that the nfs protocol is exchanged
> just fine, but at some time it simply stops, starting again with a request
> from the board several seconds later.
> I'm thinking that the processor is running (something, I don't know what)
> for all this time before I can see requests coming from the board again. I
> pinged the board from the PC and during all this I can see the packets being
> answered.
>
>
> Can you try this patch?
>
> My question to all is, did anyone see something like this already? Besides
> that, what is the status of the linux kernel support for the 8xx platform?
> Is it being actively tested / used today? I ask this because it seems that
> all the information on the internet very aged (forum discussions from 2005
> and below mostly).
>
> Is there something that I can do to try to narrow the cause of the problem?
>
> Anyway, any help would be truly appreciated. Please excuse me if this is not
> the right place to ask this too.
>
> Thanks and best regards,
> Rafael Beimsrbeims@gmail.com
> (41) 8873-7565
> "What I hear, I forget. What I see, I remember. And what I do, I
> understand."
> - Chinese Proverb
>
>
>
> _______________________________________________
> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>
[-- Attachment #2: Type: text/html, Size: 3732 bytes --]
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Wolfgang Denk @ 2011-01-05 18:35 UTC (permalink / raw)
To: Rafael Beims; +Cc: linuxppc-dev
In-Reply-To: <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com>
Dear Rafael Beims,
In message <AANLkTin5XTnDEu1BJUOeF0UWtfEpotW5Bq__i8g6U05h@mail.gmail.com> you wrote:
>
> I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
> some work, I could get the kernel up and running, mounting a rootfs via
> NFS.
2.6.32 is pretty old. Is there any specific reason for not using a
recent kernel version?
> The problem that I'm facing now is that when I try to run any process (may
> be an ls, cat, or whatever), the response of the process is *very* slow
> (something like 10 to 20 seconds for a ls).
This sounds as if only the output to the (serial ?) console port was
slow - typically this happens when there is a problem with interrupt
assignment, and you receive charatcers only after each of these times
out.
> My question to all is, did anyone see something like this already? Besides
We have seen this many times in the past, when interrupts were not
working correctly. I recommend to check youyr device tree settings
for these.
[It would have helped if you had included a log of your kernel's boot
messages.]
> that, what is the status of the linux kernel support for the 8xx platform?
It is working and actively maintained, but 8xx is a platform that is
more or less hopelessly obsoleted - nobody uses it in new designs any
more, so there is little work going on with it in recent kernel
versions (at least compared with other architectures).
> Is it being actively tested / used today? I ask this because it seems that
Yes, it is.
> all the information on the internet very aged (forum discussions from 2005
> and below mostly).
> Is there something that I can do to try to narrow the cause of the problem?
Check your interrupts.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Never underestimate the power of human stupidity when it comes to
using technology they don't understand.
^ permalink raw reply
* mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-05 18:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
Hello all,
I'm working with an MPC880 board that is supposed to run linux-2.6.32. After
some work, I could get the kernel up and running, mounting a rootfs via
NFS.
The problem that I'm facing now is that when I try to run any process (may
be an ls, cat, or whatever), the response of the process is *very* slow
(something like 10 to 20 seconds for a ls).
Monitoring the network packets, I can see that the nfs protocol is exchanged
just fine, but at some time it simply stops, starting again with a request
from the board several seconds later.
I'm thinking that the processor is running (something, I don't know what)
for all this time before I can see requests coming from the board again. I
pinged the board from the PC and during all this I can see the packets being
answered.
My question to all is, did anyone see something like this already? Besides
that, what is the status of the linux kernel support for the 8xx platform?
Is it being actively tested / used today? I ask this because it seems that
all the information on the internet very aged (forum discussions from 2005
and below mostly).
Is there something that I can do to try to narrow the cause of the problem?
Anyway, any help would be truly appreciated. Please excuse me if this is not
the right place to ask this too.
Thanks and best regards,
Rafael Beims
rbeims@gmail.com
(41) 8873-7565
"What I hear, I forget. What I see, I remember. And what I do, I
understand."
- Chinese Proverb
[-- Attachment #2: Type: text/html, Size: 1703 bytes --]
^ permalink raw reply
* Re: powerpc: Per process DSCR
From: Alexey Kardashevskiy @ 2011-01-05 7:21 UTC (permalink / raw)
To: linuxppc-dev
joining the thread...
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
^ permalink raw reply
* Re: powerpc: Per process DSCR
From: Alexey Kardashevskiy @ 2011-01-05 7:01 UTC (permalink / raw)
To: linuxppc-dev
joining the thread...
--
Alexey Kardashevskiy
IBM OzLabs, LTC Team
e-mail/sametime: aik@au1.ibm.com
notes: Alexey Kardashevskiy/Australia/IBM
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Scott Wood @ 2011-01-05 0:13 UTC (permalink / raw)
To: Meador Inge; +Cc: Blanchard, Hollis, devicetree-discuss, linuxppc-dev
In-Reply-To: <4D23B2C6.8050607@mentor.com>
On Tue, 4 Jan 2011 17:52:38 -0600
Meador Inge <meador_inge@mentor.com> wrote:
> Thanks for the feedback Scott.
>
> On 01/03/2011 02:22 PM, Scott Wood wrote:
> > On Wed, 22 Dec 2010 23:58:09 -0600
> > These nodes cannot go under the mpic node, because interrupt
> > controllers need #address-cells =<0>.
>
> Good point. Do they actually need it or is that just the way it
> currently is? [1] mandates it, I didn't see anything in [2] and I can't
> access [3].
It's because of the way interrupt maps work -- a full interrupt
specifier includes the node's reg address as well as the values in the
interrupts property. This is useful for things like PCI controllers,
but normal interrupt controllers won't have any use for it.
In theory, I suppose you could have a non-zero #address-cells in an
interrupt controller, but then you'd have to pad the parent interrupt
specifiers in any interrupt map entries that point at the MPIC node with
that many don't-care cells.
Better to just avoid the issue.
> However, AFAIK '#address-cells' is taken directly from the parent node
> and is not inherited from ancestors higher in the tree. So another
> option would be to do something like:
>
> mpic: pic@40000 {
> ...
> message-registers@0 {
> #address-cells = <1>;
> #size-cells = <1>;
>
> msgr@1400 {
> compatible = "fsl,mpic-v3.0-msgr";
> reg = <0x1400 0x200>;
> interrupts = <0xb0 0x2 0xb1 0x2 0xb2 0x2 0xb3 0x2>;
> };
>
> msgr@2400 {
> compatible = "fsl,mpic-v3.0-msgr";
> reg = <0x2400 0x200>;
> interrupts = <0xb4 0x2 0xb5 0x2 0xb6 0x2 0xb7 0x2>;
> };
> };
> };
Won't work, the reg addresses need to be translatable through ranges all
the way up to the root.
> I like the nesting as it models the physical relationship closer and
> creates a clean namespace.
Sure, if it weren't for the #address-cells issue I'd agree.
> > It would be nice if the binding provided some way of partitioning
> > up individual message interrupts within a block.
> >
> > Interrupt generation could be exported as a "service", similar to
> > (inbound) interrupts and gpios.
> >
> > Perhaps a something like this, with "doorbell" being a new standard
> > hw-independent service with its own binding:
>
> I need to think about this proposal more, but our original intent was to
> just have a simple description of the message registers in the device
> tree and the policy for how those message registers are used is in
> software (not necessarily an exact API use case, but you get the point):
That may be fine for your use case (just as some people may be happy
to hardcode device knowledge into their kernel), but in the general case
inter-partition protocols are effectively a non-probeable part of the
"hardware" the partition runs on. It's good to have a standard way of
labelling what goes where. The details of the protocol would still be
in software, referenced by the compatible string on the protocol node.
> /* Core 0 */
> mpic_msgr_reserve(0);
> mpic_msgr_reserve(1);
>
> /* Send message to Core 1 */
> mpic_msgr_write(3, 13);
>
> /* Read a value */
> u32 value;
> mpic_msgr_read(0, &value);
>
> /* Free the register */
> mpic_msgr_release(0);
> ...
>
> /* Core 1 */
> mpic_msgr_reserve(3);
> mpic_msgr_reserve(4);
>
> /* Send message to Core 0 */
> mpic_msgr_write(0, 1);
You're hardcoding into software that core 0 gets msg0 and msg1, and
core 1 gets msg3 and msg4, etc. Not much different than hardcoding that
core 0 gets enet0 and core 1 gets enet1 and enet2.
> Note that a "reservation" is still isolated to a particular core, e.g.
> 'mpic_msgr_reserve(0)' on core 0 will not cause 'mpic_msgr_reserve(0)'
> to fail on another core. Where as two invocations of
> 'mpic_msgr_reserve(0)' on the same core without an interleaved
> 'mpic_msgr_release(0)' would, of course, fail.
So basically, you're assigning the resource to both partitions, and
relying on dynamic cooperation. That's fine, in that case both
partitions would see the resource in their device tree, hopefully along
with something to indicate what the situation is. But dedicated
ownership is common enough, and similar enough to the question of
whether the hardware exists at all, that it's nice to be able to express
it in the device tree. It also makes it easier to deal with situations
where you later want to plug in different hardware (or possibly a
virtualized interface) underneath the protocol.
I'm not sure how much practical benefit there is to dynamically
allocating message registers across partitions, though -- you'd have
to have some way of communicating to the other end the result of the
allocation, so it knows which one to send a message on. And if you
only have 2 cores, and unhypervised AMP, you'll be able to dedicate 4
message registers to each partition...
-Scott
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Meador Inge @ 2011-01-04 23:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <20110103142200.738c0b17@udp111988uds.am.freescale.net>
Thanks for the feedback Scott.
On 01/03/2011 02:22 PM, Scott Wood wrote:
> On Wed, 22 Dec 2010 23:58:09 -0600
> These nodes cannot go under the mpic node, because interrupt
> controllers need #address-cells =<0>.
Good point. Do they actually need it or is that just the way it
currently is? [1] mandates it, I didn't see anything in [2] and I can't
access [3].
However, AFAIK '#address-cells' is taken directly from the parent node
and is not inherited from ancestors higher in the tree. So another
option would be to do something like:
mpic: pic@40000 {
...
message-registers@0 {
#address-cells = <1>;
#size-cells = <1>;
msgr@1400 {
compatible = "fsl,mpic-v3.0-msgr";
reg = <0x1400 0x200>;
interrupts = <0xb0 0x2 0xb1 0x2 0xb2 0x2 0xb3 0x2>;
};
msgr@2400 {
compatible = "fsl,mpic-v3.0-msgr";
reg = <0x2400 0x200>;
interrupts = <0xb4 0x2 0xb5 0x2 0xb6 0x2 0xb7 0x2>;
};
};
};
I like the nesting as it models the physical relationship closer and
creates a clean namespace.
> It would be nice if the binding provided some way of partitioning
> up individual message interrupts within a block.
>
> Interrupt generation could be exported as a "service", similar to
> (inbound) interrupts and gpios.
>
> Perhaps a something like this, with "doorbell" being a new standard
> hw-independent service with its own binding:
I need to think about this proposal more, but our original intent was to
just have a simple description of the message registers in the device
tree and the policy for how those message registers are used is in
software (not necessarily an exact API use case, but you get the point):
/* Core 0 */
mpic_msgr_reserve(0);
mpic_msgr_reserve(1);
/* Send message to Core 1 */
mpic_msgr_write(3, 13);
/* Read a value */
u32 value;
mpic_msgr_read(0, &value);
/* Free the register */
mpic_msgr_release(0);
...
/* Core 1 */
mpic_msgr_reserve(3);
mpic_msgr_reserve(4);
/* Send message to Core 0 */
mpic_msgr_write(0, 1);
Note that a "reservation" is still isolated to a particular core, e.g.
'mpic_msgr_reserve(0)' on core 0 will not cause 'mpic_msgr_reserve(0)'
to fail on another core. Where as two invocations of
'mpic_msgr_reserve(0)' on the same core without an interleaved
'mpic_msgr_release(0)' would, of course, fail.
> msg1: mpic-msg@1400 {
> compatible = "fsl,mpic-v3.0-msg";
> reg =<0x1400 0x200>;
> interrupts<176 2 178 2>;
>
> // We have message registers 0 and 2 for sending,
> // and 1 and 3 for receiving.
> // If absent, we own all message registers in this block.
> fsl,mpic-msg-send-mask =<0x5>;
> fsl,mpic-msg-receive-mask =<0xa>;
>
> doorbell-controller;
>
> // split into #doorbell-send-cells and #doorbell-receive-cells?
> #doorbell-cells =<1>;
> };
>
> some-amp-protocol-thingy {
> send-doorbells =<&msg1 0>; // generate messages on MSGR0
> receive-doorbells =<&msg1 0>; // receive messages on MSGR1
> };
>
> some-other-amp-protocol-thingy {
> send-doorbells =<&msg1 1>; // generate messages on MSGR2
> receive-doorbells =<&msg1 1>; // receive messages on MSGR3
> };
>
> Doorbell capabilities such as passing a 32-bit message can be negotiated
> between the drivers for the doorbell controller and the doorbell client.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
[1] Power.org™ Standard for Embedded Power Architecture™ Platform
Requirements (ePAPR) Version 1.0
[2] PowerPC Microprocessor Common Hardware Reference Platform (CHRP)
Binding, Version 1.8, 1998. Published by the Open Firmware Working Group.
[3] The Open Programmable Interrupt Controller (PIC) Register Interface
Specification Revision 1.2
^ permalink raw reply
* Re: Question about combining a PCI driver with an OF driver
From: Bruce_Leonard @ 2011-01-04 22:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110104152018.080ff075@udp111988uds.am.freescale.net>
>
> > Okay, I get that and it makes sense with what I know so far about how
the
> > kernel device model works (which I'm still learning). So how would I
> > manually add a device? Say I create the PCI wrapper driver that
claims
> > the clone-TSEC, is there a "register device" type call similar to
> > pci_register_driver() that I could put in the wrapper code that causes
the
> > gfar_probe() to be called?
>
> Create an OF node (probably under the root node) programatically with
> all the information the gianfar driver will want, based on what you
> detect on PCI, and call of_platform_device_create().
>
Ah, the light bulb clicks on! Thanks for the info. I appreciate it.
Bruce
^ permalink raw reply
* Re: problem backporting talitos for MPC8272
From: Scott Wood @ 2011-01-04 22:00 UTC (permalink / raw)
To: Alexandru Ionut Grama; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=s5id7QJ4nmfdSsuY3Y==b_5xyqHM3Y+K2HUXr@mail.gmail.com>
On Tue, 4 Jan 2011 22:42:49 +0100
Alexandru Ionut Grama <gramaalexandruionut@gmail.com> wrote:
> You're right Scott, there's no section in arch/powerpc/boot/Makefile
> involving dts file for mpc8272ads.
>
> Well some time ago I've already write an email explaining that I've try to
> port a custom board patch from 2.6.21 to 2.6.35. I can't make the changes
> properly in 2.6.35, so that's why I've decided to backport cryptoAPI and
> talitos to 2.6.21.
Well, you may now find that it's not any easier going the other
direction. If you have to put significant effort into either a forward
port of the board code, or a backport of crypto and/or 82xx
arch/powerpc support, it's more useful long-term to get yourself
unstuck from the old kernel -- and people will be more interested in
offering support.
> Redefining the address of CPM in the dts file, the kernel "io_block_map"
> properly that address without no more code?
You can try it, but you're on your own. That was a very early attempt
at support for 82xx in arch/powerpc. I do not recommend using it at
all, much less sinking extensive backporting work into it. Things
change for a reason.
-Scott
^ permalink raw reply
* Re: problem backporting talitos for MPC8272
From: Alexandru Ionut Grama @ 2011-01-04 21:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110103160706.4329947c@udp111988uds.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 3921 bytes --]
You're right Scott, there's no section in arch/powerpc/boot/Makefile
involving dts file for mpc8272ads.
Well some time ago I've already write an email explaining that I've try to
port a custom board patch from 2.6.21 to 2.6.35. I can't make the changes
properly in 2.6.35, so that's why I've decided to backport cryptoAPI and
talitos to 2.6.21.
Because it's custom, the CPM_MAP_ADDR it's change from 0xF0000000 to
0xFF000000. ¿Changing this in mpc8272ads.dts
soc8272@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = <00000000 f0000000 00053000>;
reg = <f0000000 10000>;
cpm@f0000000 {
linux,phandle = <f0000000>;
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "cpm";
model = "CPM2";
ranges = <00000000 00000000 20000>;
reg = <0 20000>;
command-proc = <119c0>;
brg-frequency = <17D7840>;
cpm_clk = <BEBC200>;
to this
soc8272@ff000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = <00000000 ff000000 00053000>;
reg = <ff000000 10000>;
cpm@ff000000 {
linux,phandle = <ff000000>;
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "cpm";
model = "CPM2";
ranges = <00000000 00000000 20000>;
reg = <0 20000>;
command-proc = <119c0>;
brg-frequency = <17D7840>;
cpm_clk = <BEBC200>;
should solve this issue?
Also there is change in arch/powerpc/platforms/82xx/mpc82xx_ads.c
+ static void __init m82xx_map_io(void) /* gonza */
+ {
+ io_block_mapping(CPM_MAP_ADDR, CPM_MAP_ADDR, ((uint)(4 * 64 * 1024)),
_PAGE_IO);
+ }
+
+
define_machine(mpc82xx_ads)
{
.name = "MPC82xx ADS",
***************
*** 642,645 ****
--- 648,652 ----
.get_irq = cpm2_get_irq,
.calibrate_decr = m82xx_calibrate_decr,
.restart = m82xx_restart,.halt = m82xx_halt,
+ .setup_io_mappings = m82xx_map_io, /* gonza */
};
Redefining the address of CPM in the dts file, the kernel "io_block_map"
properly that address without no more code?
Thank you very much.
Alexandru.
2011/1/3 Scott Wood <scottwood@freescale.com>
> On Wed, 29 Dec 2010 02:10:55 +0100
> Alexandru Ionut Grama <gramaalexandruionut@gmail.com> wrote:
>
> > My final question it's about of-tree. I have the mpc8272ads.dts file with
> a
> > tree that involves talitos, but I've changed the properties acording the
> new
> > version of it on 2.6.35. ¿This file (mpc8272ads.dts) when it's used?I
> think
> > I don't use this file for nothing (it doesn't appears on make V=1)
> because I
> > don't have a normal bootloader and I have to load the kernel like a
> > flat-binary gz, so there's no more step after building System.map.
>
> IIRC, in 2.6.21, it wasn't used on 82xx (I think there was only
> arch/ppc support for 82xx, or at best 82xx arch/powerpc support was
> just getting started). 2.6.21 is very old, and doing new development on
> it is not recommended.
>
> Why not work with the current kernel?
>
> -Scott
>
>
--
*---------------------------------------------------------------
Alexandru Ionut Grama
**email: gramaalexandruionut@gmail.com**
*
[-- Attachment #2: Type: text/html, Size: 5031 bytes --]
^ permalink raw reply
* Re: Question about combining a PCI driver with an OF driver
From: Sean MacLennan @ 2011-01-04 21:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <OF2F9BC586.7E8383F3-ON8825780E.0072ACEA-8825780E.00735E90@selinc.com>
On Tue, 4 Jan 2011 13:00:07 -0800
Bruce_Leonard@selinc.com wrote:
> True, but we really didn't want to recreate all the infrastructure
> that the gianfar driver has in it we wanted to just use it. Maybe
> what I should do is just take the guts of the gianfar driver and make
> a pure PCI driver out of it.
This is what I would do. Odds are the final FPGA driver will have a lot
of "optimizations" and "we don't need this" changes to the point where
you won't be able to read the original code for ifdefs ;)
Cheers,
Sean
^ permalink raw reply
* Re: Question about combining a PCI driver with an OF driver
From: Scott Wood @ 2011-01-04 21:20 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-dev
In-Reply-To: <OF2F9BC586.7E8383F3-ON8825780E.0072ACEA-8825780E.00735E90@selinc.com>
On Tue, 4 Jan 2011 13:00:07 -0800
<Bruce_Leonard@selinc.com> wrote:
> Okay, I get that and it makes sense with what I know so far about how the
> kernel device model works (which I'm still learning). So how would I
> manually add a device? Say I create the PCI wrapper driver that claims
> the clone-TSEC, is there a "register device" type call similar to
> pci_register_driver() that I could put in the wrapper code that causes the
> gfar_probe() to be called?
Create an OF node (probably under the root node) programatically with
all the information the gianfar driver will want, based on what you
detect on PCI, and call of_platform_device_create().
-Scott
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Fix SPRG get/set for Book3S and BookE
From: Alexander Graf @ 2011-01-04 21:09 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1293652285-13313-1-git-send-email-ptyser@xes-inc.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 29.12.2010, at 20:51, Peter Tyser wrote:
> Previously SPRGs 4-7 were improperly read and written in
> kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();
>=20
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
Thanks a lot for the catch. At least for Book3S we don't support SPRGs > =
3 anyways, so it's not really too bad of a glitch. It's irritating =
nevertheless :).
Marcelo/Avi, please include this patch in the kvm tree.
Signed-off-by: Alexander Graf <agraf@suse.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
iEYEARECAAYFAk0jjJIACgkQq7Wi27wfN1PIMwCfffOOFsI5K6LXi5AYBUcwK07Q
dGoAn21M9Brz8vxpXxHFNs1QhGOuPGlo
=3D/b/r
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Question about combining a PCI driver with an OF driver
From: Benjamin Herrenschmidt @ 2011-01-04 21:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Bruce_Leonard
In-Reply-To: <20110104132317.006ead39@udp111988uds.am.freescale.net>
On Tue, 2011-01-04 at 13:23 -0600, Scott Wood wrote:
> On Tue, 4 Jan 2011 10:58:35 -0800
> <Bruce_Leonard@selinc.com> wrote:
>
> > Hi all,
> >
> > I'm working on a project with an MPC8347 and three ethernet ports. Because
> > of end of life issues we've had to replace the part we're using for the
> > third ethernet port and we decided rather than rely on a vendor who would
> > pull a part out from under us every two to three years we would do our own
> > MAC in an FPGA. In order to reduce driver work it was decided that we
> > would use the same hardware interface as the TSEC in the 8347 so we could
> > reuse the gianfar driver.
>
> Making a faithful clone of any reasonably complex device strikes me as
> more work than writing a new ethernet driver.
>
> The last thing you want to end up doing is...
>
> > And for speed sake it would go on the PCI bus.
> > (So much for letting HW make decisions regarding SW :) )
>
> ...hacking up the existing driver to deal with the quirks of the clone,
> and having to maintain those hacks. :-)
I definitely agree. You're up for more work and problems than just doing
a new design or getting an existing one off opencores or even buying an
IP block with its own driver.
> > So now I'm stuck with hacking the gianfar driver to work on PCI. However,
> > I think it would be a lot more elegant if I could wrap the gianfar driver
> > with a PCI interface. After all the idea is sound, with a HW interface
> > that looks like the TSEC I should be able to reuse the gianfar driver. But
> > the gianfar driver is an open firmware driver registered with a call to
> > of_register_platform_driver() and depending on the order in which the
> > busses are walked the PCI bus may not be enumerated and available when the
> > onboard TSECS are detected and the gianfar driver claims them.
>
> It shouldn't matter -- the way buses work in Linux, you should be able
> to add a platform device at any time, and the driver will receive a
> probe() callback. The driver never actively searches for devices to
> claim.
Cheers,
Ben.
> -Scott
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Question about combining a PCI driver with an OF driver
From: Bruce_Leonard @ 2011-01-04 21:00 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110104132317.006ead39@udp111988uds.am.freescale.net>
Scott,
Thanks for the feedback.
>
> Making a faithful clone of any reasonably complex device strikes me as
> more work than writing a new ethernet driver.
>
> The last thing you want to end up doing is...
>
> > And for speed sake it would go on the PCI bus.
> > (So much for letting HW make decisions regarding SW :) )
>
> ...hacking up the existing driver to deal with the quirks of the clone,
> and having to maintain those hacks. :-)
>
True, but we really didn't want to recreate all the infrastructure that
the gianfar driver has in it we wanted to just use it. Maybe what I
should do is just take the guts of the gianfar driver and make a pure PCI
driver out of it.
>
> It shouldn't matter -- the way buses work in Linux, you should be able
> to add a platform device at any time, and the driver will receive a
> probe() callback. The driver never actively searches for devices to
> claim.
>
Okay, I get that and it makes sense with what I know so far about how the
kernel device model works (which I'm still learning). So how would I
manually add a device? Say I create the PCI wrapper driver that claims
the clone-TSEC, is there a "register device" type call similar to
pci_register_driver() that I could put in the wrapper code that causes the
gfar_probe() to be called?
Bruce
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis @ 2011-01-04 20:14 UTC (permalink / raw)
To: Grant Likely; +Cc: Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <4D13C402.2090209@mentor.com>
On 12/23/2010 01:49 PM, Meador Inge wrote:
>
> We can't just remove the IRQ of the _other_ OS from the 'interrupts'=20
> property in the message node because we need to know the IRQ in order=20
> to talk to the other OS. So, we use protected sources to tell the OS=20
> that an IRQ is not available for its own use, while at the same time=20
> keeping=20
> complete information on all the IRQ mappings for the message =
registers.
There's a simpler and more fundamental problem: the Linux MPIC driver=20
initializes the "VECPRI" register for all interrupt sources (which is=20
how you associate a source with a vector). We need the Linux driver not=20
to do this.
(The "no-reset" property solves a related problem: it tells the driver=20
not to use the hardware's special "reset all registers" bit.)
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: Question about combining a PCI driver with an OF driver
From: Scott Wood @ 2011-01-04 19:23 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-dev
In-Reply-To: <OF413F3FA8.B1C9F99A-ON8825780E.006706F6-8825780E.00683E0B@selinc.com>
On Tue, 4 Jan 2011 10:58:35 -0800
<Bruce_Leonard@selinc.com> wrote:
> Hi all,
>
> I'm working on a project with an MPC8347 and three ethernet ports. Because
> of end of life issues we've had to replace the part we're using for the
> third ethernet port and we decided rather than rely on a vendor who would
> pull a part out from under us every two to three years we would do our own
> MAC in an FPGA. In order to reduce driver work it was decided that we
> would use the same hardware interface as the TSEC in the 8347 so we could
> reuse the gianfar driver.
Making a faithful clone of any reasonably complex device strikes me as
more work than writing a new ethernet driver.
The last thing you want to end up doing is...
> And for speed sake it would go on the PCI bus.
> (So much for letting HW make decisions regarding SW :) )
...hacking up the existing driver to deal with the quirks of the clone,
and having to maintain those hacks. :-)
> So now I'm stuck with hacking the gianfar driver to work on PCI. However,
> I think it would be a lot more elegant if I could wrap the gianfar driver
> with a PCI interface. After all the idea is sound, with a HW interface
> that looks like the TSEC I should be able to reuse the gianfar driver. But
> the gianfar driver is an open firmware driver registered with a call to
> of_register_platform_driver() and depending on the order in which the
> busses are walked the PCI bus may not be enumerated and available when the
> onboard TSECS are detected and the gianfar driver claims them.
It shouldn't matter -- the way buses work in Linux, you should be able
to add a platform device at any time, and the driver will receive a
probe() callback. The driver never actively searches for devices to
claim.
-Scott
^ permalink raw reply
* Question about combining a PCI driver with an OF driver
From: Bruce_Leonard @ 2011-01-04 18:58 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm working on a project with an MPC8347 and three ethernet ports. Because
of end of life issues we've had to replace the part we're using for the
third ethernet port and we decided rather than rely on a vendor who would
pull a part out from under us every two to three years we would do our own
MAC in an FPGA. In order to reduce driver work it was decided that we
would use the same hardware interface as the TSEC in the 8347 so we could
reuse the gianfar driver. And for speed sake it would go on the PCI bus.
(So much for letting HW make decisions regarding SW :) )
So now I'm stuck with hacking the gianfar driver to work on PCI. However,
I think it would be a lot more elegant if I could wrap the gianfar driver
with a PCI interface. After all the idea is sound, with a HW interface
that looks like the TSEC I should be able to reuse the gianfar driver. But
the gianfar driver is an open firmware driver registered with a call to
of_register_platform_driver() and depending on the order in which the
busses are walked the PCI bus may not be enumerated and available when the
onboard TSECS are detected and the gianfar driver claims them.
So the question is, how can I wrap an OF driver with a PCI driver so that
I can just do a thin layer of probing the PCI bus, registering with the
PCI sub-system, and then calling the OF probe in the gianfar driver?
Thanks for any insight.
Bruce
^ permalink raw reply
* Re: [PATCH] powerpc/dts: fix syntax bugs in bluestone.dts
From: Grant Likely @ 2011-01-04 18:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: tmarri, linuxppc-dev
In-Reply-To: <20110104143132.GC2364@zod.rchland.ibm.com>
On Tue, Jan 04, 2011 at 09:31:32AM -0500, Josh Boyer wrote:
> On Tue, Jan 04, 2011 at 07:30:30AM -0700, Grant Likely wrote:
> >On Tue, Jan 04, 2011 at 08:59:31AM -0500, Josh Boyer wrote:
> >> On Mon, Jan 03, 2011 at 02:07:40PM -0700, Grant Likely wrote:
> >> >Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >> >---
> >> >
> >> >I'm picking this one up immediately into my next-devicetree branch
> >>
> >> Hm. So these are of course correct, and with that:
> >>
> >> Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> >>
> >> but I do wonder how you noticed them? DTC didn't throw an error when I
> >> built this originally. Either way, more diligence on my part would be
> >> appropriate, but knowing how you came across these might teach me
> >> something.
> >
> >I updated the copy of dtc in the kernel and rebuilt all the .dts files.
>
> Are you going to push that DTC update into the kernel as well?
Yes, that's what I mean by updating dtc. It is in my next-devicetree branch.
g.
^ 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