* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Timur Tabi @ 2012-07-24 18:55 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <500EEA46.6030807@freescale.com>
Scott Wood wrote:
>>>> + compatible = "fsl,P5040";
>>>
>>> When would we not override this?
>>
>> I don't understand.
>
> I was wondering why we put these chip-based toplevel compatibles in the
> dtsi, when we'll always overwrite it with a board-based toplevel compatible.
That's a good point, but I'm loathe to break the current convention. I'd
rather post a patch that removes them from all boards, but I'd like an ACK
from Kumar first.
>>> Why are kernel/dtb read only?
>>
>> Because that's how it is on the P5020!
>
> This is a copy-and-paste meme that I've probably complained about a few
> dozen times by now. :-)
I know, I know, but you would think problems like this would already be
fixed upstream. I didn't think I would need to review every single
property in the P5020 device trees.
>>>> +#ifdef CONFIG_SMP
>>>> + /*
>>>> + * Disable the timebase sync operations because we can't write
>>>> + * to the timebase registers under the hypervisor.
>>>> + */
>>>> + smp_85xx_ops.give_timebase = NULL;
>>>> + smp_85xx_ops.take_timebase = NULL;
>>>> +#endif
>>>
>>> Why are they getting set in the first place?
>>
>> This is how the structure is defined in smp.c:
>>
>> struct smp_ops_t smp_85xx_ops = {
>> .kick_cpu = smp_85xx_kick_cpu,
>> #ifdef CONFIG_KEXEC
>> .give_timebase = smp_generic_give_timebase,
>> .take_timebase = smp_generic_take_timebase,
>> #endif
>> };
>>
>> This code has not changed in years.
>
> There was a patch to fix this, but I guess it hasn't been merged yet.
Can you give me a clue which patch this is, so I can find it on the
mailing list?
>> I'm not sure what you think is wrong
>> with it.
>
> We should never be using smp_generic_take/give_timebase. We have a
> better way of synchronizing for the few cases where we need to.
Ok, I'll match the new paradigm when I find it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Timur Tabi @ 2012-07-24 19:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <500EE1BB.6060104@freescale.com>
Scott Wood wrote:
>> +/include/ "qoriq-mpic.dtsi"
>> +
>> + guts: global-utilities@e0000 {
>> + compatible = "fsl,qoriq-device-config-1.0";
>> + reg = <0xe0000 0xe00>;
>> + fsl,has-rstcr;
>> + #sleep-cells = <1>;
>> + fsl,liodn-bits = <12>;
>> + };
>> +
>> + pins: global-utilities@e0e00 {
>> + compatible = "fsl,qoriq-pin-control-1.0";
>> + reg = <0xe0e00 0x200>;
>> + #sleep-cells = <2>;
>> + };
>
> Please add fsl,p5040-device-config and fsl,p5040-pin-control. If you
> want to leave the "1.0" thing in (which was a mistake since this stuff
> doesn't seem to be versioned in any public way), double check that it's
> 100% backwards compatible with p4080.
For "fsl,qoriq-device-config-1.0", the only difference is in the LIODN
registers, since the P4080 and the P5040 have different devices. For
those devices that are the same, the LIODN registers are the same.
Is that compatible enough?
The same can be said for "fsl,qoriq-pin-control-1.0". The registers are
generally the same, except when they reference devices that are different
on the SOCs. For example, the P4080 does not have 000E_0E84 USB Polarity
Configuration Register (DCFG_USBPCR).
>> + rcpm: global-utilities@e2000 {
>> + compatible = "fsl,qoriq-rcpm-1.0";
>> + reg = <0xe2000 0x1000>;
>> + #sleep-cells = <1>;
>> + };
Same thing here. Except for a few bits for devices that don't exist on
the other SOC, they're the same.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH -V3 11/11] arch/powerpc: Add 64TB support
From: Aneesh Kumar K.V @ 2012-07-24 19:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <87boj5o70h.fsf@skywalker.in.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
......
> /* Returns the segment size indicator for a user address */
> @@ -534,11 +544,17 @@ static inline int user_segment_size(unsigned long addr)
> static inline unsigned long get_vsid(unsigned long context, unsigned long ea,
> int ssize)
> {
> - if (ssize == MMU_SEGSIZE_256M)
> - return vsid_scramble((context << USER_ESID_BITS)
> - | (ea >> SID_SHIFT), 256M);
> - return vsid_scramble((context << USER_ESID_BITS_1T)
> - | (ea >> SID_SHIFT_1T), 1T);
> + unsigned long proto_vsid;
> + if (ssize == MMU_SEGSIZE_256M) {
> + proto_vsid = ((context << USER_ESID_BITS) |(ea >> SID_SHIFT));
> + /* truncate this to 37 bits */
> + proto_vsid &= (1UL << (CONTEXT_BITS + USER_ESID_BITS)) - 1;
> + return vsid_scramble(proto_vsid, 256M);
> + }
> + proto_vsid = ((context << USER_ESID_BITS_1T) | (ea >> SID_SHIFT_1T));
> + /* truncate this to 25 bits */
> + proto_vsid &= (1UL << (CONTEXT_BITS + USER_ESID_BITS_1T)) - 1;
> + return vsid_scramble( proto_vsid, 1T);
> }
I guess we can drop this hunk and related asm, because context is
guaranteed to be <= CONTEXT_BITS (via MAX_CONTEXTS )
-aneesh
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Timur Tabi @ 2012-07-24 20:16 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <500EE1BB.6060104@freescale.com>
Scott Wood wrote:
>> > + flash@0,0 {
>> > + compatible = "cfi-flash";
>> > + reg = <0 0 0x08000000>;
>> > + bank-width = <2>;
>> > + device-width = <2>;
>> > + };
> No partitions on NOR flash?
None of the CoreNet device trees include NOR flash partitions.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Scott Wood @ 2012-07-24 20:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <500EEF86.5040806@freescale.com>
On 07/24/2012 01:55 PM, Timur Tabi wrote:
> Scott Wood wrote:
>
>>>>> + compatible = "fsl,P5040";
>>>>
>>>> When would we not override this?
>>>
>>> I don't understand.
>>
>> I was wondering why we put these chip-based toplevel compatibles in the
>> dtsi, when we'll always overwrite it with a board-based toplevel compatible.
>
> That's a good point, but I'm loathe to break the current convention. I'd
> rather post a patch that removes them from all boards, but I'd like an ACK
> from Kumar first.
Yeah, that was more a question for Kumar and the list than a "remove
this" request.
>>>> Why are kernel/dtb read only?
>>>
>>> Because that's how it is on the P5020!
>>
>> This is a copy-and-paste meme that I've probably complained about a few
>> dozen times by now. :-)
>
> I know, I know, but you would think problems like this would already be
> fixed upstream. I didn't think I would need to review every single
> property in the P5020 device trees.
In this particular case I should probably go fix the existing trees, but
in general blind copy and paste is a bad thing.
Maybe we should have include files for common partition schemes.
>>> This is how the structure is defined in smp.c:
>>>
>>> struct smp_ops_t smp_85xx_ops = {
>>> .kick_cpu = smp_85xx_kick_cpu,
>>> #ifdef CONFIG_KEXEC
>>> .give_timebase = smp_generic_give_timebase,
>>> .take_timebase = smp_generic_take_timebase,
>>> #endif
>>> };
>>>
>>> This code has not changed in years.
>>
>> There was a patch to fix this, but I guess it hasn't been merged yet.
>
> Can you give me a clue which patch this is, so I can find it on the
> mailing list?
http://patchwork.ozlabs.org/patch/172243/
...but it only deals with e500v2 so far, so I was wrong when I said that
patch fixes it. Once we do the equivalent thing for e500mc we can
remove all mpc85xx references to the generic tbsync code.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Timur Tabi @ 2012-07-24 20:45 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <500EE1BB.6060104@freescale.com>
Scott Wood wrote:
>> > + bus-range = <0x0 0xff>;
> Do we really need this?
I can't find any documentation for this property, but it does appear to be
initialized by U-Boot:
/* We assume a cfg_addr not being set means we didn't setup the controller */
if ((hose == NULL) || (hose->cfg_addr == NULL)) {
fdt_del_node(blob, off);
} else {
bus_range[0] = 0;
bus_range[1] = hose->last_busno - hose->first_busno;
fdt_setprop(blob, off, "bus-range", &bus_range[0], 2*4);
fdt_pci_dma_ranges(blob, off, hose);
}
So I have no idea if it's required in the DTS.
>> > + clock-frequency = <33333333>;
> I doubt this is accurate.
Every other DTS sets this property to 33333333, and I don't see any code
in U-boot that fixes it up.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Timur Tabi @ 2012-07-24 21:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <500EE1BB.6060104@freescale.com>
Scott Wood wrote:
>> > + compatible = "fsl,p5040-pcie", "fsl,qoriq-pcie-v2.2";
> p5040 has PCIe v2.4.
>
> Note that there is a version register, so perhaps we should drop the
> version number from the compatible (and mention the version register in
> the binding).
>
> Might want to double check the other version numbers in this file too.
It appears that this compatible string is used by U-Boot to find the nodes
for fixups:
#elif defined(CONFIG_PPC_P5040)
#define CONFIG_MAX_CPUS 4
...
#define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.2"
Which means that I can't just change it from v2.2 to v2.4 without breaking
U-Boot. Ugh.
How do you know that the P5040 has v2.4?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Scott Wood @ 2012-07-24 21:31 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <500F1165.9040404@freescale.com>
On 07/24/2012 04:19 PM, Timur Tabi wrote:
> Scott Wood wrote:
>>>> + compatible = "fsl,p5040-pcie", "fsl,qoriq-pcie-v2.2";
>> p5040 has PCIe v2.4.
>>
>> Note that there is a version register, so perhaps we should drop the
>> version number from the compatible (and mention the version register in
>> the binding).
>>
>> Might want to double check the other version numbers in this file too.
>
> It appears that this compatible string is used by U-Boot to find the nodes
> for fixups:
SDK U-Boot, I assume you mean.
> #elif defined(CONFIG_PPC_P5040)
> #define CONFIG_MAX_CPUS 4
> ...
> #define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.2"
>
> Which means that I can't just change it from v2.2 to v2.4 without breaking
> U-Boot. Ugh.
Another reason for dropping the version from this particular compatible.
Wouldn't stop this breakage, but would make future ones less likely.
And of course why we should carefully verify the information in the
device trees before we go copying and pasting in the first place.
Though, it depends on whether we determine that v2.4 is 100% backwards
compatible with v2.2, in which case we could list both. It looks like
the v2.3 chips list both, and U-Boot refers to v2.2. One possible point
of contention on compatibility is the change in where LIODN is specified
(moved from guts to the PCIe registers), especially if we're claiming
backwards comaptibility on the guts side as well.
> How do you know that the P5040 has v2.4?
See PEX_IP_BLK_REV1.
One new thing in v2.4 is the LIODN permission table, rather than one
LIODN for the entire root complex.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Timur Tabi @ 2012-07-24 21:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <500F144D.5080508@freescale.com>
Scott Wood wrote:
>> It appears that this compatible string is used by U-Boot to find the nodes
>> for fixups:
>
> SDK U-Boot, I assume you mean.
No, upstream as well. It's pretty much the same code:
#ifdef CONFIG_SYS_FSL_PCIE_COMPAT
#define FSL_PCIE_COMPAT CONFIG_SYS_FSL_PCIE_COMPAT
#else
#define FSL_PCIE_COMPAT "fsl,mpc8548-pcie"
#endif
#define FT_FSL_PCIE1_SETUP __FT_FSL_PCIE_SETUP(blob, FSL_PCIE_COMPAT, 1)
#define FT_FSL_PCIE2_SETUP __FT_FSL_PCIE_SETUP(blob, FSL_PCIE_COMPAT, 2)
#define FT_FSL_PCIE3_SETUP __FT_FSL_PCIE_SETUP(blob, FSL_PCIE_COMPAT, 3)
#define FT_FSL_PCIE4_SETUP __FT_FSL_PCIE_SETUP(blob, FSL_PCIE_COMPAT, 4)
#define __FT_FSL_PCIE_SETUP(blob, compat, num) \
ft_fsl_pci_setup(blob, compat, CONFIG_SYS_PCIE##num##_ADDR)
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Scott Wood @ 2012-07-24 21:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <500F1545.1020705@freescale.com>
On 07/24/2012 04:36 PM, Timur Tabi wrote:
> Scott Wood wrote:
>
>>> It appears that this compatible string is used by U-Boot to find the nodes
>>> for fixups:
>>
>> SDK U-Boot, I assume you mean.
>
> No, upstream as well. It's pretty much the same code:
I don't see P5040 support in upstream U-Boot yet.
> #ifdef CONFIG_SYS_FSL_PCIE_COMPAT
> #define FSL_PCIE_COMPAT CONFIG_SYS_FSL_PCIE_COMPAT
> #else
> #define FSL_PCIE_COMPAT "fsl,mpc8548-pcie"
> #endif
>
> #define FT_FSL_PCIE1_SETUP __FT_FSL_PCIE_SETUP(blob, FSL_PCIE_COMPAT, 1)
> #define FT_FSL_PCIE2_SETUP __FT_FSL_PCIE_SETUP(blob, FSL_PCIE_COMPAT, 2)
> #define FT_FSL_PCIE3_SETUP __FT_FSL_PCIE_SETUP(blob, FSL_PCIE_COMPAT, 3)
> #define FT_FSL_PCIE4_SETUP __FT_FSL_PCIE_SETUP(blob, FSL_PCIE_COMPAT, 4)
>
> #define __FT_FSL_PCIE_SETUP(blob, compat, num) \
> ft_fsl_pci_setup(blob, compat, CONFIG_SYS_PCIE##num##_ADDR)
>
Yeah, the code's there, but not the wrong compatible string for P5040.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Timur Tabi @ 2012-07-24 21:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <500F16B6.1080605@freescale.com>
Scott Wood wrote:
> Yeah, the code's there, but not the wrong compatible string for P5040.
I wasn't talking about the P5040DS specifically.
My point was that we cannot get rid of the compatible string outright
because U-Boot uses it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Scott Wood @ 2012-07-24 21:45 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <500F1717.6040900@freescale.com>
On 07/24/2012 04:43 PM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> Yeah, the code's there, but not the wrong compatible string for P5040.
>
> I wasn't talking about the P5040DS specifically.
>
> My point was that we cannot get rid of the compatible string outright
> because U-Boot uses it.
I thought we were specifically talking about what to set the P5040 PCIe
compatible stringlist to.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Timur Tabi @ 2012-07-24 21:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <500F178A.6000107@freescale.com>
Scott Wood wrote:
> I thought we were specifically talking about what to set the P5040 PCIe
> compatible stringlist to.
What, I can't have two different conversations going on simultaneously in
one thread?!!?!?
:-)
Yes, we are talking about the P5040 compatible string, but earlier in this
thread, you said:
"Note that there is a version register, so perhaps we should drop the
version number from the compatible (and mention the version register in
the binding)."
and I was responding to your statement about whether we should drop the
version number.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Scott Wood @ 2012-07-24 21:54 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <500F1806.5040808@freescale.com>
On 07/24/2012 04:47 PM, Timur Tabi wrote:
> Scott Wood wrote:
>> I thought we were specifically talking about what to set the P5040 PCIe
>> compatible stringlist to.
>
> What, I can't have two different conversations going on simultaneously in
> one thread?!!?!?
>
> :-)
>
> Yes, we are talking about the P5040 compatible string, but earlier in this
> thread, you said:
>
> "Note that there is a version register, so perhaps we should drop the
> version number from the compatible (and mention the version register in
> the binding)."
>
> and I was responding to your statement about whether we should drop the
> version number.
I meant for new device trees.
-Scott
^ permalink raw reply
* [PATCH] KVM: PPC: BookE: HV: Fix compile
From: Alexander Graf @ 2012-07-24 23:02 UTC (permalink / raw)
To: kvm-ppc; +Cc: Linus Torvalds, linuxppc-dev, KVM list
After merging the register type check patches from Ben's tree, the
hv enabled booke implementation ceased to compile.
This patch fixes things up so everyone's happy again.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/kvm/bookehv_interrupts.S | 77 +++++++++++++++++----------------
1 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
index d28c2d4..099fe82 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -50,8 +50,9 @@
#define HOST_R2 (3 * LONGBYTES)
#define HOST_CR (4 * LONGBYTES)
#define HOST_NV_GPRS (5 * LONGBYTES)
-#define HOST_NV_GPR(n) (HOST_NV_GPRS + ((n - 14) * LONGBYTES))
-#define HOST_MIN_STACK_SIZE (HOST_NV_GPR(31) + LONGBYTES)
+#define __HOST_NV_GPR(n) (HOST_NV_GPRS + ((n - 14) * LONGBYTES))
+#define HOST_NV_GPR(n) __HOST_NV_GPR(__REG_##n)
+#define HOST_MIN_STACK_SIZE (HOST_NV_GPR(R31) + LONGBYTES)
#define HOST_STACK_SIZE ((HOST_MIN_STACK_SIZE + 15) & ~15) /* Align. */
#define HOST_STACK_LR (HOST_STACK_SIZE + LONGBYTES) /* In caller stack frame. */
@@ -410,24 +411,24 @@ heavyweight_exit:
PPC_STL r31, VCPU_GPR(R31)(r4)
/* Load host non-volatile register state from host stack. */
- PPC_LL r14, HOST_NV_GPR(r14)(r1)
- PPC_LL r15, HOST_NV_GPR(r15)(r1)
- PPC_LL r16, HOST_NV_GPR(r16)(r1)
- PPC_LL r17, HOST_NV_GPR(r17)(r1)
- PPC_LL r18, HOST_NV_GPR(r18)(r1)
- PPC_LL r19, HOST_NV_GPR(r19)(r1)
- PPC_LL r20, HOST_NV_GPR(r20)(r1)
- PPC_LL r21, HOST_NV_GPR(r21)(r1)
- PPC_LL r22, HOST_NV_GPR(r22)(r1)
- PPC_LL r23, HOST_NV_GPR(r23)(r1)
- PPC_LL r24, HOST_NV_GPR(r24)(r1)
- PPC_LL r25, HOST_NV_GPR(r25)(r1)
- PPC_LL r26, HOST_NV_GPR(r26)(r1)
- PPC_LL r27, HOST_NV_GPR(r27)(r1)
- PPC_LL r28, HOST_NV_GPR(r28)(r1)
- PPC_LL r29, HOST_NV_GPR(r29)(r1)
- PPC_LL r30, HOST_NV_GPR(r30)(r1)
- PPC_LL r31, HOST_NV_GPR(r31)(r1)
+ PPC_LL r14, HOST_NV_GPR(R14)(r1)
+ PPC_LL r15, HOST_NV_GPR(R15)(r1)
+ PPC_LL r16, HOST_NV_GPR(R16)(r1)
+ PPC_LL r17, HOST_NV_GPR(R17)(r1)
+ PPC_LL r18, HOST_NV_GPR(R18)(r1)
+ PPC_LL r19, HOST_NV_GPR(R19)(r1)
+ PPC_LL r20, HOST_NV_GPR(R20)(r1)
+ PPC_LL r21, HOST_NV_GPR(R21)(r1)
+ PPC_LL r22, HOST_NV_GPR(R22)(r1)
+ PPC_LL r23, HOST_NV_GPR(R23)(r1)
+ PPC_LL r24, HOST_NV_GPR(R24)(r1)
+ PPC_LL r25, HOST_NV_GPR(R25)(r1)
+ PPC_LL r26, HOST_NV_GPR(R26)(r1)
+ PPC_LL r27, HOST_NV_GPR(R27)(r1)
+ PPC_LL r28, HOST_NV_GPR(R28)(r1)
+ PPC_LL r29, HOST_NV_GPR(R29)(r1)
+ PPC_LL r30, HOST_NV_GPR(R30)(r1)
+ PPC_LL r31, HOST_NV_GPR(R31)(r1)
/* Return to kvm_vcpu_run(). */
mtlr r5
@@ -453,24 +454,24 @@ _GLOBAL(__kvmppc_vcpu_run)
stw r5, HOST_CR(r1)
/* Save host non-volatile register state to stack. */
- PPC_STL r14, HOST_NV_GPR(r14)(r1)
- PPC_STL r15, HOST_NV_GPR(r15)(r1)
- PPC_STL r16, HOST_NV_GPR(r16)(r1)
- PPC_STL r17, HOST_NV_GPR(r17)(r1)
- PPC_STL r18, HOST_NV_GPR(r18)(r1)
- PPC_STL r19, HOST_NV_GPR(r19)(r1)
- PPC_STL r20, HOST_NV_GPR(r20)(r1)
- PPC_STL r21, HOST_NV_GPR(r21)(r1)
- PPC_STL r22, HOST_NV_GPR(r22)(r1)
- PPC_STL r23, HOST_NV_GPR(r23)(r1)
- PPC_STL r24, HOST_NV_GPR(r24)(r1)
- PPC_STL r25, HOST_NV_GPR(r25)(r1)
- PPC_STL r26, HOST_NV_GPR(r26)(r1)
- PPC_STL r27, HOST_NV_GPR(r27)(r1)
- PPC_STL r28, HOST_NV_GPR(r28)(r1)
- PPC_STL r29, HOST_NV_GPR(r29)(r1)
- PPC_STL r30, HOST_NV_GPR(r30)(r1)
- PPC_STL r31, HOST_NV_GPR(r31)(r1)
+ PPC_STL r14, HOST_NV_GPR(R14)(r1)
+ PPC_STL r15, HOST_NV_GPR(R15)(r1)
+ PPC_STL r16, HOST_NV_GPR(R16)(r1)
+ PPC_STL r17, HOST_NV_GPR(R17)(r1)
+ PPC_STL r18, HOST_NV_GPR(R18)(r1)
+ PPC_STL r19, HOST_NV_GPR(R19)(r1)
+ PPC_STL r20, HOST_NV_GPR(R20)(r1)
+ PPC_STL r21, HOST_NV_GPR(R21)(r1)
+ PPC_STL r22, HOST_NV_GPR(R22)(r1)
+ PPC_STL r23, HOST_NV_GPR(R23)(r1)
+ PPC_STL r24, HOST_NV_GPR(R24)(r1)
+ PPC_STL r25, HOST_NV_GPR(R25)(r1)
+ PPC_STL r26, HOST_NV_GPR(R26)(r1)
+ PPC_STL r27, HOST_NV_GPR(R27)(r1)
+ PPC_STL r28, HOST_NV_GPR(R28)(r1)
+ PPC_STL r29, HOST_NV_GPR(R29)(r1)
+ PPC_STL r30, HOST_NV_GPR(R30)(r1)
+ PPC_STL r31, HOST_NV_GPR(R31)(r1)
/* Load guest non-volatiles. */
PPC_LL r14, VCPU_GPR(R14)(r4)
--
1.6.0.2
^ permalink raw reply related
* Re: [2/3][PATCH][upstream] TDM Framework
From: Michael Ellerman @ 2012-07-24 23:43 UTC (permalink / raw)
To: Timur Tabi
Cc: Aggrwal Poonam-B10812, linuxppc-dev@lists.ozlabs.org,
Singh Sandeep-B37400
In-Reply-To: <500EB47F.1040903@freescale.com>
On Tue, 2012-07-24 at 09:43 -0500, Timur Tabi wrote:
> Singh Sandeep-B37400 wrote:
>
> >> +int tdm_adap_send(struct tdm_adapter *adap, void **buf, int count) {
> >> + int res;
> >> +
> >> + if (adap->algo->tdm_write)
> >> + res = adap->algo->tdm_write(adap, buf, count);
> >
> > Why does tdm_write() return a u32? And shouldn't 'res' also be a u32, to make tdm_write()?
> > [Sandeep] tdm_write() returns number of bytes written. You are right, 'res' should be declared as u32
>
> Then it should return an unsigned int. You should used a sized integer
> type only when the size really matters (e.g. hardware registers or packed
> fields in a structure).
>
> >> +/* tdm_adapter_mode is to define in mode of the device */ enum
> >> +tdm_adapter_mode {
> >> + TDM_ADAPTER_MODE_NONE = 0x00,
> >> + TDM_ADAPTER_MODE_T1 = 0x01,
> >> + TDM_ADAPTER_MODE_E1 = 0x02,
> >> + TDM_ADAPTER_MODE_T1_RAW = 0x10,
> >> + TDM_ADAPTER_MODE_E1_RAW = 0x20,
> >
> > Where did these numbers come from?
> > [Sandeep] This is not related to any bit definition, just enum values.
>
> Yes, but why these particular numbers? Also, do they really need to be an
> enum? Since you're defining hard values for each enum, you're not really
> using them as an enum. Make these into macros.
I agree these values are odd. But there's no rule that you can only use
an enum if the values are monotonically increasing.
It can still serve as helpful documentation, and reduce the number of
places you pass a bare int around.
cheers
^ permalink raw reply
* RE: [PATCH 1/6] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Jia Hongtao-B38951 @ 2012-07-25 2:35 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <500EECA3.3050806@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDI1LCAyMDEyIDI6NDMgQU0NCj4gVG86IEppYSBI
b25ndGFvLUIzODk1MQ0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGdhbGFr
QGtlcm5lbC5jcmFzaGluZy5vcmc7IFdvb2QgU2NvdHQtDQo+IEIwNzQyMTsgTGkgWWFuZy1SNTg0
NzINCj4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzZdIHBvd2VycGMvZnNsLXBjaTogVW5pZnkgcGNp
L3BjaWUgaW5pdGlhbGl6YXRpb24NCj4gY29kZQ0KPiANCj4gT24gMDcvMjQvMjAxMiAwNToyMCBB
TSwgSmlhIEhvbmd0YW8gd3JvdGU6DQo+ID4gV2UgdW5pZmllZCB0aGUgRnJlZXNjYWxlIHBjaS9w
Y2llIGluaXRpYWxpemF0aW9uIGJ5IGNoYW5naW5nIHRoZQ0KPiBmc2xfcGNpDQo+ID4gdG8gYSBw
bGF0Zm9ybSBkcml2ZXIuDQo+ID4NCj4gPiBJbiBwcmV2aW91cyB2ZXJzaW9uIHBjaS9wY2llIGlu
aXRpYWxpemF0aW9uIGlzIGluIHBsYXRmb3JtIGNvZGUgd2hpY2gNCj4gPiBJbml0aWFsaXplIHBj
aSBicmlkZ2UgYmFzZSBvbiBFUC9SQyBvciBob3N0L2FnZW50IHNldHRpbmdzLg0KPiANCj4gVGhl
IHByZXZpb3VzIHZlcnNpb24gb2Ygd2hhdD8gIFRoaXMgcGF0Y2gsIG9yIHRoZSBQQ0kgY29kZT8g
IFdoYXQNCj4gY2hhbmdlZCBpbiB0aGlzIHBhdGNoIHNpbmNlIHRoZSBsYXN0IHRpbWUgeW91IHNl
bnQgaXQsIGFuZCB3aGVyZSBpcyB0aGUNCj4gdmVyc2lvbiBudW1iZXI/DQo+IA0KPiA+ICsjaWYg
ZGVmaW5lZChDT05GSUdfRlNMX1NPQ19CT09LRSkgfHwgZGVmaW5lZChDT05GSUdfUFBDXzg2eHgp
DQo+ID4gK3N0YXRpYyBjb25zdCBzdHJ1Y3Qgb2ZfZGV2aWNlX2lkIHBjaV9pZHNbXSA9IHsNCj4g
PiArCXsgLmNvbXBhdGlibGUgPSAiZnNsLG1wYzg1NDAtcGNpIiwgfSwNCj4gPiArCXsgLmNvbXBh
dGlibGUgPSAiZnNsLG1wYzg1NDgtcGNpZSIsIH0sDQo+ID4gKwl7IC5jb21wYXRpYmxlID0gImZz
bCxtcGM4NjQxLXBjaWUiLCB9LA0KPiA+ICsJeyAuY29tcGF0aWJsZSA9ICJmc2wscDEwMjItcGNp
ZSIsIH0sDQo+ID4gKwl7IC5jb21wYXRpYmxlID0gImZzbCxwMTAxMC1wY2llIiwgfSwNCj4gPiAr
CXsgLmNvbXBhdGlibGUgPSAiZnNsLHAxMDIzLXBjaWUiLCB9LA0KPiA+ICsJeyAuY29tcGF0aWJs
ZSA9ICJmc2wscDQwODAtcGNpZSIsIH0sDQo+ID4gKwl7IC5jb21wYXRpYmxlID0gImZzbCxxb3Jp
cS1wY2llLXYyLjMiLCB9LA0KPiA+ICsJeyAuY29tcGF0aWJsZSA9ICJmc2wscW9yaXEtcGNpZS12
Mi4yIiwgfSwNCj4gPiArCXt9LA0KPiA+ICt9Ow0KPiANCj4gQWdhaW4sIHBsZWFzZSBiYXNlIHRo
aXMgb24gdGhlIGxhdGVzdCB0cmVlLCB3aGljaCBoYXMgbXkgUENJIHBhdGNoZXMuDQo+IFRoaXMg
dGFibGUgYWxyZWFkeSBleGlzdHMgaW4gdGhpcyBmaWxlLiAgQW5kIHlvdSdyZSBzdGlsbCBtaXNz
aW5nDQo+IGZzbCxtcGM4NjEwLXBjaS4NCg0KU29ycnkgZnNsLG1wYzg2MTAtcGNpIHdpbGwgYmUg
YWRkZWQuDQoNCj4gDQo+ID4gK2ludCBwcmltYXJ5X3BoYl9hZGRyOw0KPiA+ICtzdGF0aWMgaW50
IF9fZGV2aW5pdCBmc2xfcGNpX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+
ID4gK3sNCj4gPiArCXN0cnVjdCBwY2lfY29udHJvbGxlciAqaG9zZTsNCj4gPiArCWJvb2wgaXNf
cHJpbWFyeTsNCj4gPiArDQo+ID4gKwlpZiAob2ZfbWF0Y2hfbm9kZShwY2lfaWRzLCBwZGV2LT5k
ZXYub2Zfbm9kZSkpIHsNCj4gPiArCQlzdHJ1Y3QgcmVzb3VyY2UgcnNyYzsNCj4gPiArCQlvZl9h
ZGRyZXNzX3RvX3Jlc291cmNlKHBkZXYtPmRldi5vZl9ub2RlLCAwLCAmcnNyYyk7DQo+ID4gKwkJ
aXNfcHJpbWFyeSA9ICgocnNyYy5zdGFydCAmIDB4ZmZmZmYpID09IHByaW1hcnlfcGhiX2FkZHIp
Ow0KPiA+ICsJCWZzbF9hZGRfYnJpZGdlKHBkZXYtPmRldi5vZl9ub2RlLCBpc19wcmltYXJ5KTsN
Cj4gPiArDQo+ID4gKyNpZmRlZiBDT05GSUdfU1dJT1RMQg0KPiA+ICsJCWhvc2UgPSBwY2lfZmlu
ZF9ob3NlX2Zvcl9PRl9kZXZpY2UocGRldi0+ZGV2Lm9mX25vZGUpOw0KPiA+ICsJCS8qDQo+ID4g
KwkJICogaWYgd2UgY291bGRuJ3QgbWFwIGFsbCBvZiBEUkFNIHZpYSB0aGUgZG1hIHdpbmRvd3MN
Cj4gPiArCQkgKiB3ZSBuZWVkIFNXSU9UTEIgdG8gaGFuZGxlIGJ1ZmZlcnMgbG9jYXRlZCBvdXRz
aWRlIG9mDQo+ID4gKwkJICogZG1hIGNhcGFibGUgbWVtb3J5IHJlZ2lvbg0KPiA+ICsJCSAqLw0K
PiA+ICsJCWlmIChtZW1ibG9ja19lbmRfb2ZfRFJBTSgpID4gaG9zZS0+ZG1hX3dpbmRvd19iYXNl
X2N1cg0KPiA+ICsJCQkJKyBob3NlLT5kbWFfd2luZG93X3NpemUpIHsNCj4gPiArCQkJcHBjX3N3
aW90bGJfZW5hYmxlID0gMTsNCj4gPiArCQkJc2V0X3BjaV9kbWFfb3BzKCZzd2lvdGxiX2RtYV9v
cHMpOw0KPiA+ICsJCQlwcGNfbWQucGNpX2RtYV9kZXZfc2V0dXAgPSBwY2lfZG1hX2Rldl9zZXR1
cF9zd2lvdGxiOw0KPiA+ICsJCX0NCj4gPiArI2VuZGlmDQo+ID4gKwl9DQo+IA0KPiBJdCdzIHRv
byBsYXRlIGZvciBzd2lvdGxiIGhlcmUuICBBZ2FpbiwgcGxlYXNlIGRvbid0IGJyZWFrIHNvbWV0
aGluZyBpbg0KPiBvbmUgcGF0Y2ggYW5kIHRoZW4gZml4IGl0IGluIGEgbGF0ZXIgcGF0Y2guICBV
c2UgImdpdCByZWJhc2UgLWkiIHRvIGVkaXQNCj4geW91ciBwYXRjaHNldCBpbnRvIGEgcmV2aWV3
YWJsZSwgYmlzZWN0YWJsZSBmb3JtLg0KPiANCj4gLVNjb3R0DQoNClllcywgYmlzZWN0YWJsZSBy
ZXF1aXJlbWVudCBpcyBzb3J0IG9mIHJlYXNvbmFibGUuIA0KDQpCdXQgSSBjaGVjayB0aGUgU3Vi
bWl0dGluZ1BhdGNoZXMgRG9jIGFuZCBpdCBzYXlzICJJZiBvbmUgcGF0Y2ggZGVwZW5kcyBvbg0K
YW5vdGhlciBwYXRjaCBpbiBvcmRlciBmb3IgYSBjaGFuZ2UgdG8gYmUgY29tcGxldGUsIHRoYXQg
aXMgT0suIFNpbXBseQ0Kbm90ZSAndGhpcyBwYXRjaCBkZXBlbmRzIG9uIHBhdGNoIFgnIGluIHlv
dXIgcGF0Y2ggZGVzY3JpcHRpb24iLiBJbiBteQ0Kb3BpbmlvbiBzd2lvdGxiIGlzIGEgd2hvbGUg
ZnVuY3Rpb25hbCBwYXRjaCBzbyBJIHNlcGFyYXRlIHRoZW0uIE1heWJlDQpJIHNob3VsZCBhZGQg
ZGVwZW5kcyBkZXNjcmlwdGlvbiBpbiB0aGUgbmV4dCBwYXRjaC4NCg0KDQpBYm91dCBhbGwgdGhp
cyBwYXRjaCBzZXQgTGVvIGFuZCBJIGluc2lzdCB0byBtYWtlIGl0IGFzIGEgcGxhdGZvcm0gZHJp
dmVyDQp3aGljaCBpcyBhcmNoaXRlY3R1cmFsIGJldHRlci4gSSBkaWRuJ3QgYmFzZSB0aGlzIHBh
dGNoIHNldCBvbiB0aGUgbGF0ZXN0DQp0cmVlIGFuZCBpdCdzIHVuYXBwbGljYWJsZSBqdXN0IGJl
Y2F1c2UgSSB3YW50IHRvIHNob3cgdGhlIHdob2xlIGlkZWEgb2YNCnRoaXMgcGF0Y2hzZXQuIElm
IHRoZSBpZGVhIGlzIG9rIGZvciB1cHN0cmVhbSBJIHdpbGwgcmViYXNlIHRoZSBwYXRjaCBzZXQu
DQoNCi1Ib25ndGFvLiANCg==
^ permalink raw reply
* Re: [2/3][PATCH][upstream] TDM Framework
From: Tabi Timur-B04825 @ 2012-07-25 2:40 UTC (permalink / raw)
To: Michael Ellerman
Cc: Aggrwal Poonam-B10812, linuxppc-dev@lists.ozlabs.org,
Singh Sandeep-B37400
In-Reply-To: <1343173422.2218.2.camel@concordia>
Michael Ellerman wrote:
> I agree these values are odd. But there's no rule that you can only use
> an enum if the values are monotonically increasing.
>
> It can still serve as helpful documentation, and reduce the number of
> places you pass a bare int around.
IMHO, an enum should only be used if
1) You are doing real type checking of the enum
2) You don't care what the actual values of each enum is
For this patch, neither is true.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* RE: [PATCH 3/6] powerpc/fsl-pci: Determine primary bus by looking for ISA node
From: Jia Hongtao-B38951 @ 2012-07-25 2:42 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <500EEDD9.8050507@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDI1LCAyMDEyIDI6NDggQU0NCj4gVG86IEppYSBI
b25ndGFvLUIzODk1MQ0KPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGdhbGFr
QGtlcm5lbC5jcmFzaGluZy5vcmc7IFdvb2QgU2NvdHQtDQo+IEIwNzQyMTsgTGkgWWFuZy1SNTg0
NzINCj4gU3ViamVjdDogUmU6IFtQQVRDSCAzLzZdIHBvd2VycGMvZnNsLXBjaTogRGV0ZXJtaW5l
IHByaW1hcnkgYnVzIGJ5DQo+IGxvb2tpbmcgZm9yIElTQSBub2RlDQo+IA0KPiBPbiAwNy8yNC8y
MDEyIDA1OjIwIEFNLCBKaWEgSG9uZ3RhbyB3cm90ZToNCj4gPiBQQ0kgaG9zdCBicmlkZ2UgaXMg
cHJpbWFyeSBidXMgaWYgaXQgY29udGFpbnMgYW4gSVNBIG5vZGUuIEJ1dCBub3QgYWxsDQo+IGJv
YXJkcw0KPiA+IGZpdCB0aGlzIHJ1bGUuIERldmljZSB0cmVlIHNob3VsZCBiZSB1cGRhdGVkIGZv
ciBhbGwgdGhlc2UgYm9hcmRzLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogSmlhIEhvbmd0YW8g
PEIzODk1MUBmcmVlc2NhbGUuY29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6IExpIFlhbmcgPGxlb2xp
QGZyZWVzY2FsZS5jb20+DQo+ID4gLS0tDQo+ID4gIGFyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9w
Y2ktYnJpZGdlLmggfCAgICAxICsNCj4gPiAgYXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfcGNpLmMg
ICAgICAgICB8ICAgMzEgKysrKysrKysrKysrKysrKysrKysrKysrLQ0KPiAtLS0tLS0NCj4gPiAg
YXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfcGNpLmggICAgICAgICB8ICAgMTIgKysrKysrKysrKyst
DQo+ID4gIDMgZmlsZXMgY2hhbmdlZCwgMzYgaW5zZXJ0aW9ucygrKSwgOCBkZWxldGlvbnMoLSkN
Cj4gPg0KPiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vcGNpLWJyaWRn
ZS5oDQo+IGIvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL3BjaS1icmlkZ2UuaA0KPiA+IGluZGV4
IGFjMzllNmEuLmI0OGZhN2YgMTAwNjQ0DQo+ID4gLS0tIGEvYXJjaC9wb3dlcnBjL2luY2x1ZGUv
YXNtL3BjaS1icmlkZ2UuaA0KPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wY2kt
YnJpZGdlLmgNCj4gPiBAQCAtMjAsNiArMjAsNyBAQCBzdHJ1Y3QgZGV2aWNlX25vZGU7DQo+ID4g
IHN0cnVjdCBwY2lfY29udHJvbGxlciB7DQo+ID4gIAlzdHJ1Y3QgcGNpX2J1cyAqYnVzOw0KPiA+
ICAJY2hhciBpc19keW5hbWljOw0KPiA+ICsJaW50IGlzX3ByaW1hcnk7DQo+ID4gICNpZmRlZiBD
T05GSUdfUFBDNjQNCj4gPiAgCWludCBub2RlOw0KPiA+ICAjZW5kaWYNCj4gPiBkaWZmIC0tZ2l0
IGEvYXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfcGNpLmMNCj4gYi9hcmNoL3Bvd2VycGMvc3lzZGV2
L2ZzbF9wY2kuYw0KPiA+IGluZGV4IDk5YTNlNzguLjJhMzY5YmUgMTAwNjQ0DQo+ID4gLS0tIGEv
YXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfcGNpLmMNCj4gPiArKysgYi9hcmNoL3Bvd2VycGMvc3lz
ZGV2L2ZzbF9wY2kuYw0KPiA+IEBAIC00NTMsNiArNDUzLDcgQEAgaW50IF9faW5pdCBmc2xfYWRk
X2JyaWRnZShzdHJ1Y3QgZGV2aWNlX25vZGUgKmRldiwNCj4gaW50IGlzX3ByaW1hcnkpDQo+ID4N
Cj4gPiAgCWhvc2UtPmZpcnN0X2J1c25vID0gYnVzX3JhbmdlID8gYnVzX3JhbmdlWzBdIDogMHgw
Ow0KPiA+ICAJaG9zZS0+bGFzdF9idXNubyA9IGJ1c19yYW5nZSA/IGJ1c19yYW5nZVsxXSA6IDB4
ZmY7DQo+ID4gKwlob3NlLT5pc19wcmltYXJ5ID0gaXNfcHJpbWFyeTsNCj4gPg0KPiA+ICAJc2V0
dXBfaW5kaXJlY3RfcGNpKGhvc2UsIHJzcmMuc3RhcnQsIHJzcmMuc3RhcnQgKyAweDQsDQo+ID4g
IAkJUFBDX0lORElSRUNUX1RZUEVfQklHX0VORElBTik7DQo+ID4gQEAgLTkzMiwxOCArOTMzLDM0
IEBAIHZvaWQgcGNpX2NoZWNrX3N3aW90bGIodm9pZCkNCj4gPiAgfQ0KPiA+ICAjZW5kaWYNCj4g
Pg0KPiA+IC1pbnQgcHJpbWFyeV9waGJfYWRkcjsNCj4gPiArLyoNCj4gPiArICogUmVjdXJzaXZl
bHkgc2NhbiBhbGwgdGhlIGNoaWxkcmVuIG5vZGVzIG9mIHBhcmVudCBhbmQgZmluZCBvdXQgaWYN
Cj4gdGhlcmUNCj4gPiArICogaXMgImlzYSIgbm9kZS4gUmV0dXJuIDEgaWYgcGFyZW50IGhhcyBp
c2Egbm9kZSBvdGhlcndpc2UgcmV0dXJuIDAuDQo+ID4gKyAqLw0KPiA+ICtpbnQgaGFzX2lzYV9u
b2RlKHN0cnVjdCBkZXZpY2Vfbm9kZSAqcGFyZW50KQ0KPiA+ICt7DQo+ID4gKwlzdGF0aWMgaW50
IHJlc3VsdDsNCj4gPiArCXN0cnVjdCBkZXZpY2Vfbm9kZSAqY3VyX2NoaWxkOw0KPiA+ICsNCj4g
PiArCWN1cl9jaGlsZCA9IE5VTEw7DQo+ID4gKwlyZXN1bHQgPSAwOw0KPiA+ICsJd2hpbGUgKCFy
ZXN1bHQgJiYgKGN1cl9jaGlsZCA9IG9mX2dldF9uZXh0X2NoaWxkKHBhcmVudCwNCj4gY3VyX2No
aWxkKSkpIHsNCj4gPiArCQkvKiBHZXQgImlzYSIgbm9kZSBhbmQgcmV0dXJuIDEgKi8NCj4gPiAr
CQlpZiAob2Zfbm9kZV9jbXAoY3VyX2NoaWxkLT50eXBlLCAiaXNhIikgPT0gMCkNCj4gPiArCQkJ
cmV0dXJuIHJlc3VsdCA9IDE7DQo+ID4gKwkJaGFzX2lzYV9ub2RlKGN1cl9jaGlsZCk7DQo+ID4g
Kwl9DQo+ID4gKw0KPiA+ICsJcmV0dXJuIHJlc3VsdDsNCj4gPiArfQ0KPiANCj4gV2h5IGFyZSB5
b3UgcmVpbXBsZW1lbnRpbmcgdGhpcz8gIEl0J3MgYWxyZWFkeSBpbiBMaW51cydzIHRyZWUuICBT
ZWUNCj4gZnNsX3BjaV9pbml0KCkuDQo+IA0KPiBQbHVzLCB5b3VyIHZlcnNpb24gaXMgcmVjdXJz
aXZlIHdoaWNoIGlzIHVuYWNjZXB0YWJsZSBpbiBrZXJuZWwgY29kZQ0KPiB3aXRoIGEgc21hbGwg
c3RhY2sgKG91dHNpZGUgb2YgYSBmZXcgcmFyZSBleGFtcGxlcyB3aGVyZSB0aGUgZGVwdGggaGFz
IGENCj4gc21hbGwgZml4ZWQgdXBwZXIgYm91bmQpLCBhbmQgb25jZSBpdCBmaW5kcyBhbiBJU0Eg
bm9kZSwgaXQgcmV0dXJucyAxDQo+IGZvcmV2ZXIsIHJlZ2FyZGxlc3Mgb2Ygd2hhdCBub2RlIHlv
dSBwYXNzIGluIGluIHRoZSBmdXR1cmUuDQo+IA0KPiAtU2NvdHQNCg0KQWJvdXQgcmVjdXJzaW9u
IEkgd2lsbCBkbyBzb21lIG1vcmUgaW52ZXN0aWdhdGlvbi4NCklmIGl0IGZpbmRzIElTQSBpdCBy
ZXR1cm5zIDEuIEJ1dCBmb3IgbmV4dCBQQ0kgbm9kZSBpdCB3aWxsIHJldHVybiAwIGlmDQpubyBJ
U0EgaXMgZm91bmQgKG5vdGUgdGhhdCBJIHNldCByZXN1bHQgdG8gMCBhdCB0aGUgYmVnaW5uaW5n
KS4NCg0KLUhvbmd0YW8uDQoNCg==
^ permalink raw reply
* RE: [PATCH] powerpc/p5040ds: Add support for P5040DS board
From: Zang Roy-R61911 @ 2012-07-25 2:55 UTC (permalink / raw)
To: Wood Scott-B07421, Tabi Timur-B04825; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <500EEA46.6030807@freescale.com>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Scott Wood
> Sent: Wednesday, July 25, 2012 2:33 AM
> To: Tabi Timur-B04825
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] powerpc/p5040ds: Add support for P5040DS board
>=20
> On 07/24/2012 01:09 PM, Timur Tabi wrote:
> > Scott Wood wrote:
> >> On 07/24/2012 11:42 AM, Timur Tabi wrote:
> >>> +/* controller at 0x200000 */
> >>> +&pci0 {
> >>> + compatible =3D "fsl,p5040-pcie", "fsl,qoriq-pcie-v2.2";
> >>
> >> p5040 has PCIe v2.4.
> >
> > Then it's broken on the SDK as well.
>=20
> Yes. There was internal discussion about this over the last few days.
In SDK, we use consist v2.2, so there is no obvious problem, but we need to=
fix this to v2.4. P5020 PCIe adds Liodn registers.
Roy
^ permalink raw reply
* Re: More irqdomain problems (Was: next/mmotm unbootable on G5: irqdomain)
From: Grant Likely @ 2012-07-25 5:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Hugh Dickins, linux-kernel, Milton Miller,
Paul Mundt, Rob Herring, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <1343025161.2957.22.camel@pasglop>
On Mon, Jul 23, 2012 at 12:32 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Allright, another one Grant:
>
> unsigned int irq_find_mapping(struct irq_domain *domain,
> irq_hw_number_t hwirq)
> {
> struct irq_data *data;
>
> /* Look for default domain if nececssary */
> if (domain == NULL)
> domain = irq_default_domain;
> if (domain == NULL)
> return 0;
>
> switch (domain->revmap_type) {
> case IRQ_DOMAIN_MAP_LEGACY:
> return irq_domain_legacy_revmap(domain, hwirq);
> case IRQ_DOMAIN_MAP_LINEAR:
> return irq_linear_revmap(domain, hwirq);
> case IRQ_DOMAIN_MAP_TREE:
> rcu_read_lock();
> data = radix_tree_lookup(&domain->revmap_data.tree, hwirq);
> rcu_read_unlock();
> if (data)
> return data->irq;
> - break;
> + return 0;
> case IRQ_DOMAIN_MAP_NOMAP:
>
> Please, stick a proper commit message and my s-o-b and see if you can fix
> your tree before you ask Linus to pull because that's not pretty on any
> pseries .... irq_find_mapping() does get called for all interrupt the
> first time it's mapped to check if there's a pre-existing mapping, so
> the case of the thing being unpopulated is absolutely legit.
>
> the NOMAP case has a similar dubious exit case but since I'm not that
> familiar with NOMAP I haven't touched it.
I've decided to rework the patch to simply omit the WARN statement. It
isn't really needed. I've merged in Linus' tree below the eliminate
slow-path patch and remove the WARN statement. It's been pushed out to
my irqdomain/next branch, so it should show up in tomorrow's
linux-next.
You can find it here if you want to give it a spin:
git://git.secretlab.ca/git/linux-2.6 irqdomain/next
I'll give it a bit more time in linux-next before I ask Linus to pull.
g.
^ permalink raw reply
* Re: [2/3][PATCH][upstream] TDM Framework
From: Michael Ellerman @ 2012-07-25 5:18 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Aggrwal Poonam-B10812, linuxppc-dev@lists.ozlabs.org,
Singh Sandeep-B37400
In-Reply-To: <500F5C99.6060704@freescale.com>
On Wed, 2012-07-25 at 02:40 +0000, Tabi Timur-B04825 wrote:
> Michael Ellerman wrote:
> > I agree these values are odd. But there's no rule that you can only use
> > an enum if the values are monotonically increasing.
> >
> > It can still serve as helpful documentation, and reduce the number of
> > places you pass a bare int around.
>
> IMHO, an enum should only be used if
>
> 1) You are doing real type checking of the enum
Yes, if you're going to define an enum you should use it, which this
patch doesn't, but that's just a bug in this patch.
> 2) You don't care what the actual values of each enum is
I disagree.
They make even more sense when you don't care what the values are, but
that doesn't mean you should only use them in those cases.
And the bible, K & R, includes an example of an enum which explicitly
specifies all its values. It goes on to say "enumeration variables offer
the chance of [type] checking and so are often better than #defines".
cheers
^ permalink raw reply
* Re: Errors related to i2c-powermac on the G4
From: Andrey Gusev @ 2012-07-25 7:29 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, benh@kernel.crashing.org,
paulus@samba.org
In-Reply-To: <50096F45.80601@list.ru>
20.07.2012 18:46, Andrey Gusev пишет:
> Hi!
> I build kernel from git and can see errors in dmesg on boot. 3.4.5
> doesn't have such issue.
> git show | head -n2
> commit 85efc72a0218335324d358ac479a04c16316fd4d
>
Actual for 3.5.0
[ 2.841441] i2c /dev entries driver
[ 2.850155] i2c i2c-0: therm_windtunnel: attach_adapter method is deprecated
[ 2.858330] i2c i2c-0: Please use another way to instantiate your i2c_client
[ 2.866457] PowerMac i2c bus pmu 2 registered
[ 2.874885] i2c i2c-1: therm_windtunnel: attach_adapter method is deprecated
[ 2.882965] i2c i2c-1: Please use another way to instantiate your i2c_client
[ 2.890928] PowerMac i2c bus pmu 1 registered
[ 2.899526] i2c i2c-2: therm_windtunnel: attach_adapter method is deprecated
[ 2.907463] i2c i2c-2: Please use another way to instantiate your i2c_client
[ 2.915397] PowerMac i2c bus mac-io 0 registered
[ 2.923272] i2c i2c-2: i2c-powermac: invalid reg on
/pci@f2000000/mac-io@17/i2c@18000/cereal
[ 2.931286] i2c i2c-2: i2c-powermac: invalid reg on
/pci@f2000000/mac-io@17/i2c@18000/deq
[ 2.939246] i2c i2c-2: i2c-powermac: invalid reg on
/pci@f2000000/mac-io@17/i2c@18000/i2c-modem
[ 2.947580] i2c i2c-3: therm_windtunnel: attach_adapter method is deprecated
[ 2.955559] i2c i2c-3: Please use another way to instantiate your i2c_client
[ 2.964492] PowerMac i2c bus uni-n 1 registered
[ 2.972493] i2c i2c-3: i2c-powermac: invalid reg on
/uni-n@f8000000/i2c@f8001000/cereal
[ 2.980977] usb 1-1: new full-speed USB device number 2 using ohci_hcd
[ 2.989404] i2c i2c-4: therm_windtunnel: attach_adapter method is deprecated
[ 2.997793] i2c i2c-4: Please use another way to instantiate your i2c_client
[ 3.007320] DS1775 digital thermometer [@49]
[ 3.015574] Temp: 33.0 C Hyst: 75.0 C OS: 80.0 C
[ 3.024410] ADM1030 fan controller [@2c]
[ 3.032533] PowerMac i2c bus uni-n 0 registered
[ 3.040575] i2c i2c-4: Failed to register i2c client MAC,adm1030 at 0x2c
(-16)
[ 3.048714] i2c i2c-4: i2c-powermac: Failure to register
/uni-n@f8000000/i2c@f8001000/fan@58
[ 3.057147] i2c i2c-4: Failed to register i2c client MAC,ds1775 at 0x49
(-16)
[ 3.065304] i2c i2c-4: i2c-powermac: Failure to register
/uni-n@f8000000/i2c@f8001000/temp-monitor@92
[ 3.073475] i2c i2c-4: i2c-powermac: invalid reg on
/uni-n@f8000000/i2c@f8001000/cereal
[ 3.082701] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised:
dm-devel@redhat.com
Andrey
^ permalink raw reply
* RE: [1/3][PATCH][upstream]Adding documentation for TDM
From: David Laight @ 2012-07-25 8:44 UTC (permalink / raw)
To: Aggrwal Poonam-B10812, Singh Sandeep-B37400, linuxppc-dev
Cc: Singh Sandeep-B37400
In-Reply-To: <ACB6D0C0104CFF42A45A5D82A0DD4F3D079B7B35@039-SN2MPN1-013.039d.mgd.msft.net>
> > For flexibility you need to allow for 8bit samples being converted
as:
> > 1) 8bit raw ulaw or alaw data (unchanged from line).
> > 2) 8bit raw data, bit reversed, any hdlc protocol
> > is bit reversed from audio [1].
> > 3) 8bit audio, converted from alaw to ulaw
> > 4) 8bit audio, converted from ulaw to alaw
> > 5) 16bit linear converted to/from alaw or ulaw and on a per-timeslot
> > basis.
> I agree. That we only support very limited samples. But We can add
this
> in second step once the basic framework is in.
> Also right now the testing infrastructure we have, we won't be able to
> test all these scenarios.
You probably ought to make the application request a specific
format - and error the unsupported ones.
That would make it easier to add support for other formats
later.
I also suspect that this 'framework' isn't that general!
We (as a company) use the TDM interface blocks on the MSC8101
and MSC8013 Starecore DSPs as well as some bespoke FPGA logic
(which will do ulaw<->alaw convertion).
The 'framework' would almost certainly be inappropriate
for both out hardware and software.
David
^ permalink raw reply
* RE: [PATCH 3/6] powerpc/fsl-pci: Determine primary bus by looking for ISA node
From: Jia Hongtao-B38951 @ 2012-07-25 9:01 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <500EEDD9.8050507@freescale.com>
PiA+ICsvKg0KPiA+ICsgKiBSZWN1cnNpdmVseSBzY2FuIGFsbCB0aGUgY2hpbGRyZW4gbm9kZXMg
b2YgcGFyZW50IGFuZCBmaW5kIG91dCBpZg0KPiB0aGVyZQ0KPiA+ICsgKiBpcyAiaXNhIiBub2Rl
LiBSZXR1cm4gMSBpZiBwYXJlbnQgaGFzIGlzYSBub2RlIG90aGVyd2lzZSByZXR1cm4gMC4NCj4g
PiArICovDQo+ID4gK2ludCBoYXNfaXNhX25vZGUoc3RydWN0IGRldmljZV9ub2RlICpwYXJlbnQp
DQo+ID4gK3sNCj4gPiArCXN0YXRpYyBpbnQgcmVzdWx0Ow0KPiA+ICsJc3RydWN0IGRldmljZV9u
b2RlICpjdXJfY2hpbGQ7DQo+ID4gKw0KPiA+ICsJY3VyX2NoaWxkID0gTlVMTDsNCj4gPiArCXJl
c3VsdCA9IDA7DQo+ID4gKwl3aGlsZSAoIXJlc3VsdCAmJiAoY3VyX2NoaWxkID0gb2ZfZ2V0X25l
eHRfY2hpbGQocGFyZW50LA0KPiBjdXJfY2hpbGQpKSkgew0KPiA+ICsJCS8qIEdldCAiaXNhIiBu
b2RlIGFuZCByZXR1cm4gMSAqLw0KPiA+ICsJCWlmIChvZl9ub2RlX2NtcChjdXJfY2hpbGQtPnR5
cGUsICJpc2EiKSA9PSAwKQ0KPiA+ICsJCQlyZXR1cm4gcmVzdWx0ID0gMTsNCj4gPiArCQloYXNf
aXNhX25vZGUoY3VyX2NoaWxkKTsNCj4gPiArCX0NCj4gPiArDQo+ID4gKwlyZXR1cm4gcmVzdWx0
Ow0KPiA+ICt9DQo+IA0KPiBXaHkgYXJlIHlvdSByZWltcGxlbWVudGluZyB0aGlzPyAgSXQncyBh
bHJlYWR5IGluIExpbnVzJ3MgdHJlZS4gIFNlZQ0KPiBmc2xfcGNpX2luaXQoKS4NCj4gDQo+IFBs
dXMsIHlvdXIgdmVyc2lvbiBpcyByZWN1cnNpdmUgd2hpY2ggaXMgdW5hY2NlcHRhYmxlIGluIGtl
cm5lbCBjb2RlDQo+IHdpdGggYSBzbWFsbCBzdGFjayAob3V0c2lkZSBvZiBhIGZldyByYXJlIGV4
YW1wbGVzIHdoZXJlIHRoZSBkZXB0aCBoYXMgYQ0KPiBzbWFsbCBmaXhlZCB1cHBlciBib3VuZCks
IGFuZCBvbmNlIGl0IGZpbmRzIGFuIElTQSBub2RlLCBpdCByZXR1cm5zIDENCj4gZm9yZXZlciwg
cmVnYXJkbGVzcyBvZiB3aGF0IG5vZGUgeW91IHBhc3MgaW4gaW4gdGhlIGZ1dHVyZS4NCj4gDQo+
IC1TY290dA0KDQpZZXMsIHJlY3Vyc2l2ZSBmdW5jdGlvbiBpcyBub3QgcmVjb21tZW5kZWQgZm9y
IGtlcm5lbCBidXQgbWF5YmUgaXQncyBub3QgdW5hY2NlcHRhYmxlLg0KVGhpcyBmdW5jdGlvbiBp
cyBub3Qgc28gZGVlcCBzdGFja2VkIGFuZCBzaW1wbGUuIEluIG15IG9waW5pb24gdGhpcyBpcyBh
Y2NlcHRhYmxlLg0KDQpUaGFua3MuDQotSG9uZ3Rhby4NCg0K
^ 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