* RE: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
From: Tang Yuantian-B29983 @ 2013-04-17 2:44 UTC (permalink / raw)
To: Timur Tabi
Cc: devicetree-discuss, linuxppc-dev@lists.ozlabs.org, lkml,
Rob Herring
In-Reply-To: <CAOZdJXW8qKccGKic3R4o1aqJdbfHcBoAp62B4HPFnF=sUAEvuQ@mail.gmail.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUaW11ciBUYWJpIFttYWlsdG86
dGltdXJAdGFiaS5vcmddDQo+IFNlbnQ6IDIwMTPE6jTUwjE2yNUgMTk6MzcNCj4gVG86IFRhbmcg
WXVhbnRpYW4tQjI5OTgzDQo+IENjOiBHcmFudCBMaWtlbHk7IGRldmljZXRyZWUtZGlzY3Vzczsg
bGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGxrbWw7DQo+IFJvYiBIZXJyaW5nDQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggdjJdIG9mL2Jhc2U6IHJlbGVhc2UgdGhlIG5vZGUgY29ycmVjdGx5
IGluDQo+IG9mX3BhcnNlX3BoYW5kbGVfd2l0aF9hcmdzKCkNCj4gDQo+IE9uIFR1ZSwgQXByIDks
IDIwMTMgYXQgMTA6MzYgUE0sICA8WXVhbnRpYW4uVGFuZ0BmcmVlc2NhbGUuY29tPiB3cm90ZToN
Cj4gPg0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgIC8qIEZvdW5kIGl0ISByZXR1cm4gc3Vj
Y2VzcyAqLw0KPiANCj4gSSdtIHByZXR0eSBzdXJlIHRoaXMgY29tbWVudCBpcyBpbiB0aGUgd3Jv
bmcgcGxhY2UuDQoNCkl0IGlzIG5vdCBwZXJmZWN0LCBidXQgYWNjZXB0YWJsZS4NCg0KLVl1YW50
aWFuDQoNCg==
^ permalink raw reply
* Re: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
From: Timur Tabi @ 2013-04-17 3:30 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: devicetree-discuss, linuxppc-dev@lists.ozlabs.org, lkml,
Rob Herring
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B0B1456B8@039-SN2MPN1-013.039d.mgd.msft.net>
Tang Yuantian-B29983 wrote:
>> >On Tue, Apr 9, 2013 at 10:36 PM,<Yuantian.Tang@freescale.com> wrote:
>>> > >
>>> > >+ /* Found it! return success */
>> >
>> >I'm pretty sure this comment is in the wrong place.
> It is not perfect, but acceptable.
Like I said, I'm pretty sure it's in the wrong place.
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH V2 2/5] powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
From: Anshuman Khandual @ 2013-04-17 4:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, mikey, linux-kernel
In-Reply-To: <AAEA07FE-7530-46D3-B2FC-B3FD8EC2C6E2@kernel.crashing.org>
On 04/16/2013 10:53 PM, Segher Boessenkool wrote:
>> +/* r3 = n (where n = [0-1023])
>> + * The maximum number of BHRB entries supported with PPC_MFBHRBE
>> instruction
>> + * is 1024. We have limited number of table entries here as POWER8
>> implements
>> + * 32 BHRB entries.
>> + */
>> +
>> +/* .global read_bhrb */
>> +_GLOBAL(read_bhrb)
>> + cmpldi r3,1023
>
> This should be 31, since that is the last entry in the table below.
Hey Segher,
Would fix this in the next version. Thanks for pointing it out.
Regards
Anshuman
^ permalink raw reply
* RE: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
From: Tang Yuantian-B29983 @ 2013-04-17 4:49 UTC (permalink / raw)
To: Timur Tabi
Cc: devicetree-discuss, linuxppc-dev@lists.ozlabs.org, lkml,
Rob Herring
In-Reply-To: <516E1763.7040206@tabi.org>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVGltdXIgVGFiaSBbbWFp
bHRvOnRpbXVyQHRhYmkub3JnXQ0KPiBTZW50OiAyMDEzxOo01MIxN8jVIDExOjMxDQo+IFRvOiBU
YW5nIFl1YW50aWFuLUIyOTk4Mw0KPiBDYzogR3JhbnQgTGlrZWx5OyBkZXZpY2V0cmVlLWRpc2N1
c3M7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsa21sOw0KPiBSb2IgSGVycmluZw0K
PiBTdWJqZWN0OiBSZTogW1BBVENIIHYyXSBvZi9iYXNlOiByZWxlYXNlIHRoZSBub2RlIGNvcnJl
Y3RseSBpbg0KPiBvZl9wYXJzZV9waGFuZGxlX3dpdGhfYXJncygpDQo+IA0KPiBUYW5nIFl1YW50
aWFuLUIyOTk4MyB3cm90ZToNCj4gPj4gPk9uIFR1ZSwgQXByIDksIDIwMTMgYXQgMTA6MzYgUE0s
PFl1YW50aWFuLlRhbmdAZnJlZXNjYWxlLmNvbT4gIHdyb3RlOg0KPiA+Pj4gPiA+DQo+ID4+PiA+
ID4rICAgICAgICAgICAgICAgICAgICAgICAvKiBGb3VuZCBpdCEgcmV0dXJuIHN1Y2Nlc3MgKi8N
Cj4gPj4gPg0KPiA+PiA+SSdtIHByZXR0eSBzdXJlIHRoaXMgY29tbWVudCBpcyBpbiB0aGUgd3Jv
bmcgcGxhY2UuDQo+IA0KPiA+IEl0IGlzIG5vdCBwZXJmZWN0LCBidXQgYWNjZXB0YWJsZS4NCj4g
DQo+IExpa2UgSSBzYWlkLCBJJ20gcHJldHR5IHN1cmUgaXQncyBpbiB0aGUgd3JvbmcgcGxhY2Uu
DQo+IA0KDQpJdCB3YXMgcGxhY2VkIG9uIEVMU0Ugc3RhdGVtZW50IG9yaWdpbmFsbHksIEkgbW92
ZWQgaXQgdG8gSUYgc3RhdGVtZW50Lg0KV2h5IGlzIGl0IHNvIHdyb25nPw0KDQpUaGFua3MsDQpZ
dWFudGlhbg0K
^ permalink raw reply
* PowerPC, P2020RDB, application debug when the application is in tight loop, Sysrq
From: saikrishna gajula @ 2013-04-17 5:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mikey, linux-kernel, khandual
[-- Attachment #1: Type: text/plain, Size: 4135 bytes --]
HI All,
I am new to this group. I am working on Freescale P2020
platform running linux 2.6.21. I am looking for debug mechanism/utility,
when a multi threaded application running on linux , appears to be hung (
running in a tight loop,deadlock) while not able to access the board
through serial/SSH/Telnet.
I was looking at Magic sysrq option in linux to generate the stack,
register dump when the application is hung. I am able to dump the call
trace in normal working conditions. But i can't use echo t >
/proc/sysrq-trigger and debug when the application hung.
I am using below piece of code(drivers/serial/8250.c) on P2020RDB to debug
the application where in , in hung situation, when i press 'y' followed by
't' on serial console it should go to sysrq handler, and dump the call
trace, but it is not happening.(simply board hung)
{
if(sysrq_enable_flag)
handle_sysrq(ch, up->port.info->tty);
sysrq_enable_flag = 0;
if(ch == 'y')
sysrq_enable_flag = 1;
}
It would be helpful if you provide any hint on the issue, or any other way
to debug the application in hang situations.
Thanks,
Sai
On Tue, Apr 16, 2013 at 9:24 PM, Anshuman Khandual <
khandual@linux.vnet.ibm.com> wrote:
> Branch History Rolling Buffer (BHRB) is a new PMU feaure
> in IBM
> POWER8 processor which records the branch instructions inside the execution
> pipeline. This patchset enables the basic functionality of the feature
> through
> generic perf branch stack sampling framework.
>
> Sample output
> -------------
> $./perf record -b top
> $./perf report
>
> Overhead Command Source Shared Object Source
> Symbol Target Shared Object Target Symbol
> # ........ ....... ....................
> ...................................... ....................
> ...................................
> #
>
> 7.82% top libc-2.11.2.so [k] _IO_vfscanf
> libc-2.11.2.so [k] _IO_vfscanf
> 6.17% top libc-2.11.2.so [k] _IO_vfscanf
> [unknown] [k] 00000000
> 2.37% top [unknown] [k] 0xf7aafb30
> [unknown] [k] 00000000
> 1.80% top [unknown] [k] 0x0fe07978
> libc-2.11.2.so [k] _IO_vfscanf
> 1.60% top libc-2.11.2.so [k] _IO_vfscanf
> [kernel.kallsyms] [k] .do_task_stat
> 1.20% top [kernel.kallsyms] [k] .do_task_stat
> [kernel.kallsyms] [k] .do_task_stat
> 1.02% top libc-2.11.2.so [k] vfprintf
> libc-2.11.2.so [k] vfprintf
> 0.92% top top [k] _init
> [unknown] [k] 0x0fe037f4
>
> Changes in V2
> --------------
> - Added copyright messages to the newly created files
> - Modified couple of commit messages
>
> Anshuman Khandual (5):
> powerpc, perf: Add new BHRB related instructions on POWER8
> powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
> powerpc, perf: Add new BHRB related generic functions, data and flags
> powerpc, perf: Define BHRB generic functions, data and flags for POWER8
> powerpc, perf: Enable branch stack sampling framework support with BHRB
>
> arch/powerpc/include/asm/perf_event_server.h | 6 ++
> arch/powerpc/include/asm/ppc-opcode.h | 7 ++
> arch/powerpc/perf/Makefile | 2 +-
> arch/powerpc/perf/bhrb.S | 44 +++++++++++++
> arch/powerpc/perf/core-book3s.c | 96
> +++++++++++++++++++++++++++-
> arch/powerpc/perf/perf_event_bhrb.c | 85 ++++++++++++++++++++++++
> arch/powerpc/perf/power8-pmu.c | 57 ++++++++++++++++-
> 7 files changed, 292 insertions(+), 5 deletions(-)
> create mode 100644 arch/powerpc/perf/bhrb.S
> create mode 100644 arch/powerpc/perf/perf_event_bhrb.c
>
> --
> 1.7.11.7
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 5464 bytes --]
^ permalink raw reply
* Re: [PATCH 4/8] Read/Write oops nvram partition via pstore
From: Aruna Balakrishnaiah @ 2013-04-17 5:19 UTC (permalink / raw)
To: Michael Ellerman
Cc: jkenisto, mahesh, linux-kernel, linuxppc-dev, paulus, anton
In-Reply-To: <516CEDB4.9090005@linux.vnet.ibm.com>
On Tuesday 16 April 2013 11:50 AM, Aruna Balakrishnaiah wrote:
>
> Currently with this patchset, pstore is not supporting compression of
> oops-messages
> since it involves some changes in the pstore framework.
>
> big_oops_buf will hold the large part of oops data which will be compressed
> and put
> to oops_buf.
>
> big_oops_buf: (1.45 of oops_partition_size)
Sorry, big_oops_buf is (2.22 of oops_data_sz)
where oops_data_sz is oops_partition_size - sizeof(oops_log_info).
where oops_log_info is oops header.
> _________________________
> | header | oops-text |
> |_________|_____________|
>
> <header> is added by the pstore.
>
> So in case compression fails:
>
> we would need to log the header + last few bytes of big_oops_buf to oops_buf.
> oops_buf: (this is of oops_partition_size)
>
We would need to log the header + last oops_data_sz bytes of big_oops_buf to
oops_buf.
So that we can have the header while throwing away the data that immediately
follows it.
> we need last few bytes of big_oops_buf as we need to log the recent messages of
> printk buffer. For which we need to know the header size and it involves some
> changes in the pstore framework.
>
Just communicating the header size from pstore would do the job for us.
> I have the compression patches ready, will be posting it soon as a separate set.
>
>> cheers
>>
>
^ permalink raw reply
* Re: [PATCH V2 5/5] powerpc, perf: Enable branch stack sampling framework support with BHRB
From: Michael Ellerman @ 2013-04-17 7:08 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: linuxppc-dev, mikey, linux-kernel
In-Reply-To: <1366127650-1952-6-git-send-email-khandual@linux.vnet.ibm.com>
On Tue, Apr 16, 2013 at 09:24:10PM +0530, Anshuman Khandual wrote:
> This patch provides basic enablement for perf branch stack sampling framework
> on POWER8 processor with a new PMU feature called BHRB (Branch History Rolling
> Buffer).
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/core-book3s.c | 96 +++++++++++++++++++++++++++++++++++--
> arch/powerpc/perf/perf_event_bhrb.c | 85 ++++++++++++++++++++++++++++++++
> 2 files changed, 178 insertions(+), 3 deletions(-)
> create mode 100644 arch/powerpc/perf/perf_event_bhrb.c
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 4ac6e64..f4d1347 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -19,6 +19,8 @@
> #include <asm/firmware.h>
> #include <asm/ptrace.h>
>
> +#define BHRB_MAX_ENTRIES 32
> +
> struct cpu_hw_events {
> int n_events;
> int n_percpu;
> @@ -38,11 +40,21 @@ struct cpu_hw_events {
>
> unsigned int group_flag;
> int n_txn_start;
> +
> + /* BHRB bits */
> + u64 bhrb_filter; /* BHRB HW branch filter */
> + int bhrb_users;
> + void *bhrb_context;
> + struct perf_branch_stack bhrb_stack;
> + struct perf_branch_entry bhrb_entries[BHRB_MAX_ENTRIES];
> };
> +
> DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
>
> struct power_pmu *ppmu;
>
> +#include "perf_event_bhrb.c"
> +
Um, why are you doing that?
If it's code that should be in a header, put it in a header. If it's C
code, add it to the Makefile.
cheers
^ permalink raw reply
* [PATCH] powerpc: remove the unneeded trigger of decrementer interrupt in decrementer_check_overflow
From: Kevin Hao @ 2013-04-17 9:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc, Anton Blanchard
Previously in order to handle the edge sensitive decrementers,
we choose to set the decrementer to 1 to trigger a decrementer
interrupt when re-enabling interrupts. But with the rework of the
lazy EE, we would replay the decrementer interrupt when re-enabling
interrupts if a decrementer interrupt occurs with irq soft-disabled.
So there is no need to trigger a decrementer interrupt in this case
any more.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
arch/powerpc/kernel/irq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 4f97fe3..1af5744 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -116,8 +116,6 @@ static inline notrace int decrementer_check_overflow(void)
u64 now = get_tb_or_rtc();
u64 *next_tb = &__get_cpu_var(decrementers_next_tb);
- if (now >= *next_tb)
- set_dec(1);
return now >= *next_tb;
}
--
1.8.1.4
^ permalink raw reply related
* [PATCH] usb: remove redundant tdi_reset
From: Shengzhou Liu @ 2013-04-17 10:03 UTC (permalink / raw)
To: linuxppc-dev, stable, linux-usb; +Cc: Shengzhou Liu
We remove the redundant tdi_reset in ehci_setup since there
is already it in ehci_reset.
It was observed that the duplicated tdi_reset was causing
the PHY_CLK_VALID bit unstable.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
drivers/usb/host/ehci-hcd.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 416a6dc..83b5a17 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -670,9 +670,6 @@ int ehci_setup(struct usb_hcd *hcd)
if (retval)
return retval;
- if (ehci_is_TDI(ehci))
- tdi_reset(ehci);
-
ehci_reset(ehci);
return 0;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
From: Timur Tabi @ 2013-04-17 11:27 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: devicetree-discuss, linuxppc-dev@lists.ozlabs.org, lkml,
Rob Herring
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B0B1457D2@039-SN2MPN1-013.039d.mgd.msft.net>
Tang Yuantian-B29983 wrote:
> It was placed on ELSE statement originally, I moved it to IF statement.
> Why is it so wrong?
Because the logic of the comment applies to the else-condition, not the
if-condtion.
--
Timur Tabi
^ permalink raw reply
* RE: [PATCH] Enable CONFIG_DEVTMPFS_MOUNT to ensure /dev can be mounted correctly
From: Luo Zhenhua-B19537 @ 2013-04-17 11:46 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20130415050129.GB21147@concordia>
> -----Original Message-----
> From: Michael Ellerman [mailto:michael@ellerman.id.au]
> Sent: Monday, April 15, 2013 1:02 PM
>=20
> On Thu, Apr 11, 2013 at 09:56:30PM +0800, Zhenhua Luo wrote:
> > When using recent udev, the /dev node mount requires
> > CONFIG_DEVTMPFS_MOUNT is enabled in Kernel.
>=20
> Really?
>=20
> I know it makes life easier when you don't have an initramfs, but is it
> actually required now?
[Luo Zhenhua-B19537] I didn't use initramfs when the issue is found, I thin=
k the option is required to be enabled.=20
Best Regards,
Zhenhua
^ permalink raw reply
* Re: [PATCH V2 5/5] powerpc, perf: Enable branch stack sampling framework support with BHRB
From: Anshuman Khandual @ 2013-04-17 12:07 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, mikey, linux-kernel
In-Reply-To: <20130417070852.GA29203@concordia>
On 04/17/2013 12:38 PM, Michael Ellerman wrote:
> On Tue, Apr 16, 2013 at 09:24:10PM +0530, Anshuman Khandual wrote:
>> This patch provides basic enablement for perf branch stack sampling framework
>> on POWER8 processor with a new PMU feature called BHRB (Branch History Rolling
>> Buffer).
>>
>> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/perf/core-book3s.c | 96 +++++++++++++++++++++++++++++++++++--
>> arch/powerpc/perf/perf_event_bhrb.c | 85 ++++++++++++++++++++++++++++++++
>> 2 files changed, 178 insertions(+), 3 deletions(-)
>> create mode 100644 arch/powerpc/perf/perf_event_bhrb.c
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index 4ac6e64..f4d1347 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -19,6 +19,8 @@
>> #include <asm/firmware.h>
>> #include <asm/ptrace.h>
>>
>> +#define BHRB_MAX_ENTRIES 32
>> +
>> struct cpu_hw_events {
>> int n_events;
>> int n_percpu;
>> @@ -38,11 +40,21 @@ struct cpu_hw_events {
>>
>> unsigned int group_flag;
>> int n_txn_start;
>> +
>> + /* BHRB bits */
>> + u64 bhrb_filter; /* BHRB HW branch filter */
>> + int bhrb_users;
>> + void *bhrb_context;
>> + struct perf_branch_stack bhrb_stack;
>> + struct perf_branch_entry bhrb_entries[BHRB_MAX_ENTRIES];
>> };
>> +
>> DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
>>
>> struct power_pmu *ppmu;
>>
>> +#include "perf_event_bhrb.c"
>> +
>
> Um, why are you doing that?
>
There was no specific reason for that.
> If it's code that should be in a header, put it in a header. If it's C
> code, add it to the Makefile.
Sure I would get the new code in the Makefile. Thanks!
Regards
Anshuman
>
> cheers
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH] Enable CONFIG_DEVTMPFS_MOUNT to ensure /dev can be mounted correctly
From: Gary Thomas @ 2013-04-17 12:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CA452391058F6D4E9715FB2C29D9312A014D3107@039-SN2MPN1-021.039d.mgd.msft.net>
On 2013-04-17 05:46, Luo Zhenhua-B19537 wrote:
>> -----Original Message-----
>> From: Michael Ellerman [mailto:michael@ellerman.id.au]
>> Sent: Monday, April 15, 2013 1:02 PM
>>
>> On Thu, Apr 11, 2013 at 09:56:30PM +0800, Zhenhua Luo wrote:
>>> When using recent udev, the /dev node mount requires
>>> CONFIG_DEVTMPFS_MOUNT is enabled in Kernel.
>>
>> Really?
>>
>> I know it makes life easier when you don't have an initramfs, but is it
>> actually required now?
> [Luo Zhenhua-B19537] I didn't use initramfs when the issue is found, I think the option is required to be enabled.
>
Yes, it is required to get udev to work properly (versions of udev
newer than ~173)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds
From: Lucas Kannebley Tavares @ 2013-04-17 12:38 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: David Airlie, DRI mailing list, Kleber Sacilotto de Souza,
Alex Deucher, Jerome Glisse, Thadeu Lima de Souza Cascardo,
Brian King, linuxppc-dev
In-Reply-To: <CAErSpo7vxSJix83DQcsARPWYWbx8UGxQ9FN61OtEJrEv7GhK=g@mail.gmail.com>
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
> <lucaskt@linux.vnet.ibm.com> wrote:
>> radeon currently uses a drm function to get the speed capabilities for
>> the bus. However, this is a non-standard method of performing this
>> detection and this patch changes it to use the max_bus_speed attribute.
>> ---
>> drivers/gpu/drm/radeon/evergreen.c | 9 ++-------
>> drivers/gpu/drm/radeon/r600.c | 8 +-------
>> drivers/gpu/drm/radeon/rv770.c | 8 +-------
>> 3 files changed, 4 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c
>> index 305a657..3291f62 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
>>
>> void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
>> {
>> - u32 link_width_cntl, speed_cntl, mask;
>> - int ret;
>> + u32 link_width_cntl, speed_cntl;
>>
>> if (radeon_pcie_gen2 == 0)
>> return;
>> @@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
>> if (ASIC_IS_X2(rdev))
>> return;
>>
>> - ret = drm_pcie_get_speed_cap_mask(rdev->ddev,&mask);
>> - if (ret != 0)
>> - return;
>> -
>> - if (!(mask& DRM_PCIE_SPEED_50))
>> + if (rdev->pdev->bus->max_bus_speed< PCIE_SPEED_5_0GT)
>
> For devices on a root bus, we previously dereferenced a NULL pointer
> in drm_pcie_get_speed_cap_mask() because pdev->bus->self is NULL on a
> root bus. (I think this is the original problem you tripped over,
> Lucas.)
>
> These patches fix that problem. On pseries, where the device *is* on
> a root bus, your patches set max_bus_speed so this will work as
> expected. On most other systems, max_bus_speed for root buses will be
> PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
> most arches don't have code like the pseries code you're adding).
>
> PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
> the root bus, we'll attempt to enable Gen2 on the device even though
> we have no idea what the bus will support.
>
> That's why I originally suggested skipping the Gen2 stuff if
> "max_bus_speed == PCI_SPEED_UNKNOWN". I was just being conservative,
> thinking that it's better to have a functional but slow GPU rather
> than the unknown (to me) effects of enabling Gen2 on a link that might
> not support it. But I'm fine with this being either way.
You're right here, of course. I'll test for it being different from
5_0GT and 8_0GT instead. Though at some point I suppose someone will
want to tackle Gen3 speeds.
>
> It would be nice if we could get rid of drm_pcie_get_speed_cap_mask()
> altogether. It is exported, but I have no idea of anybody else uses
> it. Maybe it could at least be marked __deprecated now?
>
I'll mark it.
> I don't know who should take these patches. They don't touch
> drivers/pci, but I'd be happy to push them, given the appropriate ACKs
> from DRM and powerpc folks.
>
> Bjorn
>
>> return;
>>
>> speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
>> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
>> index 0740db3..64b90c0 100644
>> --- a/drivers/gpu/drm/radeon/r600.c
>> +++ b/drivers/gpu/drm/radeon/r600.c
>> @@ -4351,8 +4351,6 @@ static void r600_pcie_gen2_enable(struct radeon_device *rdev)
>> {
>> u32 link_width_cntl, lanes, speed_cntl, training_cntl, tmp;
>> u16 link_cntl2;
>> - u32 mask;
>> - int ret;
>>
>> if (radeon_pcie_gen2 == 0)
>> return;
>> @@ -4371,11 +4369,7 @@ static void r600_pcie_gen2_enable(struct radeon_device *rdev)
>> if (rdev->family<= CHIP_R600)
>> return;
>>
>> - ret = drm_pcie_get_speed_cap_mask(rdev->ddev,&mask);
>> - if (ret != 0)
>> - return;
>> -
>> - if (!(mask& DRM_PCIE_SPEED_50))
>> + if (rdev->pdev->bus->max_bus_speed< PCIE_SPEED_5_0GT)
>> return;
>>
>> speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
>> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
>> index d63fe1d..c683c36 100644
>> --- a/drivers/gpu/drm/radeon/rv770.c
>> +++ b/drivers/gpu/drm/radeon/rv770.c
>> @@ -1238,8 +1238,6 @@ static void rv770_pcie_gen2_enable(struct radeon_device *rdev)
>> {
>> u32 link_width_cntl, lanes, speed_cntl, tmp;
>> u16 link_cntl2;
>> - u32 mask;
>> - int ret;
>>
>> if (radeon_pcie_gen2 == 0)
>> return;
>> @@ -1254,11 +1252,7 @@ static void rv770_pcie_gen2_enable(struct radeon_device *rdev)
>> if (ASIC_IS_X2(rdev))
>> return;
>>
>> - ret = drm_pcie_get_speed_cap_mask(rdev->ddev,&mask);
>> - if (ret != 0)
>> - return;
>> -
>> - if (!(mask& DRM_PCIE_SPEED_50))
>> + if (rdev->pdev->bus->max_bus_speed< PCIE_SPEED_5_0GT)
>> return;
>>
>> DRM_INFO("enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0\n");
>> --
>> 1.7.4.4
>>
>
--
Lucas Kannebley Tavares
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCHv3 1/2] ppc64: perform proper max_bus_speed detection
From: Lucas Kannebley Tavares @ 2013-04-17 12:38 UTC (permalink / raw)
To: Michael Ellerman
Cc: David Airlie, Brian King, dri-devel, Kleber Sacilotto de Souza,
Alex Deucher, Jerome Glisse, Thadeu Lima de Souza Cascardo,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <20130415050001.GA21147@concordia>
On 04/15/2013 02:00 AM, Michael Ellerman wrote:
> On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote:
>> On pseries machines the detection for max_bus_speed should be done
>> through an OpenFirmware property. This patch adds a function to perform this
>> detection and a hook to perform dynamic adding of the function only for
>> pseries.
>
> The crucial detail you didn't mention is that pcibios_root_bridge_prepare()
> already exists as a weak function in the PCI code and is called from
> pci_create_root_bus().
Adding this comment.
>
>> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
>> index 8bcc9ca..15796b5 100644
>> --- a/arch/powerpc/platforms/pseries/setup.c
>> +++ b/arch/powerpc/platforms/pseries/setup.c
>> @@ -430,6 +430,8 @@ static void pSeries_machine_kexec(struct kimage *image)
>> }
>> #endif
>>
>> +int pseries_root_bridge_prepare(struct pci_host_bridge *bridge);
>> +
>
> Don't do that, put it in a header where it belongs.
>
And done as well.
> cheers
>
--
Lucas Kannebley Tavares
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCHv3 1/2] ppc64: perform proper max_bus_speed detection
From: Lucas Kannebley Tavares @ 2013-04-17 12:40 UTC (permalink / raw)
To: Michael Ellerman
Cc: David Airlie, Brian King, dri-devel, Kleber Sacilotto de Souza,
Alex Deucher, Jerome Glisse, Thadeu Lima de Souza Cascardo,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <20130415114202.GA12701@concordia>
On 04/15/2013 08:42 AM, Michael Ellerman wrote:
> On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote:
>> On pseries machines the detection for max_bus_speed should be done
>> through an OpenFirmware property. This patch adds a function to perform this
>> detection and a hook to perform dynamic adding of the function only for
>> pseries.
>
> This fails to build for me on ppc64_defconfig, with:
>
> arch/powerpc/include/asm/machdep.h:111:5: error: 'struct pci_host_bridge' declared inside parameter list [-Werror]
>
>
> Presumably you tested it using some other defconfig?
>
> cheers
>
Yes, I tested with another config, I did get warnings, though, so I
should've fixed that earlier.
Adding a forward declaration to prevent this from even throwing out
warnings.
--
Lucas Kannebley Tavares
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* RE: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
From: Grant Likely @ 2013-04-17 14:57 UTC (permalink / raw)
To: Tang Yuantian-B29983, Tang Yuantian-B29983
Cc: devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
rob.herring@calxeda.com
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B0B144FD3@039-SN2MPN1-013.039d.mgd.msft.net>
On Tue, 16 Apr 2013 06:54:40 +0000, Tang Yuantian-B29983 <B29983@freescale.com> wrote:
> Hi Grant.likely,
>
> I really preciate if you can spend some times to review this patch.
Applied, thanks.
g.
^ permalink raw reply
* Re: [PATCH] usb: remove redundant tdi_reset
From: Alan Stern @ 2013-04-17 15:03 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev, stable
In-Reply-To: <1366193026-20871-1-git-send-email-Shengzhou.Liu@freescale.com>
On Wed, 17 Apr 2013, Shengzhou Liu wrote:
> We remove the redundant tdi_reset in ehci_setup since there
> is already it in ehci_reset.
> It was observed that the duplicated tdi_reset was causing
> the PHY_CLK_VALID bit unstable.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> drivers/usb/host/ehci-hcd.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 416a6dc..83b5a17 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -670,9 +670,6 @@ int ehci_setup(struct usb_hcd *hcd)
> if (retval)
> return retval;
>
> - if (ehci_is_TDI(ehci))
> - tdi_reset(ehci);
> -
> ehci_reset(ehci);
>
> return 0;
Acked-by: Alan Stern <stern@rowland.harvard.edu>
This should be applied to stable kernels going back to 3.6.
In case you are wondering why that redudant call was added, I did it
because some of the PCI drivers (Intel and TDI) already had calls to
tdi_reset. The commit removed those calls, so the new one was added
in.
^ permalink raw reply
* Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
From: Linus Walleij @ 2013-04-17 15:42 UTC (permalink / raw)
To: Andrew Murray
Cc: linux-mips, siva.kallam, linux-pci, Thierry Reding, Liviu.Dudau,
Paul Mackerras, linux-samsung-soc, Russell King - ARM Linux,
Jingoo Han, Jason Gunthorpe, Thomas Abraham, Arnd Bergmann,
devicetree-discuss@lists.ozlabs.org, Rob Herring, Kukjin Kim,
bhelgaas@google.com, linux-arm-kernel@lists.infradead.org,
Thomas Petazzoni, Michal Simek, linux-kernel@vger.kernel.org,
suren.reddy, linuxppc-dev@lists.ozlabs.org list
In-Reply-To: <1366107508-12672-4-git-send-email-Andrew.Murray@arm.com>
On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray <Andrew.Murray@arm.com> wrote:
> This patch converts the pci_load_of_ranges function to use the new common
> of_pci_range_parser.
>
> Signed-off-by: Andrew Murray <Andrew.Murray@arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> Reviewed-by: Rob Herring <rob.herring@calxeda.com>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
From: Grant Likely @ 2013-04-17 16:00 UTC (permalink / raw)
To: Andrew Murray, linux-mips@linux-mips.org,
linuxppc-dev@lists.ozlabs.org
Cc: siva.kallam@samsung.com, linux-pci@vger.kernel.org,
linus.walleij@linaro.org, thierry.reding@avionic-design.de,
Liviu Dudau, paulus@samba.org, linux-samsung-soc@vger.kernel.org,
linux@arm.linux.org.uk, jg1.han@samsung.com,
jgunthorpe@obsidianresearch.com, thomas.abraham@linaro.org,
arnd@arndb.de, devicetree-discuss@lists.ozlabs.org,
rob.herring@calxeda.com, kgene.kim@samsung.com,
bhelgaas@google.com, linux-arm-kernel@lists.infradead.org,
thomas.petazzoni@free-electrons.com, monstr@monstr.eu,
linux-kernel@vger.kernel.org, suren.reddy@samsung.com
In-Reply-To: <20130416103005.GB12726@arm.com>
On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray@arm.com> wrote:
> On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> > property of a PCI host device, is found in both Microblaze and PowerPC
> > architectures. These implementations are nearly identical. This patch
> > moves this common code to a common place.
> >
> > Signed-off-by: Andrew Murray <Andrew.Murray@arm.com>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > Reviewed-by: Rob Herring <rob.herring@calxeda.com>
> > Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > Tested-by: Linus Walleij <linus.walleij@linaro.org>
> > Acked-by: Michal Simek <monstr@monstr.eu>
> > ---
> > arch/microblaze/include/asm/pci-bridge.h | 5 +-
> > arch/microblaze/pci/pci-common.c | 192 ----------------------------
> > arch/powerpc/include/asm/pci-bridge.h | 5 +-
> > arch/powerpc/kernel/pci-common.c | 192 ----------------------------
>
> Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
>
> I've tested that it builds on powerpc with a variety of configs (some which
> include fsl_pci.c implementation). Though I don't have hardware to verify that
> it works.
>
> I haven't tested this builds or runs on MIPS.
>
> You shouldn't see any difference in behaviour or new warnings and PCI devices
> should continue to operate as before.
I've got through a line-by-line comparison between powerpc, microblaze,
and then new code. The differences are purely cosmetic, so I have
absolutely no concerns about this patch. I've applied it to my tree.
g.
^ permalink raw reply
* Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
From: Jason Cooper @ 2013-04-17 16:10 UTC (permalink / raw)
To: Grant Likely
Cc: linux-mips@linux-mips.org, siva.kallam@samsung.com,
linux-pci@vger.kernel.org, linus.walleij@linaro.org,
thierry.reding@avionic-design.de, Liviu Dudau, Gregory CLEMENT,
paulus@samba.org, linux-samsung-soc@vger.kernel.org,
linux@arm.linux.org.uk, jg1.han@samsung.com,
jgunthorpe@obsidianresearch.com, thomas.abraham@linaro.org,
arnd@arndb.de, devicetree-discuss@lists.ozlabs.org,
rob.herring@calxeda.com, kgene.kim@samsung.com,
bhelgaas@google.com, linux-arm-kernel@lists.infradead.org,
thomas.petazzoni@free-electrons.com, monstr@monstr.eu,
linux-kernel@vger.kernel.org, Andrew Lunn,
suren.reddy@samsung.com, Olof Johansson, Andrew Murray,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130417160015.777453E2B73@localhost>
On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray@arm.com> wrote:
> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> > > property of a PCI host device, is found in both Microblaze and PowerPC
> > > architectures. These implementations are nearly identical. This patch
> > > moves this common code to a common place.
> > >
> > > Signed-off-by: Andrew Murray <Andrew.Murray@arm.com>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > > Reviewed-by: Rob Herring <rob.herring@calxeda.com>
> > > Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > > Tested-by: Linus Walleij <linus.walleij@linaro.org>
> > > Acked-by: Michal Simek <monstr@monstr.eu>
> > > ---
> > > arch/microblaze/include/asm/pci-bridge.h | 5 +-
> > > arch/microblaze/pci/pci-common.c | 192 ----------------------------
> > > arch/powerpc/include/asm/pci-bridge.h | 5 +-
> > > arch/powerpc/kernel/pci-common.c | 192 ----------------------------
> >
> > Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
> >
> > I've tested that it builds on powerpc with a variety of configs (some which
> > include fsl_pci.c implementation). Though I don't have hardware to verify that
> > it works.
> >
> > I haven't tested this builds or runs on MIPS.
> >
> > You shouldn't see any difference in behaviour or new warnings and PCI devices
> > should continue to operate as before.
>
> I've got through a line-by-line comparison between powerpc, microblaze,
> and then new code. The differences are purely cosmetic, so I have
> absolutely no concerns about this patch. I've applied it to my tree.
oops. Due to the number of dependencies the mvebu-pcie series has (this
being one of them, we (arm-soc/mvebu) asked if we could take this
through our tree. Rob Herring agreed to this several days ago. Is this
a problem for you?
It would truly (dogs and cats living together) upset the apple cart for
us at this stage to pipe these through a different tree...
thx,
Jason.
^ permalink raw reply
* Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
From: Grant Likely @ 2013-04-17 16:17 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-mips@linux-mips.org, siva.kallam@samsung.com,
linux-pci@vger.kernel.org, linus.walleij@linaro.org,
thierry.reding@avionic-design.de, Liviu Dudau, Gregory CLEMENT,
paulus@samba.org, linux-samsung-soc@vger.kernel.org,
linux@arm.linux.org.uk, jg1.han@samsung.com,
jgunthorpe@obsidianresearch.com, thomas.abraham@linaro.org,
arnd@arndb.de, devicetree-discuss@lists.ozlabs.org,
rob.herring@calxeda.com, kgene.kim@samsung.com,
bhelgaas@google.com, linux-arm-kernel@lists.infradead.org,
thomas.petazzoni@free-electrons.com, monstr@monstr.eu,
linux-kernel@vger.kernel.org, Andrew Lunn,
suren.reddy@samsung.com, Olof Johansson, Andrew Murray,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130417161036.GB27197@titan.lakedaemon.net>
On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
>> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray@arm.com> wrote:
>> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
>> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
>> > > property of a PCI host device, is found in both Microblaze and PowerPC
>> > > architectures. These implementations are nearly identical. This patch
>> > > moves this common code to a common place.
>> > >
>> > > Signed-off-by: Andrew Murray <Andrew.Murray@arm.com>
>> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>> > > Reviewed-by: Rob Herring <rob.herring@calxeda.com>
>> > > Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> > > Tested-by: Linus Walleij <linus.walleij@linaro.org>
>> > > Acked-by: Michal Simek <monstr@monstr.eu>
>> > > ---
>> > > arch/microblaze/include/asm/pci-bridge.h | 5 +-
>> > > arch/microblaze/pci/pci-common.c | 192 ----------------------------
>> > > arch/powerpc/include/asm/pci-bridge.h | 5 +-
>> > > arch/powerpc/kernel/pci-common.c | 192 ----------------------------
>> >
>> > Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
>> >
>> > I've tested that it builds on powerpc with a variety of configs (some which
>> > include fsl_pci.c implementation). Though I don't have hardware to verify that
>> > it works.
>> >
>> > I haven't tested this builds or runs on MIPS.
>> >
>> > You shouldn't see any difference in behaviour or new warnings and PCI devices
>> > should continue to operate as before.
>>
>> I've got through a line-by-line comparison between powerpc, microblaze,
>> and then new code. The differences are purely cosmetic, so I have
>> absolutely no concerns about this patch. I've applied it to my tree.
>
> oops. Due to the number of dependencies the mvebu-pcie series has (this
> being one of them, we (arm-soc/mvebu) asked if we could take this
> through our tree. Rob Herring agreed to this several days ago. Is this
> a problem for you?
>
> It would truly (dogs and cats living together) upset the apple cart for
> us at this stage to pipe these through a different tree...
Not a problem at all. I'll drop it.
g.
^ permalink raw reply
* Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
From: Jason Cooper @ 2013-04-17 16:22 UTC (permalink / raw)
To: Grant Likely
Cc: linux-mips@linux-mips.org, siva.kallam@samsung.com,
linux-pci@vger.kernel.org, linus.walleij@linaro.org,
thierry.reding@avionic-design.de, Liviu Dudau, Gregory CLEMENT,
paulus@samba.org, linux-samsung-soc@vger.kernel.org,
linux@arm.linux.org.uk, jg1.han@samsung.com,
jgunthorpe@obsidianresearch.com, thomas.abraham@linaro.org,
arnd@arndb.de, devicetree-discuss@lists.ozlabs.org,
rob.herring@calxeda.com, kgene.kim@samsung.com,
bhelgaas@google.com, linux-arm-kernel@lists.infradead.org,
thomas.petazzoni@free-electrons.com, monstr@monstr.eu,
linux-kernel@vger.kernel.org, Andrew Lunn,
suren.reddy@samsung.com, Olof Johansson, Andrew Murray,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CACxGe6sNk=wNinTcMHbJa5o-56Tyh=0CnFSEW+Hk-ujpjeg2gQ@mail.gmail.com>
On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote:
> On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote:
> >> On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray <andrew.murray@arm.com> wrote:
> >> > On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote:
> >> > > The pci_process_bridge_OF_ranges function, used to parse the "ranges"
> >> > > property of a PCI host device, is found in both Microblaze and PowerPC
> >> > > architectures. These implementations are nearly identical. This patch
> >> > > moves this common code to a common place.
> >> > >
> >> > > Signed-off-by: Andrew Murray <Andrew.Murray@arm.com>
> >> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >> > > Reviewed-by: Rob Herring <rob.herring@calxeda.com>
> >> > > Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >> > > Tested-by: Linus Walleij <linus.walleij@linaro.org>
> >> > > Acked-by: Michal Simek <monstr@monstr.eu>
> >> > > ---
> >> > > arch/microblaze/include/asm/pci-bridge.h | 5 +-
> >> > > arch/microblaze/pci/pci-common.c | 192 ----------------------------
> >> > > arch/powerpc/include/asm/pci-bridge.h | 5 +-
> >> > > arch/powerpc/kernel/pci-common.c | 192 ----------------------------
> >> >
> >> > Is there anyone on linuxppc-dev/linux-mips that can help test this patchset?
> >> >
> >> > I've tested that it builds on powerpc with a variety of configs (some which
> >> > include fsl_pci.c implementation). Though I don't have hardware to verify that
> >> > it works.
> >> >
> >> > I haven't tested this builds or runs on MIPS.
> >> >
> >> > You shouldn't see any difference in behaviour or new warnings and PCI devices
> >> > should continue to operate as before.
> >>
> >> I've got through a line-by-line comparison between powerpc, microblaze,
> >> and then new code. The differences are purely cosmetic, so I have
> >> absolutely no concerns about this patch. I've applied it to my tree.
> >
> > oops. Due to the number of dependencies the mvebu-pcie series has (this
> > being one of them, we (arm-soc/mvebu) asked if we could take this
> > through our tree. Rob Herring agreed to this several days ago. Is this
> > a problem for you?
> >
> > It would truly (dogs and cats living together) upset the apple cart for
> > us at this stage to pipe these through a different tree...
>
> Not a problem at all. I'll drop it.
Great! Thanks.
Jason.
^ permalink raw reply
* questions around Book III-E and branch trace
From: Chris Friesen @ 2013-04-17 18:44 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev, Benjamin Herrenschmidt, Paul Mackerras
Hi,
I'm trying to wrap my head around how linux handles branch tracing on
Book III-E. I think I understand how we set MSR[DE] and DBCR0[IDM|BT],
and how we handle fixing things up if an instruction being traced causes
an exception.
I have a few questions though:
1) Does user_enable_block_step() have a bug in it? The current code has
task->thread.dbcr0 = DBCR0_IDM | DBCR0_BT;
Should that be as follows (to match the singel-step case)?
task->thread.dbcr0 |= DBCR0_IDM | DBCR0_BT;
2) Why doesn't DBCR0_ACTIVE_EVENTS include DBCR0_BT?
3) In sys_debug_setcontext() why does SIG_DBG_BRANCH_TRACING return
-EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set? Would it not be possible
to use DBCR0_BT?
Thanks,
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.friesen@genband.com
^ permalink raw reply
* Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds
From: Alex Deucher @ 2013-04-17 20:04 UTC (permalink / raw)
To: Lucas Kannebley Tavares
Cc: Brian King, DRI mailing list, Kleber Sacilotto de Souza,
Alex Deucher, Jerome Glisse, Thadeu Lima de Souza Cascardo,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <516E97A9.7050102@linux.vnet.ibm.com>
On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
<lucaskt@linux.vnet.ibm.com> wrote:
> On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
>>
>> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
>> <lucaskt@linux.vnet.ibm.com> wrote:
>>>
>>> radeon currently uses a drm function to get the speed capabilities for
>>> the bus. However, this is a non-standard method of performing this
>>> detection and this patch changes it to use the max_bus_speed attribute.
>>> ---
>>> drivers/gpu/drm/radeon/evergreen.c | 9 ++-------
>>> drivers/gpu/drm/radeon/r600.c | 8 +-------
>>> drivers/gpu/drm/radeon/rv770.c | 8 +-------
>>> 3 files changed, 4 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/evergreen.c
>>> b/drivers/gpu/drm/radeon/evergreen.c
>>> index 305a657..3291f62 100644
>>> --- a/drivers/gpu/drm/radeon/evergreen.c
>>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>>> @@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
>>>
>>> void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
>>> {
>>> - u32 link_width_cntl, speed_cntl, mask;
>>> - int ret;
>>> + u32 link_width_cntl, speed_cntl;
>>>
>>> if (radeon_pcie_gen2 == 0)
>>> return;
>>> @@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct
>>> radeon_device *rdev)
>>> if (ASIC_IS_X2(rdev))
>>> return;
>>>
>>> - ret = drm_pcie_get_speed_cap_mask(rdev->ddev,&mask);
>>> - if (ret != 0)
>>> - return;
>>> -
>>> - if (!(mask& DRM_PCIE_SPEED_50))
>>>
>>> + if (rdev->pdev->bus->max_bus_speed< PCIE_SPEED_5_0GT)
>>
>>
>> For devices on a root bus, we previously dereferenced a NULL pointer
>> in drm_pcie_get_speed_cap_mask() because pdev->bus->self is NULL on a
>> root bus. (I think this is the original problem you tripped over,
>> Lucas.)
>>
>> These patches fix that problem. On pseries, where the device *is* on
>> a root bus, your patches set max_bus_speed so this will work as
>> expected. On most other systems, max_bus_speed for root buses will be
>> PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
>> most arches don't have code like the pseries code you're adding).
>>
>> PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
>> the root bus, we'll attempt to enable Gen2 on the device even though
>> we have no idea what the bus will support.
>>
>> That's why I originally suggested skipping the Gen2 stuff if
>> "max_bus_speed == PCI_SPEED_UNKNOWN". I was just being conservative,
>> thinking that it's better to have a functional but slow GPU rather
>> than the unknown (to me) effects of enabling Gen2 on a link that might
>> not support it. But I'm fine with this being either way.
>
>
> You're right here, of course. I'll test for it being different from 5_0GT
> and 8_0GT instead. Though at some point I suppose someone will want to
> tackle Gen3 speeds.
drm_pcie_get_speed_cap_mask() actually checked the pci bridge to see
what speeds it supported. If the new code doesn't actually check the
bridge caps then the new code does not seem like a valid replacement
unless I'm missing something.
Alex
>
>
>>
>> It would be nice if we could get rid of drm_pcie_get_speed_cap_mask()
>> altogether. It is exported, but I have no idea of anybody else uses
>> it. Maybe it could at least be marked __deprecated now?
>>
>
> I'll mark it.
>
>> I don't know who should take these patches. They don't touch
>> drivers/pci, but I'd be happy to push them, given the appropriate ACKs
>> from DRM and powerpc folks.
>>
>> Bjorn
>>
>>> return;
>>>
>>> speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
>>> diff --git a/drivers/gpu/drm/radeon/r600.c
>>> b/drivers/gpu/drm/radeon/r600.c
>>> index 0740db3..64b90c0 100644
>>> --- a/drivers/gpu/drm/radeon/r600.c
>>> +++ b/drivers/gpu/drm/radeon/r600.c
>>> @@ -4351,8 +4351,6 @@ static void r600_pcie_gen2_enable(struct
>>> radeon_device *rdev)
>>> {
>>> u32 link_width_cntl, lanes, speed_cntl, training_cntl, tmp;
>>> u16 link_cntl2;
>>> - u32 mask;
>>> - int ret;
>>>
>>> if (radeon_pcie_gen2 == 0)
>>> return;
>>> @@ -4371,11 +4369,7 @@ static void r600_pcie_gen2_enable(struct
>>> radeon_device *rdev)
>>> if (rdev->family<= CHIP_R600)
>>> return;
>>>
>>> - ret = drm_pcie_get_speed_cap_mask(rdev->ddev,&mask);
>>> - if (ret != 0)
>>> - return;
>>> -
>>> - if (!(mask& DRM_PCIE_SPEED_50))
>>>
>>> + if (rdev->pdev->bus->max_bus_speed< PCIE_SPEED_5_0GT)
>>> return;
>>>
>>> speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
>>> diff --git a/drivers/gpu/drm/radeon/rv770.c
>>> b/drivers/gpu/drm/radeon/rv770.c
>>> index d63fe1d..c683c36 100644
>>> --- a/drivers/gpu/drm/radeon/rv770.c
>>> +++ b/drivers/gpu/drm/radeon/rv770.c
>>> @@ -1238,8 +1238,6 @@ static void rv770_pcie_gen2_enable(struct
>>> radeon_device *rdev)
>>> {
>>> u32 link_width_cntl, lanes, speed_cntl, tmp;
>>> u16 link_cntl2;
>>> - u32 mask;
>>> - int ret;
>>>
>>> if (radeon_pcie_gen2 == 0)
>>> return;
>>> @@ -1254,11 +1252,7 @@ static void rv770_pcie_gen2_enable(struct
>>> radeon_device *rdev)
>>> if (ASIC_IS_X2(rdev))
>>> return;
>>>
>>> - ret = drm_pcie_get_speed_cap_mask(rdev->ddev,&mask);
>>> - if (ret != 0)
>>> - return;
>>> -
>>> - if (!(mask& DRM_PCIE_SPEED_50))
>>>
>>> + if (rdev->pdev->bus->max_bus_speed< PCIE_SPEED_5_0GT)
>>> return;
>>>
>>> DRM_INFO("enabling PCIE gen 2 link speeds, disable with
>>> radeon.pcie_gen2=0\n");
>>> --
>>> 1.7.4.4
>>>
>>
>
>
> --
> Lucas Kannebley Tavares
> Software Engineer
> IBM Linux Technology Center
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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