* [PATCH RFC v13 3/5] dma: of: add common xlate function for matching by channel id
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1400163335-29853-1-git-send-email-a13xp0p0v88@gmail.com>
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When registering the of dma provider with
of_dma_controller_register a pointer to the dma_device struct which is
associated with the dt node needs to passed as the data parameter.
New function will use this pointer to match only channels which belong to the
specified DMA controller.
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
drivers/dma/of-dma.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/of_dma.h | 4 ++++
2 files changed, 39 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index e8fe9dc..d5fbeaa 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -218,3 +218,38 @@ struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
&dma_spec->args[0]);
}
EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+/**
+ * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel id
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ * @of_dma: pointer to DMA controller data
+ *
+ * This function can be used as the of xlate callback for DMA driver which wants
+ * to match the channel based on the channel id. When using this xlate function
+ * the #dma-cells propety of the DMA controller dt node needs to be set to 1.
+ * The data parameter of of_dma_controller_register must be a pointer to the
+ * dma_device struct the function should match upon.
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct dma_device *dev = ofdma->of_dma_data;
+ struct dma_chan *chan, *candidate = NULL;
+
+ if (!dev || dma_spec->args_count != 1)
+ return NULL;
+
+ list_for_each_entry(chan, &dev->channels, device_node)
+ if (chan->chan_id == dma_spec->args[0]) {
+ candidate = chan;
+ break;
+ }
+
+ if (!candidate)
+ return NULL;
+
+ return dma_get_slave_channel(candidate);
+}
+EXPORT_SYMBOL_GPL(of_dma_xlate_by_chan_id);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..56bc026 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -41,6 +41,8 @@ extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
const char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
+extern struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -66,6 +68,8 @@ static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_s
return NULL;
}
+#define of_dma_xlate_by_chan_id NULL
+
#endif
#endif /* __LINUX_OF_DMA_H */
--
1.8.4.2
^ permalink raw reply related
* [PATCH RFC v13 4/5] dma: mpc512x: add device tree binding document
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1400163335-29853-1-git-send-email-a13xp0p0v88@gmail.com>
Introduce a device tree binding document for the MPC512x DMA controller
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
.../devicetree/bindings/dma/mpc512x-dma.txt | 40 ++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
new file mode 100644
index 0000000..b1cbc3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
@@ -0,0 +1,40 @@
+* Freescale MPC512x and MPC8308 DMA Controller
+
+The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
+blocks of memory contents between memory and peripherals or
+from memory to memory.
+
+Refer to "Generic DMA Controller and DMA request bindings" in
+the dma/dma.txt file for a more detailed description of binding.
+
+Required properties:
+- compatible: Should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma"
+- reg: Address and size of the DMA controller's register set
+- Interrupt for the DMA controller. Syntax of interrupt client node
+ is described in interrupt-controller/interrupts.txt
+
+Optional properties:
+- #dma-cells: The length of the DMA specifier, must be <1>.
+ Each channel of this DMA controller has a peripheral request line,
+ this assignment is fixed in hardware. The cell in dmas property
+ of a client device represents the channel number
+
+Example:
+
+ dma0: dma@14000 {
+ compatible = "fsl,mpc5121-dma";
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ #dma-cells = <1>;
+ };
+
+DMA clients must use the format described in dma/dma.txt
+
+Example:
+
+ sdhc@1500 {
+ compatible = "fsl,mpc5121-sdhc";
+ /* ... */
+ dmas = <&dma0 30>;
+ dma-names = "rx-tx";
+ };
--
1.8.4.2
^ permalink raw reply related
* [PATCH RFC v13 5/5] dma: mpc512x: register for device tree channel lookup
From: Alexander Popov @ 2014-05-15 14:15 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine
Cc: devicetree
In-Reply-To: <1400163335-29853-1-git-send-email-a13xp0p0v88@gmail.com>
Register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees) and
provide the '#dma-cells' property in the shared mpc5121.dtsi file
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 13 ++++++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index 2c0e155..7f9d14f 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -498,6 +498,7 @@
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
+ #dma-cells = <1>;
};
};
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 2ad4373..881db2b 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -53,6 +53,7 @@
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
+#include <linux/of_dma.h>
#include <linux/of_platform.h>
#include <linux/random.h>
@@ -1036,7 +1037,15 @@ static int mpc_dma_probe(struct platform_device *op)
if (retval)
goto err_free2;
- return retval;
+ /* Register with OF helpers for DMA lookups (nonfatal) */
+ if (dev->of_node) {
+ retval = of_dma_controller_register(dev->of_node,
+ of_dma_xlate_by_chan_id, mdma);
+ if (retval)
+ dev_warn(dev, "Could not register for OF lookup\n");
+ }
+
+ return 0;
err_free2:
if (mdma->is_mpc8308)
@@ -1057,6 +1066,8 @@ static int mpc_dma_remove(struct platform_device *op)
struct device *dev = &op->dev;
struct mpc_dma *mdma = dev_get_drvdata(dev);
+ if (dev->of_node)
+ of_dma_controller_free(dev->of_node);
dma_async_device_unregister(&mdma->dma);
if (mdma->is_mpc8308) {
free_irq(mdma->irq2, mdma);
--
1.8.4.2
^ permalink raw reply related
* Re: roundup_pow_of_two() may not handle 64-bit integers
From: David Howells @ 2014-05-15 15:03 UTC (permalink / raw)
To: Brian Norris
Cc: Linux Kernel, dhowells, Paul Mackerras, Andrew Morton,
linuxppc-dev
In-Reply-To: <20140515022238.GL28907@ld-irv-0074>
Brian Norris <computersforpeace@gmail.com> wrote:
> I'm looking to use roundup_pow_of_two() (actually, order_base_2())
> from <linux/log2.h>, but it seems that it only supports 64-bit integers
> if your toolchain uses a 64-bit 'unsigned long' type. This is strange,
> considering that ilog2() is explicitly designed for 32-bit or 64-bit
> compatibility.
ilog2() was explicitly designed for use with 'unsigned long'. See the commit
description (f0d1b0b30d250a07627ad8b9fbbb5c7cc08422e8). It may work with
unsigned long long, however...
David
^ permalink raw reply
* Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Grant Likely @ 2014-05-15 14:59 UTC (permalink / raw)
To: Leif Lindholm, Mark Rutland
Cc: devicetree@vger.kernel.org, patches@linaro.org, Lee Jones,
linux-kernel@vger.kernel.org, Rob Herring, Geert Uytterhoeven,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140424092642.GQ5904@bivouac.eciton.net>
On Thu, 24 Apr 2014 10:26:42 +0100, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Wed, Apr 23, 2014 at 02:10:58PM +0100, Grant Likely wrote:
> > > Does anyone have a LongTrail DT to hand, and if so does the root have a
> > > compatible string? From grepping through the kernel I could only find a
> > > model string ("IBM,LongTrail").
> >
> > Actually, on LongTrail this can be removed from the common code
> > entirely. It has real open firmware and PowerPC already has the
> > infrastructure for fixing up the device tree.
> >
> > Here's a draft patch that I've compile tested, but nothing else.
>
> I would certainly be happy with that.
>
> Consider my 3/3 withdrawn.
>
> And if the kernel proper will stop honoring nodes with no type,
> there is no need for the stub to treat those specially either.
So, after thinking about it some more, I've changed my minde about the
whole thing again. The impact is quite contained because there weren't a
lot of systems that had ram based at 0. I'm going to commit this patch,
but I'll include a note in the commit text that if it causes trouble for
anyone that they should yell and I'll revert it. I don't think it will
though.
g.
^ permalink raw reply
* [PATCH] selftests: PAGE_SIZE may not be defined
From: Thierry Fauck ( thierry @ linux.vnet.ibm.com ) @ 2014-05-15 16:02 UTC (permalink / raw)
To: benh, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
Hi Ben,
The following patch seems relevant for Ubuntu and Debian distro testing.
I know it's minor but I need to know if you do you care about it or sif
I should remove it from the bugs info.
Thanks
Best regards
Thierry
#---------------------------------------------------------------------------------------------------
>From 48a9a9834377a74b603be12dcc76cda24105e33c Mon Sep 17 00:00:00 2001
From: Thierry Fauck <thierry@linux.vnet.ibm.com>
Date: Fri, 28 Feb 2014 16:17:50 +0100
Subject: [PATCH] selftests: PAGE_SIZE may not be defined
Some systems have a dynamic PAGE_SIZE value and do not add a definition
for PAGE_SIZE. This value will have to be retrieved using getpagesize()
or sysconf().
Signed-off-by: Thierry Fauck <thierry@linux.vnet.ibm.com>
---
tools/testing/selftests/ptrace/peeksiginfo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ptrace/peeksiginfo.c
b/tools/testing/selftests/ptrace/peeksiginfo.c
index d46558b..f2ccbbd 100644
--- a/tools/testing/selftests/ptrace/peeksiginfo.c
+++ b/tools/testing/selftests/ptrace/peeksiginfo.c
@@ -35,7 +35,9 @@ static int sys_ptrace(int request, pid_t pid, void
*addr, void *data)
fprintf(stderr, \
"Error (%s:%d): " fmt, \
__FILE__, __LINE__, ##__VA_ARGS__)
-
+#ifndef PAGE_SIZE
+#define PAGE_SIZE sysconf(_SC_PAGESIZE)
+#endif
static int check_error_paths(pid_t child)
{
struct ptrace_peeksiginfo_args arg;
--
1.9.0
--
Thierry Fauck (thierry@linux.vnet.ibm.com)
[-- Attachment #2: Type: text/html, Size: 2508 bytes --]
^ permalink raw reply related
* [PATCH] powerpc: Fix 64 bit builds with binutils 2.24
From: Guenter Roeck @ 2014-05-15 16:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Guenter Roeck,
Alan Modra
With binutils 2.24, various 64 bit builds fail with relocation errors
such as
arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI
against symbol `interrupt_base_book3e' defined in .text section
in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI
against symbol `interrupt_end_book3e' defined in .text section
in arch/powerpc/kernel/built-in.o
The assembler maintainer says:
I changed the ABI, something that had to be done but unfortunately
happens to break the booke kernel code. When building up a 64-bit
value with lis, ori, shl, oris, ori or similar sequences, you now
should use @high and @higha in place of @h and @ha. @h and @ha
(and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA)
now report overflow if the value is out of 32-bit signed range.
ie. @h and @ha assume you're building a 32-bit value. This is needed
to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h
and @toc@ha expressions, and for consistency I did the same for all
other @h and @ha relocs.
Replacing @h with @high in one strategic location fixes the relocation
errors. This has to be done conditionally since the assembler either
supports @h or @high but not both.
Cc: Alan Modra <amodra@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
All my test targets build with both binutils 2.23 and 2.24
with this patch applied.
The patch generates two checkpatch errors, but I consider those to be
false positives. checkpatch requests spaces after , in the assembler
instructions.
Please consider adding Cc: stable.
arch/powerpc/Makefile | 4 +++-
arch/powerpc/include/asm/ppc_asm.h | 7 ++++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 4c0cedf..ce4c68a 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -150,7 +150,9 @@ endif
CFLAGS-$(CONFIG_TUNE_CELL) += $(call cc-option,-mtune=cell)
-KBUILD_CPPFLAGS += -Iarch/$(ARCH)
+asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1)
+
+KBUILD_CPPFLAGS += -Iarch/$(ARCH) $(asinstr)
KBUILD_AFLAGS += -Iarch/$(ARCH)
KBUILD_CFLAGS += -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
CPP = $(CC) -E $(KBUILD_CFLAGS)
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index 6586a40..cded7c1 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -318,11 +318,16 @@ n:
addi reg,reg,(name - 0b)@l;
#ifdef __powerpc64__
+#ifdef HAVE_AS_ATHIGH
+#define __AS_ATHIGH high
+#else
+#define __AS_ATHIGH h
+#endif
#define LOAD_REG_IMMEDIATE(reg,expr) \
lis reg,(expr)@highest; \
ori reg,reg,(expr)@higher; \
rldicr reg,reg,32,31; \
- oris reg,reg,(expr)@h; \
+ oris reg,reg,(expr)@__AS_ATHIGH; \
ori reg,reg,(expr)@l;
#define LOAD_REG_ADDR(reg,name) \
--
1.9.1
^ permalink raw reply related
* [PATCH] powerpc: Fix unused variable warning for epapr_has_idle
From: Scott Wood @ 2014-05-15 16:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
This warning can be seen in allyesconfig, and was introduced by commit
f9eb581c63b2acce827570e105205c0789360650 "powerpc: fix build of
epapr_paravirt on 64-bit book3s".
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Sorry about the churn on this -- I did try to build allyesconfig, but I
forgot that CONFIG_PPC_DISABLE_WERROR would be enabled, plus the build
failed on the "attempt to move .org backwards" issue.
---
arch/powerpc/kernel/epapr_paravirt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/epapr_paravirt.c b/arch/powerpc/kernel/epapr_paravirt.c
index eab2f2a..c47fed0 100644
--- a/arch/powerpc/kernel/epapr_paravirt.c
+++ b/arch/powerpc/kernel/epapr_paravirt.c
@@ -30,7 +30,7 @@ extern u32 epapr_ev_idle_start[];
#endif
bool epapr_paravirt_enabled;
-static bool epapr_has_idle;
+static bool __maybe_unused epapr_has_idle;
static int __init early_init_dt_scan_epapr(unsigned long node,
const char *uname,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
From: Hugh Dickins @ 2014-05-15 17:28 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: linux-arch, riel, rusty, dave.hansen, peterz, x86, linux-kernel,
linux-mm, ak, paulus, mgorman, akpm, linuxppc-dev, mingo,
kirill.shutemov
In-Reply-To: <537479E7.90806@linux.vnet.ibm.com>
On Thu, 15 May 2014, Madhavan Srinivasan wrote:
>
> Hi Ingo,
>
> Do you have any comments for the latest version of the patchset. If
> not, kindly can you pick it up as is.
>
>
> With regards
> Maddy
>
> > Kirill A. Shutemov with 8c6e50b029 commit introduced
> > vm_ops->map_pages() for mapping easy accessible pages around
> > fault address in hope to reduce number of minor page faults.
> >
> > This patch creates infrastructure to modify the FAULT_AROUND_ORDER
> > value using mm/Kconfig. This will enable architecture maintainers
> > to decide on suitable FAULT_AROUND_ORDER value based on
> > performance data for that architecture. First patch also defaults
> > FAULT_AROUND_ORDER Kconfig element to 4. Second patch list
> > out the performance numbers for powerpc (platform pseries) and
> > initialize the fault around order variable for pseries platform of
> > powerpc.
Sorry for not commenting earlier - just reminded by this ping to Ingo.
I didn't study your numbers, but nowhere did I see what PAGE_SIZE you use.
arch/powerpc/Kconfig suggests that Power supports base page size of
4k, 16k, 64k or 256k.
I would expect your optimal fault_around_order to depend very much on
the base page size.
Perhaps fault_around_size would provide a more useful default?
Hugh
^ permalink raw reply
* Re: roundup_pow_of_two() may not handle 64-bit integers
From: Brian Norris @ 2014-05-15 19:44 UTC (permalink / raw)
To: David Howells; +Cc: Andrew Morton, linuxppc-dev, Paul Mackerras, Linux Kernel
In-Reply-To: <29314.1400166189@warthog.procyon.org.uk>
On Thu, May 15, 2014 at 04:03:09PM +0100, David Howells wrote:
> Brian Norris <computersforpeace@gmail.com> wrote:
> > I'm looking to use roundup_pow_of_two() (actually, order_base_2())
> > from <linux/log2.h>, but it seems that it only supports 64-bit integers
> > if your toolchain uses a 64-bit 'unsigned long' type. This is strange,
> > considering that ilog2() is explicitly designed for 32-bit or 64-bit
> > compatibility.
>
> ilog2() was explicitly designed for use with 'unsigned long'. See the commit
> description (f0d1b0b30d250a07627ad8b9fbbb5c7cc08422e8). It may work with
> unsigned long long, however...
That's another confusing point; the commit description says 'unsigned
long', but the code shows nothing of that sort, and the comments say
nearly the reverse (mentioning '32-bit and 64-bit', not 'unsigned
long'). The code only referenes ULL constants, and it selects a 32-bit
or 64-bit runtime version based on the type. To me, this demonstrates an
explicit design for "32-bit or 64-bit", regardless of the dimensions of
your 'long'.
So this leaves me with 2 main issues:
(1) Can we make <linux/ilog2.h> have some sense of consistency? If so,
how?
- Enforce the 'unsigned long' design (i.e., don't support
ilog2(u64) when sizeof(unsigned long) == 4)?
- Make all high-level macros automatically support 32-bit or 64-bit,
regardless of type?
- Split out 32-bit vs. 64-bit functions for everything?
Obviously some of these options are sillier than others.
(2) Powerpc (and maybe some of SH's PCI) code has a potential bug, due
to using roundup_pow_of_two() on type phys_addr_t, which could
overflow for LPAE systems with large physical memory ranges. Is this
a legitimate concern?
Brian
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
From: Michael Neuling @ 2014-05-16 0:26 UTC (permalink / raw)
To: Pedro Alves
Cc: avagin, linux-kernel, oleg, michael, linuxppc-dev,
Anshuman Khandual
In-Reply-To: <5374AE24.1030302@redhat.com>
> So in sum, it very much looks like the intention is for
> PTRACE_GETREGSET/PTRACE_SETREGSET to return ENODEV in the
> case the regset doesn't exist on the running machine, and then
> it looks like at least x86 works that way.
Good point... agreed. We should ENODEV when we don't have TM hardware
(like POWER7).
Mikey
^ permalink raw reply
* G5 Quad working with Linux PPC and RadeonHD
From: Luigi Burdo @ 2014-05-16 10:31 UTC (permalink / raw)
To: linuxppc-dev
Hi all i start one week ago to write massage in ubuntu about
my object i have Radeon Hd working on my Quad G5 thanks to linuxPPC .
But there are some things to fix
One RadeonHD mesa colors are wrong .
On RadeonHD 4650 ddr3 512mb i have full video acceleration and hdmi
audio working
On RadeonHD 6570 ddr3 2048mb i have video but no chars on windows and
icons .
this is my thread on ubuntu forum Apple User in lubuntu
there are all my experieces and the bugs found ...
too much things to write on a single email
http://ubuntuforums.org/showthread.php?t=2221421&page=6
Thanks for all !
Luigi
^ permalink raw reply
* question about hvc_opal.c
From: Himangi Saraogi @ 2014-05-16 18:04 UTC (permalink / raw)
To: jslaby, Greg KH, linuxppc-dev, linux-kernel; +Cc: Julia Lawall
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Hi,
In function hvc_opal_probe I find :
hp = hvc_alloc(termno, 0, ops, MAX_VIO_PUT_CHARS);
if (IS_ERR(hp))
return PTR_ERR(hp);
Earlier, hpc_opal_privs[termno] is assigned pv which is allocated using
kzalloc. Shouldn't there be a kfree(pv) and the array element (which is
global) be made NULL before the return. Also, if array element is set to
NULL on the failure, then some cleanup must be done to undo the effect of
hvc_instantiate as well. Please let me know if the change is desirable.
Thanks.
Himangi
[-- Attachment #2: Type: text/html, Size: 699 bytes --]
^ permalink raw reply
* Re: question about hvc_opal.c
From: Greg KH @ 2014-05-16 18:26 UTC (permalink / raw)
To: Himangi Saraogi; +Cc: linuxppc-dev, jslaby, linux-kernel, Julia Lawall
In-Reply-To: <CAB78YHynbQ=cR-jDTHpwwVGgDO24fjXETO1Zp88QD=Vkjf+6GQ@mail.gmail.com>
On Fri, May 16, 2014 at 11:34:13PM +0530, Himangi Saraogi wrote:
> Hi,
>
> In function hvc_opal_probe I find :
>
> hp = hvc_alloc(termno, 0, ops, MAX_VIO_PUT_CHARS);
> if (IS_ERR(hp))
> return PTR_ERR(hp);
>
> Earlier, hpc_opal_privs[termno] is assigned pv which is allocated using
> kzalloc. Shouldn't there be a kfree(pv) and the array element (which is global)
> be made NULL before the return. Also, if array element is set to NULL on the
> failure, then some cleanup must be done to undo the effect of hvc_instantiate
> as well. Please let me know if the change is desirable.
Sounds reasonable, please send a patch.
^ permalink raw reply
* Re: [RFC PATCH 1/3] slub: search partial list on numa_mem_id(), instead of numa_node_id()
From: Nishanth Aravamudan @ 2014-05-16 23:37 UTC (permalink / raw)
To: Joonsoo Kim
Cc: Han Pingtian, mpm, penberg, linux-mm, paulus, Anton Blanchard,
David Rientjes, Christoph Lameter, linuxppc-dev, Wanpeng Li
In-Reply-To: <1391674026-20092-1-git-send-email-iamjoonsoo.kim@lge.com>
On 06.02.2014 [17:07:04 +0900], Joonsoo Kim wrote:
> Currently, if allocation constraint to node is NUMA_NO_NODE, we search
> a partial slab on numa_node_id() node. This doesn't work properly on the
> system having memoryless node, since it can have no memory on that node and
> there must be no partial slab on that node.
>
> On that node, page allocation always fallback to numa_mem_id() first. So
> searching a partial slab on numa_node_id() in that case is proper solution
> for memoryless node case.
>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Joonsoo, would you send this one on to Andrew?
Thanks,
Nish
^ permalink raw reply
* [PATCH] powerpc: numa: enable USE_PERCPU_NUMA_NODE_ID
From: Nishanth Aravamudan @ 2014-05-16 23:39 UTC (permalink / raw)
To: Andrew Morton
Cc: Lee Schermerhorn, Christoph Lameter, Mel Gorman, linux-mm,
Anton Blanchard, David Rientjes, Joonsoo Kim, linuxppc-dev
Based off 3bccd996 for ia64, convert powerpc to use the generic per-CPU
topology tracking, specifically:
initialize per cpu numa_node entry in start_secondary
remove the powerpc cpu_to_node()
define CONFIG_USE_PERCPU_NUMA_NODE_ID if NUMA
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e099899..9125964 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -453,6 +453,10 @@ config NODES_SHIFT
default "4"
depends on NEED_MULTIPLE_NODES
+config USE_PERCPU_NUMA_NODE_ID
+ def_bool y
+ depends on NUMA
+
config ARCH_SELECT_MEMORY_MODEL
def_bool y
depends on PPC64
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index c920215..5ecf7ea 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -20,19 +20,6 @@ struct device_node;
#include <asm/mmzone.h>
-static inline int cpu_to_node(int cpu)
-{
- int nid;
-
- nid = numa_cpu_lookup_table[cpu];
-
- /*
- * During early boot, the numa-cpu lookup table might not have been
- * setup for all CPUs yet. In such cases, default to node 0.
- */
- return (nid < 0) ? 0 : nid;
-}
-
#define parent_node(node) (node)
#define cpumask_of_node(node) ((node) == -1 ? \
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index e2a4232..b95be24 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -750,6 +750,11 @@ void start_secondary(void *unused)
}
traverse_core_siblings(cpu, true);
+ /*
+ * numa_node_id() works after this.
+ */
+ set_numa_node(numa_cpu_lookup_table[cpu]);
+
smp_wmb();
notify_cpu_starting(cpu);
set_cpu_online(cpu, true);
^ permalink raw reply related
* [PATCH 2/2] powerpc: numa: enable CONFIG_HAVE_MEMORYLESS_NODES
From: Nishanth Aravamudan @ 2014-05-16 23:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Lee Schermerhorn, Christoph Lameter, Mel Gorman, linux-mm,
Anton Blanchard, David Rientjes, Joonsoo Kim, linuxppc-dev
In-Reply-To: <20140516233945.GI8941@linux.vnet.ibm.com>
Based off fd1197f1 for ia64, enable CONFIG_HAVE_MEMORYLESS_NODES if
NUMA. Initialize the local memory node in start_secondary.
With this commit and the preceding to enable
CONFIG_USER_PERCPU_NUMA_NODE_ID, which is a prerequisite, in a PowerKVM
guest with the following topology:
numactl --hardware
available: 3 nodes (0-2)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94
95 96 97 98 99
node 0 size: 1998 MB
node 0 free: 521 MB
node 1 cpus: 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114
115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132
133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150
151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168
169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186
187 188 189 190 191 192 193 194 195 196 197 198 199
node 1 size: 0 MB
node 1 free: 0 MB
node 2 cpus:
node 2 size: 2039 MB
node 2 free: 1739 MB
node distances:
node 0 1 2
0: 10 40 40
1: 40 10 40
2: 40 40 10
the unreclaimable slab is reduced by close to 130M:
Before:
Slab: 418176 kB
SReclaimable: 26624 kB
SUnreclaim: 391552 kB
After:
Slab: 298944 kB
SReclaimable: 31744 kB
SUnreclaim: 267200 kB
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9125964..bd6dd6e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -457,6 +457,10 @@ config USE_PERCPU_NUMA_NODE_ID
def_bool y
depends on NUMA
+config HAVE_MEMORYLESS_NODES
+ def_bool y
+ depends on NUMA
+
config ARCH_SELECT_MEMORY_MODEL
def_bool y
depends on PPC64
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index b95be24..ebd7b9d 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -754,6 +754,7 @@ void start_secondary(void *unused)
* numa_node_id() works after this.
*/
set_numa_node(numa_cpu_lookup_table[cpu]);
+ set_numa_mem(local_memory_node(numa_cpu_lookup_table[cpu]));
smp_wmb();
notify_cpu_starting(cpu);
^ permalink raw reply related
* Re: G5 Quad working with Linux PPC and RadeonHD
From: Michel Dänzer @ 2014-05-17 3:53 UTC (permalink / raw)
To: Luigi Burdo; +Cc: linuxppc-dev
In-Reply-To: <BLU436-SMTP80159B93A5EE9CE9979A56C8310@phx.gbl>
On 16.05.2014 19:31, Luigi Burdo wrote:
> Hi all i start one week ago to write massage in ubuntu about
> my object i have Radeon Hd working on my Quad G5 thanks to linuxPPC .
>
> But there are some things to fix
> One RadeonHD mesa colors are wrong .
See https://bugs.freedesktop.org/show_bug.cgi?id=72877 . No progress yet
unfortunately.
> On RadeonHD 4650 ddr3 512mb i have full video acceleration and hdmi
> audio working
> On RadeonHD 6570 ddr3 2048mb i have video but no chars on windows and
> icons .
The latter sounds like
https://bugs.freedesktop.org/show_bug.cgi?id=74939 , which is fixed in
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=8da17f30c70f4494ce22ad781a1cee17041812f3
.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
^ permalink raw reply
* Re: G5 Quad working with Linux PPC and RadeonHD
From: Luigi Burdo @ 2014-05-17 8:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <5376DD44.4040402@daenzer.net>
Hi Michel D=C3=A4nzer thanks for your explanation about .
About the first post
https://bugs.freedesktop.org/show_bug.cgi?id=3D72877
Christian (Xeno74) had been success to have the right mesa/gl colors on
X1000 machine he make a patch about =2C i tested his package on QuadG5
but no effect probably something is different in kernel/hardware (?!?)
about the second
on X1000 r600 boards dont gave decoration problems
there is probably needed some other trick about
for the other architecture.
https://bugs.freedesktop.org/show_bug.cgi?id=3D74939
In any way thanks alot for the infos and for the works
the PPC linux staff is doing :)
Luigi
Il 17/05/14 05:53=2C Michel D=C3=A4nzer ha scritto:
> On 16.05.2014 19:31=2C Luigi Burdo wrote:
>> Hi all i start one week ago to write massage in ubuntu about
>> my object i have Radeon Hd working on my Quad G5 thanks to linuxPPC .
>>
>> But there are some things to fix
>> One RadeonHD mesa colors are wrong .
> See https://bugs.freedesktop.org/show_bug.cgi?id=3D72877 . No progress ye=
t
> unfortunately.
>
>
>> On RadeonHD 4650 ddr3 512mb i have full video acceleration and hdmi
>> audio working
>> On RadeonHD 6570 ddr3 2048mb i have video but no chars on windows and
>> icons .
> The latter sounds like
> https://bugs.freedesktop.org/show_bug.cgi?id=3D74939 =2C which is fixed i=
n
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=3D8da17=
f30c70f4494ce22ad781a1cee17041812f3
> .
>
>
^ permalink raw reply
* [PATCH] powerpc: Clear ELF personality flag if ELFv2 is not requested.
From: Jeff Bailey @ 2014-05-17 15:05 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
powerpc: Clear ELF personality flag if ELFv2 is not requested.
The POWER kernel uses a personality flag to determine whether it should
be setting up function descriptors or not (per the updated ABI). This
flag wasn't being cleared on a new process but instead was being
inherited. The visible effect was that an ELFv2 binary could not execve
to an ELFv1 binary.
Signed-off-by: Jeff Bailey <jeffbailey@google.com>
arch/powerpc/include/asm/elf.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 935b5e7..888d8f3 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -90,6 +90,8 @@ typedef elf_vrregset_t elf_fpxregset_t;
do { \
if (((ex).e_flags & 0x3) == 2) \
set_thread_flag(TIF_ELF2ABI); \
+ else \
+ clear_thread_flag(TIF_ELF2ABI); \
if ((ex).e_ident[EI_CLASS] == ELFCLASS32) \
set_thread_flag(TIF_32BIT); \
else \
[-- Attachment #2: Type: text/html, Size: 1790 bytes --]
^ permalink raw reply related
* [PATCH] macintosh: windfarm_pm121.c: Fix for possible null pointer dereference
From: Rickard Strandqvist @ 2014-05-17 17:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev; +Cc: linux-kernel, Rickard Strandqvist
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
drivers/macintosh/windfarm_pm121.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/macintosh/windfarm_pm121.c b/drivers/macintosh/windfarm_pm121.c
index 7fe58b0..b350fb8 100644
--- a/drivers/macintosh/windfarm_pm121.c
+++ b/drivers/macintosh/windfarm_pm121.c
@@ -555,8 +555,18 @@ static void pm121_create_sys_fans(int loop_id)
pid_param.interval = PM121_SYS_INTERVAL;
pid_param.history_len = PM121_SYS_HISTORY_SIZE;
pid_param.itarget = param->itarget;
- pid_param.min = control->ops->get_min(control);
- pid_param.max = control->ops->get_max(control);
+ if(control)
+ {
+ pid_param.min = control->ops->get_min(control);
+ pid_param.max = control->ops->get_max(control);
+ } else {
+ /*
+ * This is probably not the right!?
+ * Perhaps goto fail if control == NULL above?
+ */
+ pid_param.min = 0;
+ pid_param.max = 0;
+ }
wf_pid_init(&pm121_sys_state[loop_id]->pid, &pid_param);
@@ -571,7 +581,7 @@ static void pm121_create_sys_fans(int loop_id)
control the same control */
printk(KERN_WARNING "pm121: failed to set up %s loop "
"setting \"%s\" to max speed.\n",
- loop_names[loop_id], control->name);
+ loop_names[loop_id], control ? control->name : "uninitialized value");
if (control)
wf_control_set_max(control);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
From: Neelesh Gupta @ 2014-05-18 18:08 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linuxppc-dev, sbhat, jdelvare, lm-sensors
In-Reply-To: <20140514170933.GB18032@roeck-us.net>
On 05/14/2014 10:39 PM, Guenter Roeck wrote:
> On Wed, May 14, 2014 at 11:31:53AM +0530, Neelesh Gupta wrote:
>> This patch adds basic kernel enablement for reading power values, fan
>> speed rpm and temperature values on powernv platforms which will
>> be exported to user space through sysfs interface.
>>
>> Test results:
>> -------------
>> [root@tul163p1 ~]# sensors
>> ibmpowernv-isa-0000
>> Adapter: ISA adapter
>> fan1: 5294 RPM (min = 0 RPM)
>> fan2: 4945 RPM (min = 0 RPM)
>> fan3: 5831 RPM (min = 0 RPM)
>> fan4: 5212 RPM (min = 0 RPM)
>> fan5: 0 RPM (min = 0 RPM)
>> fan6: 0 RPM (min = 0 RPM)
>> fan7: 7472 RPM (min = 0 RPM)
>> fan8: 7920 RPM (min = 0 RPM)
>> temp1: +39.0°C (high = +0.0°C)
>> power1: 192.00 W
>>
>> [root@tul163p1 ~]#
>> [root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/
>> driver fan2_min fan4_min fan6_min fan8_min modalias uevent
>> fan1_fault fan3_fault fan5_fault fan7_fault hwmon name
>> fan1_input fan3_input fan5_input fan7_input in1_fault power1_input
>> fan1_min fan3_min fan5_min fan7_min in2_fault subsystem
>> fan2_fault fan4_fault fan6_fault fan8_fault in3_fault temp1_input
>> fan2_input fan4_input fan6_input fan8_input in4_fault temp1_max
>> [root@tul163p1 ~]#
>> [root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/device/
>> driver fan2_min fan4_min fan6_min fan8_min modalias uevent
>> fan1_fault fan3_fault fan5_fault fan7_fault hwmon name
>> fan1_input fan3_input fan5_input fan7_input in1_fault power1_input
>> fan1_min fan3_min fan5_min fan7_min in2_fault subsystem
>> fan2_fault fan4_fault fan6_fault fan8_fault in3_fault temp1_input
>> fan2_input fan4_input fan6_input fan8_input in4_fault temp1_max
>> [root@tul163p1 ~]#
>>
>> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
>> Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com>
>> ---
>> drivers/hwmon/Kconfig | 8 +
>> drivers/hwmon/Makefile | 1
>> drivers/hwmon/ibmpowernv.c | 386 ++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 395 insertions(+)
>> create mode 100644 drivers/hwmon/ibmpowernv.c
>>
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index bc196f4..3e308fa 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -554,6 +554,14 @@ config SENSORS_IBMPEX
>> This driver can also be built as a module. If so, the module
>> will be called ibmpex.
>>
>> +config SENSORS_IBMPOWERNV
>> + tristate "IBM POWERNV platform sensors"
>> + depends on PPC_POWERNV
>> + default y
>> + help
>> + If you say yes here you get support for the temperature/fan/power
>> + sensors on your platform.
>> +
>> config SENSORS_IIO_HWMON
>> tristate "Hwmon driver that uses channels specified via iio maps"
>> depends on IIO
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index c48f987..199c401 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -71,6 +71,7 @@ obj-$(CONFIG_SENSORS_ULTRA45) += ultra45_env.o
>> obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o
>> obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
>> obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
>> +obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
>> obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
>> obj-$(CONFIG_SENSORS_INA209) += ina209.o
>> obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>> new file mode 100644
>> index 0000000..e5cffce
>> --- /dev/null
>> +++ b/drivers/hwmon/ibmpowernv.c
>> @@ -0,0 +1,386 @@
>> +/*
>> + * IBM PowerNV platform sensors for temperature/fan/power
>> + * Copyright (C) 2014 IBM
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> Please drop the FSF address; it can change, and we don't want to update the
> driver each time it does.
>
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/kernel.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/hwmon-sysfs.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +
>> +#include <linux/platform_device.h>
>> +#include <asm/opal.h>
>> +#include <linux/err.h>
>> +
>> +#define DRVNAME "ibmpowernv"
>> +#define MAX_ATTR_LEN 32
>> +
>> +/* Sensor suffix name from DT */
>> +#define DT_FAULT_ATTR_SUFFIX "faulted"
>> +#define DT_DATA_ATTR_SUFFIX "data"
>> +#define DT_THRESHOLD_ATTR_SUFFIX "thrs"
>> +
>> +/* Enumerates all the sensors in the POWERNV platform and also index into
>> + * 'struct sensor_name'
> Comment coding style, please (this is not the networking subsystem ;-)
>
>> + */
>> +enum sensors {
>> + FAN,
>> + AMBIENT_TEMP,
>> + POWERSUPPLY,
>> + POWER,
>> + MAX_SENSOR_TYPE,
>> +};
>> +
>> +static struct sensor_name {
> const ?
>
>> + char *name;
>> + char *compatible;
>> +} sensor_names[] = {
>> + {"fan", "ibm,opal-sensor-cooling-fan"},
>> + {"temp", "ibm,opal-sensor-amb-temp"},
>> + {"in", "ibm,opal-sensor-power-supply"},
>> + {"power", "ibm,opal-sensor-power"}
>> +};
>> +
>> +struct platform_data {
>> + struct device *hwmon_dev;
> Not needed.
>
>> + struct device_attribute name_attr;
>> + struct list_head attr_list;
>> +};
>> +
>> +struct sensor_data {
>> + u32 id;
>> + enum sensors stype;
>> + char name[MAX_ATTR_LEN];
>> + struct sensor_device_attribute sd_attr;
>> + struct list_head list;
>> +};
>> +
>> +/* Platform device representing all the ibmpowernv sensors */
>> +static struct platform_device *pdevice;
>> +
>> +static void get_sensor_index_attr(const char *name, u32 *index, char *attr)
>> +{
>> + char *hash_pos = strchr(name, '#');
>> + char *dash_pos;
>> + u32 copy_len;
>> + char buf[8];
>> +
>> + memset(buf, 0, sizeof(buf));
>> + *index = 0;
>> + *attr = '\0';
>> +
>> + if (hash_pos) {
>> + dash_pos = strchr(hash_pos, '-');
>> + if (dash_pos) {
>> + copy_len = dash_pos - hash_pos - 1;
>> + if (copy_len < sizeof(buf)) {
>> + strncpy(buf, hash_pos + 1, copy_len);
>> + sscanf(buf, "%d", index);
>> + }
>> +
>> + strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
>> + }
>> + }
>> +}
>> +
>> +/*
>> + * This function translates the DT node name into the 'hwmon' attribute name.
>> + * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
>> + * which need to be mapped as fan2_input, temp1_max respectively before
>> + * populating them inside hwmon device class..
>> + */
>> +static int create_hwmon_attr_name(enum sensors stype, const char *node_name,
>> + char *hwmon_attr_name)
> Please follow CodingStyle for continuation line alignment.
>
>> +{
>> + char attr_suffix[MAX_ATTR_LEN];
>> + char *attr_name;
>> + u32 index;
>> +
>> + get_sensor_index_attr(node_name, &index, attr_suffix);
>> + if (!index || !strlen(attr_suffix)) {
>> + pr_info("%s: Sensor device node name is invalid, name: %s\n",
>> + __func__, node_name);
>> + return -EINVAL;
>> + }
>> +
>> + if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX))
>> + attr_name = "fault";
>> + else if(!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX))
>> + attr_name = "input";
>> + else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
>> + if (stype == AMBIENT_TEMP)
>> + attr_name = "max";
>> + else if (stype == FAN)
>> + attr_name = "min";
>> + else
>> + return -ENOENT;
>> + } else
>> + return -ENOENT;
>> +
>> + snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
>> + sensor_names[stype].name, index, attr_name);
>> + return 0;
>> +}
>> +
>> +static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
>> + char *buf)
>> +{
>> + struct sensor_device_attribute *sd_attr = to_sensor_dev_attr(devattr);
>> + struct sensor_data *sdata = container_of(sd_attr, struct sensor_data,
>> + sd_attr);
>> + int err;
>> + u32 x;
>> +
>> + err = opal_get_sensor_data(sdata->id, &x);
>> + if (err) {
>> + pr_err("%s: Failed to get opal sensor data\n", __func__);
>> + x = -1;
> Unusual. Why not report the error to user space ?
> Reporting <maxuint> on error doesn't seem to be very useful.
>
>> + }
>> +
>> + /* Convert temperature to milli-degrees */
>> + if (sdata->stype == AMBIENT_TEMP && x > 0)
>> + x *= 1000;
>> + /* Convert power to micro-watts */
>> + else if (sdata->stype == POWER && x > 0)
>> + x *= 1000000;
>> +
> Is there an overflow concern ? Guess not ... overflow happens at ~17KW.
> Just wondering.
>
>> + return sprintf(buf, "%d\n", x);
>> +}
>> +
>> +static void remove_device_attrs(struct platform_device *pdev)
>> +{
>> + struct platform_data *pdata = platform_get_drvdata(pdev);
>> + struct device *dev = &pdev->dev;
>> + struct sensor_data *s, *next;
>> +
>> + list_for_each_entry_safe(s, next, &pdata->attr_list, list) {
>> + device_remove_file(dev, &s->sd_attr.dev_attr);
>> + list_del(&s->list);
> This is unnecessary since you always remove the entire list anyway.
> Actually, I don't think you need the list in the first place.
> You only use it to delete entries, but that can be handled automatically
> by the infrastructure. All you really need is an array pointing to the device
> attributes so you can create all attribute files with a single operation.
>
>> + kfree(s);
>> + }
>> +}
>> +
>> +/*
>> + * Iterate through the device tree and for each child of sensor node, create
>> + * a sysfs attribute file, the file is named by translating the DT node name
>> + * to the name required by the higher 'hwmon' driver like fan1_input, temp1_max
>> + * etc..
>> + */
>> +static int create_device_attrs(struct platform_device *pdev)
>> +{
>> + struct platform_data *pdata = platform_get_drvdata(pdev);
>> + struct device *dev = &pdev->dev;
>> + struct device_node *opal, *np;
>> + struct sensor_data *sdata;
>> + const u32 *sensor_id;
>> + enum sensors stype;
>> + int err;
>> +
>> + opal = of_find_node_by_path("/ibm,opal/sensors");
>> + if (!opal) {
>> + pr_err("%s: Opal 'sensors' node not found\n", __func__);
>> + err = -ENXIO;
> ENODEV ?
>
>> + goto exit;
> I would suggest to simply return here.
>
>> + }
>> +
>> + for_each_child_of_node(opal, np) {
>> + if (np->name == NULL)
>> + continue;
>> +
>> + for (stype = 0; stype < MAX_SENSOR_TYPE; stype++)
>> + if (of_device_is_compatible(np,
>> + sensor_names[stype].compatible))
>> + break;
>> +
>> + if (stype == MAX_SENSOR_TYPE)
>> + continue;
>> +
>> + sensor_id = of_get_property(np, "sensor-id", NULL);
>> + if (!sensor_id) {
>> + pr_info("%s: %s doesn't have sensor-id\n", __func__,
>> + np->name);
>> + continue;
>> + }
>> +
>> + sdata = kzalloc(sizeof(*sdata), GFP_KERNEL);
> Can you use devm_kzalloc() ?
>
>> + if (!sdata) {
>> + pr_err("%s: Failed to allocate memory for sensor_data",
>> + __func__);
>> + err = -ENOMEM;
>> + goto exit_put_node;
>> + }
>> +
>> + sdata->id = *sensor_id;
>> + sdata->stype = stype;
>> + err = create_hwmon_attr_name(stype, np->name, sdata->name);
>> + if (err) {
>> + pr_err("%s: Failed to create the hwmon attribute name\n",
>> + __func__);
> create_hwmon_attr_name() (sometimes) already creates an error message.
> Would be nice if you can avoid duplicate error messages.
>
>> + goto exit_free_sdata;
>> + }
>> +
>> + sysfs_attr_init(&sdata->sd_attr.dev_attr.attr);
>> + sdata->sd_attr.dev_attr.attr.name = sdata->name;
>> + sdata->sd_attr.dev_attr.attr.mode = S_IRUGO;
>> + sdata->sd_attr.dev_attr.show = show_sensor;
> Since you are not using the index value from sensor_device_attribute,
> but use your own 'id' variable instead, you don't need sensor_device_attribute
> but can use device_attribute instead (or drop 'id' and use
> sd_attr.index instead).
>
>> +
>> + /* Create sysfs attribute file */
>> + err = device_create_file(dev, &sdata->sd_attr.dev_attr);
>> + if (err)
>> + goto exit_free_sdata;
>> +
> Please don't create the attribute files here but just a list of attributes
> instead. See below for more details.
>
>> + list_add_tail(&sdata->list, &pdata->attr_list);
>> + }
>> +
>> + of_node_put(opal);
>> + return 0;
>> +
>> +exit_free_sdata:
>> + kfree(sdata);
>> +exit_put_node:
>> + of_node_put(opal);
>> + remove_device_attrs(pdev);
>> +exit:
>> + return err;
>> +}
>> +
>> +static ssize_t show_name(struct device *dev, struct device_attribute *devattr,
>> + char *buf)
>> +{
>> + struct platform_device *pdev = to_platform_device(dev);
>> + return sprintf(buf, "%s\n", pdev->name);
>> +}
> Not necessary; see below.
>
>> +
>> +static int ibmpowernv_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct platform_data *pdata;
>> + int err;
>> +
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata) {
>> + err = -ENOMEM;
>> + goto exit;
>> + }
>> +
>> + INIT_LIST_HEAD(&pdata->attr_list);
>> + platform_set_drvdata(pdev, pdata);
>> +
>> + /* Create platform device 'name' attribute */
>> + sysfs_attr_init(&pdata->name_attr.attr);
>> + pdata->name_attr.attr.name = "name";
>> + pdata->name_attr.attr.mode = S_IRUGO;
>> + pdata->name_attr.show = show_name;
>> + err = device_create_file(dev, &pdata->name_attr);
> You don't need to create a name attribute.
> devm_hwmon_device_register_with_groups does it for you (from the second
> argument).
>
>> + if (err)
>> + goto exit;
>> +
>> + /* Create sysfs attribute file for each sensor found in the DT */
>> + err = create_device_attrs(pdev);
> That defeats the purpose of using devm_hwmon_device_register_with_groups.
> The idea here is to build a list of attributes, which you can do in
> create_device_attrs(), but not create the actual device entries.
> Then also create an attribute_group as well as a list of groups,
> and pass that as last argument to devm_hwmon_device_register_with_groups().
>
> drivers/hwmon/pmbus/pmbus_core.c does something similar; maybe you can
> use a similar approach.
>
> With that, you also don't need the remove functions, since the hwmon
> subsystem will auto-remove the attributes. If you do it correctly
> (ie use devm_kzalloc() for allocating memory) you should not need a
> remove function at all.
>
>> + if (err) {
>> + pr_err("%s: Failed to create the device attributes\n",
>> + __func__);
>> + goto exit_remove_name;
>> + }
>> +
>> + /* Finally, register with hwmon */
>> + pdata->hwmon_dev = devm_hwmon_device_register_with_groups(dev, DRVNAME,
>> + pdata, NULL);
>> + if (IS_ERR(pdata->hwmon_dev)) {
>> + err = PTR_ERR(pdata->hwmon_dev);
>> + goto exit_remove_devattrs;
>> + }
>> +
>> + return 0;
>> +
>> +exit_remove_devattrs:
>> + remove_device_attrs(pdev);
>> +exit_remove_name:
>> + device_remove_file(dev, &pdata->name_attr);
>> +exit:
>> + return err;
> If you do it right you should be able to reduce this to something like
>
> hwmon_dev = devm_hwmon_device_register_with_groups(dev, DRVNAME, pdata,
> pdata->attr_groups);
> return PTR_ERR_OR_ZERO(hwmon_dev);
>
> ...
>
>> +}
>> +
>> +static int ibmpowernv_remove(struct platform_device *pdev)
>> +{
>> + struct platform_data *pdata = platform_get_drvdata(pdev);
>> + struct device *dev = &pdev->dev;
>> +
>> + remove_device_attrs(pdev);
>> + device_remove_file(dev, &pdata->name_attr);
>> +
>> + return 0;
>> +}
> ... and you should be able to remove this entire function.
>
>> +
>> +
> No double empty lines please.
>
>> +static struct platform_driver ibmpowernv_driver = {
>> + .driver = {
>> + .owner = THIS_MODULE,
>> + .name = DRVNAME,
>> + },
>> + .probe = ibmpowernv_probe,
>> + .remove = ibmpowernv_remove,
>> +};
>> +
>> +
> Excessive empty lines.
>
>> +static int __init ibmpowernv_init(void)
>> +{
>> + int err;
>> +
>> +
> Excessive empty lines.
>
>> + err = platform_driver_register(&ibmpowernv_driver);
>> + if (err)
>> + goto exit;
> Sometimes you create an error message, sometimes not. I'd prefer no error
> message to start with (the module loader will create one anyway), but
> at least please be consistent.
>
>> +
>> +
> Excessive empty lines.
>
>> + pdevice = platform_device_alloc(DRVNAME, 0);
>> + if (!pdevice) {
>> + pr_err("%s: Device allocation failed\n", __func__);
>> + err = -ENOMEM;
>> + goto exit_driver_unreg;
>> + }
>> +
>> + err = platform_device_add(pdevice);
>> + if (err) {
>> + pr_err("%s: Device addition failed (%d)\n", __func__, err);
>> + goto exit_device_put;
>> + }
>> +
> Can you use platform_driver_probe() here ?
>
>> + return 0;
>> +
>> +exit_device_put:
>> + platform_device_put(pdevice);
>> +exit_driver_unreg:
>> + platform_driver_unregister(&ibmpowernv_driver);
>> +exit:
>> + return err;
>> +}
>> +
>> +static void __exit ibmpowernv_exit(void)
>> +{
>> + platform_device_unregister(pdevice);
>> + platform_driver_unregister(&ibmpowernv_driver);
>> +}
>> +
>> +MODULE_DESCRIPTION("IBM POWERNV platform sensors");
>> +MODULE_LICENSE("GPL");
>> +
>> +module_init(ibmpowernv_init);
>> +module_exit(ibmpowernv_exit);
>>
>>
> Empty lines at end.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Hi Guenter,
Thanks for the review. I'll rework on the patch and post the v2.
- Neelesh
^ permalink raw reply
* Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS
From: shiva7 @ 2014-05-18 23:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1398206224.1694.254.camel@snotra.buserror.net>
Thanks Scott.
Apologize for not quoting the old email reference. I assumed the old archive
content always will be in the trail.
Any idea whether the DBCR0 BRT bit actually works(??), if I add DBCR0 under
sys_debug context call? because this code seems like direct porting and
wondering why on first place not included under debug_context call.
And also, anything special required for "server" family application code
porting here ?? as because in server family the trace exception used to viz
NORMAL exception proglog and uses SRR0 and SRR1 but in this ISA/embedded
case have dedicated DEBUG_DEBUG prolog and dedicated registers DSRR0 and
DSRR1.
I can see the debug handler already have HACK to simulate the branch taken
case and SIGTRAP to user space.
Thanks in Advance.
--
View this message in context: http://linuxppc.10917.n7.nabble.com/questions-on-CONFIG-PPC-ADV-DEBUG-REGS-DBCR0-BRT-and-DBCR0-ACTIVE-EVENTS-tp70147p82408.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
From: Rusty Russell @ 2014-05-19 0:12 UTC (permalink / raw)
To: Hugh Dickins, Madhavan Srinivasan
Cc: linux-arch, riel, ak, dave.hansen, peterz, x86, linux-kernel,
linux-mm, paulus, mgorman, akpm, linuxppc-dev, mingo,
kirill.shutemov
In-Reply-To: <alpine.LSU.2.11.1405151026540.4664@eggly.anvils>
Hugh Dickins <hughd@google.com> writes:
> On Thu, 15 May 2014, Madhavan Srinivasan wrote:
>>
>> Hi Ingo,
>>
>> Do you have any comments for the latest version of the patchset. If
>> not, kindly can you pick it up as is.
>>
>>
>> With regards
>> Maddy
>>
>> > Kirill A. Shutemov with 8c6e50b029 commit introduced
>> > vm_ops->map_pages() for mapping easy accessible pages around
>> > fault address in hope to reduce number of minor page faults.
>> >
>> > This patch creates infrastructure to modify the FAULT_AROUND_ORDER
>> > value using mm/Kconfig. This will enable architecture maintainers
>> > to decide on suitable FAULT_AROUND_ORDER value based on
>> > performance data for that architecture. First patch also defaults
>> > FAULT_AROUND_ORDER Kconfig element to 4. Second patch list
>> > out the performance numbers for powerpc (platform pseries) and
>> > initialize the fault around order variable for pseries platform of
>> > powerpc.
>
> Sorry for not commenting earlier - just reminded by this ping to Ingo.
>
> I didn't study your numbers, but nowhere did I see what PAGE_SIZE you use.
>
> arch/powerpc/Kconfig suggests that Power supports base page size of
> 4k, 16k, 64k or 256k.
>
> I would expect your optimal fault_around_order to depend very much on
> the base page size.
It was 64k, which is what PPC64 uses on all the major distributions.
You really only get a choice of 4k and 64k with 64 bit power.
> Perhaps fault_around_size would provide a more useful default?
That seems to fit. With 4k pages and order 4, you're asking for 64k.
Maddy's result shows 64k is also reasonable for 64k pages.
Perhaps we try to generalize from two data points (a slight improvement
over doing it from 1!), eg:
/* 4 seems good for 4k-page x86, 0 seems good for 64k page ppc64, so: */
unsigned int fault_around_order __read_mostly =
(16 - PAGE_SHIFT < 0 ? 0 : 16 - PAGE_SHIFT);
Cheers,
Rusty.
^ permalink raw reply
* Re: G5 Quad working with Linux PPC and RadeonHD
From: Michel Dänzer @ 2014-05-19 2:45 UTC (permalink / raw)
To: Luigi Burdo, linuxppc-dev
In-Reply-To: <BLU436-SMTP260B93781C0F77CDD26FD4AC8300@phx.gbl>
On 17.05.2014 17:28, Luigi Burdo wrote:
>
> on X1000 r600 boards dont gave decoration problems
> there is probably needed some other trick about
> for the other architecture.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=74939
That bug is specific to Evergreen / Northern Islands family cards, which
includes your 6570, but not your 4650 for example.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
^ 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