On Wed, 2012-07-25 at 02:40 +, 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
> >
On Mon, Jul 23, 2012 at 12:32 AM, Benjamin Herrenschmidt
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 nececssa
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=freescale@lists.ozlabs.org] On Behalf Of Scott Wood
> Sent: Wednesday, July 25, 2012 2:33 AM
> To: Tabi Timur-B04825
> Cc: linuxppc-...@ozlabs.org
> Subject: Re: [PATCH] powerpc/p5040ds: Add support
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 25, 2012 2:48 AM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Wood Scott-
> B07421; Li Yang-R58472
> Subject: Re: [PATCH 3/6] powerpc/fsl-pci: Determine primary bus by
> look
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 i
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 25, 2012 2:43 AM
> To: Jia Hongtao-B38951
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Wood Scott-
> B07421; Li Yang-R58472
> Subject: Re: [PATCH 1/6] powerpc/fsl-pci: Unify pci/pcie initialization
>
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);
>
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
---
arch/powerpc/kvm/bookehv_interrupts.S | 77 +
1 files c
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 a
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
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 th
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
_
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-B
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
#de
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
>
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
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
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 boar
Scott Wood wrote:
>> > + flash@0,0 {
>> > + compatible = "cfi-flash";
>> > + reg = <0 0 0x0800>;
>> > + bank-width = <2>;
>> > + device-width = <2>;
>> > + };
> No partitions on NOR flash?
None of the CoreNet
"Aneesh Kumar K.V" 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,
>i
Scott Wood wrote:
>> +/include/ "qoriq-mpic.dtsi"
>> +
>> +guts: global-utilities@e {
>> +compatible = "fsl,qoriq-device-config-1.0";
>> +reg = <0xe 0xe00>;
>> +fsl,has-rstcr;
>> +#sleep-cells = <1>;
>> +fsl,liodn-bits = <12>;
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, b
On 07/24/2012 05:20 AM, Jia Hongtao wrote:
> PCI host bridge is primary bus if it contains an ISA node. But not all boards
> fit this rule. Device tree should be updated for all these boards.
>
> Signed-off-by: Jia Hongtao
> Signed-off-by: Li Yang
> ---
> arch/powerpc/include/asm/pci-bridge.h |
On 07/24/2012 05:20 AM, Jia Hongtao wrote:
> We unified the Freescale pci/pcie initialization by changing the fsl_pci
> to a platform driver.
>
> In previous version pci/pcie initialization is in platform code which
> Initialize pci bridge base on EP/RC or host/agent settings.
The previous versio
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 0x20 */
>>> +&pci0 {
>>> + compatible = "fsl,p5040-pcie", "fsl,qoriq-pcie-v2.2";
>>
>> p5040 has PCIe v2.4.
>
> Then it's broken on the SDK as well.
Yes. There w
Scott Wood wrote:
> On 07/24/2012 11:42 AM, Timur Tabi wrote:
>> +/* controller at 0x20 */
>> +&pci0 {
>> +compatible = "fsl,p5040-pcie", "fsl,qoriq-pcie-v2.2";
>
> p5040 has PCIe v2.4.
Then it's broken on the SDK as well.
> Note that there is a version register, so perhaps we should dro
On 07/24/2012 11:42 AM, Timur Tabi wrote:
> +/* controller at 0x20 */
> +&pci0 {
> + 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
Add support for the Freescale P5040DS Reference Board ("Superhydra"), which
is similar to the P5020DS. Features of the P5040 are listed below, but
not all of these features (e.g. DPAA networking) are currently supported.
Four P5040 single-threaded e5500 cores built
Up to 2.4 GHz with 64-bit I
Add support for the Freescale P5040DS Reference Board ("Superhydra"), which
is similar to the P5020DS. Features of the P5040 are listed below, but
not all of these features (e.g. DPAA networking) are currently supported.
Four P5040 single-threaded e5500 cores built
Up to 2.4 GHz with 64-bit I
Thanks David for the comments.
Response Inline.
Regards
Poonam
> -Original Message-
> From: David Laight [mailto:david.lai...@aculab.com]
> Sent: Monday, July 23, 2012 6:02 PM
> To: Singh Sandeep-B37400; linuxppc-dev@lists.ozlabs.org
> Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812
> Su
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
Hi Timur,
Thanks for your comments, please find response inline.
Regards,
Sandeep
-Original Message-
From: Tabi Timur-B04825
Sent: Monday, July 23, 2012 10:03 PM
To: Singh Sandeep-B37400
Cc: linuxppc-dev@lists.ozlabs.org; Singh Sandeep-B37400; Aggrwal Poonam-B10812
Subject: Re: [2/3][P
From: Chunhe Lan
Now we registered pci controllers as platform devices. It will make edac
driver failed to register pci nodes as platform devices too. So we combine
two initialization code as one platform driver.
Signed-off-by: Chunhe Lan
Signed-off-by: Li Yang
Signed-off-by: Jia Hongtao
---
Power supply for PCI inbound/outbound window registers is off when system
go to deep-sleep state. We save the values of registers before suspend
and restore to registers after resume.
Signed-off-by: Jiang Yutang
Signed-off-by: Jia Hongtao
Signed-off-by: Li Yang
---
arch/powerpc/include/asm/pci
PCI initialization is now done by PCI controller driver. In board setup_arch
stage we don't need PCI init any more but swiotlb should be determined at this
stage.
Signed-off-by: Jia Hongtao
Signed-off-by: Li Yang
---
arch/powerpc/platforms/85xx/common.c |9
arch/powerpc/platforms/8
PCI host bridge is primary bus if it contains an ISA node. But not all boards
fit this rule. Device tree should be updated for all these boards.
Signed-off-by: Jia Hongtao
Signed-off-by: Li Yang
---
arch/powerpc/include/asm/pci-bridge.h |1 +
arch/powerpc/sysdev/fsl_pci.c | 31 +++
PCI initialization is called later than swiotlb_init() due to PCI controller is
a platform driver now. So we provide a function which called at board setup_arch
stage to address swiotlb enable by parsing pci ranges.
Signed-off-by: Jia Hongtao
Signed-off-by: Li Yang
---
arch/powerpc/sysdev/fsl_p
We unified the Freescale pci/pcie initialization by changing the fsl_pci
to a platform driver.
In previous version pci/pcie initialization is in platform code which
Initialize pci bridge base on EP/RC or host/agent settings.
Signed-off-by: Jia Hongtao
Signed-off-by: Li Yang
---
arch/powerpc/sy
Scott Wood freescale.com> writes:
>
> On 07/23/2012 10:34 AM, Geoffrey Bugniot wrote:
> > I got something like that :
> > [ 148.891584] Kernel panic - not syncing: Attempted to kill init!
>
> Was there anything before this?
>
No, that's the complete dump.
> > [ 148.897503] Call Trace:
> >
"Aneesh Kumar K.V" writes:
> Paul Mackerras writes:
>
>> On Mon, Jul 23, 2012 at 03:52:05PM +0530, Aneesh Kumar K.V wrote:
>>> Paul Mackerras writes:
>>>
>>> > On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote:
>>> >
>>> >> -#define USER_ESID_BITS 16
>>> >> -#define USE
Paul Mackerras writes:
> On Mon, Jul 23, 2012 at 03:52:05PM +0530, Aneesh Kumar K.V wrote:
>> Paul Mackerras writes:
>>
>> > On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote:
>> >
>> >> -#define USER_ESID_BITS 16
>> >> -#define USER_ESID_BITS_1T4
>> >> +#define
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Benjamin
> Herrenschmidt
> Sent: Tuesday, July 24, 2012 10:16 AM
> To: Tabi Timur-B04825
> Cc: Wood Scott-B07421; Hu Mingkai-B21284; linuxppc-dev@lists.ozl
The pseries hvterm driver only registers a udbg backend (for xmon and
other low level debugging mechanisms) when hvc0 is recognized as the
firmware console at boot time, not if it's detected later on, for
example because the firmware is using a graphics card.
This can make debugging challenging es
hvc_console has two methods to instanciate the consoles.
hvc_instanciate is meant to be called at early boot, while hvc_alloc is
called for more dynamically probed objects.
Currently, it only deals with adding kernel consoles in the former case,
which means for example that if a console only uses
44 matches
Mail list logo
