LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* 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

* 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: [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

* 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: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: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 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] 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 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: [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: [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 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: [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: [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: 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] 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

* [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

* [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

* 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

* 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

* 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 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

* 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: 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] 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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox