* 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 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 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 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 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: 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 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: 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
* [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 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
* Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()
From: Archit Taneja @ 2013-09-26 10:51 UTC (permalink / raw)
To: Russell King, alsa-devel, b43-dev, devel, devicetree, dri-devel,
e1000-devel, linux-arm-kernel, linux-crypto, linux-doc,
linux-fbdev, linux-ide, linux-media, linux-mmc, linux-nvme,
linux-omap, linuxppc-dev, linux-samsung-soc, linux-scsi,
linux-tegra, linux-usb, linux-wireless, netdev,
Solarflare linux maintainers, uclinux-dist-devel
Cc: Kukjin Kim, Joonyoung Shim, David Airlie, Seung-Woo Kim,
Rob Clark, Inki Dae, Kyungmin Park, Valkeinen, Tomi, Tejun Heo
In-Reply-To: <E1VMnNq-0007s4-HN@rmk-PC.arm.linux.org.uk>
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/ata/pata_ixp4xx_cf.c | 5 ++++-
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++++-
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 5 +++--
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
> index 1ec53f8..ddf470c 100644
> --- a/drivers/ata/pata_ixp4xx_cf.c
> +++ b/drivers/ata/pata_ixp4xx_cf.c
> @@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
> struct ata_host *host;
> struct ata_port *ap;
> struct ixp4xx_pata_data *data = dev_get_platdata(&pdev->dev);
> + int ret;
>
> cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> @@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> /* acquire resources and fill host */
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
>
> data->cs0 = devm_ioremap(&pdev->dev, cs0->start, 0x1000);
> data->cs1 = devm_ioremap(&pdev->dev, cs1->start, 0x1000);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index bb82ef7..81192d0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
>
> static int exynos_drm_platform_probe(struct platform_device *pdev)
> {
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + int ret;
> +
> + ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
>
> return drm_platform_init(&exynos_drm_driver, pdev);
> }
> diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> index acf6678..701c4c1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
> @@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
> }
>
> /* set dma mask for device */
> - /* NOTE: this is a workaround for the hwmod not initializing properly */
> - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto fail;
Tested with omapdrm on omap4 panda es board.
Thanks,
Archit
^ permalink raw reply
* Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: Alexander Gordeev @ 2013-09-26 10:45 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: <AE90C24D6B3A694183C094C60CF0A2F6026B735D@saturn3.aculab.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.
Repeated calls to msi_enable_msi/msix() is what we are trying to avoid.
> Interrupts could then be allocated after it is known how many
> are required and how many are available.
Yep, that what we are heading to. So basic pattern I see would be like this:
int foo_driver_enable_msix(struct pci_dev *pdev, int nvec)
{
...
rc = pci_msix_table_size(pdev);
if (rc < 0)
return rc;
nvec = min(nvec, rc);
if (nvec < FOO_DRIVER_MINIMUM_NVEC)
goto single_msi;
for (i = 0; i < nvec; i++)
entries[i].entry = i;
rc = pci_enable_msix(pdev, entries, nvec);
if (rc)
goto single_msi;
return 0;
single_msi:
...
}
But this will break pSeries and we might end up with something like this:
int foo_driver_enable_msix(struct pci_dev *pdev, int nvec)
{
...
rc = pci_msix_table_size(pdev);
if (rc < 0)
return rc;
nvec = min(nvec, rc);
if (nvec < FOO_DRIVER_MINIMUM_NVEC)
goto single_msi;
rc = pci_get_msix_limit(pdev, nvec);
if (rc < 0)
return rc;
nvec = min(nvec, rc);
if (nvec < FOO_DRIVER_MINIMUM_NVEC)
goto single_msi;
for (i = 0; i < nvec; i++)
entries[i].entry = i;
rc = pci_enable_msix(pdev, entries, nvec);
if (rc)
goto single_msi;
return 0;
single_msi:
...
}
> David
--
Regards,
Alexander Gordeev
agordeev@redhat.com
^ permalink raw reply
* Re: [PATCH v2] sound/soc/fsl/fsl_ssi.c: let check zero instead of check NO_IRQ
From: Chen Gang @ 2013-09-26 10:40 UTC (permalink / raw)
To: Mark Brown
Cc: Takashi Iwai, alsa-devel, linuxppc-dev@lists.ozlabs.org,
lgirdwood, perex
In-Reply-To: <20130926102914.GG19304@sirena.org.uk>
On 09/26/2013 06:29 PM, Mark Brown wrote:
> On Mon, Sep 23, 2013 at 11:36:21AM +0800, Chen Gang wrote:
>> NO_IRQ may be defined as '(unsigned int) -1' in some architectures
>> (arm, sh ...), and either may not be defined in some architectures
>> which can enable SND_SOC_FSL_SSI (e.g. allmodconfig for arc).
>
> Applied, thanks.
>
Thank you too. :-)
--
Chen Gang
^ permalink raw reply
* Re: [PATCH v2] sound/soc/fsl/fsl_ssi.c: let check zero instead of check NO_IRQ
From: Mark Brown @ 2013-09-26 10:29 UTC (permalink / raw)
To: Chen Gang
Cc: Takashi Iwai, alsa-devel, linuxppc-dev@lists.ozlabs.org,
lgirdwood, perex
In-Reply-To: <523FB735.2060906@asianux.com>
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
On Mon, Sep 23, 2013 at 11:36:21AM +0800, Chen Gang wrote:
> NO_IRQ may be defined as '(unsigned int) -1' in some architectures
> (arm, sh ...), and either may not be defined in some architectures
> which can enable SND_SOC_FSL_SSI (e.g. allmodconfig for arc).
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: therm_adt746x: -3 invalid for parameter limit_adjust
From: Jean Delvare @ 2013-09-26 9:39 UTC (permalink / raw)
To: Christian Kujau; +Cc: colin, Andrew Morton, Jingoo Han, linuxppc-dev
In-Reply-To: <alpine.DEB.2.11.1309260202480.6519@trent.utfs.org>
Hi Christian,
On Thu, 26 Sep 2013 02:16:16 -0700 (PDT), Christian Kujau wrote:
> Hi,
>
> after upgrading from 3.11 to 3.12-rc2, the therm_adt746x module could not
> be loaded any more:
>
> therm_adt746x: `-2' invalid for parameter `limit_adjust'
>
> I've alwasy passed "limit_adjust=-3" (negative 3) to the module via
> modprobe.conf, to lower the max temperature. Up until 3.11, loading the
> module would print:
>
> adt746x: Lowering max temperatures from 73, 80, 109 to 67, 47, 67
>
> I can load the module without limit_adjust or with positive values, but
> really wanted to lower the temperature, so that the fan would kick in
> earlier. For reference, this is what happens in 3.12-rc2:
>
> v--- limit_adjust
> |
> 0: adt746x: Lowering max temperatures from 73, 80, 109 to 70, 50, 70
> 1: adt746x: Lowering max temperatures from 73, 80, 109 to 71, 51, 71
> 2: adt746x: Lowering max temperatures from 73, 80, 109 to 72, 52, 72
> 3: adt746x: Lowering max temperatures from 73, 80, 109 to 73, 53, 73
> 4: adt746x: Lowering max temperatures from 73, 80, 109 to 74, 54, 74
> 10: adt746x: Lowering max temperatures from 73, 80, 109 to 80, 60, 80
>
> Was passing negative values to therm_adt746x ever supported?
As far as I can see, yes.
> drivers/macintosh/therm_adt746x.c hasn't been touched in a while, this
> means some other change did it.
>
> Before I attempt a full git bisect, any hints what could have caused this?
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:
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
^ permalink raw reply
* [PATCH V5 2/2] powerpc/85xx: Add TWR-P1025 board support
From: Xie Xiaobo @ 2013-09-26 9:37 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: Michael Johnston, Xie Xiaobo
In-Reply-To: <1380188253-4710-1-git-send-email-X.Xie@freescale.com>
TWR-P1025 Overview
-----------------
512Mbyte DDR3 (on board DDR)
64MB Nor Flash
eTSEC1: Connected to RGMII PHY AR8035
eTSEC3: Connected to RGMII PHY AR8035
Two USB2.0 Type A
One microSD Card slot
One mini-PCIe slot
One mini-USB TypeB dual UART
Signed-off-by: Michael Johnston <michael.johnston@freescale.com>
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
Patch V5: Miscellaneous modification. e.g. move the qe ucc node into dtsi.
Patch V4: Fix the mdio phy interrupt issue in dts
Patch V3: fix pcie range issue in dts
Patch V2: QE related init codes were factored out to a common file
arch/powerpc/boot/dts/p1025twr.dtsi | 274 ++++++++++++++++++++++++++++++++
arch/powerpc/boot/dts/p1025twr_32b.dts | 94 +++++++++++
arch/powerpc/platforms/85xx/Kconfig | 6 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/twr_p102x.c | 147 +++++++++++++++++
5 files changed, 522 insertions(+)
create mode 100644 arch/powerpc/boot/dts/p1025twr.dtsi
create mode 100644 arch/powerpc/boot/dts/p1025twr_32b.dts
create mode 100644 arch/powerpc/platforms/85xx/twr_p102x.c
diff --git a/arch/powerpc/boot/dts/p1025twr.dtsi b/arch/powerpc/boot/dts/p1025twr.dtsi
new file mode 100644
index 0000000..30cdf8d
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1025twr.dtsi
@@ -0,0 +1,274 @@
+/*
+ * P1025 TWR Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/{
+ aliases {
+ ethernet3 = &enet3;
+ ethernet4 = &enet4;
+ };
+};
+
+&lbc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x4000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 256KB for Vitesse 7385 Switch firmware */
+ reg = <0x0 0x00040000>;
+ label = "NOR Vitesse-7385 Firmware";
+ read-only;
+ };
+
+ partition@40000 {
+ /* 256KB for DTB Image */
+ reg = <0x00040000 0x00040000>;
+ label = "NOR DTB Image";
+ };
+
+ partition@80000 {
+ /* 5.5 MB for Linux Kernel Image */
+ reg = <0x00080000 0x00580000>;
+ label = "NOR Linux Kernel Image";
+ };
+
+ partition@400000 {
+ /* 56.75MB for Root file System */
+ reg = <0x00600000 0x038c0000>;
+ label = "NOR Root File System";
+ };
+
+ partition@ec0000 {
+ /* This location must not be altered */
+ /* 256KB for QE ucode firmware*/
+ reg = <0x03ec0000 0x00040000>;
+ label = "NOR QE microcode firmware";
+ read-only;
+ };
+
+ partition@f00000 {
+ /* This location must not be altered */
+ /* 512KB for u-boot Bootloader Image */
+ /* 512KB for u-boot Environment Variables */
+ reg = <0x03f00000 0x00100000>;
+ label = "NOR U-Boot Image";
+ read-only;
+ };
+ };
+
+};
+
+&soc {
+ usb@22000 {
+ phy_type = "ulpi";
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@2 {
+ interrupt-parent = <&mpic>;
+ interrupts = <1 1 0 0>;
+ reg = <0x2>;
+ };
+
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&mpic>;
+ interrupts = <2 1 0 0>;
+ reg = <0x1>;
+ };
+
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ mdio@25000 {
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ mdio@26000 {
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@b0000 {
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+
+ };
+
+ enet1: ethernet@b1000 {
+ status = "disabled";
+ };
+
+ enet2: ethernet@b2000 {
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ par_io@e0100 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xe0100 0x60>;
+ ranges = <0x0 0xe0100 0x60>;
+ device_type = "par_io";
+ num-ports = <3>;
+ pio1: ucc_pin@01 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0x1 0x13 0x1 0x0 0x1 0x0 /* QE_MUX_MDC */
+ 0x1 0x14 0x3 0x0 0x1 0x0 /* QE_MUX_MDIO */
+ 0x0 0x17 0x2 0x0 0x2 0x0 /* CLK12 */
+ 0x0 0x18 0x2 0x0 0x1 0x0 /* CLK9 */
+ 0x0 0x7 0x1 0x0 0x2 0x0 /* ENET1_TXD0_SER1_TXD0 */
+ 0x0 0x9 0x1 0x0 0x2 0x0 /* ENET1_TXD1_SER1_TXD1 */
+ 0x0 0xb 0x1 0x0 0x2 0x0 /* ENET1_TXD2_SER1_TXD2 */
+ 0x0 0xc 0x1 0x0 0x2 0x0 /* ENET1_TXD3_SER1_TXD3 */
+ 0x0 0x6 0x2 0x0 0x2 0x0 /* ENET1_RXD0_SER1_RXD0 */
+ 0x0 0xa 0x2 0x0 0x2 0x0 /* ENET1_RXD1_SER1_RXD1 */
+ 0x0 0xe 0x2 0x0 0x2 0x0 /* ENET1_RXD2_SER1_RXD2 */
+ 0x0 0xf 0x2 0x0 0x2 0x0 /* ENET1_RXD3_SER1_RXD3 */
+ 0x0 0x5 0x1 0x0 0x2 0x0 /* ENET1_TX_EN_SER1_RTS_B */
+ 0x0 0xd 0x1 0x0 0x2 0x0 /* ENET1_TX_ER */
+ 0x0 0x4 0x2 0x0 0x2 0x0 /* ENET1_RX_DV_SER1_CTS_B */
+ 0x0 0x8 0x2 0x0 0x2 0x0 /* ENET1_RX_ER_SER1_CD_B */
+ 0x0 0x11 0x2 0x0 0x2 0x0 /* ENET1_CRS */
+ 0x0 0x10 0x2 0x0 0x2 0x0>; /* ENET1_COL */
+ };
+
+ pio2: ucc_pin@02 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0x1 0x13 0x1 0x0 0x1 0x0 /* QE_MUX_MDC */
+ 0x1 0x14 0x3 0x0 0x1 0x0 /* QE_MUX_MDIO */
+ 0x1 0xb 0x2 0x0 0x1 0x0 /* CLK13 */
+ 0x1 0x7 0x1 0x0 0x2 0x0 /* ENET5_TXD0_SER5_TXD0 */
+ 0x1 0xa 0x1 0x0 0x2 0x0 /* ENET5_TXD1_SER5_TXD1 */
+ 0x1 0x6 0x2 0x0 0x2 0x0 /* ENET5_RXD0_SER5_RXD0 */
+ 0x1 0x9 0x2 0x0 0x2 0x0 /* ENET5_RXD1_SER5_RXD1 */
+ 0x1 0x5 0x1 0x0 0x2 0x0 /* ENET5_TX_EN_SER5_RTS_B */
+ 0x1 0x4 0x2 0x0 0x2 0x0 /* ENET5_RX_DV_SER5_CTS_B */
+ 0x1 0x8 0x2 0x0 0x2 0x0>; /* ENET5_RX_ER_SER5_CD_B */
+ };
+
+ pio3: ucc_pin@03 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0x0 0x16 0x2 0x0 0x2 0x0 /* SER7_CD_B*/
+ 0x0 0x12 0x2 0x0 0x2 0x0 /* SER7_CTS_B*/
+ 0x0 0x13 0x1 0x0 0x2 0x0 /* SER7_RTS_B*/
+ 0x0 0x14 0x2 0x0 0x2 0x0 /* SER7_RXD0*/
+ 0x0 0x15 0x1 0x0 0x2 0x0>; /* SER7_TXD0*/
+ };
+
+ pio4: ucc_pin@04 {
+ pio-map = <
+ /* port pin dir open_drain assignment has_irq */
+ 0x1 0x0 0x2 0x0 0x2 0x0 /* SER3_CD_B*/
+ 0x0 0x1c 0x2 0x0 0x2 0x0 /* SER3_CTS_B*/
+ 0x0 0x1d 0x1 0x0 0x2 0x0 /* SER3_RTS_B*/
+ 0x0 0x1e 0x2 0x0 0x2 0x0 /* SER3_RXD0*/
+ 0x0 0x1f 0x1 0x0 0x2 0x0>; /* SER3_TXD0*/
+ };
+ };
+};
+
+&qe {
+ enet3: ucc@2000 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ rx-clock-name = "clk12";
+ tx-clock-name = "clk9";
+ pio-handle = <&pio1>;
+ phy-handle = <&qe_phy0>;
+ phy-connection-type = "mii";
+ };
+
+ mdio@2120 {
+ qe_phy0: ethernet-phy@18 {
+ interrupt-parent = <&mpic>;
+ interrupts = <4 1 0 0>;
+ reg = <0x18>;
+ device_type = "ethernet-phy";
+ };
+ qe_phy1: ethernet-phy@19 {
+ interrupt-parent = <&mpic>;
+ interrupts = <5 1 0 0>;
+ reg = <0x19>;
+ device_type = "ethernet-phy";
+ };
+ tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet4: ucc@2400 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ rx-clock-name = "none";
+ tx-clock-name = "clk13";
+ pio-handle = <&pio2>;
+ phy-handle = <&qe_phy1>;
+ phy-connection-type = "rmii";
+ };
+
+ serial2: ucc@2600 {
+ device_type = "serial";
+ compatible = "ucc_uart";
+ port-number = <0>;
+ rx-clock-name = "brg6";
+ tx-clock-name = "brg6";
+ pio-handle = <&pio3>;
+ };
+
+ serial3: ucc@2200 {
+ device_type = "serial";
+ compatible = "ucc_uart";
+ port-number = <1>;
+ rx-clock-name = "brg2";
+ tx-clock-name = "brg2";
+ pio-handle = <&pio4>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/p1025twr_32b.dts b/arch/powerpc/boot/dts/p1025twr_32b.dts
new file mode 100644
index 0000000..9acf019
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1025twr_32b.dts
@@ -0,0 +1,94 @@
+/*
+ * P1025 TWR Device Tree Source (32-bit address map)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1021si-pre.dtsi"
+/ {
+ model = "fsl,P1025";
+ compatible = "fsl,TWR-P1025";
+
+ memory {
+ device_type = "memory";
+ };
+
+ lbc: localbus@ffe05000 {
+ reg = <0 0xffe05000 0 0x1000>;
+
+ /* NOR Flash */
+ ranges = <0x0 0x0 0x0 0xec000000 0x04000000>;
+ };
+
+ soc: soc@ffe00000 {
+ ranges = <0x0 0x0 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@ffe09000 {
+ ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
+ reg = <0 0xffe09000 0 0x1000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0xa0000000
+ 0x2000000 0x0 0xa0000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ pci1: pcie@ffe0a000 {
+ reg = <0 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+
+ qe: qe@ffe80000 {
+ ranges = <0x0 0x0 0xffe80000 0x40000>;
+ reg = <0 0xffe80000 0 0x480>;
+ brg-frequency = <0>;
+ bus-frequency = <0>;
+ };
+};
+
+/include/ "p1025twr.dtsi"
+/include/ "fsl/p1021si-post.dtsi"
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index de2eb93..b1a7d0a 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -123,6 +123,12 @@ config P1023_RDS
help
This option enables support for the P1023 RDS and RDB boards
+config TWR_P102x
+ bool "Freescale TWR-P102x"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the TWR-P1025 board.
+
config SOCRATES
bool "Socrates"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 53c9f75..228c4dd 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_P1010_RDB) += p1010rdb.o
obj-$(CONFIG_P1022_DS) += p1022_ds.o
obj-$(CONFIG_P1022_RDK) += p1022_rdk.o
obj-$(CONFIG_P1023_RDS) += p1023_rds.o
+obj-$(CONFIG_TWR_P102x) += twr_p102x.o
obj-$(CONFIG_P2041_RDB) += p2041_rdb.o corenet_ds.o
obj-$(CONFIG_P3041_DS) += p3041_ds.o corenet_ds.o
obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
diff --git a/arch/powerpc/platforms/85xx/twr_p102x.c b/arch/powerpc/platforms/85xx/twr_p102x.c
new file mode 100644
index 0000000..4d264e3
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/twr_p102x.c
@@ -0,0 +1,147 @@
+/*
+ * Copyright 2010-2011, 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Michael Johnston <michael.johnston@freescale.com>
+ *
+ * Description:
+ * TWR-P102x Board Setup
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/pci.h>
+#include <linux/of_platform.h>
+
+#include <asm/pci-bridge.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+#include <asm/qe.h>
+#include <asm/qe_ic.h>
+#include <asm/fsl_guts.h>
+
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+#include "smp.h"
+
+#include "mpc85xx.h"
+
+static void __init twr_p1025_pic_init(void)
+{
+ struct mpic *mpic;
+
+#ifdef CONFIG_QUICC_ENGINE
+ struct device_node *np;
+#endif
+
+ mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
+ MPIC_SINGLE_DEST_CPU,
+ 0, 256, " OpenPIC ");
+
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+
+#ifdef CONFIG_QUICC_ENGINE
+ np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
+ if (np) {
+ qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
+ qe_ic_cascade_high_mpic);
+ of_node_put(np);
+ } else
+ pr_err("Could not find qe-ic node\n");
+#endif
+}
+
+/* ************************************************************************
+ *
+ * Setup the architecture
+ *
+ */
+static void __init twr_p1025_setup_arch(void)
+{
+#ifdef CONFIG_QUICC_ENGINE
+ struct device_node *np;
+#endif
+
+ if (ppc_md.progress)
+ ppc_md.progress("twr_p1025_setup_arch()", 0);
+
+ mpc85xx_smp_init();
+
+ fsl_pci_assign_primary();
+
+#ifdef CONFIG_QUICC_ENGINE
+ mpc85xx_qe_init();
+
+#if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)
+ if (machine_is(twr_p1025)) {
+ struct ccsr_guts __iomem *guts;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,p1021-guts");
+ if (np) {
+ guts = of_iomap(np, 0);
+ if (!guts)
+ pr_err("twr_p1025: could not map global utilities register\n");
+ else {
+ /* P1025 has pins muxed for QE and other functions. To
+ * enable QE UEC mode, we need to set bit QE0 for UCC1
+ * in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9
+ * and QE12 for QE MII management signals in PMUXCR
+ * register.
+ * Set QE mux bits in PMUXCR */
+ setbits32(&guts->pmuxcr, MPC85xx_PMUXCR_QE(0) |
+ MPC85xx_PMUXCR_QE(3) |
+ MPC85xx_PMUXCR_QE(9) |
+ MPC85xx_PMUXCR_QE(12));
+ iounmap(guts);
+
+#if defined(CONFIG_SERIAL_QE)
+ /* On P1025TWR board, the UCC7 acted as UART port.
+ * However, The UCC7's CTS pin is low level in default,
+ * it will impact the transmission in full duplex
+ * communication. So disable the Flow control pin PA18.
+ * The UCC7 UART just can use RXD and TXD pins.
+ */
+ par_io_config_pin(0, 18, 0, 0, 0, 0);
+#endif
+ /* Drive PB29 to CPLD low - CPLD will then change
+ * muxing from LBC to QE */
+ par_io_config_pin(1, 29, 1, 0, 0, 0);
+ par_io_data_set(1, 29, 0);
+ }
+ of_node_put(np);
+ }
+ }
+#endif
+#endif /* CONFIG_QUICC_ENGINE */
+
+ printk(KERN_INFO "TWR-P1025 board from Freescale Semiconductor\n");
+}
+
+machine_arch_initcall(twr_p1025, mpc85xx_common_publish_devices);
+
+static int __init twr_p1025_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "fsl,TWR-P1025");
+}
+
+define_machine(twr_p1025) {
+ .name = "TWR-P1025",
+ .probe = twr_p1025_probe,
+ .setup_arch = twr_p1025_setup_arch,
+ .init_IRQ = twr_p1025_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.8.0
^ permalink raw reply related
* [PATCH V5 1/2] powerpc/85xx: Add QE common init function
From: Xie Xiaobo @ 2013-09-26 9:37 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: Xie Xiaobo
Define a QE init function in common file, and avoid
the same codes being duplicated in board files.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
---
V5 -> V4: add the board files modification, remove the qe_pic_init.
V4 -> V3: Nochange
arch/powerpc/platforms/85xx/common.c | 33 +++++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/mpc85xx.h | 6 ++++++
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 29 ++-------------------------
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 25 ++---------------------
4 files changed, 43 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
index d0861a0..568fd1f 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -7,6 +7,7 @@
*/
#include <linux/of_platform.h>
+#include <asm/qe.h>
#include <sysdev/cpm2_pic.h>
#include "mpc85xx.h"
@@ -80,3 +81,35 @@ void __init mpc85xx_cpm2_pic_init(void)
irq_set_chained_handler(irq, cpm2_cascade);
}
#endif
+
+#ifdef CONFIG_QUICC_ENGINE
+void __init mpc85xx_qe_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,qe");
+ if (!np) {
+ np = of_find_node_by_name(NULL, "qe");
+ if (!np) {
+ pr_err("%s: Could not find Quicc Engine node\n",
+ __func__);
+ return;
+ }
+ }
+
+ qe_reset();
+ of_node_put(np);
+
+ np = of_find_node_by_name(NULL, "par_io");
+ if (np) {
+ struct device_node *ucc;
+
+ par_io_init(np);
+ of_node_put(np);
+
+ for_each_node_by_name(ucc, "ucc")
+ par_io_of_config(ucc);
+
+ }
+}
+#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/platforms/85xx/mpc85xx.h
index 2aa7c5d..fc51dd4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -8,4 +8,10 @@ extern void mpc85xx_cpm2_pic_init(void);
static inline void __init mpc85xx_cpm2_pic_init(void) {}
#endif /* CONFIG_CPM2 */
+#ifdef CONFIG_QUICC_ENGINE
+extern void mpc85xx_qe_init(void);
+#else
+static inline void __init mpc85xx_qe_init(void) {}
+#endif
+
#endif
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index a7b3621..34f3c5e 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2006-2010, 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2006-2010, 2012-2013 Freescale Semiconductor, Inc.
* All rights reserved.
*
* Author: Andy Fleming <afleming@freescale.com>
@@ -238,32 +238,7 @@ static void __init mpc85xx_mds_qe_init(void)
{
struct device_node *np;
- np = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!np) {
- np = of_find_node_by_name(NULL, "qe");
- if (!np)
- return;
- }
-
- if (!of_device_is_available(np)) {
- of_node_put(np);
- return;
- }
-
- qe_reset();
- of_node_put(np);
-
- np = of_find_node_by_name(NULL, "par_io");
- if (np) {
- struct device_node *ucc;
-
- par_io_init(np);
- of_node_put(np);
-
- for_each_node_by_name(ucc, "ucc")
- par_io_of_config(ucc);
- }
-
+ mpc85xx_qe_init();
mpc85xx_mds_reset_ucc_phys();
if (machine_is(p1021_mds)) {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 53b6fb0..e15bdd1 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -1,7 +1,7 @@
/*
* MPC85xx RDB Board Setup
*
- * Copyright 2009,2012 Freescale Semiconductor Inc.
+ * Copyright 2009,2012-2013 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -98,26 +98,7 @@ static void __init mpc85xx_rdb_setup_arch(void)
fsl_pci_assign_primary();
#ifdef CONFIG_QUICC_ENGINE
- np = of_find_compatible_node(NULL, NULL, "fsl,qe");
- if (!np) {
- pr_err("%s: Could not find Quicc Engine node\n", __func__);
- goto qe_fail;
- }
-
- qe_reset();
- of_node_put(np);
-
- np = of_find_node_by_name(NULL, "par_io");
- if (np) {
- struct device_node *ucc;
-
- par_io_init(np);
- of_node_put(np);
-
- for_each_node_by_name(ucc, "ucc")
- par_io_of_config(ucc);
-
- }
+ mpc85xx_qe_init();
#if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)
if (machine_is(p1025_rdb)) {
@@ -148,8 +129,6 @@ static void __init mpc85xx_rdb_setup_arch(void)
}
#endif
-
-qe_fail:
#endif /* CONFIG_QUICC_ENGINE */
printk(KERN_INFO "MPC85xx RDB board from Freescale Semiconductor\n");
--
1.8.0
^ permalink raw reply related
* [PATCH v11 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: hongbo.zhang @ 2013-09-26 9:33 UTC (permalink / raw)
To: rob.herring, pawel.moll, mark.rutland, swarren, ian.campbell,
vinod.koul, djbw
Cc: Hongbo Zhang, devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <1380188023-3936-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
.../devicetree/bindings/powerpc/fsl/dma.txt | 70 +++++++++++++++++
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82 ++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +-
5 files changed, 238 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 0584168..7fc1b01 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -128,6 +128,76 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ DMA controller which has same function as EloPlus except that Elo3 has 8
+ channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible : must include "fsl,elo3-dma"
+- reg : contains two entries for DMA General Status Registers,
+ i.e. DGSR0 which includes status for channel 1~4, and
+ DGSR1 for channel 5~8
+- ranges : describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+ - compatible : must include "fsl,eloplus-dma-channel"
+ - reg : DMA channel specific registers
+ - interrupts : interrupt specifier for DMA channel IRQ
+ - interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4>,
+ <0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = <0xe2000 0x1000>;
};
-/include/ "qoriq-dma-0.dtsi"
+/include/ "elo3-dma-0.dtsi"
dma@100300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x580>; /* DMA1LIODNR */
};
-/include/ "qoriq-dma-1.dtsi"
+/include/ "elo3-dma-1.dtsi"
dma@101300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
new file mode 100644
index 0000000..3c210e0
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
@@ -0,0 +1,82 @@
+/*
+ * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x100000 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma0: dma@100300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x100300 0x4>,
+ <0x100600 0x4>;
+ ranges = <0x0 0x100100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <28 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <29 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <30 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <31 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <76 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <77 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <78 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <79 2 0 0>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
new file mode 100644
index 0000000..cccf3bb
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
@@ -0,0 +1,82 @@
+/*
+ * QorIQ Elo3 DMA device tree stub [ controller @ offset 0x101000 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+dma1: dma@101300 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,elo3-dma";
+ reg = <0x101300 0x4>,
+ <0x101600 0x4>;
+ ranges = <0x0 0x101100 0x500>;
+ dma-channel@0 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x0 0x80>;
+ interrupts = <32 2 0 0>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x80 0x80>;
+ interrupts = <33 2 0 0>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x100 0x80>;
+ interrupts = <34 2 0 0>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x180 0x80>;
+ interrupts = <35 2 0 0>;
+ };
+ dma-channel@300 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x300 0x80>;
+ interrupts = <80 2 0 0>;
+ };
+ dma-channel@380 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x380 0x80>;
+ interrupts = <81 2 0 0>;
+ };
+ dma-channel@400 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x400 0x80>;
+ interrupts = <82 2 0 0>;
+ };
+ dma-channel@480 {
+ compatible = "fsl,eloplus-dma-channel";
+ reg = <0x480 0x80>;
+ interrupts = <83 2 0 0>;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index bd611a9..ec95c60 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -387,8 +387,8 @@
reg = <0xea000 0x4000>;
};
-/include/ "qoriq-dma-0.dtsi"
-/include/ "qoriq-dma-1.dtsi"
+/include/ "elo3-dma-0.dtsi"
+/include/ "elo3-dma-1.dtsi"
/include/ "qoriq-espi-0.dtsi"
spi@110000 {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: hongbo.zhang @ 2013-09-26 9:33 UTC (permalink / raw)
To: rob.herring, pawel.moll, mark.rutland, swarren, ian.campbell,
vinod.koul, djbw
Cc: Hongbo Zhang, devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <1380188023-3936-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
---
drivers/dma/Kconfig | 9 +++++----
drivers/dma/fsldma.c | 9 ++++++---
drivers/dma/fsldma.h | 2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
- tristate "Freescale Elo and Elo Plus DMA support"
+ tristate "Freescale Elo series DMA support"
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate "Freescale MPC512x built-in DMA engine support"
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev->feature != chan->feature);
chan->dev = fdev->dev;
- chan->id = ((res.start - 0x100) & 0xfff) >> 7;
+ chan->id = (res.start & 0xfff) < 0x300 ?
+ ((res.start - 0x100) & 0xfff) >> 7 :
+ ((res.start - 0x200) & 0xfff) >> 7;
if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev->dev, "too many channels for device\n");
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+ { .compatible = "fsl,elo3-dma", },
{ .compatible = "fsl,eloplus-dma", },
{ .compatible = "fsl,elo-dma", },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
- pr_info("Freescale Elo / Elo Plus DMA driver\n");
+ pr_info("Freescale Elo series DMA driver\n");
return platform_driver_register(&fsldma_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");
+MODULE_DESCRIPTION("Freescale Elo series DMA driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs; /* DGSR register base */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v11 1/3] DMA: Freescale: revise device tree binding document
From: hongbo.zhang @ 2013-09-26 9:33 UTC (permalink / raw)
To: rob.herring, pawel.moll, mark.rutland, swarren, ian.campbell,
vinod.koul, djbw
Cc: Hongbo Zhang, devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <1380188023-3936-1-git-send-email-hongbo.zhang@freescale.com>
From: Hongbo Zhang <hongbo.zhang@freescale.com>
This patch updates the discription of each type of DMA controller and its
channels, it is preparation for adding another new DMA controller binding, it
also fixes some defects of indent for text alignment at the same time.
Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
---
.../devicetree/bindings/powerpc/fsl/dma.txt | 68 +++++++++-----------
1 file changed, 31 insertions(+), 37 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 2a4b4bc..0584168 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -1,33 +1,30 @@
-* Freescale 83xx DMA Controller
+* Freescale DMA Controllers
-Freescale PowerPC 83xx have on chip general purpose DMA controllers.
+** Freescale Elo DMA Controller
+ This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx
+ series chips such as mpc8315, mpc8349, mpc8379 etc.
Required properties:
-- compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-dma", where CHIP is the processor
- (mpc8349, mpc8360, etc.) and the second is
- "fsl,elo-dma"
-- reg : <registers mapping for DMA general status reg>
-- ranges : Should be defined as specified in 1) to describe the
- DMA controller channels.
+- compatible : must include "fsl,elo-dma"
+- reg : DMA General Status Register, i.e. DGSR which contains
+ status for all the 4 DMA channels
+- ranges : describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
- cell-index : controller index. 0 for controller @ 0x8100
-- interrupts : <interrupt mapping for DMA IRQ>
+- interrupts : interrupt specifier for DMA IRQ
- interrupt-parent : optional, if needed for interrupt mapping
-
- DMA channel nodes:
- - compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-dma-channel", where CHIP is the processor
- (mpc8349, mpc8350, etc.) and the second is
- "fsl,elo-dma-channel". However, see note below.
- - reg : <registers mapping for channel>
- - cell-index : dma channel index starts at 0.
+ - compatible : must include "fsl,elo-dma-channel"
+ However, see note below.
+ - reg : DMA channel specific registers
+ - cell-index : DMA channel index starts at 0.
Optional properties:
- - interrupts : <interrupt mapping for DMA channel IRQ>
- (on 83xx this is expected to be identical to
- the interrupts property of the parent node)
+ - interrupts : interrupt specifier for DMA channel IRQ
+ (on 83xx this is expected to be identical to
+ the interrupts property of the parent node)
- interrupt-parent : optional, if needed for interrupt mapping
Example:
@@ -70,30 +67,27 @@ Example:
};
};
-* Freescale 85xx/86xx DMA Controller
-
-Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers.
+** Freescale EloPlus DMA Controller
+ This is a 4-channel DMA controller with extended addresses and chaining,
+ mainly used in Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as
+ mpc8540, mpc8641 p4080, bsc9131 etc.
Required properties:
-- compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-dma", where CHIP is the processor
- (mpc8540, mpc8540, etc.) and the second is
- "fsl,eloplus-dma"
-- reg : <registers mapping for DMA general status reg>
+- compatible : must include "fsl,eloplus-dma"
+- reg : DMA General Status Register, i.e. DGSR which contains
+ status for all the 4 DMA channels
- cell-index : controller index. 0 for controller @ 0x21000,
1 for controller @ 0xc000
-- ranges : Should be defined as specified in 1) to describe the
- DMA controller channels.
+- ranges : describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
- DMA channel nodes:
- - compatible : compatible list, contains 2 entries, first is
- "fsl,CHIP-dma-channel", where CHIP is the processor
- (mpc8540, mpc8560, etc.) and the second is
- "fsl,eloplus-dma-channel". However, see note below.
- - cell-index : dma channel index starts at 0.
- - reg : <registers mapping for channel>
- - interrupts : <interrupt mapping for DMA channel IRQ>
+ - compatible : must include "fsl,eloplus-dma-channel"
+ However, see note below.
+ - cell-index : DMA channel index starts at 0.
+ - reg : DMA channel specific registers
+ - interrupts : interrupt specifier for DMA channel IRQ
- interrupt-parent : optional, if needed for interrupt mapping
Example:
--
1.7.9.5
^ permalink raw reply related
* [PATCH v11 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: hongbo.zhang @ 2013-09-26 9:33 UTC (permalink / raw)
To: rob.herring, pawel.moll, mark.rutland, swarren, ian.campbell,
vinod.koul, djbw
Cc: Hongbo Zhang, devicetree, linuxppc-dev, linux-kernel
From: Hongbo Zhang <hongbo.zhang@freescale.com>
Hi DMA and DT maintainers, please have a look at these V11 patches.
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set
adds support this DMA engine.
V10->V11 changes:
- add "contains two entries" for reg description in patch [2/3]
V9->V10 changes:
- update binding description text, mainly about the reg property and also Elo3
DMA controller specification
V8->V9 changes:
- add "Acked-by: Mark Rutland <mark.rutland@arm.com>" into patch [1/3]
- update reg entry <0x100300 0x4 0x100600 0x4> to two seperate ones
<0x100300 0x4>, <0x100600 0x4> in patch [2/3]
- and also use "QorIQ Elo3 DMA" to mention previous "QorIQ DMA" in [2/3]
V7->V8 changes:
- change the word "mapping" to "specifier" for reg and interrupts description
V6->V7 changes:
- only remove unnecessary "CHIP-dma" explanations in [1/3]
V5->V6 changes:
- minor updates of descriptions in binding document and Kconfig
- remove [4/4], that should be another patch in future
V4->V5 changes:
- update description in the dt binding document, to make it more resonable
- add new patch [4/4] to eliminate a compiling warning which already exists
for a long time
V3->V4 changes:
- introduce new patch [1/3] to revise the legacy dma binding document
- and then add new paragraph to describe new dt node binding in [2/3]
- rebase to latest kernel v3.11-rc1
V2->V3 changes:
- edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt
- edit text string in Kconfig and the driver files, using "elo series" to
mention all the current "elo*"
V1->V2 changes:
- removed the codes handling the register dgsr1, since it isn't used currently
- renamed the DMA DT compatible to "fsl,elo3-dma"
- renamed the new dts files to "elo3-dma-<n>.dtsi"
Hongbo Zhang (3):
DMA: Freescale: revise device tree binding document
DMA: Freescale: Add new 8-channel DMA engine device tree nodes
DMA: Freescale: update driver to support 8-channel DMA engine
.../devicetree/bindings/powerpc/fsl/dma.txt | 138 ++++++++++++++------
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82 ++++++++++++
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82 ++++++++++++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +-
drivers/dma/Kconfig | 9 +-
drivers/dma/fsldma.c | 9 +-
drivers/dma/fsldma.h | 2 +-
8 files changed, 281 insertions(+), 49 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
--
1.7.9.5
^ permalink raw reply
* RE: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board support
From: Xie Xiaobo-R63061 @ 2013-09-26 9:27 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Johnston Michael-R49610, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1380150578.24959.213.camel@snotra.buserror.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0K
PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI2LCAyMDEzIDc6MTAgQU0NCj4gVG86IFhpZSBY
aWFvYm8tUjYzMDYxDQo+IENjOiBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxpc3Rz
Lm96bGFicy5vcmc7IEpvaG5zdG9uIE1pY2hhZWwtDQo+IFI0OTYxMA0KPiBTdWJqZWN0OiBSZTog
W1BBVENIIFY0IDMvM10gcG93ZXJwYy84NXh4OiBBZGQgVFdSLVAxMDI1IGJvYXJkIHN1cHBvcnQN
Cj4gDQo+IE9uIFdlZCwgMjAxMy0wOS0yNSBhdCAwNDo1MCAtMDUwMCwgWGllIFhpYW9iby1SNjMw
NjEgd3JvdGU6DQo+ID4gSGkgU2NvdHQsDQo+ID4NCj4gPiBTZWUgdGhlIHJlcGx5IGlubGluZS4N
Cj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFdvb2Qg
U2NvdHQtQjA3NDIxDQo+ID4gPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxMyA3
OjIyIEFNDQo+ID4gPiBUbzogWGllIFhpYW9iby1SNjMwNjENCj4gPiA+IENjOiBsaW51eHBwYy1k
ZXZAbGlzdHMub3psYWJzLm9yZzsgSm9obnN0b24gTWljaGFlbC1SNDk2MTANCj4gPiA+IFN1Ympl
Y3Q6IFJlOiBbUEFUQ0ggVjQgMy8zXSBwb3dlcnBjLzg1eHg6IEFkZCBUV1ItUDEwMjUgYm9hcmQN
Cj4gPiA+IHN1cHBvcnQNCj4gPiA+DQo+ID4gPiBPbiBUdWUsIDIwMTMtMDktMjQgYXQgMTg6NDgg
KzA4MDAsIFhpZSBYaWFvYm8gd3JvdGU6DQo+ID4gPiA+ICsJCXBhcnRpdGlvbkA4MDAwMCB7DQo+
ID4gPiA+ICsJCQkvKiAzLjUgTUIgZm9yIExpbnV4IEtlcm5lbCBJbWFnZSAqLw0KPiA+ID4gPiAr
CQkJcmVnID0gPDB4MDAwODAwMDAgMHgwMDM4MDAwMD47DQo+ID4gPiA+ICsJCQlsYWJlbCA9ICJO
T1IgTGludXggS2VybmVsIEltYWdlIjsNCj4gPiA+ID4gKwkJfTsNCj4gPiA+DQo+ID4gPiBJcyB0
aGlzIGVub3VnaD8NCj4gPg0KPiA+IEkgd2lsbCBlbmxhcmdlIGl0IHRvIDZNQi4NCj4gPg0KPiA+
ID4NCj4gPiA+ID4gKwkJcGFydGl0aW9uQDQwMDAwMCB7DQo+ID4gPiA+ICsJCQkvKiA1OC43NU1C
IGZvciBKRkZTMiBiYXNlZCBSb290IGZpbGUgU3lzdGVtICovDQo+ID4gPiA+ICsJCQlyZWcgPSA8
MHgwMDQwMDAwMCAweDAzYWMwMDAwPjsNCj4gPiA+ID4gKwkJCWxhYmVsID0gIk5PUiBSb290IEZp
bGUgU3lzdGVtIjsNCj4gPiA+ID4gKwkJfTsNCj4gPiA+DQo+ID4gPiBEb24ndCBzcGVjaWZ5IGpm
ZnMyLg0KPiA+DQo+ID4gT0ssIEkgd2lsbCByZW1vdmUgImpmZnMyIg0KPiA+DQo+ID4gPg0KPiA+
ID4gPiArCS8qIENTMiBmb3IgRGlzcGxheSAqLw0KPiA+ID4gPiArCXNzZDEyODlAMiwwIHsNCj4g
PiA+ID4gKwkJI2FkZHJlc3MtY2VsbHMgPSA8MT47DQo+ID4gPiA+ICsJCSNzaXplLWNlbGxzID0g
PDE+Ow0KPiA+ID4gPiArCQljb21wYXRpYmxlID0gInNzZDEyODkiOw0KPiA+ID4gPiArCQlyZWcg
PSA8MHgyIDB4MDAwMCAweDAwMDINCj4gPiA+ID4gKwkJICAgICAgIDB4MiAweDAwMDIgMHgwMDAy
PjsNCj4gPiA+ID4gKwl9Ow0KPiA+ID4NCj4gPiA+IE5vZGUgbmFtZXMgc2hvdWxkIGJlIGdlbmVy
aWMuICBXaGF0IGRvZXMgc3NkMTI4OSBkbz8gIElmIHRoaXMgaXMNCj4gPiA+IGFjdHVhbGx5IHRo
ZSBkaXNwbGF5IGRldmljZSwgdGhlbiBpdCBzaG91bGQgYmUgY2FsbGVkICJkaXNwbGF5QDIsMCIu
DQo+ID4NCj4gPiBPSy4gVGhlIHNzZDEyODkgaXMgYSBMQ0QgY29udHJvbGxlci4NCj4gPg0KPiA+
ID4NCj4gPiA+IEhvdyBhYm91dCBhIHZlbmRvciBwcmVmaXggb24gdGhhdCBjb21wYXRpYmxlPyAg
V2h5DQo+ID4gPiAjYWRkcmVzcy1jZWxscy8jc2l6ZS0gY2VsbHMgZGVzcGl0ZSBubyBjaGlsZCBu
b2Rlcz8gIFdoZXJlIGlzIGENCj4gPiA+IGJpbmRpbmcgdGhhdCBzYXlzIHdoYXQgZWFjaCBvZiB0
aG9zZSB0d28gcmVnIHJlc291cmNlcyBtZWFuPw0KPiA+DQo+ID4gSSB3aWxsIGFkZCB0aGUgdmVu
ZG9yIHByZWZpeC4gSSByZXZpZXcgdGhlIHNzZDEyODkgZHJpdmVyLCBhbmQgdGhlDQo+ICNhZGRy
ZXNzLWNlbGxzLyNzaXplLWNlbGxzIHdlcmUgdW4tdXNlZC4gSSB3aWxsIHJlbW92ZSB0aGVtLg0K
PiANCj4gQW5kIGEgYmluZGluZz8NCj4gDQo+IFdoeSBkbyB5b3UgbmVlZCB0d28gc2VwYXJhdGUg
cmVnIHJlc291cmNlcyByYXRoZXIgdGhhbiBqdXN0IDwyIDAgND4/DQo+IFdpbGwgdGhleSBldmVy
IGJlIGRpc2NvbnRpZ3VvdXM/DQoNCltYaWVdIEkgcmV2aWV3IHRoZSBzc2QxMjg5IGRyaXZlciBj
b2RlLCBhbmQgZm91bmQgdGhlIGRyaXZlciBuZWVkIHR3byByZWcgcmVzb3VyY2VzLCBpZiBjaGFu
Z2UgdGhlIGR0cywgdGhlIGRyaXZlciBhbHNvIHNob3VsZCBiZSBtb2RpZmllZCBhY2NvcmRpbmds
eS4gU28gSSByZW1vdmUgdGhlIHNzZDEyODkgbm9kZSBmcm9tIHRoaXMgcGF0Y2guIEkgd2lsbCBz
dWJtaXQgbmV3IHBhdGNoIGluY2x1ZGUgdGhlIGR0cyBtb2RpZmljYXRpb24sIHNzZDEyODkgZHJp
dmVyIGFuZCB0aGUgYmluZGluZy4gICANCg0KPiANCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* therm_adt746x: -3 invalid for parameter limit_adjust
From: Christian Kujau @ 2013-09-26 9:16 UTC (permalink / raw)
To: colin, khali, linuxppc-dev
Hi,
after upgrading from 3.11 to 3.12-rc2, the therm_adt746x module could not
be loaded any more:
therm_adt746x: `-2' invalid for parameter `limit_adjust'
I've alwasy passed "limit_adjust=-3" (negative 3) to the module via
modprobe.conf, to lower the max temperature. Up until 3.11, loading the
module would print:
adt746x: Lowering max temperatures from 73, 80, 109 to 67, 47, 67
I can load the module without limit_adjust or with positive values, but
really wanted to lower the temperature, so that the fan would kick in
earlier. For reference, this is what happens in 3.12-rc2:
v--- limit_adjust
|
0: adt746x: Lowering max temperatures from 73, 80, 109 to 70, 50, 70
1: adt746x: Lowering max temperatures from 73, 80, 109 to 71, 51, 71
2: adt746x: Lowering max temperatures from 73, 80, 109 to 72, 52, 72
3: adt746x: Lowering max temperatures from 73, 80, 109 to 73, 53, 73
4: adt746x: Lowering max temperatures from 73, 80, 109 to 74, 54, 74
10: adt746x: Lowering max temperatures from 73, 80, 109 to 80, 60, 80
Was passing negative values to therm_adt746x ever supported?
drivers/macintosh/therm_adt746x.c hasn't been touched in a while, this
means some other change did it.
Before I attempt a full git bisect, any hints what could have caused this?
Thanks,
Christian.
--
BOFH excuse #339:
manager in the cable duct
^ permalink raw reply
* RE: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
From: David Laight @ 2013-09-26 8:58 UTC (permalink / raw)
To: Alexander Gordeev, Tejun Heo
Cc: linux-pci, Joerg Roedel, x86, linux-kernel, linux-ide,
Jan Beulich, Bjorn Helgaas, linuxppc-dev, Ingo Molnar
In-Reply-To: <20130926074646.GA16774@dhcp-26-207.brq.redhat.com>
> Subject: Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() =
interface
>=20
> On Wed, Sep 25, 2013 at 05:00:16PM -0400, Tejun Heo wrote:
> > Hello,
> >
> > On Wed, Sep 25, 2013 at 10:58:05PM +0200, Alexander Gordeev wrote:
> > > Unfortunately, pSeries is a shows-topper here :( It seems we have =
to
> > > introduce pci_get_msi{,x}_limit() interfaces to honour the quota
> > > thing. I just hope the hardware set for pSeries is limited and we
> > > won't need to use it for all drivers.
> >
> > Can you please go into a bit of detail on that? Why does it matter?
>=20
> 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."
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.
Interrupts could then be allocated after it is known how many
are required and how many are available.
David
^ permalink raw reply
* Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems
From: Paolo Bonzini @ 2013-09-26 9:06 UTC (permalink / raw)
To: Michael Ellerman
Cc: tytso, herbert, gleb, linux-kernel, kvm-ppc, agraf, linuxppc-dev,
Paul Mackerras, kvm, mpm
In-Reply-To: <1380177066-3835-3-git-send-email-michael@ellerman.id.au>
Il 26/09/2013 08:31, Michael Ellerman ha scritto:
> Some powernv systems include a hwrng. Guests can access it via the
> H_RANDOM hcall.
>
> We add a real mode implementation of H_RANDOM when a hwrng is found.
> Userspace can detect the presence of the hwrng by quering the
> KVM_CAP_PPC_HWRNG capability.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/include/asm/archrandom.h | 11 ++-
> arch/powerpc/include/asm/kvm_ppc.h | 2 +
> arch/powerpc/kvm/book3s_hv_builtin.c | 15 ++++
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 119 ++++++++++++++++++++++++++++++++
> arch/powerpc/kvm/powerpc.c | 3 +
> arch/powerpc/platforms/powernv/rng.c | 25 +++++++
> include/uapi/linux/kvm.h | 1 +
> 7 files changed, 174 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/archrandom.h b/arch/powerpc/include/asm/archrandom.h
> index d853d16..86296d5 100644
> --- a/arch/powerpc/include/asm/archrandom.h
> +++ b/arch/powerpc/include/asm/archrandom.h
> @@ -25,8 +25,15 @@ static inline int arch_get_random_int(unsigned int *v)
> return rc;
> }
>
> -int powernv_get_random_long(unsigned long *v);
> -
> #endif /* CONFIG_ARCH_RANDOM */
>
> +#ifdef CONFIG_PPC_POWERNV
> +int powernv_hwrng_present(void);
> +int powernv_get_random_long(unsigned long *v);
> +int powernv_get_random_real_mode(unsigned long *v);
> +#else
> +static inline int powernv_hwrng_present(void) { return 0; }
> +static inline int powernv_get_random_real_mode(unsigned long *v) { return 0; }
> +#endif
> +
> #endif /* _ASM_POWERPC_ARCHRANDOM_H */
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index b15554a..51966fd 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -177,6 +177,8 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq, u32 *server,
> extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
> extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
>
> +extern int kvmppc_hwrng_present(void);
> +
> /*
> * Cuts out inst bits with ordering according to spec.
> * That means the leftmost bit is zero. All given bits are included.
> diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c
> index 8cd0dae..de12592 100644
> --- a/arch/powerpc/kvm/book3s_hv_builtin.c
> +++ b/arch/powerpc/kvm/book3s_hv_builtin.c
> @@ -19,6 +19,7 @@
> #include <asm/cputable.h>
> #include <asm/kvm_ppc.h>
> #include <asm/kvm_book3s.h>
> +#include <asm/archrandom.h>
>
> #include "book3s_hv_cma.h"
> /*
> @@ -181,3 +182,17 @@ void __init kvm_cma_reserve(void)
> kvm_cma_declare_contiguous(selected_size, align_size);
> }
> }
> +
> +int kvmppc_hwrng_present(void)
> +{
> + return powernv_hwrng_present();
> +}
> +EXPORT_SYMBOL_GPL(kvmppc_hwrng_present);
> +
> +long kvmppc_h_random(struct kvm_vcpu *vcpu)
> +{
> + if (powernv_get_random_real_mode(&vcpu->arch.gpr[4]))
> + return H_SUCCESS;
> +
> + return H_HARDWARE;
> +}
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index 294b7af..35ce59e 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1502,6 +1502,125 @@ hcall_real_table:
> .long 0 /* 0x11c */
> .long 0 /* 0x120 */
> .long .kvmppc_h_bulk_remove - hcall_real_table
> + .long 0 /* 0x128 */
> + .long 0 /* 0x12c */
> + .long 0 /* 0x130 */
> + .long 0 /* 0x134 */
> + .long 0 /* 0x138 */
> + .long 0 /* 0x13c */
> + .long 0 /* 0x140 */
> + .long 0 /* 0x144 */
> + .long 0 /* 0x148 */
> + .long 0 /* 0x14c */
> + .long 0 /* 0x150 */
> + .long 0 /* 0x154 */
> + .long 0 /* 0x158 */
> + .long 0 /* 0x15c */
> + .long 0 /* 0x160 */
> + .long 0 /* 0x164 */
> + .long 0 /* 0x168 */
> + .long 0 /* 0x16c */
> + .long 0 /* 0x170 */
> + .long 0 /* 0x174 */
> + .long 0 /* 0x178 */
> + .long 0 /* 0x17c */
> + .long 0 /* 0x180 */
> + .long 0 /* 0x184 */
> + .long 0 /* 0x188 */
> + .long 0 /* 0x18c */
> + .long 0 /* 0x190 */
> + .long 0 /* 0x194 */
> + .long 0 /* 0x198 */
> + .long 0 /* 0x19c */
> + .long 0 /* 0x1a0 */
> + .long 0 /* 0x1a4 */
> + .long 0 /* 0x1a8 */
> + .long 0 /* 0x1ac */
> + .long 0 /* 0x1b0 */
> + .long 0 /* 0x1b4 */
> + .long 0 /* 0x1b8 */
> + .long 0 /* 0x1bc */
> + .long 0 /* 0x1c0 */
> + .long 0 /* 0x1c4 */
> + .long 0 /* 0x1c8 */
> + .long 0 /* 0x1cc */
> + .long 0 /* 0x1d0 */
> + .long 0 /* 0x1d4 */
> + .long 0 /* 0x1d8 */
> + .long 0 /* 0x1dc */
> + .long 0 /* 0x1e0 */
> + .long 0 /* 0x1e4 */
> + .long 0 /* 0x1e8 */
> + .long 0 /* 0x1ec */
> + .long 0 /* 0x1f0 */
> + .long 0 /* 0x1f4 */
> + .long 0 /* 0x1f8 */
> + .long 0 /* 0x1fc */
> + .long 0 /* 0x200 */
> + .long 0 /* 0x204 */
> + .long 0 /* 0x208 */
> + .long 0 /* 0x20c */
> + .long 0 /* 0x210 */
> + .long 0 /* 0x214 */
> + .long 0 /* 0x218 */
> + .long 0 /* 0x21c */
> + .long 0 /* 0x220 */
> + .long 0 /* 0x224 */
> + .long 0 /* 0x228 */
> + .long 0 /* 0x22c */
> + .long 0 /* 0x230 */
> + .long 0 /* 0x234 */
> + .long 0 /* 0x238 */
> + .long 0 /* 0x23c */
> + .long 0 /* 0x240 */
> + .long 0 /* 0x244 */
> + .long 0 /* 0x248 */
> + .long 0 /* 0x24c */
> + .long 0 /* 0x250 */
> + .long 0 /* 0x254 */
> + .long 0 /* 0x258 */
> + .long 0 /* 0x25c */
> + .long 0 /* 0x260 */
> + .long 0 /* 0x264 */
> + .long 0 /* 0x268 */
> + .long 0 /* 0x26c */
> + .long 0 /* 0x270 */
> + .long 0 /* 0x274 */
> + .long 0 /* 0x278 */
> + .long 0 /* 0x27c */
> + .long 0 /* 0x280 */
> + .long 0 /* 0x284 */
> + .long 0 /* 0x288 */
> + .long 0 /* 0x28c */
> + .long 0 /* 0x290 */
> + .long 0 /* 0x294 */
> + .long 0 /* 0x298 */
> + .long 0 /* 0x29c */
> + .long 0 /* 0x2a0 */
> + .long 0 /* 0x2a4 */
> + .long 0 /* 0x2a8 */
> + .long 0 /* 0x2ac */
> + .long 0 /* 0x2b0 */
> + .long 0 /* 0x2b4 */
> + .long 0 /* 0x2b8 */
> + .long 0 /* 0x2bc */
> + .long 0 /* 0x2c0 */
> + .long 0 /* 0x2c4 */
> + .long 0 /* 0x2c8 */
> + .long 0 /* 0x2cc */
> + .long 0 /* 0x2d0 */
> + .long 0 /* 0x2d4 */
> + .long 0 /* 0x2d8 */
> + .long 0 /* 0x2dc */
> + .long 0 /* 0x2e0 */
> + .long 0 /* 0x2e4 */
> + .long 0 /* 0x2e8 */
> + .long 0 /* 0x2ec */
> + .long 0 /* 0x2f0 */
> + .long 0 /* 0x2f4 */
> + .long 0 /* 0x2f8 */
> + .long 0 /* 0x2fc */
> + .long .kvmppc_h_random - hcall_real_table
> hcall_real_table_end:
>
> ignore_hdec:
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 07c0106..0d7208e 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -356,6 +356,9 @@ int kvm_dev_ioctl_check_extension(long ext)
> if (cpu_has_feature(CPU_FTR_ARCH_201))
> r = 2;
> break;
> + case KVM_CAP_PPC_HWRNG:
> + r = kvmppc_hwrng_present();
> + break;
> #endif
> case KVM_CAP_SYNC_MMU:
> #ifdef CONFIG_KVM_BOOK3S_64_HV
> diff --git a/arch/powerpc/platforms/powernv/rng.c b/arch/powerpc/platforms/powernv/rng.c
> index 51d2e6a..ea7e5cd 100644
> --- a/arch/powerpc/platforms/powernv/rng.c
> +++ b/arch/powerpc/platforms/powernv/rng.c
> @@ -20,12 +20,18 @@
>
> struct powernv_rng {
> void __iomem *regs;
> + void __iomem *regs_real;
> unsigned long mask;
> };
>
> static DEFINE_PER_CPU(struct powernv_rng *, powernv_rng);
>
>
> +int powernv_hwrng_present(void)
> +{
> + return __raw_get_cpu_var(powernv_rng) != NULL;
> +}
> +
> static unsigned long rng_whiten(struct powernv_rng *rng, unsigned long val)
> {
> unsigned long parity;
> @@ -42,6 +48,17 @@ static unsigned long rng_whiten(struct powernv_rng *rng, unsigned long val)
> return val;
> }
>
> +int powernv_get_random_real_mode(unsigned long *v)
> +{
> + struct powernv_rng *rng;
> +
> + rng = __raw_get_cpu_var(powernv_rng);
> +
> + *v = rng_whiten(rng, in_rm64(rng->regs_real));
> +
> + return 1;
> +}
> +
> int powernv_get_random_long(unsigned long *v)
> {
> struct powernv_rng *rng;
> @@ -76,12 +93,20 @@ static __init void rng_init_per_cpu(struct powernv_rng *rng,
> static __init int rng_create(struct device_node *dn)
> {
> struct powernv_rng *rng;
> + struct resource res;
> unsigned long val;
>
> rng = kzalloc(sizeof(*rng), GFP_KERNEL);
> if (!rng)
> return -ENOMEM;
>
> + if (of_address_to_resource(dn, 0, &res)) {
> + kfree(rng);
> + return -ENXIO;
> + }
> +
> + rng->regs_real = (void __iomem *)res.start;
> +
> rng->regs = of_iomap(dn, 0);
> if (!rng->regs) {
> kfree(rng);
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 99c2533..493a409 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
> #define KVM_CAP_IRQ_XICS 92
> #define KVM_CAP_ARM_EL1_32BIT 93
> #define KVM_CAP_SPAPR_MULTITCE 94
> +#define KVM_CAP_PPC_HWRNG 95
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
>
Is there any reason to do this in the kernel? It does not have to be a
particularly fast path; on x86, we are simply forwarding /dev/hwrng or
/dev/random data to the guest. You can simply use virtio-rng.
If you really want to have the hypercall, implementing it in QEMU means
that you can support it on all systems, in fact even when running
without KVM. The QEMU command line would be something like "-object
rng-random,filename=/dev/random,id=rng0 -device spapr-rng,rng=rng0".
Paolo
^ 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