* Re: [PATCH V2 0/6] perf: New conditional branch filter
From: Stephane Eranian @ 2013-09-26 11:14 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Arnaldo Carvalho de Melo, Sukadev Bhattiprolu, LKML,
Linux PPC dev, Michael Neuling
In-Reply-To: <524006C4.3010006@linux.vnet.ibm.com>
On Mon, Sep 23, 2013 at 11:15 AM, Anshuman Khandual
<khandual@linux.vnet.ibm.com> wrote:
> On 09/21/2013 12:25 PM, Stephane Eranian wrote:
>> On Tue, Sep 10, 2013 at 4:06 AM, Michael Ellerman
>> <michael@ellerman.id.au> wrote:
>>> >
>>> > On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote:
>>>> > > This patchset is the re-spin of the original branch stack sampling
>>>> > > patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset
>>>> > > also enables SW based branch filtering support for PPC64 platforms which have
>>>> > > branch stack sampling support. With this new enablement, the branch filter support
>>>> > > for PPC64 platforms have been extended to include all these combinations discussed
>>>> > > below with a sample test application program.
>>> >
>>> > ...
>>> >
>>>> > > Mixed filters
>>>> > > -------------
>>>> > > (6) perf record -e branch-misses:u -j any_call,any_ret ./cprog
>>>> > > Error:
>>>> > > The perf.data file has no samples!
>>>> > >
>>>> > > NOTE: As expected. The HW filters all the branches which are calls and SW tries to find return
>>>> > > branches in that given set. Both the filters are mutually exclussive, so obviously no samples
>>>> > > found in the end profile.
>>> >
>>> > The semantics of multiple filters is not clear to me. It could be an OR,
>>> > or an AND. You have implemented AND, does that match existing behaviour
>>> > on x86 for example?
>>> >
>> The semantic on the API is OR. AND does not make sense: CALL & RETURN?
>> On x86, the HW filter is an OR (default: ALL, set bit to disable a
>> type). I suspect
>> it is similar on PPC.
>
> Hey Stephane,
>
> In POWER8 BHRB, we have got three HW PMU filters out of which we are trying
> to use two of them PERF_SAMPLE_BRANCH_ANY_CALL and PERF_SAMPLE_BRANCH_COND
> respectively.
>
> (1) These filters are exclusive of each other and cannot be OR-ed with each other
>
So you are saying that the HW filter is exclusive. That seems odd. But
I think it is
because of the choices is ANY. ANY covers all the types of branches. Therefore
it does not make a difference whether you add COND or not. And
vice-versa, if you
set COND, you need to disable ANY. I bet if you add other filters such
as CALL, RETURN,
then you could OR them and say: I want RETURN or CALLS.
But that's okay. The API operates in OR mode but if the HW does not
support it, you
can check the mask and reject if more than one type is set. That is
arch-specific code.
The alternative, if to only capture ANY and emulate the filter in SW.
This will work, of
course. But the downside, is that you lose the way to appreciate how
many, for instance,
COND branches you sampled out of the total number of COND branches
retired. Unless
you can count COND branches separately.
> (2) The SW filters are applied on the branch record set captured with BHRB
> which have the HW filters applied. So the working set is already reduced
> with the HW PMU filters. SW filter goes through the working set and figures
> out which one of them satisfy the SW filter criteria and gets picked up. The
> SW filter cannot find out branches records which matches the criteria outside
> of BHRB captured set. So we cannot OR the filters.
>
Yes, you can if you set the HW filter to ANY. And then filter the
branches by type
based on the SW mask. You need to decode each sampled branch for that. This
is done in X86 to work around HW bugs in the HW filter, for instance.
> This makes the combination of HW and SW filter inherently an "AND" not OR.
>
> (3) But once we have captured the BHRB filtered data with HW PMU filter, multiple SW
> filters (if requested) can be applied either in OR or AND manner.
>
> It should be either like
> (1) (HW_FILTER_1) && (SW_FILTER_1) && (SW_FILTER_2)
> or like
> (2) (HW_FILTER_1) && (SW_FILTER_1 || SW_FILTER_2)
>
> NOTE: I admit that the current validate_instruction() function does not do
> either of them correctly. Will fix it in the next iteration.
>
Just set the HW filter to ANY and filter in SW.
Isn't that possible?
> (4) These combination of filters are not supported right now because
>
> (a) We are unable to process two HW PMU filters simultaneously
> (b) We have not worked on replacement SW filter for either of the HW filters
>
> (1) (HW_FILTER_1), (HW_FILTER_2)
> (2) (HW_FILTER_1), (HW_FILTER_2), (SW_FILTER_1)
> (3) (HW_FILTER_1), (HW_FILTER_2), (SW_FILTER_1), (SW_FILTER_2)
>
> How ever these combination of filters can be supported right now.
>
> (1) (HW_FILTER_1)
> (2) (HW_FILTER_2)
>
> (3) (SW_FILTER_1)
> (4) (SW_FILTER_2)
> (5) (SW_FILTER_1), (SW_FILTER_2)
>
> (6) (HW_FILTER_1), (SW_FILTER_1)
> (7) (HW_FILTER_1), (SW_FILTER_2)
> (8) (HW_FILTER_1), (SW_FILTER_1), (SW_FILTER_2)
> (9) (HW_FILTER_2), (SW_FILTER_1)
> (10) (HW_FILTER_2), (SW_FILTER_2)
> (11) (HW_FILTER_2), (SW_FILTER_1), (SW_FILTER_2)
>
>
> Given the situation as explained here, which semantic would be better for single
> HW and multiple SW filters. Accordingly validate_instruction() function will have
> to be re-implemented. But I believe OR-ing the SW filters will be preferable.
>
> (1) (HW_FILTER_1) && (SW_FILTER_1) && (SW_FILTER_2)
> or
> (2) (HW_FILTER_1) && (SW_FILTER_1 || SW_FILTER_2)
>
> Please let me know your inputs and suggestions on this. Thank you.
>
> Regards
> Anshuman
>
^ permalink raw reply
* [PATCH] powerpc/powernv: Reduce panic timeout from 180s to 10s
From: Anton Blanchard @ 2013-09-26 11:17 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
We made this change to pseries in 2011 and I think it makes
sense to do the same on powernv.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: b/arch/powerpc/platforms/powernv/setup.c
===================================================================
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -37,6 +37,8 @@
static void __init pnv_setup_arch(void)
{
+ panic_timeout = 10;
+
/* Initialize SMP */
pnv_smp_init();
^ permalink raw reply
* RE: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: David Laight @ 2013-09-26 11:34 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linuxppc-dev, linux-pci, Joerg Roedel, x86, linux-kernel,
linux-ide, Jan Beulich, Tejun Heo, Bjorn Helgaas, Ingo Molnar
In-Reply-To: <20130926104548.GB16774@dhcp-26-207.brq.redhat.com>
> On Thu, Sep 26, 2013 at 09:58:53AM +0100, David Laight wrote:
> > Would it be possible to do some kind of 2-stage allocation.
> > In the first pass the driver would pass a minimum and desired
> > number of MSI-X interrupts, but not actually be given any.
>=20
> Repeated calls to msi_enable_msi/msix() is what we are trying to =
avoid.
I was thinking that the first call would be done during driver probe
(assuming such a time exists) so that the subsystem could determine
how many interrupts all the drivers would like, so it can then
hand out a smaller number to some of the early drivers in order
to have some left to satisfy the minimum requirement of later
ones.
So all it would do is sum the requirements of all the drivers.
David
^ permalink raw reply
* Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: Alexander Gordeev @ 2013-09-26 12:13 UTC (permalink / raw)
To: David Laight
Cc: linuxppc-dev, linux-pci, Joerg Roedel, x86, linux-kernel,
linux-ide, Jan Beulich, Tejun Heo, Bjorn Helgaas, Ingo Molnar
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7360@saturn3.aculab.com>
On Thu, Sep 26, 2013 at 12:34:36PM +0100, David Laight wrote:
> I was thinking that the first call would be done during driver probe
> (assuming such a time exists) so that the subsystem could determine
> how many interrupts all the drivers would like, so it can then
> hand out a smaller number to some of the early drivers in order
> to have some left to satisfy the minimum requirement of later
> ones.
>
> So all it would do is sum the requirements of all the drivers.
It is already implemented - please see commit 448e2ca ("powerpc/pseries:
Implement a quota system for MSIs")
All other archs do not have MSI vector space limitations.
> David
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: Mark Lord @ 2013-09-26 12:32 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linuxppc-dev, Joerg Roedel, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Jan Beulich, linux-pci@vger.kernel.org, Tejun Heo, Bjorn Helgaas,
Ingo Molnar
In-Reply-To: <20130918094759.GA2353@dhcp-26-207.brq.redhat.com>
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
>
> The last pattern makes most of sense to me and could be updated with a more
> clear sequence - a call to (bit modified) pci_msix_table_size() followed
> by a call to pci_enable_msix(). I think this pattern can effectively
> supersede the currently recommended "loop" practice.
The loop is still necessary, because there's a race between those two calls,
so that pci_enable_msix() can still fail due to lack of MSIX slots.
^ permalink raw reply
* Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: Alexander Gordeev @ 2013-09-26 13:03 UTC (permalink / raw)
To: Mark Lord
Cc: linuxppc-dev, Joerg Roedel, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Jan Beulich, linux-pci@vger.kernel.org, Tejun Heo, Bjorn Helgaas,
Ingo Molnar
In-Reply-To: <52442975.9000603@start.ca>
On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
> On 13-09-18 05:48 AM, Alexander Gordeev wrote:
> > The last pattern makes most of sense to me and could be updated with a more
> > clear sequence - a call to (bit modified) pci_msix_table_size() followed
> > by a call to pci_enable_msix(). I think this pattern can effectively
> > supersede the currently recommended "loop" practice.
>
> The loop is still necessary, because there's a race between those two calls,
> so that pci_enable_msix() can still fail due to lack of MSIX slots.
Moreover, the existing loop pattern is racy and could fail just as easily ;)
But (1) that is something drivers should expect and (2) there is basically
nothing to race against - that is probably the reason it has not been a
problem for pSeries. So I think we should not care about this.
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: Tejun Heo @ 2013-09-26 13:11 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-pci@vger.kernel.org, Joerg Roedel, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Jan Beulich, Bjorn Helgaas, linuxppc-dev, Ingo Molnar
In-Reply-To: <20130926074646.GA16774@dhcp-26-207.brq.redhat.com>
Hello,
On Thu, Sep 26, 2013 at 09:46:46AM +0200, Alexander Gordeev wrote:
> > Can you please go into a bit of detail on that? Why does it matter?
>
> Because otherwise we will re-introduce a problem described by Michael:
> "We have a small number of MSIs available, limited by hardware &
> firmware, if we don't impose a quota then the first device that probes
> will get most/all of the MSIs and other devices miss out."
Still not following. Why wouldn't just letting the drivers request
the optimal number they want and falling back to single interrupt mode
work? ie. why can't we just have an all or nothing interface?
> > Is it because you're worried you might cause performance regression by
> > forcing prevoius partial multiple allocations to single interrupt
> > operation?
>
> Well, not really. I think it won't be possible to force people not to use
> partial allocations anyway. Some controllers just do not care how many MSIs
> they are configured with. Some drivers derive the number of MSIs desired
> from the number of CPUs online - in such cases allocating more MSIs (i.e.
> a number the controller advertised) could cause a performance degradation
> even.
Yeah, sure thing but just let the *driver* decide that number without
worrying about how many they can actually get. Ultimately, what we
want is removing this extra variable which can arbitrarily affect the
number of allocated interrupts so that we only have to worry about
either proper multiple MSI mode or single interrupt mode, not
something random inbetween. It is possible that there exists a driver
which absolutely requires partial allocation on certain archs, but
that should be a very special case and the interface should look
accordingly ugly / special. But do we actually have those?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: Alexander Gordeev @ 2013-09-26 14:39 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-pci@vger.kernel.org, Joerg Roedel, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Jan Beulich, Bjorn Helgaas, linuxppc-dev, Ingo Molnar
In-Reply-To: <20130926131147.GA31249@mtj.dyndns.org>
On Thu, Sep 26, 2013 at 09:11:47AM -0400, Tejun Heo wrote:
> > Because otherwise we will re-introduce a problem described by Michael:
> > "We have a small number of MSIs available, limited by hardware &
> > firmware, if we don't impose a quota then the first device that probes
> > will get most/all of the MSIs and other devices miss out."
>
> Still not following. Why wouldn't just letting the drivers request
> the optimal number they want and falling back to single interrupt mode
> work? ie. why can't we just have an all or nothing interface?
I can imagine a scenario where the first device probes in, requests its
optimal number, acquires that number and exhausts MSIs in pSeries firmware.
The next few devices possibly end up with single MSI, since no MSIs left
to satisfy their optimal numbers. If one of those single-MSI'ed devices
happened to be a high-performance HBA hitting a degraded performance that
alone would force (IBM) to introduce the quotas. Now, if the same/another
device happened does not support the legacy interrupt mode and no MSI
resources have left in the platform firmware at all...
> tejun
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: Tejun Heo @ 2013-09-26 14:42 UTC (permalink / raw)
To: Alexander Gordeev
Cc: linux-pci@vger.kernel.org, Joerg Roedel, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Jan Beulich, Bjorn Helgaas, linuxppc-dev, Ingo Molnar
In-Reply-To: <20130926143901.GE16774@dhcp-26-207.brq.redhat.com>
Hello,
On Thu, Sep 26, 2013 at 10:39 AM, Alexander Gordeev <agordeev@redhat.com> wrote:
> I can imagine a scenario where the first device probes in, requests its
Well, we can imagine a lot of thing but usually have to draw the line somewhere.
> optimal number, acquires that number and exhausts MSIs in pSeries firmware.
> The next few devices possibly end up with single MSI, since no MSIs left
> to satisfy their optimal numbers. If one of those single-MSI'ed devices
> happened to be a high-performance HBA hitting a degraded performance that
> alone would force (IBM) to introduce the quotas. Now, if the same/another
> device happened does not support the legacy interrupt mode and no MSI
> resources have left in the platform firmware at all...
If that happens, that's just the platform code being dumb. Quota is
there to prevent that from happening, right? Let's please do something
simple and worry about problems if they actually exist.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/pseries: CONFIG_PSERIES_MSI should depend on PPC_PSERIES
From: Gavin Shan @ 2013-09-26 15:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, shangw
In-Reply-To: <1380181937-15156-1-git-send-email-michael@ellerman.id.au>
On Thu, Sep 26, 2013 at 05:52:16PM +1000, Michael Ellerman wrote:
>Previously PSERIES_MSI depended on PPC_PSERIES via EEH. However in
>commit 317f06d "powerpc/eeh: Move common part to kernel directory" we
>made CONFIG_EEH selectable on POWERNV. That leaves us with PSERIES_MSI
>being live even when PSERIES=n. Fix it by making PSERIES_MSI depend
>directly on PPC_PSERIES.
>
>Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Reviewed-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>---
> arch/powerpc/platforms/pseries/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
>index 62b4f80..e666432 100644
>--- a/arch/powerpc/platforms/pseries/Kconfig
>+++ b/arch/powerpc/platforms/pseries/Kconfig
>@@ -34,7 +34,7 @@ config PPC_SPLPAR
>
> config PSERIES_MSI
> bool
>- depends on PCI_MSI && EEH
>+ depends on PCI_MSI && PPC_PSERIES && EEH
> default y
>
> config PSERIES_ENERGY
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/powernv: Replace CONFIG_POWERNV_MSI with just CONFIG_PPC_POWERNV
From: Gavin Shan @ 2013-09-26 15:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, shangw
In-Reply-To: <1380181937-15156-2-git-send-email-michael@ellerman.id.au>
On Thu, Sep 26, 2013 at 05:52:17PM +1000, Michael Ellerman wrote:
>We currently have a user visible CONFIG_POWERNV_MSI option, but it
>doesn't actually disable MSI for powernv. The MSI code is always built,
>what it does disable is the inclusion of the MSI bitmap code, which
>leads to a build error.
>
>eg, with PPC_POWERNV=y and POWERNV_MSI=n we get:
>
> arch/powerpc/platforms/built-in.o: In function `.pnv_teardown_msi_irqs':
> pci.c:(.text+0x3558): undefined reference to `.msi_bitmap_free_hwirqs'
>
>We don't really need a POWERNV_MSI symbol, just have the MSI bitmap code
>depend directly on PPC_POWERNV.
>
>Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Reviewed-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>---
> arch/powerpc/platforms/powernv/Kconfig | 5 -----
> arch/powerpc/sysdev/Kconfig | 2 +-
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
>index 6fae5eb..09a5afd 100644
>--- a/arch/powerpc/platforms/powernv/Kconfig
>+++ b/arch/powerpc/platforms/powernv/Kconfig
>@@ -11,11 +11,6 @@ config PPC_POWERNV
> select PPC_UDBG_16550
> default y
>
>-config POWERNV_MSI
>- bool "Support PCI MSI on PowerNV platform"
>- depends on PCI_MSI
>- default y
>-
> config PPC_POWERNV_RTAS
> depends on PPC_POWERNV
> bool "Support for RTAS based PowerNV platforms such as BML"
>diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
>index ab4cb54..8223f78 100644
>--- a/arch/powerpc/sysdev/Kconfig
>+++ b/arch/powerpc/sysdev/Kconfig
>@@ -19,7 +19,7 @@ config PPC_MSI_BITMAP
> default y if MPIC
> default y if FSL_PCI
> default y if PPC4xx_MSI
>- default y if POWERNV_MSI
>+ default y if PPC_POWERNV
>
> source "arch/powerpc/sysdev/xics/Kconfig"
>
Thanks,
Gavin
^ permalink raw reply
* [PATCH 17/21] of: move of_translate_dma_address to of_address.h
From: Rob Herring @ 2013-09-26 18:50 UTC (permalink / raw)
To: linux-kernel, devicetree
Cc: Grant Likely, Paul Mackerras, linuxppc-dev, Rob Herring
In-Reply-To: <1380221456-11192-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
of_translate_dma_address is implemented in common code, so move the
declaration there too.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/prom.h | 4 ----
include/linux/of_address.h | 4 ++++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index 43fe002..b8774bd 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -24,10 +24,6 @@
* OF address retreival & translation
*/
-/* Translate a DMA address from device space to CPU space */
-extern u64 of_translate_dma_address(struct device_node *dev,
- const __be32 *in_addr);
-
/* Parse the ibm,dma-window property of an OF node into the busno, phys and
* size parameters.
*/
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index e8a1797..5f6ed6b 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -34,6 +34,10 @@ static inline void of_pci_range_to_resource(struct of_pci_range *range,
res->name = np->full_name;
}
+/* Translate a DMA address from device space to CPU space */
+extern u64 of_translate_dma_address(struct device_node *dev,
+ const __be32 *in_addr);
+
#ifdef CONFIG_OF_ADDRESS
extern u64 of_translate_address(struct device_node *np, const __be32 *addr);
extern bool of_can_translate_address(struct device_node *dev);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 19/21] powerpc: add explicit OF includes
From: Rob Herring @ 2013-09-26 18:50 UTC (permalink / raw)
To: linux-kernel, devicetree
Cc: Rob Herring, Olof Johansson, Paul Mackerras, Grant Likely,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <1380221456-11192-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
When removing prom.h include by of.h, several OF headers will no longer
be implicitly included. Add explicit includes of of_*.h as needed.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/epapr_paravirt.c | 1 +
arch/powerpc/platforms/512x/clock.c | 1 +
arch/powerpc/platforms/512x/pdm360ng.c | 2 ++
arch/powerpc/platforms/82xx/mpc8272_ads.c | 2 ++
arch/powerpc/platforms/82xx/pq2fads.c | 2 ++
arch/powerpc/platforms/83xx/suspend.c | 2 ++
arch/powerpc/platforms/86xx/pic.c | 1 +
arch/powerpc/platforms/embedded6xx/flipper-pic.c | 1 +
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 2 ++
arch/powerpc/platforms/pasemi/gpio_mdio.c | 1 +
arch/powerpc/platforms/powermac/pfunc_base.c | 1 +
arch/powerpc/platforms/powernv/opal-lpc.c | 1 +
arch/powerpc/platforms/powernv/opal.c | 1 +
arch/powerpc/platforms/powernv/setup.c | 1 +
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 ++
arch/powerpc/sysdev/cpm_common.c | 1 +
arch/powerpc/sysdev/fsl_gtm.c | 2 ++
arch/powerpc/sysdev/fsl_pmc.c | 1 +
arch/powerpc/sysdev/mpic.c | 8 ++++----
arch/powerpc/sysdev/mpic_timer.c | 2 ++
20 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/epapr_paravirt.c b/arch/powerpc/kernel/epapr_paravirt.c
index 6300c13..7898be9 100644
--- a/arch/powerpc/kernel/epapr_paravirt.c
+++ b/arch/powerpc/kernel/epapr_paravirt.c
@@ -18,6 +18,7 @@
*/
#include <linux/of.h>
+#include <linux/of_fdt.h>
#include <asm/epapr_hcalls.h>
#include <asm/cacheflush.h>
#include <asm/code-patching.h>
diff --git a/arch/powerpc/platforms/512x/clock.c b/arch/powerpc/platforms/512x/clock.c
index e504166..fd8a376 100644
--- a/arch/powerpc/platforms/512x/clock.c
+++ b/arch/powerpc/platforms/512x/clock.c
@@ -24,6 +24,7 @@
#include <linux/mutex.h>
#include <linux/io.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <asm/mpc5xxx.h>
#include <asm/mpc5121.h>
diff --git a/arch/powerpc/platforms/512x/pdm360ng.c b/arch/powerpc/platforms/512x/pdm360ng.c
index 24b314d..116f2325 100644
--- a/arch/powerpc/platforms/512x/pdm360ng.c
+++ b/arch/powerpc/platforms/512x/pdm360ng.c
@@ -14,6 +14,8 @@
#include <linux/kernel.h>
#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_fdt.h>
#include <linux/of_platform.h>
#include <asm/machdep.h>
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c b/arch/powerpc/platforms/82xx/mpc8272_ads.c
index 30394b4..6a14cf5 100644
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -16,6 +16,8 @@
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/fsl_devices.h>
+#include <linux/of_address.h>
+#include <linux/of_fdt.h>
#include <linux/of_platform.h>
#include <linux/io.h>
diff --git a/arch/powerpc/platforms/82xx/pq2fads.c b/arch/powerpc/platforms/82xx/pq2fads.c
index e1dceee..e5f82ec 100644
--- a/arch/powerpc/platforms/82xx/pq2fads.c
+++ b/arch/powerpc/platforms/82xx/pq2fads.c
@@ -15,6 +15,8 @@
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/fsl_devices.h>
+#include <linux/of_address.h>
+#include <linux/of_fdt.h>
#include <linux/of_platform.h>
#include <asm/io.h>
diff --git a/arch/powerpc/platforms/83xx/suspend.c b/arch/powerpc/platforms/83xx/suspend.c
index 1d769a2..3d9716c 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -20,6 +20,8 @@
#include <linux/freezer.h>
#include <linux/suspend.h>
#include <linux/fsl_devices.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/export.h>
diff --git a/arch/powerpc/platforms/86xx/pic.c b/arch/powerpc/platforms/86xx/pic.c
index 9982f57..d5b98c0 100644
--- a/arch/powerpc/platforms/86xx/pic.c
+++ b/arch/powerpc/platforms/86xx/pic.c
@@ -10,6 +10,7 @@
#include <linux/stddef.h>
#include <linux/kernel.h>
#include <linux/interrupt.h>
+#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <asm/mpic.h>
diff --git a/arch/powerpc/platforms/embedded6xx/flipper-pic.c b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
index 53d6eee0..4cde8e7 100644
--- a/arch/powerpc/platforms/embedded6xx/flipper-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <asm/io.h>
#include "flipper-pic.h"
diff --git a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
index 3006b51..7cab21d 100644
--- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
@@ -18,6 +18,8 @@
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <asm/io.h>
#include "hlwd-pic.h"
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index 0237ab7..15adee5 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -30,6 +30,7 @@
#include <linux/ioport.h>
#include <linux/interrupt.h>
#include <linux/phy.h>
+#include <linux/of_address.h>
#include <linux/of_mdio.h>
#include <linux/of_platform.h>
diff --git a/arch/powerpc/platforms/powermac/pfunc_base.c b/arch/powerpc/platforms/powermac/pfunc_base.c
index f5e3cda..e49d07f 100644
--- a/arch/powerpc/platforms/powermac/pfunc_base.c
+++ b/arch/powerpc/platforms/powermac/pfunc_base.c
@@ -4,6 +4,7 @@
#include <linux/kernel.h>
#include <linux/interrupt.h>
#include <linux/spinlock.h>
+#include <linux/of_irq.h>
#include <asm/pmac_feature.h>
#include <asm/pmac_pfunc.h>
diff --git a/arch/powerpc/platforms/powernv/opal-lpc.c b/arch/powerpc/platforms/powernv/opal-lpc.c
index a7614bb..e7e59e4 100644
--- a/arch/powerpc/platforms/powernv/opal-lpc.c
+++ b/arch/powerpc/platforms/powernv/opal-lpc.c
@@ -17,6 +17,7 @@
#include <asm/firmware.h>
#include <asm/xics.h>
#include <asm/opal.h>
+#include <asm/prom.h>
static int opal_lpc_chip_id = -1;
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 2911abe..f36ff35 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -13,6 +13,7 @@
#include <linux/types.h>
#include <linux/of.h>
+#include <linux/of_fdt.h>
#include <linux/of_platform.h>
#include <linux/interrupt.h>
#include <linux/notifier.h>
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index e239dcf..19884b2 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -23,6 +23,7 @@
#include <linux/irq.h>
#include <linux/seq_file.h>
#include <linux/of.h>
+#include <linux/of_fdt.h>
#include <linux/interrupt.h>
#include <linux/bug.h>
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 9a432de..9590dbb 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -10,12 +10,14 @@
*/
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/memblock.h>
#include <linux/vmalloc.h>
#include <linux/memory.h>
#include <asm/firmware.h>
#include <asm/machdep.h>
+#include <asm/prom.h>
#include <asm/sparsemem.h>
static unsigned long get_memblock_size(void)
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 4dd5341..4f78695 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -22,6 +22,7 @@
#include <linux/spinlock.h>
#include <linux/export.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/slab.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
index 0eb871c..1b980ee 100644
--- a/arch/powerpc/sysdev/fsl_gtm.c
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -19,6 +19,8 @@
#include <linux/list.h>
#include <linux/io.h>
#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
#include <linux/spinlock.h>
#include <linux/bitops.h>
#include <linux/slab.h>
diff --git a/arch/powerpc/sysdev/fsl_pmc.c b/arch/powerpc/sysdev/fsl_pmc.c
index 592a0f8..8cf4aa0 100644
--- a/arch/powerpc/sysdev/fsl_pmc.c
+++ b/arch/powerpc/sysdev/fsl_pmc.c
@@ -18,6 +18,7 @@
#include <linux/suspend.h>
#include <linux/delay.h>
#include <linux/device.h>
+#include <linux/of_address.h>
#include <linux/of_platform.h>
struct pmc_regs {
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 1be54fa..2d30eaf 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -535,7 +535,7 @@ static void __init mpic_scan_ht_pic(struct mpic *mpic, u8 __iomem *devbase,
mpic->fixups[irq].data = readl(base + 4) | 0x80000000;
}
}
-
+
static void __init mpic_scan_ht_pics(struct mpic *mpic)
{
@@ -1475,7 +1475,7 @@ struct mpic * __init mpic_alloc(struct device_node *node,
* as a default instead of the value read from the HW.
*/
last_irq = (greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK)
- >> MPIC_GREG_FEATURE_LAST_SRC_SHIFT;
+ >> MPIC_GREG_FEATURE_LAST_SRC_SHIFT;
if (isu_size)
last_irq = isu_size * MPIC_MAX_ISU - 1;
of_property_read_u32(mpic->node, "last-interrupt-source", &last_irq);
@@ -1625,7 +1625,7 @@ void __init mpic_init(struct mpic *mpic)
/* start with vector = source number, and masked */
u32 vecpri = MPIC_VECPRI_MASK | i |
(8 << MPIC_VECPRI_PRIORITY_SHIFT);
-
+
/* check if protected */
if (mpic->protected && test_bit(i, mpic->protected))
continue;
@@ -1634,7 +1634,7 @@ void __init mpic_init(struct mpic *mpic)
mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), 1 << cpu);
}
}
-
+
/* Init spurious vector */
mpic_write(mpic->gregs, MPIC_INFO(GREG_SPURIOUS), mpic->spurious_vec);
diff --git a/arch/powerpc/sysdev/mpic_timer.c b/arch/powerpc/sysdev/mpic_timer.c
index c06db92..22d7d57 100644
--- a/arch/powerpc/sysdev/mpic_timer.c
+++ b/arch/powerpc/sysdev/mpic_timer.c
@@ -19,7 +19,9 @@
#include <linux/interrupt.h>
#include <linux/slab.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <linux/syscore_ops.h>
#include <sysdev/fsl_soc.h>
#include <asm/io.h>
--
1.8.1.2
^ permalink raw reply related
* Re: therm_adt746x: -3 invalid for parameter limit_adjust
From: Christian Kujau @ 2013-09-26 20:07 UTC (permalink / raw)
To: Jean Delvare; +Cc: colin, Andrew Morton, Jingoo Han, linuxppc-dev
In-Reply-To: <20130926113936.24c10b78@endymion.delvare>
On Thu, 26 Sep 2013 at 11:39, Jean Delvare wrote:
> I think it is a bug in:
>
> commit 6072ddc8520b86adfac6939ca32fb6e6c4de017a
> Author: Jingoo Han <jg1.han@samsung.com>
> Date: Thu Sep 12 15:14:07 2013 -0700
>
> kernel: replace strict_strto*() with kstrto*()
>
> The change was a good idea but the code itself is not, it has kstrtoul
> in many places where kstrtol should be used. Please try the following
> patch, hopefully that should fix your problem:
>
Bingo, this did it! Applied to 3.12.0-rc2, the limit is now lowered again:
$ modprobe therm_adt746x limit_adjust=-3
$ dmesg
[...]
adt746x: Lowering max temperatures from 73, 80, 109 to 67, 47, 67
Thanks!
Tested-by: Christian Kujau <lists@nerdbynature.de>
Christian.
> From: Jean Delvare <khali@linux-fr.org>
> Subject: kernel/params: Fix handling of signed integer types
>
> Commit 6072ddc8520b86adfac6939ca32fb6e6c4de017a broke the handling
> of signed integer types, fix it.
>
> Reported-by: Christian Kujau <lists@nerdbynature.de>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> kernel/params.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- linux-3.12-rc2.orig/kernel/params.c 2013-09-24 00:41:09.000000000 +0200
> +++ linux-3.12-rc2/kernel/params.c 2013-09-26 11:32:43.434586197 +0200
> @@ -254,11 +254,11 @@ int parse_args(const char *doing,
>
>
> STANDARD_PARAM_DEF(byte, unsigned char, "%hhu", unsigned long, kstrtoul);
> -STANDARD_PARAM_DEF(short, short, "%hi", long, kstrtoul);
> +STANDARD_PARAM_DEF(short, short, "%hi", long, kstrtol);
> STANDARD_PARAM_DEF(ushort, unsigned short, "%hu", unsigned long, kstrtoul);
> -STANDARD_PARAM_DEF(int, int, "%i", long, kstrtoul);
> +STANDARD_PARAM_DEF(int, int, "%i", long, kstrtol);
> STANDARD_PARAM_DEF(uint, unsigned int, "%u", unsigned long, kstrtoul);
> -STANDARD_PARAM_DEF(long, long, "%li", long, kstrtoul);
> +STANDARD_PARAM_DEF(long, long, "%li", long, kstrtol);
> STANDARD_PARAM_DEF(ulong, unsigned long, "%lu", unsigned long, kstrtoul);
>
> int param_set_charp(const char *val, const struct kernel_param *kp)
>
>
> --
> Jean Delvare
>
--
BOFH excuse #353:
Second-system effect.
^ permalink raw reply
* Re: [PATCH 00/51] DMA mask changes
From: Rafał Miłecki @ 2013-09-26 20:23 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel@driverdev.osuosl.org, linux-samsung-soc,
Linux SCSI List, e1000-devel, b43-dev, linux-media, devicetree,
dri-devel, linux-tegra, linux-omap,
linux-arm-kernel@lists.infradead.org,
Solarflare linux maintainers, Network Development, linux-usb,
linux-wireless@vger.kernel.org, linux-crypto, uclinux-dist-devel,
linux ppc dev
In-Reply-To: <20130919212235.GD12758@n2100.arm.linux.org.uk>
2013/9/19 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> This email is only being sent to the mailing lists in question, not to
> anyone personally. The list of individuals is far to great to do that.
> I'm hoping no mailing lists reject the patches based on the number of
> recipients.
Huh, I think it was enough to send only 3 patches to the b43-dev@. Like:
[PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA ma=
sks
[PATCH 14/51] DMA-API: net: b43: (...)
[PATCH 15/51] DMA-API: net: b43legacy: (...)
;)
I believe Joe has some nice script for doing it that way. When fixing
some coding style / formatting, he sends only related patches to the
given ML.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH] powerpc/fsl/defconfig: enable CONFIG_AT803X_PHY
From: Scott Wood @ 2013-09-26 21:11 UTC (permalink / raw)
To: Liu Shengzhou-B36685; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3F453DDFF675A64A89321A1F35281021ADFACA@039-SN1MPN1-003.039d.mgd.msft.net>
On Wed, 2013-09-25 at 22:02 -0500, Liu Shengzhou-B36685 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, September 26, 2013 9:24 AM
> > To: Liu Shengzhou-B36685
> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
> > Subject: Re: [PATCH] powerpc/fsl/defconfig: enable CONFIG_AT803X_PHY
> >
> > On Tue, 2013-09-03 at 16:28 +0800, Shengzhou Liu wrote:
> > > Enable CONFIG_AT803X_PHY to support AR8030/8033/8035 PHY.
> > >
> > > Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> > > ---
> > > arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> > > arch/powerpc/configs/mpc85xx_defconfig | 1 +
> > > arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
> > > 3 files changed, 3 insertions(+), 0 deletions(-)
> >
> > Why not corenet64_smp_defconfig? Which boards have this PHY?
> >
> > -Scott
> >
> Currently AT803X exists on P1010RDB, P1025TWR, etc.
> It seems we don't use AT803X for those boards of corenet64.
Neither of those boards are corenet32 either.
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_vio: Do not override preferred console set by kernel parameter
From: Greg Kroah-Hartman @ 2013-09-26 21:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Bastian Blank, Jiri Slaby, Ben Hutchings, linuxppc-dev,
Debian kernel maintainers
In-Reply-To: <1378079740.3978.13.camel@pasglop>
On Mon, Sep 02, 2013 at 09:55:40AM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2013-09-01 at 17:24 +0100, Ben Hutchings wrote:
> > The original version of this was done by Bastian Blank, who wrote:
> >
> > > The problem is the following:
> > > - Architecture specific code sets preferred console to something bogus.
> > > - Command line handling tries to set preferred console but is overruled
> > > by the old setting.
> > >
> > > The udbg0 console is a boot console and independant.
> >
> > References: http://bugs.debian.org/492703
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > ---
> > We've been carrying this in Debian for 5 years now, so it's about time
> > it got reviewed.
> >
> > I'm not convinced strstr() is the right way to check the command line
> > (what if there's also a 'netconsole='?).
>
> Also I think the problem should be solved elsewhere :-)
>
> In the end, what that code is trying to do (as are all the other similar
> instances) is to set "this is a good default in case nothing is
> specified *or* what is specified doesn't actually exist".
>
> Of course "doesn't exist" is tricky since the console could be provided
> by a module loaded god knows when ... but in that case, maybe it does
> make sense to stick to one of the known good defaults. After all, init
> will fail without a tty ...
>
> So I'm thinking we should in kernel/printk.c keep track of all those
> "arch defaults" when console= is specified as "latent" consoles, and
> right before starting init, if the specified one didn't work out (we
> have no console with an associated tty), then go through those latent
> ones and pick one that works.
So, I shouldn't apply this patch? We should do something to fix this,
if Debian has to drag this patch on for 5 years, that's an indication
that this might be one solution we should use, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board support
From: Scott Wood @ 2013-09-26 21:27 UTC (permalink / raw)
To: Xie Xiaobo-R63061
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Johnston Michael-R49610
In-Reply-To: <69EC9ED88E3CC04094A78F8074A7986D600530@039-SN1MPN1-003.039d.mgd.msft.net>
On Thu, 2013-09-26 at 04:27 -0500, Xie Xiaobo-R63061 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, September 26, 2013 7:10 AM
> > To: Xie Xiaobo-R63061
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Johnston Michael-
> > R49610
> > Subject: Re: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board support
> >
> > On Wed, 2013-09-25 at 04:50 -0500, Xie Xiaobo-R63061 wrote:
> > > Hi Scott,
> > >
> > > See the reply inline.
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 25, 2013 7:22 AM
> > > > To: Xie Xiaobo-R63061
> > > > Cc: linuxppc-dev@lists.ozlabs.org; Johnston Michael-R49610
> > > > Subject: Re: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board
> > > > support
> > > >
> > > > On Tue, 2013-09-24 at 18:48 +0800, Xie Xiaobo wrote:
> > > > > + partition@80000 {
> > > > > + /* 3.5 MB for Linux Kernel Image */
> > > > > + reg = <0x00080000 0x00380000>;
> > > > > + label = "NOR Linux Kernel Image";
> > > > > + };
> > > >
> > > > Is this enough?
> > >
> > > I will enlarge it to 6MB.
> > >
> > > >
> > > > > + partition@400000 {
> > > > > + /* 58.75MB for JFFS2 based Root file System */
> > > > > + reg = <0x00400000 0x03ac0000>;
> > > > > + label = "NOR Root File System";
> > > > > + };
> > > >
> > > > Don't specify jffs2.
> > >
> > > OK, I will remove "jffs2"
> > >
> > > >
> > > > > + /* CS2 for Display */
> > > > > + ssd1289@2,0 {
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <1>;
> > > > > + compatible = "ssd1289";
> > > > > + reg = <0x2 0x0000 0x0002
> > > > > + 0x2 0x0002 0x0002>;
> > > > > + };
> > > >
> > > > Node names should be generic. What does ssd1289 do? If this is
> > > > actually the display device, then it should be called "display@2,0".
> > >
> > > OK. The ssd1289 is a LCD controller.
> > >
> > > >
> > > > How about a vendor prefix on that compatible? Why
> > > > #address-cells/#size- cells despite no child nodes? Where is a
> > > > binding that says what each of those two reg resources mean?
> > >
> > > I will add the vendor prefix. I review the ssd1289 driver, and the
> > #address-cells/#size-cells were un-used. I will remove them.
> >
> > And a binding?
> >
> > Why do you need two separate reg resources rather than just <2 0 4>?
> > Will they ever be discontiguous?
>
> [Xie] I review the ssd1289 driver code, and found the driver need two reg resources,
The device tree describes the hardware, not the current state of Linux
drivers. Especially drivers that aren't yet in Linux. :-)
> if change the dts, the driver also should be modified accordingly. So I
> remove the ssd1289 node from this patch. I will submit new patch
> include the dts modification, ssd1289 driver and the binding.
Ideally all devices (and bindings) should be described when the device
tree is initally added, regardless of whether you have a driver yet.
-Scott
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2013-09-26 21:37 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F1543925901090B4F@039-SN2MPN1-021.039d.mgd.msft.net>
On Thu, 2013-09-26 at 01:18 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Bhushan Bharat-R65777
> > Sent: Thursday, September 26, 2013 12:23 PM
> > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> >
> >
> > > -----Original Message-----
> > > From: Wang Dongsheng-B40534
> > > Sent: Thursday, September 26, 2013 8:02 AM
> > > To: Wood Scott-B07421
> > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> > > altivec idle
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Thursday, September 26, 2013 1:57 AM
> > > > To: Wang Dongsheng-B40534
> > > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > > dev@lists.ozlabs.org
> > > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > and altivec idle
> > > >
> > > > On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Bhushan Bharat-R65777
> > > > > > Sent: Wednesday, September 25, 2013 2:23 PM
> > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > > > > bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On
> > > > > > > bounces+Behalf Of Dongsheng
> > > > > > > Wang
> > > > > > > Sent: Tuesday, September 24, 2013 2:59 PM
> > > > > > > To: Wood Scott-B07421
> > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > > Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > > > and altivec idle
> > > > > > >
> > > > > > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > > > >
> > > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > > idle, and control the wait entry time.
> > > > > > >
> > > > > > > Enable/Disable interface:
> > > > > > > 0, disable. 1, enable.
> > > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > > >
> > > > > > > Set wait time interface:(Nanosecond)
> > > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > > > > Example: Base on TBfreq is 41MHZ.
> > > > > > > 1~47(ns): TB[63]
> > > > > > > 48~95(ns): TB[62]
> > > > > > > 96~191(ns): TB[61]
> > > > > > > 192~383(ns): TB[62]
> > > > > > > 384~767(ns): TB[60]
> > > > > > > ...
> > > > > > >
> > > > > > > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > > > > ---
> > > > > > > *v4:
> > > > > > > Move code from 85xx/common.c to kernel/sysfs.c.
> > > > > > >
> > > > > > > Remove has_pw20_altivec_idle function.
> > > > > > >
> > > > > > > Change wait "entry_bit" to wait time.
> > > > > > >
> > > > > > > arch/powerpc/kernel/sysfs.c | 291
> > > > > > > ++++++++++++++++++++++++++++++++++++++++++++
> > > > > > > 1 file changed, 291 insertions(+)
> > > > > > >
> > > > > > > diff --git a/arch/powerpc/kernel/sysfs.c
> > > > > > > b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6 100644
> > > > > > > --- a/arch/powerpc/kernel/sysfs.c
> > > > > > > +++ b/arch/powerpc/kernel/sysfs.c
> > > > > > > @@ -85,6 +85,279 @@ __setup("smt-snooze-delay=",
> > > > > > > setup_smt_snooze_delay);
> > > > > > >
> > > > > > > #endif /* CONFIG_PPC64 */
> > > > > > >
> > > > > > > +#ifdef CONFIG_FSL_SOC
> > > > > > > +#define MAX_BIT 63
> > > > > > > +
> > > > > > > +static u64 pw20_wt;
> > > > > > > +static u64 altivec_idle_wt;
> > > > > > > +
> > > > > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > > > > + u64 cycle;
> > > > > > > +
> > > > > > > + cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
> > > > > >
> > > > > > When tb_ticks_per_usec > 1000 (timebase frequency > 1GHz) then
> > > > > > this will always be ns, which is not correct, no?
> > > >
> > > > Actually it'll be a divide by zero in that case.
> > > >
> > > tb_ticks_per_usec = ppc_tb_freq / 1000000; Means TB freq should be
> > > more than 1MHZ.
> > >
> > > if ppc_tb_freq less than 1000000, the tb_ticks_per_usec will be a
> > > divide by zero.
> > > If this condition is established, I think kernel cannot work as a
> > normal.
> > >
> > > So I think we need to believe that the variable is not zero.
> >
> > We do believe it is non-zero but greater than 1000 :)
> >
> > > And I think TB freq
> > > should not less than 1MHZ on PPC platform, because if TB freq less
> > > than 1MHZ, the precision time will become very poor and system
> > > response time will be slower.
> >
> > Not sure what you are describing here related to divide by zero we are
> > mentioning.
> > You are talking about if tb_ticks_per_usec is ZERO and we are talking
> > about if (1000/tb_ticks_per_usec) will be zero.
> >
> > BTW, div_u64() handle the case where divider is zero.
How? When I checked yesterday it looked like div_u64() mapped to a
hardware division on 64-bit targets. In any case it's not good to rely
on such behavior.
> cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
> For this, I think we were discussing the two issues:
>
> 1. Scott talking about, when the tb_ticks_per_usec is a zero.
No I wasn't. I was talking about when tb_ticks_per_usec > 1000, and
thus "1000 / tb_ticks_per_usec" is zero. You said that the result would
be ns in that case.
> 2. You are talking about 1000/tb_ticks_per_usec is a zero.
> This situation is about TB freq > 1GHZ.
>
> I will fix this issue. Like I said before,
> "If timebase frequency > 1GHz, this should be "tb_ticks_per_usec / 1000" and to get tb_ticks_per_nsec.
> This should be changed to "cycle = ns * tb_ticks_per_nsec;""
>
> #define TB_FREQ_1GHZ 1000
>
> If (tb_ticks_per_usec > TB_FREQ_1GHZ)
> cycle = ns * (tb_ticks_per_usec / 1000);
> else
> cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
>
> how about this? :)
I suggested an alternative to satisfy your complaint that it's hard to
test one of those if/else branches.
Plus, your version will be quite inaccurate if (e.g.) tb_ticks_per_usec
is 501, or 1999.
-Scott
^ permalink raw reply
* Re: [PATCH] hvc_vio: Do not override preferred console set by kernel parameter
From: Benjamin Herrenschmidt @ 2013-09-26 22:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Bastian Blank, Jiri Slaby, Ben Hutchings, linuxppc-dev,
Debian kernel maintainers
In-Reply-To: <20130926212254.GA12564@kroah.com>
On Thu, 2013-09-26 at 14:22 -0700, Greg Kroah-Hartman wrote:
> So, I shouldn't apply this patch? We should do something to fix this,
> if Debian has to drag this patch on for 5 years, that's an indication
> that this might be one solution we should use, right?
Ah sorry, dropped the ball on that one. Yes the patch is an acceptable
band-aid but somebody should work on a better solution :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 5/7] iommu: supress loff_t compilation error on powerpc
From: Scott Wood @ 2013-09-26 22:20 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: agraf@suse.de, Wood Scott-B07421, joro@8bytes.org,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Alex Williamson, linux-pci@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D07183CA4@039-SN2MPN1-011.039d.mgd.msft.net>
On Wed, 2013-09-25 at 22:53 -0500, Bhushan Bharat-R65777 wrote:
>
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Wednesday, September 25, 2013 10:10 PM
> > To: Bhushan Bharat-R65777
> > Cc: joro@8bytes.org; benh@kernel.crashing.org; galak@kernel.crashing.org; linux-
> > kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; linux-
> > pci@vger.kernel.org; agraf@suse.de; Wood Scott-B07421; iommu@lists.linux-
> > foundation.org; Bhushan Bharat-R65777
> > Subject: Re: [PATCH 5/7] iommu: supress loff_t compilation error on powerpc
> >
> > On Thu, 2013-09-19 at 12:59 +0530, Bharat Bhushan wrote:
> > > Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> > > ---
> > > drivers/vfio/pci/vfio_pci_rdwr.c | 3 ++-
> > > 1 files changed, 2 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c
> > > b/drivers/vfio/pci/vfio_pci_rdwr.c
> > > index 210db24..8a8156a 100644
> > > --- a/drivers/vfio/pci/vfio_pci_rdwr.c
> > > +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
> > > @@ -181,7 +181,8 @@ ssize_t vfio_pci_vga_rw(struct vfio_pci_device *vdev, char
> > __user *buf,
> > > size_t count, loff_t *ppos, bool iswrite) {
> > > int ret;
> > > - loff_t off, pos = *ppos & VFIO_PCI_OFFSET_MASK;
> > > + loff_t off;
> > > + u64 pos = (u64 )(*ppos & VFIO_PCI_OFFSET_MASK);
> > > void __iomem *iomem = NULL;
> > > unsigned int rsrc;
> > > bool is_ioport;
> >
> > What's the compile error that this fixes?
>
> I was getting below error; and after some googling I came to know that this is how it is fixed by other guys.
>
> /home/r65777/linux-vfio/drivers/vfio/pci/vfio_pci_rdwr.c:193: undefined reference to `__cmpdi2'
> /home/r65777/linux-vfio/drivers/vfio/pci/vfio_pci_rdwr.c:193: undefined reference to `__cmpdi2'
It looks like PPC Linux implements __ucmpdi2, but not the signed
version. That should be fixed, rather than hacking up random code to
avoid it.
-Scott
^ permalink raw reply
* [PATCH] powerpc/mpic: Disable preemption when calling mpic_processor_id()
From: Scott Wood @ 2013-09-27 0:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev
Otherwise, we get a debug traceback due to the use of
smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
mpic_host_map() is just looking for a default CPU, so it doesn't matter
if we migrate after getting the CPU ID.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/mpic.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 1be54fa..bdcb858 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1088,8 +1088,14 @@ static int mpic_host_map(struct irq_domain *h, unsigned int virq,
* is done here.
*/
if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
+ int cpu;
+
+ preempt_disable();
+ cpu = mpic_processor_id(mpic);
+ preempt_enable();
+
mpic_set_vector(virq, hw);
- mpic_set_destination(virq, mpic_processor_id(mpic));
+ mpic_set_destination(virq, cpu);
mpic_irq_set_priority(virq, 8);
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH] powerpc/p1010rdb:update mtd of nand to adapt to both old and new p1010rdb
From: Zhao Qiang @ 2013-09-27 1:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Zhao Qiang, B36685, R61911
P1010rdb-pa and p1010rdb-pb have different mtd of nand.
So update dts to adapt to both p1010rdb-pa and p1010rdb-pb.
Signed-off-by: Zhao Qiang <B45475@freescale.com>
---
arch/powerpc/boot/dts/p1010rdb-pa.dts | 40 +++++++++++++++++++++++++++++++++++
arch/powerpc/boot/dts/p1010rdb-pb.dts | 34 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/p1010rdb.dtsi | 40 +----------------------------------
3 files changed, 75 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1010rdb-pa.dts b/arch/powerpc/boot/dts/p1010rdb-pa.dts
index e1688d4..9b4ca89 100644
--- a/arch/powerpc/boot/dts/p1010rdb-pa.dts
+++ b/arch/powerpc/boot/dts/p1010rdb-pa.dts
@@ -18,6 +18,46 @@
/include/ "p1010rdb.dtsi"
};
+&ifc_nand {
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = <0x0 0x00100000>;
+ label = "NAND U-Boot Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 1MB for DTB Image */
+ reg = <0x00100000 0x00100000>;
+ label = "NAND DTB Image";
+ };
+
+ partition@200000 {
+ /* 4MB for Linux Kernel Image */
+ reg = <0x00200000 0x00400000>;
+ label = "NAND Linux Kernel Image";
+ };
+
+ partition@600000 {
+ /* 4MB for Compressed Root file System Image */
+ reg = <0x00600000 0x00400000>;
+ label = "NAND Compressed RFS Image";
+ };
+
+ partition@a00000 {
+ /* 15MB for JFFS2 based Root file System */
+ reg = <0x00a00000 0x00f00000>;
+ label = "NAND JFFS2 Root File System";
+ };
+
+ partition@1900000 {
+ /* 7MB for User Area */
+ reg = <0x01900000 0x00700000>;
+ label = "NAND User area";
+ };
+};
+
&phy0 {
interrupts = <3 1 0 0>;
};
diff --git a/arch/powerpc/boot/dts/p1010rdb-pb.dts b/arch/powerpc/boot/dts/p1010rdb-pb.dts
index 37f9366..f4c97fd 100644
--- a/arch/powerpc/boot/dts/p1010rdb-pb.dts
+++ b/arch/powerpc/boot/dts/p1010rdb-pb.dts
@@ -18,6 +18,40 @@
/include/ "p1010rdb.dtsi"
};
+&ifc_nand {
+ partition@0 {
+ /* This location must not be altered */
+ /* 2MB for u-boot Image and environment */
+ reg = <0x0 0x00200000>;
+ label = "NAND U-Boot Image and env";
+ read-only;
+ };
+
+ partition@200000 {
+ /* 1MB for DTB Image */
+ reg = <0x00200000 0x00100000>;
+ label = "NAND DTB Image";
+ };
+
+ partition@300000 {
+ /* 5MB for Linux Kernel Image */
+ reg = <0x00300000 0x00500000>;
+ label = "NAND Linux Kernel Image";
+ };
+
+ partition@800000 {
+ /* 56MB for Compressed Root file System Image */
+ reg = <0x00800000 0x03800000>;
+ label = "NAND ROOTFS";
+ };
+
+ partition@4000000 {
+ /* 1984MB for User Area */
+ reg = <0x04000000 0x7c000000>;
+ label = "NAND User area";
+ };
+};
+
&phy0 {
interrupts = <0 1 0 0>;
};
diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi b/arch/powerpc/boot/dts/p1010rdb.dtsi
index 5e5ca56..61abc18 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
@@ -79,49 +79,11 @@ board_ifc: ifc: ifc@ffe1e000 {
};
};
- nand@1,0 {
+ ifc_nand: nand@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,ifc-nand";
reg = <0x1 0x0 0x10000>;
-
- partition@0 {
- /* This location must not be altered */
- /* 1MB for u-boot Bootloader Image */
- reg = <0x0 0x00100000>;
- label = "NAND U-Boot Image";
- read-only;
- };
-
- partition@100000 {
- /* 1MB for DTB Image */
- reg = <0x00100000 0x00100000>;
- label = "NAND DTB Image";
- };
-
- partition@200000 {
- /* 4MB for Linux Kernel Image */
- reg = <0x00200000 0x00400000>;
- label = "NAND Linux Kernel Image";
- };
-
- partition@600000 {
- /* 4MB for Compressed Root file System Image */
- reg = <0x00600000 0x00400000>;
- label = "NAND Compressed RFS Image";
- };
-
- partition@a00000 {
- /* 15MB for JFFS2 based Root file System */
- reg = <0x00a00000 0x00f00000>;
- label = "NAND JFFS2 Root File System";
- };
-
- partition@1900000 {
- /* 7MB for User Area */
- reg = <0x01900000 0x00700000>;
- label = "NAND User area";
- };
};
cpld@3,0 {
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()
From: Laurent Pinchart @ 2013-09-27 1:56 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
linux-omap, linux-arm-kernel, Solarflare linux maintainers,
netdev, linux-usb, linux-wireless, linux-crypto,
uclinux-dist-devel, linuxppc-dev, Mauro Carvalho Chehab
In-Reply-To: <E1VMmCg-0007j1-Pi@rmk-PC.arm.linux.org.uk>
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
> The code sequence:
> isp->raw_dmamask = DMA_BIT_MASK(32);
> isp->dev->dma_mask = &isp->raw_dmamask;
> isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> bypasses the architectures check on the DMA mask. It can be replaced
> with dma_coerce_mask_and_coherent(), avoiding the direct initialization
> of this mask.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/media/platform/omap3isp/isp.c | 6 +++---
> drivers/media/platform/omap3isp/isp.h | 3 ---
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index df3a0ec..1c36080 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
> isp->pdata = pdata;
> isp->ref_count = 0;
>
> - isp->raw_dmamask = DMA_BIT_MASK(32);
> - isp->dev->dma_mask = &isp->raw_dmamask;
> - isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
>
> platform_set_drvdata(pdev, isp);
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index cd3eff4..ce65d3a 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -152,7 +152,6 @@ struct isp_xclk {
> * @mmio_base_phys: Array with physical L4 bus addresses for ISP register
> * regions.
> * @mmio_size: Array with ISP register regions size in bytes.
> - * @raw_dmamask: Raw DMA mask
> * @stat_lock: Spinlock for handling statistics
> * @isp_mutex: Mutex for serializing requests to ISP.
> * @crashed: Bitmask of crashed entities (indexed by entity ID)
> @@ -190,8 +189,6 @@ struct isp_device {
> unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
> resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
>
> - u64 raw_dmamask;
> -
> /* ISP Obj */
> spinlock_t stat_lock; /* common lock for statistic drivers */
> struct mutex isp_mutex; /* For handling ref_count field */
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: [PATCH] powerpc/fsl/defconfig: enable CONFIG_AT803X_PHY
From: Liu Shengzhou-B36685 @ 2013-09-27 2:51 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1380229898.24959.318.camel@snotra.buserror.net>
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI3LCAyMDEzIDU6MTIgQU0NCj4gVG86IExpdSBT
aGVuZ3pob3UtQjM2Njg1DQo+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmc7IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmcNCj4gU3ViamVjdDogUmU6
IFtQQVRDSF0gcG93ZXJwYy9mc2wvZGVmY29uZmlnOiBlbmFibGUgQ09ORklHX0FUODAzWF9QSFkN
Cj4gDQo+IE9uIFdlZCwgMjAxMy0wOS0yNSBhdCAyMjowMiAtMDUwMCwgTGl1IFNoZW5nemhvdS1C
MzY2ODUgd3JvdGU6DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJv
bTogV29vZCBTY290dC1CMDc0MjENCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjYs
IDIwMTMgOToyNCBBTQ0KPiA+ID4gVG86IExpdSBTaGVuZ3pob3UtQjM2Njg1DQo+ID4gPiBDYzog
bGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGdhbGFrQGtlcm5lbC5jcmFzaGluZy5vcmcN
Cj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2VycGMvZnNsL2RlZmNvbmZpZzogZW5hYmxl
IENPTkZJR19BVDgwM1hfUEhZDQo+ID4gPg0KPiA+ID4gT24gVHVlLCAyMDEzLTA5LTAzIGF0IDE2
OjI4ICswODAwLCBTaGVuZ3pob3UgTGl1IHdyb3RlOg0KPiA+ID4gPiBFbmFibGUgQ09ORklHX0FU
ODAzWF9QSFkgdG8gc3VwcG9ydCBBUjgwMzAvODAzMy84MDM1IFBIWS4NCj4gPiA+ID4NCj4gPiA+
ID4gU2lnbmVkLW9mZi1ieTogU2hlbmd6aG91IExpdSA8U2hlbmd6aG91LkxpdUBmcmVlc2NhbGUu
Y29tPg0KPiA+ID4gPiAtLS0NCj4gPiA+ID4gIGFyY2gvcG93ZXJwYy9jb25maWdzL2NvcmVuZXQz
Ml9zbXBfZGVmY29uZmlnIHwgICAgMSArDQo+ID4gPiA+ICBhcmNoL3Bvd2VycGMvY29uZmlncy9t
cGM4NXh4X2RlZmNvbmZpZyAgICAgICB8ICAgIDEgKw0KPiA+ID4gPiAgYXJjaC9wb3dlcnBjL2Nv
bmZpZ3MvbXBjODV4eF9zbXBfZGVmY29uZmlnICAgfCAgICAxICsNCj4gPiA+ID4gIDMgZmlsZXMg
Y2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQ0KPiA+ID4NCj4gPiA+IFdo
eSBub3QgY29yZW5ldDY0X3NtcF9kZWZjb25maWc/ICBXaGljaCBib2FyZHMgaGF2ZSB0aGlzIFBI
WT8NCj4gPiA+DQo+ID4gPiAtU2NvdHQNCj4gPiA+DQo+ID4gQ3VycmVudGx5IEFUODAzWCBleGlz
dHMgb24gUDEwMTBSREIsIFAxMDI1VFdSLCBldGMuDQo+ID4gSXQgc2VlbXMgd2UgZG9uJ3QgdXNl
IEFUODAzWCBmb3IgdGhvc2UgYm9hcmRzIG9mIGNvcmVuZXQ2NC4NCj4gDQo+IE5laXRoZXIgb2Yg
dGhvc2UgYm9hcmRzIGFyZSBjb3JlbmV0MzIgZWl0aGVyLg0KPiANCkdlbmVyYWxseSwgd2UgdXNl
IEFUODAzWCBhcyBsb3ctY29zdCBzb2x1dGlvbiwgaXQncyBwb3NzaWJsZSB0byB1c2UgaXQgb24g
UDEvUDIvUDMgc2VyaWFsLCBjb3JlbmV0NjQgaXMgZm9yIGhpZ2gtZW5kIGNhc2UsIHRoYXQncyB3
aHkgSSBkaWRuJ3QgZW5hYmxlIGl0IGZvciBjb3JlbmV0NjQuDQotU2hlbmd6aG91DQo=
^ 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