[PATCH] macintosh: ams: replace strict_strtoul() with kstrtoul()
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/macintosh/ams/ams-input.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/macintosh/ams/ams-input.c
b/drivers/macintosh/ams/ams-input.c
index b27e530..2edae7d 100644
--- a/drivers/macintosh/ams/ams-input.c
+++ b/drivers/macintosh/ams/ams-input.c
@@ -118,8 +118,12 @@ static ssize_t ams_input_store_joystick(struct device *dev,
{
unsigned long enable;
int error = 0;
+ int ret;
- if (strict_strtoul(buf, 0, enable) || enable 1)
+ ret = kstrtoul(buf, 0, enable);
+ if (ret)
+ return ret;
+ if (enable 1)
return -EINVAL;
mutex_lock(ams_input_mutex);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [GIT PULL 00/76] perf/core improvements and fixes
* Arnaldo Carvalho de Melo a...@infradead.org wrote: From: Arnaldo Carvalho de Melo a...@ghostprotocols.net Hi Ingo, Please consider pulling. There was a long delay in processing patches related to my vacations that took longer than antecipated to being addressed. With the recent acme/perf/urgent merge and this one I get closer to processing the resulting long backlog. There are still many patches to process, which I will be working on as time permits in the next days and weeks. Thanks, - Arnaldo The following changes since commit 67516844625f45f0ce148a01c27bf41f591872b2: perf: Remove the 'match' callback for auxiliary events processing (2013-07-12 13:50:36 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux tags/perf-core-for-mingo for you to fetch changes up to 2a08c3ec4f7d6058a450d2d4bc6e366955872707: perf header: Recognize version number for perf data file (2013-07-17 17:04:00 -0300) perf/core improvements and fixes: . Add missing 'finished_round' event forwarding in 'perf inject', from Adrian Hunter. . Assorted tidy ups, from Adrian Hunter. . Fall back to sysfs event names when parsing fails, from Andi Kleen. . List pmu events in perf list, from Andi Kleen. . Cleanup some memory allocation/freeing uses, from David Ahern. . Add option to collapse undesired parts of call graph, from Greg Price. . Prep work for multi perf data file storage, from Jiri Olsa. . Add support for more than two files comparision in 'perf diff', from Jiri Olsa . A few more 'perf test' improvements, from Jiri Olsa . libtraceevent cleanups, from Namhyung Kim. . Remove odd build stall in 'perf sched' by moving a large struct initialization from a local variable to a global one, from Namhyung Kim. . Add support for callchains in the gtk UI, from Namhyung Kim. . Do not apply symfs for an absolute vmlinux path, fix from Namhyung Kim. . Use default include path notation for libtraceevent, from Robert Richter. . Fix 'make tools/perf', from Robert Richter. . Make Power7 events available, from Runzhen Wang. . Add --objdump option to 'perf top', from Sukadev Bhattiprolu. Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com Adrian Hunter (7): perf inject: Remove unused parameter perf tools: Fix missing tool parameter perf inject: Add missing 'finished_round' perf tools: Add const specifier to perf_pmu__find name parameter perf evlist: Tidy duplicated munmap code perf tools: Validate perf event header size perf tools: struct thread has a tid not a pid Andi Kleen (2): perf tools: Default to cpu// for events v5 perf list: List kernel supplied event aliases David Ahern (5): perf tools: Add methods for setting/retrieving priv element of thread struct perf evlist: Fix use of uninitialized variable perf tools: Don't free list head in parse_events__free_terms perf tests: Make terms a stack variable in test_term perf parse events: Demystify memory allocations Greg Price (1): perf report/top: Add option to collapse undesired parts of call graph Jiri Olsa (30): perf tools: Remove cwd from perf_session struct perf tests: Omit end of the symbol check failure for test 1 perf tests: Make TEST_ASSERT_VAL global perf tools: Remove callchain_cursor_reset call perf tools: Do not elide parent symbol column perf report: Fix perf_session__delete removal perf tools: Add struct perf_hpp_fmt into hpp callbacks perf tools: Centralize default columns init in perf_hpp__init perf diff: Introducing diff_data object to hold files perf diff: Switching the base hists to be pairs head perf hists: Marking dummy hists entries perf diff: Display data file info ahead of the diff output perf diff: Move diff related columns into diff command perf diff: Move columns into struct data__file perf diff: Change diff command to work over multiple data files perf diff: Update perf diff documentation for multiple data comparison perf diff: Making compute functions static perf diff: Add generic order option for compute sorting perf tools: Move hist_entry__period_snprintf into stdio code perf timechart: Use traceevent lib event-parse.h include perf timechart: Remove event types framework only user perf tools: Remove event types from perf data file perf record: Remove event types pushing perf tools: Remove event types framework completely perf tests: Check proper prev_state size for sched_switch tp perf session: Use session-fd instead of passing fd as argument
Re: [PATCH v2 18/24] i2c: mpc: OF clock lookup for MPC512x
On Thu, Jul 18, 2013 at 21:33 +0100, Russell King - ARM Linux wrote:
On Thu, Jul 18, 2013 at 10:20:52PM +0200, Gerhard Sittig wrote:
+ /* enable clock for the I2C peripheral (non fatal) */
+ clk = of_clk_get_by_name(node, per);
+ if (!IS_ERR(clk)) {
+ clk_prepare_enable(clk);
+ clk_put(clk);
+ }
+
This kind of hacked up approach to the clk API is exactly the thing I
really don't like seeing. I don't know what it is... is the clk API
somehow difficult to use or what's the problem with doing stuff correctly?
1. Get the clock in your probe function.
2. Prepare it at the appropriate time.
3. Enable it appropriately. (or if you want to combine 2 and 3, use
clk_prepare_enable().)
4. Ensure that enables/disables and prepares/unprepares are appropriately
balanced.
5. 'put' the clock in your remove function.
Certainly do not get-enable-put a clock. You're supposed to hold on to
the clock all the time that you're actually using it.
Russel, thank you for the feedback! I agree that your outline of
steps to take is simple and should not be a problem to do.
I noticed that I kept looking at the wrong spot in the driver,
hooked up to some setup routine which lacks a counter part. You
made me re-visit the drivers and find better locations to hook up
to (probe and remove). Part of my sloppiness with immediate put
after enable was caused by put being a NOP at the moment, and the
assumption that clocks without references but in the enabled
state won't go away. But I saw your recent message as well about
how clocks shall get reference counted and keep their provider's
module loaded.
I've queued an update to the I2C, ethernet, and PCI drivers,
which addresses your concerns. I2C and ethernet clock handling
will become correctly balanced, while PCI won't since the
existing driver already lacks a remove() routine. These changes
will be part of v3 of the series.
Mark, Greg, v2 of the series already addresses the above concerns
for the serial communication with the PSC hardware (UART and
SPI). See how 01/24 and 02/24 became much more complex than in
v1, yet should result in appropriate clock handling in these
drivers.
In the very minute I wanted to send out v3, I received feedback
on the CAN driver manipulation from Marc. Apparently it suffers
from the same problem (my blindness to locate the best spot for
resource release), but CAN shall be the last driver in the series
which is not acceptable yet.
Final point - if you want to make it non-fatal, don't play games like:
clk = clk_get(whatever);
if (IS_ERR(clk))
clk = NULL;
...
if (clk)
clk_prepare(clk);
Do this instead:
clk = clk_get(whatever);
...
if (!IS_ERR(clk))
clk_prepare(clk);
etc.
You saw this in the ethernet driver, right? This interesting
style of normalization to NULL in the setup path was meant to
simplify the cleanup path, but that point has become obsolete by
now. Your example doesn't reflect that 'clk' was a more complex
to access member in the driver's private data.
It seems that doing the setup in steps with a local variable, to
only store the reference when all steps were successful, cleans
up the release code paths.
Immediately putting the clock and not having stored the reference
when enable failed is one more instruction before jumping to the
bailout label, but eliminates the pain of tracking get and enable
separately, and needing two labels for disable and put (you
cannot disable a clock that wasn't enabled).
As mentioned, both the I2C driver you responded to as well as the
ethernet driver you reference here got adjusted. v3 will get
sent when I could address the remaining CAN driver issue.
(And on this subject, I'm considering whether to make a change to the
clk API where clk_prepare() and clk_enable() return zero when passed
an error pointer - this means drivers with optional clocks don't have
to burden themselves with these kinds of checks.)
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 16/24] net: can: mscan: make mpc512x code use common clock
On Fri, Jul 19, 2013 at 09:34 +0200, Marc Kleine-Budde wrote:
On 07/18/2013 10:20 PM, Gerhard Sittig wrote:
extend the mscan(4) driver with alternative support for the COMMON_CLK
approach which is an option in the MPC512x platform, keep the existing
clock support implementation in place since the driver is shared with
other MPC5xxx SoCs which don't have common clock support
one byproduct of this change is that the CAN driver no longer needs to
access the SoC's clock control registers, which shall be the domain of
the platform's clock driver
Signed-off-by: Gerhard Sittig g...@denx.de
---
drivers/net/can/mscan/mpc5xxx_can.c | 139
+++
1 file changed, 139 insertions(+)
diff --git a/drivers/net/can/mscan/mpc5xxx_can.c
b/drivers/net/can/mscan/mpc5xxx_can.c
index bc422ba..dd26ab6 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -108,6 +108,143 @@ static u32 mpc52xx_can_get_clock(struct
platform_device *ofdev,
#endif /* CONFIG_PPC_MPC52xx */
#ifdef CONFIG_PPC_MPC512x
+
+#if IS_ENABLED(CONFIG_COMMON_CLK)
+
+static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
+const char *clock_source, int *mscan_clksrc)
+{
+ struct device_node *np;
+ u32 clockdiv;
+ enum {
+ CLK_FROM_AUTO,
+ CLK_FROM_IPS,
+ CLK_FROM_SYS,
+ CLK_FROM_REF,
+ } clk_from;
+ struct clk *clk_in, *clk_can;
+ unsigned long freq_calc;
+
+ /* the caller passed in the clock source spec that was read from
+* the device tree, get the optional clock divider as well
+*/
+ np = ofdev-dev.of_node;
+ clockdiv = 1;
+ of_property_read_u32(np, fsl,mscan-clock-divider, clockdiv);
+ dev_dbg(ofdev-dev, device tree specs: clk src[%s] div[%d]\n,
+ clock_source ? clock_source : NULL, clockdiv);
+
+ /* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
+* get set, and the 'ips' clock is the input to the MSCAN
+* component
+*
+* for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
+* bit needs to get cleared, an optional clock-divider may have
+* been specified (the default value is 1), the appropriate
+* MSCAN related MCLK is the input to the MSCAN component
+*
+* in the absence of a clock-source spec, first an optimal clock
+* gets determined based on the 'sys' clock, if that fails the
+* 'ref' clock is used
+*/
+ clk_from = CLK_FROM_AUTO;
+ if (clock_source) {
+ /* interpret the device tree's spec for the clock source */
+ if (!strcmp(clock_source, ip))
+ clk_from = CLK_FROM_IPS;
+ else if (!strcmp(clock_source, sys))
+ clk_from = CLK_FROM_SYS;
+ else if (!strcmp(clock_source, ref))
+ clk_from = CLK_FROM_REF;
+ else
+ goto err_invalid;
+ dev_dbg(ofdev-dev, got a clk source spec[%d]\n, clk_from);
+ }
+ if (clk_from == CLK_FROM_AUTO) {
+ /* no spec so far, try the 'sys' clock; round to the
+* next MHz and see if we can get a multiple of 16MHz
+*/
+ dev_dbg(ofdev-dev, no clk source spec, trying SYS\n);
+ clk_in = clk_get(ofdev-dev, sys);
+ if (IS_ERR(clk_in))
+ goto err_notavail;
+ freq_calc = clk_get_rate(clk_in);
+ freq_calc += 49;
+ freq_calc /= 100;
+ freq_calc *= 100;
+ if ((freq_calc % 1600) == 0) {
+ clk_from = CLK_FROM_SYS;
+ clockdiv = freq_calc / 1600;
+ dev_dbg(ofdev-dev,
+ clk fit, sys[%lu] div[%d] freq[%lu]\n,
+ freq_calc, clockdiv, freq_calc / clockdiv);
+ }
+ }
+ if (clk_from == CLK_FROM_AUTO) {
+ /* no spec so far, use the 'ref' clock */
+ dev_dbg(ofdev-dev, no clk source spec, trying REF\n);
+ clk_in = clk_get(ofdev-dev, ref);
+ if (IS_ERR(clk_in))
+ goto err_notavail;
+ clk_from = CLK_FROM_REF;
+ freq_calc = clk_get_rate(clk_in);
+ dev_dbg(ofdev-dev,
+ clk fit, ref[%lu] (no div) freq[%lu]\n,
+ freq_calc, freq_calc);
+ }
+
+ /* select IPS or MCLK as the MSCAN input (returned to the caller),
+* setup the MCLK mux source and rate if applicable, apply the
+* optionally specified or derived above divider, and determine
+* the actual resulting clock rate to return to the caller
+*/
+ switch (clk_from) {
+ case CLK_FROM_IPS:
+ clk_can = clk_get(ofdev-dev, ips);
+ if (IS_ERR(clk_can))
+
Re: [PATCH v2 16/24] net: can: mscan: make mpc512x code use common clock
On 07/19/2013 11:41 AM, Gerhard Sittig wrote:
On Fri, Jul 19, 2013 at 09:34 +0200, Marc Kleine-Budde wrote:
On 07/18/2013 10:20 PM, Gerhard Sittig wrote:
extend the mscan(4) driver with alternative support for the COMMON_CLK
approach which is an option in the MPC512x platform, keep the existing
clock support implementation in place since the driver is shared with
other MPC5xxx SoCs which don't have common clock support
one byproduct of this change is that the CAN driver no longer needs to
access the SoC's clock control registers, which shall be the domain of
the platform's clock driver
Signed-off-by: Gerhard Sittig g...@denx.de
---
drivers/net/can/mscan/mpc5xxx_can.c | 139
+++
1 file changed, 139 insertions(+)
diff --git a/drivers/net/can/mscan/mpc5xxx_can.c
b/drivers/net/can/mscan/mpc5xxx_can.c
index bc422ba..dd26ab6 100644
--- a/drivers/net/can/mscan/mpc5xxx_can.c
+++ b/drivers/net/can/mscan/mpc5xxx_can.c
@@ -108,6 +108,143 @@ static u32 mpc52xx_can_get_clock(struct
platform_device *ofdev,
#endif /* CONFIG_PPC_MPC52xx */
#ifdef CONFIG_PPC_MPC512x
+
+#if IS_ENABLED(CONFIG_COMMON_CLK)
+
+static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
+const char *clock_source, int *mscan_clksrc)
+{
+ struct device_node *np;
+ u32 clockdiv;
+ enum {
+ CLK_FROM_AUTO,
+ CLK_FROM_IPS,
+ CLK_FROM_SYS,
+ CLK_FROM_REF,
+ } clk_from;
+ struct clk *clk_in, *clk_can;
+ unsigned long freq_calc;
+
+ /* the caller passed in the clock source spec that was read from
+* the device tree, get the optional clock divider as well
+*/
+ np = ofdev-dev.of_node;
+ clockdiv = 1;
+ of_property_read_u32(np, fsl,mscan-clock-divider, clockdiv);
+ dev_dbg(ofdev-dev, device tree specs: clk src[%s] div[%d]\n,
+ clock_source ? clock_source : NULL, clockdiv);
+
+ /* when clock-source is 'ip', the CANCTL1[CLKSRC] bit needs to
+* get set, and the 'ips' clock is the input to the MSCAN
+* component
+*
+* for clock-source values of 'ref' or 'sys' the CANCTL1[CLKSRC]
+* bit needs to get cleared, an optional clock-divider may have
+* been specified (the default value is 1), the appropriate
+* MSCAN related MCLK is the input to the MSCAN component
+*
+* in the absence of a clock-source spec, first an optimal clock
+* gets determined based on the 'sys' clock, if that fails the
+* 'ref' clock is used
+*/
+ clk_from = CLK_FROM_AUTO;
+ if (clock_source) {
+ /* interpret the device tree's spec for the clock source */
+ if (!strcmp(clock_source, ip))
+ clk_from = CLK_FROM_IPS;
+ else if (!strcmp(clock_source, sys))
+ clk_from = CLK_FROM_SYS;
+ else if (!strcmp(clock_source, ref))
+ clk_from = CLK_FROM_REF;
+ else
+ goto err_invalid;
+ dev_dbg(ofdev-dev, got a clk source spec[%d]\n, clk_from);
+ }
+ if (clk_from == CLK_FROM_AUTO) {
+ /* no spec so far, try the 'sys' clock; round to the
+* next MHz and see if we can get a multiple of 16MHz
+*/
+ dev_dbg(ofdev-dev, no clk source spec, trying SYS\n);
+ clk_in = clk_get(ofdev-dev, sys);
+ if (IS_ERR(clk_in))
+ goto err_notavail;
+ freq_calc = clk_get_rate(clk_in);
+ freq_calc += 49;
+ freq_calc /= 100;
+ freq_calc *= 100;
+ if ((freq_calc % 1600) == 0) {
+ clk_from = CLK_FROM_SYS;
+ clockdiv = freq_calc / 1600;
+ dev_dbg(ofdev-dev,
+ clk fit, sys[%lu] div[%d] freq[%lu]\n,
+ freq_calc, clockdiv, freq_calc / clockdiv);
+ }
+ }
+ if (clk_from == CLK_FROM_AUTO) {
+ /* no spec so far, use the 'ref' clock */
+ dev_dbg(ofdev-dev, no clk source spec, trying REF\n);
+ clk_in = clk_get(ofdev-dev, ref);
+ if (IS_ERR(clk_in))
+ goto err_notavail;
+ clk_from = CLK_FROM_REF;
+ freq_calc = clk_get_rate(clk_in);
+ dev_dbg(ofdev-dev,
+ clk fit, ref[%lu] (no div) freq[%lu]\n,
+ freq_calc, freq_calc);
+ }
+
+ /* select IPS or MCLK as the MSCAN input (returned to the caller),
+* setup the MCLK mux source and rate if applicable, apply the
+* optionally specified or derived above divider, and determine
+* the actual resulting clock rate to return to the caller
+*/
+ switch (clk_from) {
+ case CLK_FROM_IPS:
+ clk_can = clk_get(ofdev-dev, ips);
+ if (IS_ERR(clk_can))
+ goto err_notavail;
+
Re: Inbound PCI and Memory Corruption
On Thu, Jul 18, 2013 at 14:30 -0700, Peter LaDow wrote: We are still stumped on this one, but during a review of the system setup one thing came up that we aren't sure about is the device tree and the DMA engine. It does seem that for incoming PCI transactions the Freescale DMA engine is not used. And in our device tree we have the DMA engine commented out. That is, the fsl,mpc8349-dma and fsl,elo-dma compatible items are not present in the FDT. I don't suppose this could be a problem? Can't tell whether it helps or whether I'm telling you what's already known, but here we go: Some Freescale SoC's don't have _the_ DMA, but instead several of them. Many peripherals have a DMA engine of their own, which you won't notice as a separate entity from the software POV (typically ethernet, USB, PCI, partially video in and out, even coprocessor may have dedicated DMA engines which they might take care of themselves). The thing that you do see (in the device tree, as a software controllable entity) is the general purpose DMA with user servicable channels. This one is may be used for serial communication via UART or SPI, or SDHC/MMC, or peripherals attached to the EMB. Sometimes it's called DMA2 to reflect that there are others as well. So: No, not having to fiddle with DMA stuff when doing PCI need not be a problem, it's actually expected. But since a DMA engine might be involved (that's just not under your command), the accompanying problems may arise. You may need to flush CPU provided data upon write before telling an external entity to access it, and may need to invalidate caches (to have data re-fetched) before the CPU accesses what an external entity did manipulate. And this applies to both payload data as well as management data (descriptors) if the latter apply to the former. HTH virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4 V2] mmc: esdhc: Add broken timeout quirk for p4/p5 board
On 07/18/2013 09:19:59 PM, Zhang Haijun-B42677 wrote: Thanks. Regards Haijun. -Original Message- From: Wood Scott-B07421 Sent: Thursday, July 18, 2013 1:14 AM To: Zhang Haijun-B42677 Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; cbouatmai...@gmail.com; c...@laptop.org; Fleming Andy-AFLEMING; Zhang Haijun-B42677; Zhang Haijun-B42677 Subject: Re: [PATCH 4/4 V2] mmc: esdhc: Add broken timeout quirk for p4/p5 board On 07/17/2013 05:11:31 AM, Haijun Zhang wrote: Sometimes command can't be completed within the time give in eSDHC_SYSCTL[DTOCV]. So just give the max value 0x14 to avoid this issue. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- changes for v2: - Rebuild patch of eSDHC host need long time to generate command interrupt drivers/mmc/host/sdhci-of-esdhc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c index 570bca8..30bfb5c 100644 --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -325,6 +325,12 @@ static void esdhc_of_platform_init(struct sdhci_host *host) if (vvn VENDOR_V_22) host-quirks = ~SDHCI_QUIRK_NO_BUSY_IRQ; + + if ((SVR_SOC_VER(svr) == SVR_B4860) || + (SVR_SOC_VER(svr) == SVR_P5020) || + (SVR_SOC_VER(svr) == SVR_P5040) || + (SVR_SOC_VER(svr) == SVR_P4080)) + host-quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; } Please don't line up the continuation lines of the if-condition with the if-body. [Haijun Wrote:] I'll correct it. Please check variant SoCs as well. If the bug exists on p4080, then it exists on p4040. Likewise with p5040/p5021, and p5020/p5010. Is it present on all revisions of these SoCs? How about p3041, which is usually pretty similar to p5020? p2040/p2041? Is there an erratum number for this problem? [Haijun Wrote:] I only checked this on these boards. These aren't boards; they're chips. Please find out for sure which chips are affected, or else we'll have support issues later when someone is using a chip you didn't test with. And always include the fewer-core variants -- if p4080 is affected, then p4040 is affected, and so on as described above. No errata number yet, Will one be coming? This quirk only give the host max detecting time value to check card's response. No impact on performance or other functions. Does this affect boot time if a card is not present? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4 V4] powerpc/85xx: Add support for 85xx cpu type detection
On 07/18/2013 09:28:20 PM, Zhang Haijun-B42677 wrote: Hi, scott I had update this patch, this is the newest version. If there is no other problem, can you help merge this patch? I hope to make sure the following patch don't need to rebuild due to the change of this patch. It looks OK. I'll pick it up when I do my next batch of patch application (hopefully soon). Go ahead and send the patches that depend on it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Fri, Jan 18, 2013 at 10:38:05AM +1100, Benjamin Herrenschmidt wrote: On Thu, 2013-01-17 at 15:38 +0100, Jan Engelhardt wrote: Meanwhile, I run Linux 3.7.1 and the software side changed somewhat. windfarm_rm31 seems to no longer calm the fans down once loaded, whereas therm_pm72 on Linux 3.0 did so. Hrm, that would be a bug ... unfortunately I never got to test it properly due to my xserve being dead. I booted a Xserve today with 3.11-rc1, and noticed the noise is coming from slots-fan (PCI fan?) which is always 99%, although the slots-temp is just 33. Is it on purpose the rm31 slots PID params are totally different from therm_pm72 slots params? It seems like they have been copied from pm72 drive bay PID params instead. A. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Inbound PCI and Memory Corruption
On 07/18/2013 05:02:33 PM, Benjamin Herrenschmidt wrote: On Thu, 2013-07-18 at 14:30 -0700, Peter LaDow wrote: We are still stumped on this one, but during a review of the system setup one thing came up that we aren't sure about is the device tree and the DMA engine. It does seem that for incoming PCI transactions the Freescale DMA engine is not used. And in our device tree we have the DMA engine commented out. That is, the fsl,mpc8349-dma and fsl,elo-dma compatible items are not present in the FDT. I don't suppose this could be a problem? I doubt it but somebody from FSL might be able to give a better answer. The DMA engine is not related to inbound PCI transactions. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Inbound PCI and Memory Corruption
On Thu, Jul 18, 2013 at 4:30 PM, Peter LaDow pet...@gocougs.wsu.edu wrote: It does seem that for incoming PCI transactions the Freescale DMA engine is not used. And in our device tree we have the DMA engine commented out. That is, the fsl,mpc8349-dma and fsl,elo-dma compatible items are not present in the FDT. This is the standard on-chip DMA engine used (primarily) as an off-loaded memcpy. I've never seen it used for anything related to PCI. You can remove the DMA nodes from the device tree and see if that fixes anything. If it does, then it might be the DMA offload from the network layer that's causing the problems. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
On 07/17/2013 11:00:45 PM, Anton Blanchard wrote: Hi Scott, What specifically should I do to test it? Could you double check perf annotate works? I'm 99% sure it will but that is what was failing on ppc64. I'm not really sure what it's supposed to look like when perf annotate works. It spits a bunch of unreadable[1] dark-blue-on-black assembly code at me, all with 0.00 : in the left column. Oh, wait -- some lines have 100.00 : on the left, in even-more-unreadable dark-red-on-black. Apart from the annoying colors, is there anything specific I should be looking for? Some sort of error message, or output that actually makes sense? I've attached the output from perf annotate and perf report. perf.data was generated by perf record find /usr /dev/null on an NFS root (which took a few seconds to complete), so the large amount of __alloc_skb makes some sense, but the way perf annotate shows 100% on one instruction in each function seems odd. -Scott [1] ...unless I crank the brightness up on my monitor to the point where whites are blinding, or redirect the output to a file so the colors go away. Percent | Source code Disassembly of vmlinux : : : : Disassembly of section .text: : : c0097510 perf_event_comm: 0.00 : c0097510: 94 21 ff a0 stwur1,-96(r1) 0.00 : c0097514: 7c 08 02 a6 mflrr0 0.00 : c0097518: bf 01 00 40 stmwr24,64(r1) 0.00 : c009751c: 7c 7e 1b 78 mr r30,r3 0.00 : c0097520: 90 01 00 64 stw r0,100(r1) 0.00 : c0097524: 3b 80 00 00 li r28,0 0.00 : c0097528: 3b 63 04 68 addir27,r3,1128 0.00 : c009752c: 3b 40 00 00 li r26,0 0.00 : c0097530: 87 bb 00 04 lwzur29,4(r27) 0.00 : c0097534: 2f 9d 00 00 cmpwi cr7,r29,0 0.00 : c0097538: 41 9e 00 1c beq-cr7,c0097554 perf_event_comm+0x44 0.00 : c009753c: 7f 00 00 a6 mfmsr r24 0.00 : c0097540: 7c 00 01 46 .long 0x7c000146 0.00 : c0097544: 80 1d 00 3c lwz r0,60(r29) 0.00 : c0097548: 2f 80 00 00 cmpwi cr7,r0,0 0.00 : c009754c: 40 9e 00 c4 bne-cr7,c0097610 perf_event_comm+0x100 0.00 : c0097550: 7f 00 01 06 .long 0x7f000106 100.00 : c0097554: 2f 9c 00 01 cmpwi cr7,r28,1 0.00 : c0097558: 3b 9c 00 01 addir28,r28,1 0.00 : c009755c: 40 be ff d4 bne-cr7,c0097530 perf_event_comm+0x20 0.00 : c0097560: 3d 20 c0 72 lis r9,-16270 0.00 : c0097564: 80 09 99 50 lwz r0,-26288(r9) 0.00 : c0097568: 2f 80 00 00 cmpwi cr7,r0,0 0.00 : c009756c: 41 be 00 88 beq+cr7,c00975f4 perf_event_comm+0xe4 0.00 : c0097570: 3b e1 00 08 addir31,r1,8 0.00 : c0097574: 38 00 00 00 li r0,0 0.00 : c0097578: 39 20 00 03 li r9,3 0.00 : c009757c: 38 9e 01 d8 addir4,r30,472 0.00 : c0097580: 38 a0 00 10 li r5,16 0.00 : c0097584: 7f e3 fb 78 mr r3,r31 0.00 : c0097588: 90 01 00 1c stw r0,28(r1) 0.00 : c009758c: 90 01 00 20 stw r0,32(r1) 0.00 : c0097590: 90 01 00 28 stw r0,40(r1) 0.00 : c0097594: 90 01 00 2c stw r0,44(r1) 0.00 : c0097598: 90 01 00 30 stw r0,48(r1) 0.00 : c009759c: 91 21 00 24 stw r9,36(r1) 0.00 : c00975a0: 90 01 00 08 stw r0,8(r1) 0.00 : c00975a4: 90 01 00 0c stw r0,12(r1) 0.00 : c00975a8: 90 01 00 10 stw r0,16(r1) 0.00 : c00975ac: 90 01 00 14 stw r0,20(r1) 0.00 : c00975b0: 93 c1 00 18 stw r30,24(r1) 0.00 : c00975b4: 48 1a 05 8d bl c0237b40 strlcpy 0.00 : c00975b8: 7f e3 fb 78 mr r3,r31 0.00 : c00975bc: 4b f8 0e 89 bl c0018444 strlen 0.00 : c00975c0: 3c 80 c0 09 lis r4,-16375 0.00 : c00975c4: 39 23 00 08 addir9,r3,8 0.00 : c00975c8: 93 e1 00 1c stw r31,28(r1) 0.00 : c00975cc: 55 29 00 38 rlwinm r9,r9,0,0,28 0.00 : c00975d0: 3c 60 c0 09 lis r3,-16375 0.00 : c00975d4: 38 09 00 10 addir0,r9,16 0.00 : c00975d8: 91 21 00 20 stw r9,32(r1) 0.00 : c00975dc: 38 63 fd 80 addir3,r3,-640 0.00 : c00975e0: 38 84 65 50 addir4,r4,25936 0.00 : c00975e4: 38 a1
Re: ABI defined register usage within function calls
On 07/10/2013 08:54:39 AM, JiveTalkin wrote: Hello. I would like to monitor the value of one of the parameters (within the stack frame) that have been passed as part of a context switch (from process context to interrupt context). I don't understand this... What specifically do you mean by interrupt context? Do you mean syscall context? Syscall parameters are passed in registers, not in the stack frame. START_EXCEPTION does nothing more than align us to a word (32bit) boundary (obviously for performance reasons). What I need to understand is the NORMAL_EXCEPTION_PROLOG. I reproduce it here: First thing it does it saves r10, r11 and r1(containing the Stack pointer) into the scratch registers 0,1 and 2 respectively. Correct me if I am wrong, but as per the older EABI, isn't it recommended for the OS to load SPRG0 with the start address of an area of memory (the stack top) to be used by the 1st level interrupt handler? Or can these registers be used anyway we see fit? Linux doesn't use EABI -- and in any case, I don't see SPRG anywhere in the EABI document, and no relevant mention in the SVR4 ABI. It's up to the OS how SPRGs are used. Moving on, it seems the kernel folks have decided to use SPRNG3 to point to the currently running process's thread_struct structure. Is there a document which recommends so or was it an unanimous decision taken during early development? Just curios. Then we go on to check the value of the PR bit from the MSR which has been copied by the hardware to SRR1. So here we are actually checking whether the exception occurred when the machine was in user space or kernel space right? So once we determine that we've originated in the userspace, as is the case for SystemCall, we are apparently updating r1 (stack pointer) with (r1 + THREAD) - THREAD_INFO. Or is it actually r1 + (THREAD_INFO-THREAD)? Neither; it's the address stored at r10 + (THREAD_INFO-THREAD). In either case, how does this take us to the top of the kernel stack, is something I am unable to get my head around. May be I do not know some basic concepts here, which is why this is looking strange to me. Could someone please elaborate? Some ASCII art would be really nice here. r10 was loaded from SPRG3, and thus points to the thread struct. The thread struct (a.k.a. SPRG3, a.k.a. THREAD) and a pointer to the stack are both contained within the task_struct (a.k.a. current). At the bottom of the stack is the thread_info struct, which is why current-stack is called THREAD_INFO in asm-offsets.c. Since THREAD and THREAD_INFO are both in the same struct, we can get THREAD_INFO by adding the difference in offsets to the THREAD pointer that we got from SPRG3. That gets us to the bottom of the stack; ALLOC_STACK_FRAME() adds the size of the stack so that we point to the top and are ready to create a frame. It's a confusing name since it doesn't actually allocate a frame; that happens in the subi instruction that follows. We then allocate an exception frame to hold the activation record (stack frame) for the caller. Into this frame, we save the CR. We also save R12 and R9 (as they are volatile registers and the caller must save them before calling a function). We then retrieve the earlier stored values of r10 and r11 and store them into the frame (using r11 as an anchor as it now points to the top of the stack frame). Then we store the link register. We retrieve previously stored r1 (previous frame's stack pointer isn't it?), retrieve SRR0 (which includes the return address and in this case, the address of the next instruction in case of a syscall from userspace, correct?). If we have already stored the previous value of R1 then what are we doing with this: What are we doing with what? The previous value of r1 is still in r1. At this point r11 holds the new stack pointer. Did you misread the stw r1, GPR1(r11) as a load? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
