* [PATCH v1] dma: imx-sdma: add virt-dma support
From: Robin Gong @ 2018-05-24 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523133441.GK20991@vkoul-mobl>
Okay, I'll try to split it.
On ?, 2018-05-23 at 19:04 +0530, Vinod wrote:
> On 23-05-18, 12:56, s.hauer at pengutronix.de wrote:
>
> >
> > Well, it's somewhat related to virtual dma support, but that's not
> > my
> > point. My point is that this patch is quite big and thus hard to
> > review.
> > If we find ways to make it smaller and to split it up in multiple
> > patches then we should do so, because it makes it easier to review
> > and
> > in case you break something here we raise the chance that a "git
> > bisect"
> > lands on a smaller patch which is easier to understand.
> >
> > Please try and make that a separate change. I haven't really looked
> > into
> > it and it may not be possible due to reasons I haven't seen, but
> > please
> > at least give it a try.
> That is something would help me as well. I have reviewed the patch
> and am not
> sure I fully understand the changes, so breaking up stuff would
> definitely help
> in the review..
>
^ permalink raw reply
* [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Levin Du @ 2018-05-24 1:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+VBspzCaLD2Wy=fyC-S+LKGZbVsB+b+Etkx91ioXOCuQ@mail.gmail.com>
Hi all, I'd like to quote reply of Robin Murphy at
?http://lists.infradead.org/pipermail/linux-rockchip/2018-May/020619.html
>
> I would suggest s/pin number/bit number in the associated GRF register/
> here. At least in this RK3328 case there's only one pin, which isn't
> numbered, and if you naively considered it pin 0 of this 'bank' you'd
> already have the wrong number. Since we're dealing with the "random
> SoC-specific controls" region of the GRF as opposed to the
> relatively-consistent and organised pinmux parts, I don't think we
> should rely on any assumptions about how things are laid out.
>
> I was initially going to suggest a more specific compatible string as
> well, but on reflection I think the generic "rockchip,gpio-syscon" for
> basic "flip this single GRF bit" functionality actually is the right way
> to go. In the specific RK3328 GPIO_MUTE case, there look to be 4 bits in
> total related to this pin - the enable, value, and some pull controls
> (which I assume apply when the output is disabled) - if at some point in
> future we *did* want to start explicitly controlling the rest of them
> too, then would be a good time to define a separate
> "rockchip,rk3328-gpio-mute" binding (and probably a dedicated driver)
> for that specialised functionality, independently of this basic one.
Shall we go the generic "rockchip,gpio-syscon" way, or the specific
?"rockchip,rk3328-gpio-mute" way? I prefer the former one.
The property of "gpio,syscon-dev" in gpio-syscon driver should be
documented.
Since the gpio controller is defined in the dtsi file, which inevitably
contains voodoo
register addresses. But at the board level dts file, there won't be more
register
addresses.
On 2018-05-24 3:53 AM, Rob Herring wrote:
> On Wed, May 23, 2018 at 10:12 AM, Heiko St?bner <heiko@sntech.de> wrote:
>> Hi Rob, Levin,
>>
>> sorry for being late to the party.
>>
>> Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
>>> On Tue, May 22, 2018 at 9:02 PM, Levin Du <djw@t-chip.com.cn> wrote:
>>>> On 2018-05-23 2:02 AM, Rob Herring wrote:
>>>>> On Fri, May 18, 2018 at 11:52:05AM +0800, djw at t-chip.com.cn wrote:
>>>>>> From: Levin Du <djw@t-chip.com.cn>
>>>>>>
>>>>>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
>>>>>> which do not belong to the general pinctrl.
>>>>>>
>>>>>> Adding gpio-syscon support makes controlling regulator or
>>>>>> LED using these special pins very easy by reusing existing
>>>>>> drivers, such as gpio-regulator and led-gpio.
>>>>>>
>>>>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>>>>
>>>>>> Changes in v1:
>>>>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>>>>> - Add doc rockchip,gpio-syscon.txt
>>>>>>
>>>>>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41
>>>>>>
>>>>>> ++++++++++++++++++++++
>>>>>>
>>>>>> drivers/gpio/gpio-syscon.c | 30
>>>>>>
>>>>>> ++++++++++++++++
>>>>>>
>>>>>> 2 files changed, 71 insertions(+)
>>>>>> create mode 100644
>>>>>>
>>>>>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..b1b2a67
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>>>>>> @@ -0,0 +1,41 @@
>>>>>> +* Rockchip GPIO support for GRF_SOC_CON registers
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: Should contain "rockchip,gpio-syscon".
>>>>>> +- gpio-controller: Marks the device node as a gpio controller.
>>>>>> +- #gpio-cells: Should be two. The first cell is the pin number and
>>>>>> + the second cell is used to specify the gpio polarity:
>>>>>> + 0 = Active high,
>>>>>> + 1 = Active low.
>>>>> There's no need for this child node. Just make the parent node a gpio
>>>>> controller.
>>>>>
>>>>> Rob
>>>> Hi Rob, it is not clear to me. Do you suggest that the grf node should be
>>>> a
>>>> gpio controller,
>>>> like below?
>>>>
>>>> + grf: syscon at ff100000 {
>>>> + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
>>>> "syscon", "simple-mfd";
>>> Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
>> I would disagree quite a bit here. The grf are the "general register files",
>> a bunch of registers used for quite a lot of things, and so it seems
>> among other users, also a gpio-controller for some more random pins
>> not controlled through the regular gpio controllers.
>>
>> For a more fully stocked grf, please see
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
>>
>> So the gpio controller should definitly also be a subnode.
> Sigh, yes, if there are a bunch of functions needing subnodes like the
> above, then yes that makes sense. But that's not what has been
> presented. Please make some attempt at defining *all* the functions.
> An actual binding would be nice, but I'll settle for just a list of
> things. The list should have functions that have DT dependencies (like
> clocks for phys in the above) because until you do, you don't need
> child nodes.
In rk3328.dtsi file, there are lots of line "rockchip,grf = <&grf>;" in
various nodes,
such as tsadc,? cru, gmac2io, gmac2phy, and also pinctrl, which are not
sub nodes of
`grf`, but for reference only. The gpio-syscon node should also have
similar behavior.
?They are not strongly coupled. The gpio-syscon node should be defined
outside of the
`grf` node.
>
>> The gpio in question is called "mute", so I'd think the gpio-syscon driver
>> should just define a "rockchip,rk3328-gpio-mute" compatible and contain
>> all the register voodoo in the driver itself and not define it in the dt.
> Is there really just one GPIO? If it has a defined function, then is
> it really GP? Can you control direction? I know Linus W doesn't like
> that kind of abuse of GPIO.
The "mute" pin is a output only GPIO, which is already supported by
setting flags in the gpio-syscon
?driver. And yes, this pin has a defined function, but can also be used
for general purpose operation.
Thanks
Levin
^ permalink raw reply
* [v3 03/10] mfd: mtk-mmsys: Add mmsys driver
From: Sean Wang @ 2018-05-24 2:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180430101826.GC5147@dell>
On Mon, 2018-04-30 at 11:18 +0100, Lee Jones wrote:
> On Fri, 27 Apr 2018, matthias.bgg at kernel.org wrote:
>
> > From: Matthias Brugger <mbrugger@suse.com>
> >
> > The MMSYS subsystem includes clocks and drm components.
> > This patch adds a MFD device to probe both drivers from the same
> > device tree compatible.
> >
> > Signed-off-by: Matthias Brugger <mbrugger@suse.com>
> > ---
> > drivers/mfd/Kconfig | 9 ++++++
> > drivers/mfd/Makefile | 2 ++
> > drivers/mfd/mtk-mmsys.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++
[ ... ]
> > +};
>
> This driver is pretty pointless. It doesn't actually do anything.
>
> I think you just want to use "simple-mfd" instead.
>
Hi, Matthias
Why not embedded a platform_device_register_data call into existent
MMSYS driver ?
It looks elegant and makes sense that mmsys device is being as parent
device for all its DRM components device and no need to create an
additional node representing the same device with mmsys simply in order
to probe its DRM components.
I'm planing to send a bunch of HDMI, MIPI related to MMSYS nodes for
MT7623 SoC when 4.18 rc1 comes out, so we should want to solve the
dt-binding violation issue first.
Though there are two same mmsys-compatible strings involving in dts
though, it seems that hdmi still can work fine in my setup.
Sean
> > +static const struct of_device_id of_match_mmsys[] = {
> > + { .compatible = "mediatek,mt2701-mmsys",
> > + .data = (void *) MMSYS_MT2701,
> > + },
> > + { /* sentinel */ },
> > +};
> > +
> > +static struct platform_driver mmsys_drv = {
> > + .probe = mmsys_probe,
> > + .driver = {
> > + .name = "mediatek-mmysys",
> > + .of_match_table = of_match_ptr(of_match_mmsys),
> > + },
> > +};
> > +
> > +builtin_platform_driver(mmsys_drv);
> > +
> > +MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver");
> > +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* [PATCH] arm64: dts: msm8916: fix Coresight ETF graph connections
From: Ivan T. Ivanov @ 2018-05-24 4:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL8qBiJUMyUEcih07UoFSAghn6Amfo8OfY-pKU-QX2_mw@mail.gmail.com>
Quoting Rob Herring (2018-05-23 23:29:29)
> On Tue, May 8, 2018 at 10:09 AM, Rob Herring <robh@kernel.org> wrote:
> > The ETF input should be connected to the funnel output, and the ETF
> > output should be connected to the replicator input. The labels are wrong
> > and these got swapped:
> >
> > Warning (graph_endpoint): /soc/funnel at 821000/ports/port at 8/endpoint: graph connection to node '/soc/etf at 825000/ports/port at 1/endpoint' is not bidirectional
> > Warning (graph_endpoint): /soc/replicator at 824000/ports/port at 2/endpoint: graph connection to node '/soc/etf at 825000/ports/port at 0/endpoint' is not bidirectional
> >
> > Fixes: 7c10da373698 ("arm64: dts: qcom: Add msm8916 CoreSight components")
> > Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org>
> > Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> > Cc: Andy Gross <andy.gross@linaro.org>
> > Cc: David Brown <david.brown@linaro.org>
> > Cc: linux-arm-msm at vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Ping. Still seeing warnings in -next for these.
>
Hi Rob,
I no longer have access to this hardware and documentation.
I am sure that Mathieu and friends will take care for verification
of this patch :-)
Regards,
Ivan
^ permalink raw reply
* [PATCH] arm64: dts: sprd: fix typo in 'remote-endpoint'
From: Baolin Wang @ 2018-05-24 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKrsTpgnLfxhcxeucpoh9NkyGwwZq82QUBgJZrdjGYQzg@mail.gmail.com>
On 24 May 2018 at 04:30, Rob Herring <robh@kernel.org> wrote:
> On Tue, May 8, 2018 at 8:58 PM, Chunyan Zhang <zhang.lyra@gmail.com> wrote:
>> Hi Rob,
>>
>> On 8 May 2018 at 23:09, Rob Herring <robh@kernel.org> wrote:
>>> dtc now warns on incomplete OF graph endpoint connections:
>>>
>>> arch/arm64/boot/dts/sprd/sp9860g-1h10.dtb: Warning (graph_endpoint): /soc/stm at 10006000/port/endpoint: graph connection to node '/soc/funnel at 10001000/ports/port at 2/endpoint' is not bidirectional
>>>
>>> The cause is a typo in 'remote-endpoint'.
>>
>> Thanks for fixing this and,
>>
>> Acked-by: Chunyan Zhang <zhang.lyra@gmail.com>
>
> Is someone going to apply this? Still seeing warnings in linux-next.
I think Arnd will pick up this patch.
--
Baolin.wang
Best Regards
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Tomi Valkeinen @ 2018-05-24 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523220254.GD2299@darkstar.musicnaut.iki.fi>
On 24/05/18 01:02, Aaro Koskinen wrote:
> But turns out that omapdrm tree is unbisectable, as I get build failures such
> as (commit 28d79f3e56b2c1d5ff0fd363da3229be0962cc85):
>
> /home/aaro/git/devel/linux/drivers/gpu/drm/omapdrm/dss/dss.c:1473:52: error: undefined identifier 'dss_debug_dump_clocks'
> /home/aaro/git/devel/linux/drivers/gpu/drm/omapdrm/dss/dss.c:1472:51: warning: callwith no type!
This goes away if you enable CONFIG_OMAP2_DSS_DEBUGFS.
> In file included from /home/aaro/git/devel/linux/drivers/gpu/drm/omapdrm/dss/core.c:28:0:
> /home/aaro/git/devel/linux/drivers/gpu/drm/omapdrm/dss/dss.h:395:25: error: conflicting types for 'port'
> struct device_node *port,
> ^~~~
And this goes away if you enable CONFIG_OMAP2_DSS_DPI.
Sorry about those.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [rjarzmik:test/daniel 23/34] sound/arm/pxa2xx-ac97.c:27:10: fatal error: mach/regs-ac97.h: No such file or directory
From: Robert Jarzmik @ 2018-05-24 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <831EE4E5E37DCC428EB295A351E662494CB32366@shsmsx102.ccr.corp.intel.com>
"Li, Philip" <philip.li@intel.com> writes:
>> Is it possible to exclude a pattern instead ?
>> I mean would it be possible to exclude each branch of the form "test/*" ?
> sure, we will use test/.* to match the branch to exclude.
That's great, thanks a lot.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v9 3/4] arm64: Implement page table free interfaces
From: Chintan Pandya @ 2018-05-24 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527085967.14039.10.camel@hpe.com>
On 5/23/2018 8:04 PM, Kani, Toshi wrote:
> On Wed, 2018-05-23 at 15:01 +0100, Will Deacon wrote:
>> Hi Chintan,
>>
>> [as a side note: I'm confused on the status of this patch series, as part
>> of it was reposted separately by Toshi. Please can you work together?]
>
> I do not know the status of my patch series, either... That being said,
> I made my x86 patches based off from Chintan's 1/4 patch (which changes
> both x86 and arm) so that my series won't conflict with his.
>
> Chintan,
Hi Toshi,
> If you need to update your series before mine's accepted, please make
> sure to use the updated 1/4 below. I've updated the descriptions per
> review comment.
> https://patchwork.kernel.org/patch/10407065/
For the sake of completeness, I will re-push my previous 1/4 but will
take your version of change log. I've seen this and your change log
describes the change better.
>
> Thanks,
> -Toshi
>
Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply
* [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd
From: Ulf Hansson @ 2018-05-24 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3838f17a-2ac8-bf3f-f0b1-f69bbe17629c@nvidia.com>
On 23 May 2018 at 11:07, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 23/05/18 07:12, Ulf Hansson wrote:
>
> ...
>
>
>>>>>> Thanks for sending this. Believe it or not this has still been on my
>>>>>> to-do list
>>>>>> and so we definitely need a solution for Tegra.
>>>>>>
>>>>>> Looking at the above it appears that additional power-domains exposed
>>>>>> as devices
>>>>>> to the client device. So I assume that this means that the drivers for
>>>>>> devices
>>>>>> with multiple power-domains will need to call RPM APIs for each of
>>>>>> these
>>>>>> additional power-domains. Is that correct?
>>>>>
>>>>>
>>>>> They can, but should not!
>>>>>
>>>>> Instead, the driver shall use device_link_add() and device_link_del(),
>>>>> dynamically, depending on what PM domain that their original device
>>>>> needs for the current running use case.
>>>>>
>>>>> In that way, they keep existing runtime PM deployment, operating on
>>>>> its original device.
>>>>
>>>>
>>>> OK, sounds good. Any reason why the linking cannot be handled by the
>>>> above API? Is there a use-case where you would not want it linked?
>>>
>>>
>>> I am guessing the linking is what would give the driver the ability to
>>> decide which subset of powerdomains it actually wants to control
>>> at any point using runtime PM. If we have cases wherein the driver would
>>> want to turn on/off _all_ its associated powerdomains _always_
>>> then a default linking of all would help.
>>
>>
>> First, I think we need to decide on *where* the linking should be
>> done, not at both places, as that would just mess up synchronization
>> of who is responsible for calling the device_link_del() at detach.
>>
>> Second, It would in principle be fine to call device_link_add() and
>> device_link_del() as a part of the attach/detach APIs. However, there
>> is a downside to such solution, which would be that the driver then
>> needs call the detach API, just to do device_link_del(). Of course
>> then it would also needs to call the attach API later if/when needed.
>> Doing this adds unnecessary overhead - comparing to just let the
>> driver call device_link_add|del() when needed. On the upside, yes, it
>> would put less burden on the drivers as it then only needs to care
>> about using one set of functions.
>>
>> Which solution do you prefer?
>
>
> Any reason why we could not add a 'boolean' argument to the API to indicate
> whether the new device should be linked? I think that I prefer the API
> handles it, but I can see there could be instances where drivers may wish to
> handle it themselves.
Coming back to this question. Both Tegra XUSB and Qcom Camera use
case, would benefit from doing the linking themselves, as it needs
different PM domains to be powered on depending on the current use
case - as to avoid wasting power.
However, I can understand that you prefer some simplicity over
optimizations, as you told us. Then, does it mean that you are
insisting on extending the APIs with a boolean for linking, or are you
fine with the driver to call device_link_add()?
[...]
Kind regards
Uffe
^ permalink raw reply
* [PATCH v2 00/13] ARM: pxa: switch to DMA slave maps
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
This v1 cover letter is quoted in [1].
For maintainers the table below should help you focus on the patches targetted at you, and ignore the other noise.
The differences since v1 is by maintainers / topic / patch :
- Arnd and Daniel / PXA topic / 0002
devices.c split into pxa25x.c, pxa27x.c and pxa3xx.c
- Boris and Daniel / MTD topic / 0005
Review and ack of this one
- Arnd and netdev / NET topic / 0006 and 0007
Arnd comment taken, review and ack of these one
- Mark and alsa-devel / ASoC topic / 0008
Mark, I couldn't keep your former Ack because :
- I changed one line so that the cpu device provides the DMA
- I added pxa2xx-i2s which was forgotten
Therefore I need a new ack
- Arnd and Daniel / SSP topic / 0013
Review and ack of this one
Happy review.
--
Robert
Robert Jarzmik (13):
dmaengine: pxa: use a dma slave map
ARM: pxa: add dma slave map
mmc: pxamci: remove the dmaengine compat need
media: pxa_camera: remove the dmaengine compat need
mtd: rawnand: marvell: remove the dmaengine compat need
net: smc911x: remove the dmaengine compat need
net: smc91x: remove the dmaengine compat need
ASoC: pxa: remove the dmaengine compat need
ata: pata_pxa: remove the dmaengine compat need
dmaengine: pxa: document pxad_param
dmaengine: pxa: make the filter function internal
ARM: pxa: remove the DMA IO resources
ARM: pxa: change SSP DMA channels allocation
arch/arm/mach-pxa/devices.c | 148 +---------------------------------
arch/arm/mach-pxa/devices.h | 6 +-
arch/arm/mach-pxa/pxa25x.c | 41 +++++++++-
arch/arm/mach-pxa/pxa27x.c | 42 +++++++++-
arch/arm/mach-pxa/pxa3xx.c | 44 +++++++++-
arch/arm/plat-pxa/ssp.c | 47 -----------
drivers/ata/pata_pxa.c | 10 +--
drivers/dma/pxa_dma.c | 13 ++-
drivers/media/platform/pxa_camera.c | 22 +----
drivers/mmc/host/pxamci.c | 29 +------
drivers/mtd/nand/raw/marvell_nand.c | 17 +---
drivers/net/ethernet/smsc/smc911x.c | 16 +---
drivers/net/ethernet/smsc/smc91x.c | 12 +--
drivers/net/ethernet/smsc/smc91x.h | 1 -
include/linux/dma/pxa-dma.h | 20 +++--
include/linux/platform_data/mmp_dma.h | 4 +
include/linux/pxa2xx_ssp.h | 2 -
sound/arm/pxa2xx-ac97.c | 14 +---
sound/arm/pxa2xx-pcm-lib.c | 6 +-
sound/soc/pxa/pxa-ssp.c | 5 +-
sound/soc/pxa/pxa2xx-ac97.c | 32 ++------
sound/soc/pxa/pxa2xx-i2s.c | 6 +-
22 files changed, 180 insertions(+), 357 deletions(-)
--
2.11.0
---
[1] Former v1 cover letter
This serie is aimed at removing the dmaengine slave compat use, and transfer
knowledge of the DMA requestors into architecture code.
This was discussed/advised by Arnd a couple of years back, it's almost time.
The serie is divided in 3 phasees :
- phase 1 : patch 1/15 and patch 2/15
=> this is the preparation work
- phase 2 : patches 3/15 .. 10/15
=> this is the switch of all the drivers
=> this one will require either an Ack of the maintainers or be taken by them
once phase 1 is merged
- phase 3 : patches 11/15
=> this is the last part, cleanup and removal of export of the DMA filter
function
As this looks like a patch bomb, each maintainer expressing for his tree either
an Ack or "I want to take through my tree" will be spared in the next iterations
of this serie.
Several of these changes have been tested on actual hardware, including :
- pxamci
- pxa_camera
- smc*
- ASoC and SSP
^ permalink raw reply
* [PATCH v2 01/13] dmaengine: pxa: use a dma slave map
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
In order to remove the specific knowledge of the dma mapping from PXA
drivers, add a default slave map for pxa architectures.
This won't impact MMP architecture, but is aimed only at all PXA boards.
This is the first step, and once all drivers are converted,
pxad_filter_fn() will be made static, and the DMA resources removed from
device.c.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/pxa_dma.c | 10 +++++++++-
include/linux/platform_data/mmp_dma.h | 4 ++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index b53fb618bbf6..9505334f9c6e 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -179,6 +179,8 @@ static unsigned int pxad_drcmr(unsigned int line)
return 0x1000 + line * 4;
}
+bool pxad_filter_fn(struct dma_chan *chan, void *param);
+
/*
* Debug fs
*/
@@ -1396,9 +1398,10 @@ static int pxad_probe(struct platform_device *op)
{
struct pxad_device *pdev;
const struct of_device_id *of_id;
+ const struct dma_slave_map *slave_map = NULL;
struct mmp_dma_platdata *pdata = dev_get_platdata(&op->dev);
struct resource *iores;
- int ret, dma_channels = 0, nb_requestors = 0;
+ int ret, dma_channels = 0, nb_requestors = 0, slave_map_cnt = 0;
const enum dma_slave_buswidth widths =
DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES |
DMA_SLAVE_BUSWIDTH_4_BYTES;
@@ -1429,6 +1432,8 @@ static int pxad_probe(struct platform_device *op)
} else if (pdata && pdata->dma_channels) {
dma_channels = pdata->dma_channels;
nb_requestors = pdata->nb_requestors;
+ slave_map = pdata->slave_map;
+ slave_map_cnt = pdata->slave_map_cnt;
} else {
dma_channels = 32; /* default 32 channel */
}
@@ -1440,6 +1445,9 @@ static int pxad_probe(struct platform_device *op)
pdev->slave.device_prep_dma_memcpy = pxad_prep_memcpy;
pdev->slave.device_prep_slave_sg = pxad_prep_slave_sg;
pdev->slave.device_prep_dma_cyclic = pxad_prep_dma_cyclic;
+ pdev->slave.filter.map = slave_map;
+ pdev->slave.filter.mapcnt = slave_map_cnt;
+ pdev->slave.filter.fn = pxad_filter_fn;
pdev->slave.copy_align = PDMA_ALIGNMENT;
pdev->slave.src_addr_widths = widths;
diff --git a/include/linux/platform_data/mmp_dma.h b/include/linux/platform_data/mmp_dma.h
index d1397c8ed94e..6397b9c8149a 100644
--- a/include/linux/platform_data/mmp_dma.h
+++ b/include/linux/platform_data/mmp_dma.h
@@ -12,9 +12,13 @@
#ifndef MMP_DMA_H
#define MMP_DMA_H
+struct dma_slave_map;
+
struct mmp_dma_platdata {
int dma_channels;
int nb_requestors;
+ int slave_map_cnt;
+ const struct dma_slave_map *slave_map;
};
#endif /* MMP_DMA_H */
--
2.11.0
^ permalink raw reply related
* [PATCH v2 02/13] ARM: pxa: add dma slave map
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
In order to remove the specific knowledge of the dma mapping from PXA
drivers, add a default slave map for pxa architectures.
This is the first step, and once all drivers are converted,
pxad_filter_fn() will be made static, and the DMA resources removed from
device.c.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Reported-by: Arnd Bergmann <arnd@arndb.de>
---
Since v1: revamped the SSP part, split into pxa25.c, pxa27x.c and
pxa3xx.c, and add pxa-i2s.
---
arch/arm/mach-pxa/devices.c | 12 +++---------
arch/arm/mach-pxa/devices.h | 6 +++++-
arch/arm/mach-pxa/pxa25x.c | 41 ++++++++++++++++++++++++++++++++++++++++-
arch/arm/mach-pxa/pxa27x.c | 42 +++++++++++++++++++++++++++++++++++++++++-
arch/arm/mach-pxa/pxa3xx.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
5 files changed, 132 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index d7c9a8476d57..1e8915fc340d 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -4,6 +4,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
#include <linux/spi/pxa2xx_spi.h>
#include <linux/platform_data/i2c-pxa.h>
@@ -1202,11 +1203,6 @@ void __init pxa2xx_set_spi_info(unsigned id, struct pxa2xx_spi_master *info)
platform_device_add(pd);
}
-static struct mmp_dma_platdata pxa_dma_pdata = {
- .dma_channels = 0,
- .nb_requestors = 0,
-};
-
static struct resource pxa_dma_resource[] = {
[0] = {
.start = 0x40000000,
@@ -1233,9 +1229,7 @@ static struct platform_device pxa2xx_pxa_dma = {
.resource = pxa_dma_resource,
};
-void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors)
+void __init pxa2xx_set_dmac_info(struct mmp_dma_platdata *dma_pdata)
{
- pxa_dma_pdata.dma_channels = nb_channels;
- pxa_dma_pdata.nb_requestors = nb_requestors;
- pxa_register_device(&pxa2xx_pxa_dma, &pxa_dma_pdata);
+ pxa_register_device(&pxa2xx_pxa_dma, dma_pdata);
}
diff --git a/arch/arm/mach-pxa/devices.h b/arch/arm/mach-pxa/devices.h
index 11263f7c455b..498b07bc6a3e 100644
--- a/arch/arm/mach-pxa/devices.h
+++ b/arch/arm/mach-pxa/devices.h
@@ -1,4 +1,8 @@
/* SPDX-License-Identifier: GPL-2.0 */
+#define PDMA_FILTER_PARAM(_prio, _requestor) (&(struct pxad_param) { \
+ .prio = PXAD_PRIO_##_prio, .drcmr = _requestor })
+struct mmp_dma_platdata;
+
extern struct platform_device pxa_device_pmu;
extern struct platform_device pxa_device_mci;
extern struct platform_device pxa3xx_device_mci2;
@@ -55,7 +59,7 @@ extern struct platform_device pxa3xx_device_gpio;
extern struct platform_device pxa93x_device_gpio;
void __init pxa_register_device(struct platform_device *dev, void *data);
-void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors);
+void __init pxa2xx_set_dmac_info(struct mmp_dma_platdata *dma_pdata);
struct i2c_pxa_platform_data;
extern void pxa_set_i2c_info(struct i2c_pxa_platform_data *info);
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index ba431fad5c47..2d61de41a9d5 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -16,6 +16,8 @@
* initialization stuff for PXA machines which can be overridden later if
* need be.
*/
+#include <linux/dmaengine.h>
+#include <linux/dma/pxa-dma.h>
#include <linux/gpio.h>
#include <linux/gpio-pxa.h>
#include <linux/module.h>
@@ -26,6 +28,7 @@
#include <linux/syscore_ops.h>
#include <linux/irq.h>
#include <linux/irqchip.h>
+#include <linux/platform_data/mmp_dma.h>
#include <asm/mach/map.h>
#include <asm/suspend.h>
@@ -201,6 +204,42 @@ static struct platform_device *pxa25x_devices[] __initdata = {
&pxa_device_asoc_platform,
};
+static const struct dma_slave_map pxa25x_slave_map[] = {
+ /* PXA25x, PXA27x and PXA3xx common entries */
+ { "pxa2xx-ac97", "pcm_pcm_mic_mono", PDMA_FILTER_PARAM(LOWEST, 8) },
+ { "pxa2xx-ac97", "pcm_pcm_aux_mono_in", PDMA_FILTER_PARAM(LOWEST, 9) },
+ { "pxa2xx-ac97", "pcm_pcm_aux_mono_out",
+ PDMA_FILTER_PARAM(LOWEST, 10) },
+ { "pxa2xx-ac97", "pcm_pcm_stereo_in", PDMA_FILTER_PARAM(LOWEST, 11) },
+ { "pxa2xx-ac97", "pcm_pcm_stereo_out", PDMA_FILTER_PARAM(LOWEST, 12) },
+ { "pxa-ssp-dai.1", "rx", PDMA_FILTER_PARAM(LOWEST, 13) },
+ { "pxa-ssp-dai.1", "tx", PDMA_FILTER_PARAM(LOWEST, 14) },
+ { "pxa-ssp-dai.2", "rx", PDMA_FILTER_PARAM(LOWEST, 15) },
+ { "pxa-ssp-dai.2", "tx", PDMA_FILTER_PARAM(LOWEST, 16) },
+ { "pxa2xx-ir", "rx", PDMA_FILTER_PARAM(LOWEST, 17) },
+ { "pxa2xx-ir", "tx", PDMA_FILTER_PARAM(LOWEST, 18) },
+ { "pxa2xx-mci.0", "rx", PDMA_FILTER_PARAM(LOWEST, 21) },
+ { "pxa2xx-mci.0", "tx", PDMA_FILTER_PARAM(LOWEST, 22) },
+ { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
+ { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
+ { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
+
+ /* PXA25x specific map */
+ { "pxa25x-ssp.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) },
+ { "pxa25x-ssp.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) },
+ { "pxa25x-nssp.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) },
+ { "pxa25x-nssp.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) },
+ { "pxa25x-nssp.2", "rx", PDMA_FILTER_PARAM(LOWEST, 23) },
+ { "pxa25x-nssp.2", "tx", PDMA_FILTER_PARAM(LOWEST, 24) },
+};
+
+static struct mmp_dma_platdata pxa25x_dma_pdata = {
+ .dma_channels = 16,
+ .nb_requestors = 40,
+ .slave_map = pxa25x_slave_map,
+ .slave_map_cnt = ARRAY_SIZE(pxa25x_slave_map),
+};
+
static int __init pxa25x_init(void)
{
int ret = 0;
@@ -215,7 +254,7 @@ static int __init pxa25x_init(void)
register_syscore_ops(&pxa2xx_mfp_syscore_ops);
if (!of_have_populated_dt()) {
- pxa2xx_set_dmac_info(16, 40);
+ pxa2xx_set_dmac_info(&pxa25x_dma_pdata);
pxa_register_device(&pxa25x_device_gpio, &pxa25x_gpio_info);
ret = platform_add_devices(pxa25x_devices,
ARRAY_SIZE(pxa25x_devices));
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 0c06f383ad52..b44e3c4f3013 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -11,6 +11,8 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include <linux/dmaengine.h>
+#include <linux/dma/pxa-dma.h>
#include <linux/gpio.h>
#include <linux/gpio-pxa.h>
#include <linux/module.h>
@@ -23,6 +25,7 @@
#include <linux/io.h>
#include <linux/irq.h>
#include <linux/platform_data/i2c-pxa.h>
+#include <linux/platform_data/mmp_dma.h>
#include <asm/mach/map.h>
#include <mach/hardware.h>
@@ -297,6 +300,43 @@ static struct platform_device *devices[] __initdata = {
&pxa27x_device_pwm1,
};
+static const struct dma_slave_map pxa27x_slave_map[] = {
+ /* PXA25x, PXA27x and PXA3xx common entries */
+ { "pxa2xx-ac97", "pcm_pcm_mic_mono", PDMA_FILTER_PARAM(LOWEST, 8) },
+ { "pxa2xx-ac97", "pcm_pcm_aux_mono_in", PDMA_FILTER_PARAM(LOWEST, 9) },
+ { "pxa2xx-ac97", "pcm_pcm_aux_mono_out",
+ PDMA_FILTER_PARAM(LOWEST, 10) },
+ { "pxa2xx-ac97", "pcm_pcm_stereo_in", PDMA_FILTER_PARAM(LOWEST, 11) },
+ { "pxa2xx-ac97", "pcm_pcm_stereo_out", PDMA_FILTER_PARAM(LOWEST, 12) },
+ { "pxa-ssp-dai.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) },
+ { "pxa-ssp-dai.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) },
+ { "pxa-ssp-dai.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) },
+ { "pxa-ssp-dai.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) },
+ { "pxa2xx-ir", "rx", PDMA_FILTER_PARAM(LOWEST, 17) },
+ { "pxa2xx-ir", "tx", PDMA_FILTER_PARAM(LOWEST, 18) },
+ { "pxa2xx-mci.0", "rx", PDMA_FILTER_PARAM(LOWEST, 21) },
+ { "pxa2xx-mci.0", "tx", PDMA_FILTER_PARAM(LOWEST, 22) },
+ { "pxa-ssp-dai.2", "rx", PDMA_FILTER_PARAM(LOWEST, 66) },
+ { "pxa-ssp-dai.2", "tx", PDMA_FILTER_PARAM(LOWEST, 67) },
+ { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
+ { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
+ { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
+
+ /* PXA27x specific map */
+ { "pxa2xx-i2s", "rx", PDMA_FILTER_PARAM(LOWEST, 2) },
+ { "pxa2xx-i2s", "tx", PDMA_FILTER_PARAM(LOWEST, 3) },
+ { "pxa27x-camera.0", "CI_Y", PDMA_FILTER_PARAM(HIGHEST, 68) },
+ { "pxa27x-camera.0", "CI_U", PDMA_FILTER_PARAM(HIGHEST, 69) },
+ { "pxa27x-camera.0", "CI_V", PDMA_FILTER_PARAM(HIGHEST, 70) },
+};
+
+static struct mmp_dma_platdata pxa27x_dma_pdata = {
+ .dma_channels = 32,
+ .nb_requestors = 75,
+ .slave_map = pxa27x_slave_map,
+ .slave_map_cnt = ARRAY_SIZE(pxa27x_slave_map),
+};
+
static int __init pxa27x_init(void)
{
int ret = 0;
@@ -313,7 +353,7 @@ static int __init pxa27x_init(void)
if (!of_have_populated_dt()) {
pxa_register_device(&pxa27x_device_gpio,
&pxa27x_gpio_info);
- pxa2xx_set_dmac_info(32, 75);
+ pxa2xx_set_dmac_info(&pxa27x_dma_pdata);
ret = platform_add_devices(devices,
ARRAY_SIZE(devices));
}
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index 4b8a0df8ea57..b5ca4be093ec 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -12,6 +12,8 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include <linux/dmaengine.h>
+#include <linux/dma/pxa-dma.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
@@ -24,6 +26,7 @@
#include <linux/of.h>
#include <linux/syscore_ops.h>
#include <linux/platform_data/i2c-pxa.h>
+#include <linux/platform_data/mmp_dma.h>
#include <asm/mach/map.h>
#include <asm/suspend.h>
@@ -421,6 +424,45 @@ static struct platform_device *devices[] __initdata = {
&pxa27x_device_pwm1,
};
+static const struct dma_slave_map pxa3xx_slave_map[] = {
+ /* PXA25x, PXA27x and PXA3xx common entries */
+ { "pxa2xx-ac97", "pcm_pcm_mic_mono", PDMA_FILTER_PARAM(LOWEST, 8) },
+ { "pxa2xx-ac97", "pcm_pcm_aux_mono_in", PDMA_FILTER_PARAM(LOWEST, 9) },
+ { "pxa2xx-ac97", "pcm_pcm_aux_mono_out",
+ PDMA_FILTER_PARAM(LOWEST, 10) },
+ { "pxa2xx-ac97", "pcm_pcm_stereo_in", PDMA_FILTER_PARAM(LOWEST, 11) },
+ { "pxa2xx-ac97", "pcm_pcm_stereo_out", PDMA_FILTER_PARAM(LOWEST, 12) },
+ { "pxa-ssp-dai.0", "rx", PDMA_FILTER_PARAM(LOWEST, 13) },
+ { "pxa-ssp-dai.0", "tx", PDMA_FILTER_PARAM(LOWEST, 14) },
+ { "pxa-ssp-dai.1", "rx", PDMA_FILTER_PARAM(LOWEST, 15) },
+ { "pxa-ssp-dai.1", "tx", PDMA_FILTER_PARAM(LOWEST, 16) },
+ { "pxa2xx-ir", "rx", PDMA_FILTER_PARAM(LOWEST, 17) },
+ { "pxa2xx-ir", "tx", PDMA_FILTER_PARAM(LOWEST, 18) },
+ { "pxa2xx-mci.0", "rx", PDMA_FILTER_PARAM(LOWEST, 21) },
+ { "pxa2xx-mci.0", "tx", PDMA_FILTER_PARAM(LOWEST, 22) },
+ { "pxa-ssp-dai.2", "rx", PDMA_FILTER_PARAM(LOWEST, 66) },
+ { "pxa-ssp-dai.2", "tx", PDMA_FILTER_PARAM(LOWEST, 67) },
+ { "smc911x.0", "rx", PDMA_FILTER_PARAM(LOWEST, -1) },
+ { "smc911x.0", "tx", PDMA_FILTER_PARAM(LOWEST, -1) },
+ { "smc91x.0", "data", PDMA_FILTER_PARAM(LOWEST, -1) },
+
+ /* PXA3xx specific map */
+ { "pxa-ssp-dai.3", "rx", PDMA_FILTER_PARAM(LOWEST, 2) },
+ { "pxa-ssp-dai.3", "tx", PDMA_FILTER_PARAM(LOWEST, 3) },
+ { "pxa2xx-mci.1", "rx", PDMA_FILTER_PARAM(LOWEST, 93) },
+ { "pxa2xx-mci.1", "tx", PDMA_FILTER_PARAM(LOWEST, 94) },
+ { "pxa3xx-nand", "data", PDMA_FILTER_PARAM(LOWEST, 97) },
+ { "pxa2xx-mci.2", "rx", PDMA_FILTER_PARAM(LOWEST, 100) },
+ { "pxa2xx-mci.2", "tx", PDMA_FILTER_PARAM(LOWEST, 101) },
+};
+
+static struct mmp_dma_platdata pxa3xx_dma_pdata = {
+ .dma_channels = 32,
+ .nb_requestors = 100,
+ .slave_map = pxa3xx_slave_map,
+ .slave_map_cnt = ARRAY_SIZE(pxa3xx_slave_map),
+};
+
static int __init pxa3xx_init(void)
{
int ret = 0;
@@ -452,7 +494,7 @@ static int __init pxa3xx_init(void)
if (of_have_populated_dt())
return 0;
- pxa2xx_set_dmac_info(32, 100);
+ pxa2xx_set_dmac_info(&pxa3xx_dma_pdata);
ret = platform_add_devices(devices, ARRAY_SIZE(devices));
if (ret)
return ret;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 03/13] mmc: pxamci: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/mmc/host/pxamci.c | 29 +++--------------------------
1 file changed, 3 insertions(+), 26 deletions(-)
diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index c763b404510f..6c94474e36f4 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -24,7 +24,6 @@
#include <linux/interrupt.h>
#include <linux/dmaengine.h>
#include <linux/dma-mapping.h>
-#include <linux/dma/pxa-dma.h>
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/mmc/host.h>
@@ -637,10 +636,8 @@ static int pxamci_probe(struct platform_device *pdev)
{
struct mmc_host *mmc;
struct pxamci_host *host = NULL;
- struct resource *r, *dmarx, *dmatx;
- struct pxad_param param_rx, param_tx;
+ struct resource *r;
int ret, irq, gpio_cd = -1, gpio_ro = -1, gpio_power = -1;
- dma_cap_mask_t mask;
ret = pxamci_of_init(pdev);
if (ret)
@@ -739,34 +736,14 @@ static int pxamci_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mmc);
- if (!pdev->dev.of_node) {
- dmarx = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- dmatx = platform_get_resource(pdev, IORESOURCE_DMA, 1);
- if (!dmarx || !dmatx) {
- ret = -ENXIO;
- goto out;
- }
- param_rx.prio = PXAD_PRIO_LOWEST;
- param_rx.drcmr = dmarx->start;
- param_tx.prio = PXAD_PRIO_LOWEST;
- param_tx.drcmr = dmatx->start;
- }
-
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
- host->dma_chan_rx =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶m_rx, &pdev->dev, "rx");
+ host->dma_chan_rx = dma_request_slave_channel(&pdev->dev, "rx");
if (host->dma_chan_rx == NULL) {
dev_err(&pdev->dev, "unable to request rx dma channel\n");
ret = -ENODEV;
goto out;
}
- host->dma_chan_tx =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶m_tx, &pdev->dev, "tx");
+ host->dma_chan_tx = dma_request_slave_channel(&pdev->dev, "tx");
if (host->dma_chan_tx == NULL) {
dev_err(&pdev->dev, "unable to request tx dma channel\n");
ret = -ENODEV;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 04/13] media: pxa_camera: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
drivers/media/platform/pxa_camera.c | 22 +++-------------------
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c
index c71a00736541..4c82d1880753 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -2357,8 +2357,6 @@ static int pxa_camera_probe(struct platform_device *pdev)
.src_maxburst = 8,
.direction = DMA_DEV_TO_MEM,
};
- dma_cap_mask_t mask;
- struct pxad_param params;
char clk_name[V4L2_CLK_NAME_SIZE];
int irq;
int err = 0, i;
@@ -2432,34 +2430,20 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev->base = base;
/* request dma */
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
- dma_cap_set(DMA_PRIVATE, mask);
-
- params.prio = 0;
- params.drcmr = 68;
- pcdev->dma_chans[0] =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶ms, &pdev->dev, "CI_Y");
+ pcdev->dma_chans[0] = dma_request_slave_channel(&pdev->dev, "CI_Y");
if (!pcdev->dma_chans[0]) {
dev_err(&pdev->dev, "Can't request DMA for Y\n");
return -ENODEV;
}
- params.drcmr = 69;
- pcdev->dma_chans[1] =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶ms, &pdev->dev, "CI_U");
+ pcdev->dma_chans[1] = dma_request_slave_channel(&pdev->dev, "CI_U");
if (!pcdev->dma_chans[1]) {
dev_err(&pdev->dev, "Can't request DMA for Y\n");
err = -ENODEV;
goto exit_free_dma_y;
}
- params.drcmr = 70;
- pcdev->dma_chans[2] =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶ms, &pdev->dev, "CI_V");
+ pcdev->dma_chans[2] = dma_request_slave_channel(&pdev->dev, "CI_V");
if (!pcdev->dma_chans[2]) {
dev_err(&pdev->dev, "Can't request DMA for V\n");
err = -ENODEV;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 05/13] mtd: rawnand: marvell: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/mtd/nand/raw/marvell_nand.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c
index 10e953218948..f9763be078ef 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -2613,8 +2613,6 @@ static int marvell_nfc_init_dma(struct marvell_nfc *nfc)
dev);
struct dma_slave_config config = {};
struct resource *r;
- dma_cap_mask_t mask;
- struct pxad_param param;
int ret;
if (!IS_ENABLED(CONFIG_PXA_DMA)) {
@@ -2627,20 +2625,7 @@ static int marvell_nfc_init_dma(struct marvell_nfc *nfc)
if (ret)
return ret;
- r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!r) {
- dev_err(nfc->dev, "No resource defined for data DMA\n");
- return -ENXIO;
- }
-
- param.drcmr = r->start;
- param.prio = PXAD_PRIO_LOWEST;
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
- nfc->dma_chan =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶m, nfc->dev,
- "data");
+ nfc->dma_chan = dma_request_slave_channel(&nfc->dev, "data");
if (!nfc->dma_chan) {
dev_err(nfc->dev,
"Unable to request data DMA channel\n");
--
2.11.0
^ permalink raw reply related
* [PATCH v2 06/13] net: smc911x: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/net/ethernet/smsc/smc911x.c | 16 ++--------------
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
index 05157442a980..4c3713bd5caa 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -74,7 +74,6 @@ static const char version[] =
#include <linux/skbuff.h>
#include <linux/dmaengine.h>
-#include <linux/dma/pxa-dma.h>
#include <asm/io.h>
@@ -1794,8 +1793,6 @@ static int smc911x_probe(struct net_device *dev)
unsigned long irq_flags;
#ifdef SMC_USE_DMA
struct dma_slave_config config;
- dma_cap_mask_t mask;
- struct pxad_param param;
#endif
DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
@@ -1969,17 +1966,8 @@ static int smc911x_probe(struct net_device *dev)
#ifdef SMC_USE_DMA
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
- param.prio = PXAD_PRIO_LOWEST;
- param.drcmr = -1UL;
-
- lp->rxdma =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶m, &dev->dev, "rx");
- lp->txdma =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶m, &dev->dev, "tx");
+ lp->rxdma = dma_request_slave_channel(&dev->dev, "rx");
+ lp->txdma = dma_request_slave_channel(&dev->dev, "tx");
lp->rxdma_active = 0;
lp->txdma_active = 0;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 07/13] net: smc91x: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/net/ethernet/smsc/smc91x.c | 12 +-----------
drivers/net/ethernet/smsc/smc91x.h | 1 -
2 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 080428762858..4c600f430f6d 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2018,18 +2018,8 @@ static int smc_probe(struct net_device *dev, void __iomem *ioaddr,
lp->cfg.flags |= SMC91X_USE_DMA;
# endif
if (lp->cfg.flags & SMC91X_USE_DMA) {
- dma_cap_mask_t mask;
- struct pxad_param param;
-
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
- param.prio = PXAD_PRIO_LOWEST;
- param.drcmr = -1UL;
-
lp->dma_chan =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶m, &dev->dev,
- "data");
+ dma_request_slave_channel(lp->device, "data");
}
#endif
diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
index b337ee97e0c0..a27352229fc2 100644
--- a/drivers/net/ethernet/smsc/smc91x.h
+++ b/drivers/net/ethernet/smsc/smc91x.h
@@ -301,7 +301,6 @@ struct smc_local {
* as RX which can overrun memory and lose packets.
*/
#include <linux/dma-mapping.h>
-#include <linux/dma/pxa-dma.h>
#ifdef SMC_insl
#undef SMC_insl
--
2.11.0
^ permalink raw reply related
* [PATCH v2 08/13] ASoC: pxa: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
sound/arm/pxa2xx-ac97.c | 14 ++------------
sound/arm/pxa2xx-pcm-lib.c | 6 +++---
sound/soc/pxa/pxa2xx-ac97.c | 32 +++++---------------------------
sound/soc/pxa/pxa2xx-i2s.c | 6 ++----
4 files changed, 12 insertions(+), 46 deletions(-)
diff --git a/sound/arm/pxa2xx-ac97.c b/sound/arm/pxa2xx-ac97.c
index 4bc244c40f80..236a63cdaf9f 100644
--- a/sound/arm/pxa2xx-ac97.c
+++ b/sound/arm/pxa2xx-ac97.c
@@ -63,28 +63,18 @@ static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
.reset = pxa2xx_ac97_legacy_reset,
};
-static struct pxad_param pxa2xx_ac97_pcm_out_req = {
- .prio = PXAD_PRIO_LOWEST,
- .drcmr = 12,
-};
-
static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_out = {
.addr = __PREG(PCDR),
.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .chan_name = "pcm_pcm_stereo_out",
.maxburst = 32,
- .filter_data = &pxa2xx_ac97_pcm_out_req,
-};
-
-static struct pxad_param pxa2xx_ac97_pcm_in_req = {
- .prio = PXAD_PRIO_LOWEST,
- .drcmr = 11,
};
static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_in = {
.addr = __PREG(PCDR),
.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .chan_name = "pcm_pcm_stereo_in",
.maxburst = 32,
- .filter_data = &pxa2xx_ac97_pcm_in_req,
};
static struct snd_pcm *pxa2xx_ac97_pcm;
diff --git a/sound/arm/pxa2xx-pcm-lib.c b/sound/arm/pxa2xx-pcm-lib.c
index e8da3b8ee721..dcbe7ecc1835 100644
--- a/sound/arm/pxa2xx-pcm-lib.c
+++ b/sound/arm/pxa2xx-pcm-lib.c
@@ -125,9 +125,9 @@ int __pxa2xx_pcm_open(struct snd_pcm_substream *substream)
if (ret < 0)
return ret;
- return snd_dmaengine_pcm_open_request_chan(substream,
- pxad_filter_fn,
- dma_params->filter_data);
+ return snd_dmaengine_pcm_open(
+ substream, dma_request_slave_channel(rtd->cpu_dai->dev,
+ dma_params->chan_name));
}
EXPORT_SYMBOL(__pxa2xx_pcm_open);
diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c
index 803818aabee9..1b41c0f2a8fb 100644
--- a/sound/soc/pxa/pxa2xx-ac97.c
+++ b/sound/soc/pxa/pxa2xx-ac97.c
@@ -68,61 +68,39 @@ static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
.reset = pxa2xx_ac97_cold_reset,
};
-static struct pxad_param pxa2xx_ac97_pcm_stereo_in_req = {
- .prio = PXAD_PRIO_LOWEST,
- .drcmr = 11,
-};
-
static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_stereo_in = {
.addr = __PREG(PCDR),
.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .chan_name = "pcm_pcm_stereo_in",
.maxburst = 32,
- .filter_data = &pxa2xx_ac97_pcm_stereo_in_req,
-};
-
-static struct pxad_param pxa2xx_ac97_pcm_stereo_out_req = {
- .prio = PXAD_PRIO_LOWEST,
- .drcmr = 12,
};
static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_stereo_out = {
.addr = __PREG(PCDR),
.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .chan_name = "pcm_pcm_stereo_out",
.maxburst = 32,
- .filter_data = &pxa2xx_ac97_pcm_stereo_out_req,
};
-static struct pxad_param pxa2xx_ac97_pcm_aux_mono_out_req = {
- .prio = PXAD_PRIO_LOWEST,
- .drcmr = 10,
-};
static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_aux_mono_out = {
.addr = __PREG(MODR),
.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
+ .chan_name = "pcm_aux_mono_out",
.maxburst = 16,
- .filter_data = &pxa2xx_ac97_pcm_aux_mono_out_req,
};
-static struct pxad_param pxa2xx_ac97_pcm_aux_mono_in_req = {
- .prio = PXAD_PRIO_LOWEST,
- .drcmr = 9,
-};
static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_aux_mono_in = {
.addr = __PREG(MODR),
.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
+ .chan_name = "pcm_aux_mono_in",
.maxburst = 16,
- .filter_data = &pxa2xx_ac97_pcm_aux_mono_in_req,
};
-static struct pxad_param pxa2xx_ac97_pcm_aux_mic_mono_req = {
- .prio = PXAD_PRIO_LOWEST,
- .drcmr = 8,
-};
static struct snd_dmaengine_dai_dma_data pxa2xx_ac97_pcm_mic_mono_in = {
.addr = __PREG(MCDR),
.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
+ .chan_name = "pcm_aux_mic_mono",
.maxburst = 16,
- .filter_data = &pxa2xx_ac97_pcm_aux_mic_mono_req,
};
static int pxa2xx_ac97_hifi_startup(struct snd_pcm_substream *substream,
diff --git a/sound/soc/pxa/pxa2xx-i2s.c b/sound/soc/pxa/pxa2xx-i2s.c
index 3fb60baf6eab..e7184de0de04 100644
--- a/sound/soc/pxa/pxa2xx-i2s.c
+++ b/sound/soc/pxa/pxa2xx-i2s.c
@@ -82,20 +82,18 @@ static struct pxa_i2s_port pxa_i2s;
static struct clk *clk_i2s;
static int clk_ena = 0;
-static unsigned long pxa2xx_i2s_pcm_stereo_out_req = 3;
static struct snd_dmaengine_dai_dma_data pxa2xx_i2s_pcm_stereo_out = {
.addr = __PREG(SADR),
.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .chan_name = "tx",
.maxburst = 32,
- .filter_data = &pxa2xx_i2s_pcm_stereo_out_req,
};
-static unsigned long pxa2xx_i2s_pcm_stereo_in_req = 2;
static struct snd_dmaengine_dai_dma_data pxa2xx_i2s_pcm_stereo_in = {
.addr = __PREG(SADR),
.addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES,
+ .chan_name = "rx",
.maxburst = 32,
- .filter_data = &pxa2xx_i2s_pcm_stereo_in_req,
};
static int pxa2xx_i2s_startup(struct snd_pcm_substream *substream,
--
2.11.0
^ permalink raw reply related
* [PATCH v2 09/13] ata: pata_pxa: remove the dmaengine compat need
From: Robert Jarzmik @ 2018-05-24 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the pxa architecture switched towards the dmaengine slave map, the
old compatibility mechanism to acquire the dma requestor line number and
priority are not needed anymore.
This patch simplifies the dma resource acquisition, using the more
generic function dma_request_slave_channel().
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
drivers/ata/pata_pxa.c | 10 +---------
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/ata/pata_pxa.c b/drivers/ata/pata_pxa.c
index f6c46e9a4dc0..e8b6a2e464c9 100644
--- a/drivers/ata/pata_pxa.c
+++ b/drivers/ata/pata_pxa.c
@@ -25,7 +25,6 @@
#include <linux/libata.h>
#include <linux/platform_device.h>
#include <linux/dmaengine.h>
-#include <linux/dma/pxa-dma.h>
#include <linux/gpio.h>
#include <linux/slab.h>
#include <linux/completion.h>
@@ -180,8 +179,6 @@ static int pxa_ata_probe(struct platform_device *pdev)
struct resource *irq_res;
struct pata_pxa_pdata *pdata = dev_get_platdata(&pdev->dev);
struct dma_slave_config config;
- dma_cap_mask_t mask;
- struct pxad_param param;
int ret = 0;
/*
@@ -278,10 +275,6 @@ static int pxa_ata_probe(struct platform_device *pdev)
ap->private_data = data;
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
- param.prio = PXAD_PRIO_LOWEST;
- param.drcmr = pdata->dma_dreq;
memset(&config, 0, sizeof(config));
config.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
config.dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
@@ -294,8 +287,7 @@ static int pxa_ata_probe(struct platform_device *pdev)
* Request the DMA channel
*/
data->dma_chan =
- dma_request_slave_channel_compat(mask, pxad_filter_fn,
- ¶m, &pdev->dev, "data");
+ dma_request_slave_channel(&pdev->dev, "data");
if (!data->dma_chan)
return -EBUSY;
ret = dmaengine_slave_config(data->dma_chan, &config);
--
2.11.0
^ permalink raw reply related
* [PATCH v2 10/13] dmaengine: pxa: document pxad_param
From: Robert Jarzmik @ 2018-05-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
Add some documentation for the pxad_param structure, and describe the
contract behind the minimal required priority of a DMA channel.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
include/linux/dma/pxa-dma.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/linux/dma/pxa-dma.h b/include/linux/dma/pxa-dma.h
index e56ec7af4fd7..9fc594f69eff 100644
--- a/include/linux/dma/pxa-dma.h
+++ b/include/linux/dma/pxa-dma.h
@@ -9,6 +9,15 @@ enum pxad_chan_prio {
PXAD_PRIO_LOWEST,
};
+/**
+ * struct pxad_param - dma channel request parameters
+ * @drcmr: requestor line number
+ * @prio: minimal mandatory priority of the channel
+ *
+ * If a requested channel is granted, its priority will be at least @prio,
+ * ie. if PXAD_PRIO_LOW is required, the requested channel will be either
+ * PXAD_PRIO_LOW, PXAD_PRIO_NORMAL or PXAD_PRIO_HIGHEST.
+ */
struct pxad_param {
unsigned int drcmr;
enum pxad_chan_prio prio;
--
2.11.0
^ permalink raw reply related
* [PATCH v2 11/13] dmaengine: pxa: make the filter function internal
From: Robert Jarzmik @ 2018-05-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the pxa architecture and all its related drivers do not rely anymore
on the filter function, thanks to the slave map conversion, make
pxad_filter_fn() static, and remove it from the global namespace.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/dma/pxa_dma.c | 5 ++---
include/linux/dma/pxa-dma.h | 11 -----------
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index 9505334f9c6e..a332ad1d7dfb 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -179,7 +179,7 @@ static unsigned int pxad_drcmr(unsigned int line)
return 0x1000 + line * 4;
}
-bool pxad_filter_fn(struct dma_chan *chan, void *param);
+static bool pxad_filter_fn(struct dma_chan *chan, void *param);
/*
* Debug fs
@@ -1496,7 +1496,7 @@ static struct platform_driver pxad_driver = {
.remove = pxad_remove,
};
-bool pxad_filter_fn(struct dma_chan *chan, void *param)
+static bool pxad_filter_fn(struct dma_chan *chan, void *param)
{
struct pxad_chan *c = to_pxad_chan(chan);
struct pxad_param *p = param;
@@ -1509,7 +1509,6 @@ bool pxad_filter_fn(struct dma_chan *chan, void *param)
return true;
}
-EXPORT_SYMBOL_GPL(pxad_filter_fn);
module_platform_driver(pxad_driver);
diff --git a/include/linux/dma/pxa-dma.h b/include/linux/dma/pxa-dma.h
index 9fc594f69eff..fceb5df07097 100644
--- a/include/linux/dma/pxa-dma.h
+++ b/include/linux/dma/pxa-dma.h
@@ -23,15 +23,4 @@ struct pxad_param {
enum pxad_chan_prio prio;
};
-struct dma_chan;
-
-#ifdef CONFIG_PXA_DMA
-bool pxad_filter_fn(struct dma_chan *chan, void *param);
-#else
-static inline bool pxad_filter_fn(struct dma_chan *chan, void *param)
-{
- return false;
-}
-#endif
-
#endif /* _PXA_DMA_H_ */
--
2.11.0
^ permalink raw reply related
* [PATCH v2 12/13] ARM: pxa: remove the DMA IO resources
From: Robert Jarzmik @ 2018-05-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
As the last driver using the former mechanism to acquire the DMA
requestor line has be converted to the dma_slave_map, remove all these
resources from the PXA devices.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/devices.c | 136 --------------------------------------------
1 file changed, 136 deletions(-)
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 1e8915fc340d..5a16ea74e28a 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -60,16 +60,6 @@ static struct resource pxamci_resources[] = {
.end = IRQ_MMC,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- .start = 21,
- .end = 21,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- .start = 22,
- .end = 22,
- .flags = IORESOURCE_DMA,
- },
};
static u64 pxamci_dmamask = 0xffffffffUL;
@@ -407,16 +397,6 @@ static struct resource pxa_ir_resources[] = {
.end = 0x40700023,
.flags = IORESOURCE_MEM,
},
- [5] = {
- .start = 17,
- .end = 17,
- .flags = IORESOURCE_DMA,
- },
- [6] = {
- .start = 18,
- .end = 18,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa_device_ficp = {
@@ -545,18 +525,6 @@ static struct resource pxa25x_resource_ssp[] = {
.end = IRQ_SSP,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* DRCMR for RX */
- .start = 13,
- .end = 13,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- /* DRCMR for TX */
- .start = 14,
- .end = 14,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa25x_device_ssp = {
@@ -583,18 +551,6 @@ static struct resource pxa25x_resource_nssp[] = {
.end = IRQ_NSSP,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* DRCMR for RX */
- .start = 15,
- .end = 15,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- /* DRCMR for TX */
- .start = 16,
- .end = 16,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa25x_device_nssp = {
@@ -621,18 +577,6 @@ static struct resource pxa25x_resource_assp[] = {
.end = IRQ_ASSP,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* DRCMR for RX */
- .start = 23,
- .end = 23,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- /* DRCMR for TX */
- .start = 24,
- .end = 24,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa25x_device_assp = {
@@ -751,18 +695,6 @@ static struct resource pxa27x_resource_ssp1[] = {
.end = IRQ_SSP,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* DRCMR for RX */
- .start = 13,
- .end = 13,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- /* DRCMR for TX */
- .start = 14,
- .end = 14,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa27x_device_ssp1 = {
@@ -789,18 +721,6 @@ static struct resource pxa27x_resource_ssp2[] = {
.end = IRQ_SSP2,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* DRCMR for RX */
- .start = 15,
- .end = 15,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- /* DRCMR for TX */
- .start = 16,
- .end = 16,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa27x_device_ssp2 = {
@@ -827,18 +747,6 @@ static struct resource pxa27x_resource_ssp3[] = {
.end = IRQ_SSP3,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* DRCMR for RX */
- .start = 66,
- .end = 66,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- /* DRCMR for TX */
- .start = 67,
- .end = 67,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa27x_device_ssp3 = {
@@ -895,16 +803,6 @@ static struct resource pxa3xx_resources_mci2[] = {
.end = IRQ_MMC2,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- .start = 93,
- .end = 93,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- .start = 94,
- .end = 94,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa3xx_device_mci2 = {
@@ -934,16 +832,6 @@ static struct resource pxa3xx_resources_mci3[] = {
.end = IRQ_MMC3,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- .start = 100,
- .end = 100,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- .start = 101,
- .end = 101,
- .flags = IORESOURCE_DMA,
- },
};
struct platform_device pxa3xx_device_mci3 = {
@@ -1021,18 +909,6 @@ static struct resource pxa3xx_resources_nand[] = {
.end = IRQ_NAND,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* DRCMR for Data DMA */
- .start = 97,
- .end = 97,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- /* DRCMR for Command DMA */
- .start = 99,
- .end = 99,
- .flags = IORESOURCE_DMA,
- },
};
static u64 pxa3xx_nand_dma_mask = DMA_BIT_MASK(32);
@@ -1066,18 +942,6 @@ static struct resource pxa3xx_resource_ssp4[] = {
.end = IRQ_SSP4,
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* DRCMR for RX */
- .start = 2,
- .end = 2,
- .flags = IORESOURCE_DMA,
- },
- [3] = {
- /* DRCMR for TX */
- .start = 3,
- .end = 3,
- .flags = IORESOURCE_DMA,
- },
};
/*
--
2.11.0
^ permalink raw reply related
* [PATCH v2 13/13] ARM: pxa: change SSP DMA channels allocation
From: Robert Jarzmik @ 2018-05-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524070703.11901-1-robert.jarzmik@free.fr>
Now the dma_slave_map is available for PXA architecture, switch the SSP
device to it.
This specifically means that :
- for platform data based machines, the DMA requestor channels are
extracted from the slave map, where pxa-ssp-dai.<N> is a 1-1 match to
ssp.<N>, and the channels are either "rx" or "tx".
- for device tree platforms, the dma node should be hooked into the
pxa2xx-ac97 or pxa-ssp-dai node.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
Since v1: Removed channel names from platform_data
---
arch/arm/plat-pxa/ssp.c | 47 ----------------------------------------------
include/linux/pxa2xx_ssp.h | 2 --
sound/soc/pxa/pxa-ssp.c | 5 ++---
3 files changed, 2 insertions(+), 52 deletions(-)
diff --git a/arch/arm/plat-pxa/ssp.c b/arch/arm/plat-pxa/ssp.c
index ba13f793fbce..ed36dcab80f1 100644
--- a/arch/arm/plat-pxa/ssp.c
+++ b/arch/arm/plat-pxa/ssp.c
@@ -127,53 +127,6 @@ static int pxa_ssp_probe(struct platform_device *pdev)
if (IS_ERR(ssp->clk))
return PTR_ERR(ssp->clk);
- if (dev->of_node) {
- struct of_phandle_args dma_spec;
- struct device_node *np = dev->of_node;
- int ret;
-
- /*
- * FIXME: we should allocate the DMA channel from this
- * context and pass the channel down to the ssp users.
- * For now, we lookup the rx and tx indices manually
- */
-
- /* rx */
- ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
- 0, &dma_spec);
-
- if (ret) {
- dev_err(dev, "Can't parse dmas property\n");
- return -ENODEV;
- }
- ssp->drcmr_rx = dma_spec.args[0];
- of_node_put(dma_spec.np);
-
- /* tx */
- ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells",
- 1, &dma_spec);
- if (ret) {
- dev_err(dev, "Can't parse dmas property\n");
- return -ENODEV;
- }
- ssp->drcmr_tx = dma_spec.args[0];
- of_node_put(dma_spec.np);
- } else {
- res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (res == NULL) {
- dev_err(dev, "no SSP RX DRCMR defined\n");
- return -ENODEV;
- }
- ssp->drcmr_rx = res->start;
-
- res = platform_get_resource(pdev, IORESOURCE_DMA, 1);
- if (res == NULL) {
- dev_err(dev, "no SSP TX DRCMR defined\n");
- return -ENODEV;
- }
- ssp->drcmr_tx = res->start;
- }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
dev_err(dev, "no memory resource defined\n");
diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h
index 8461b18e4608..03a7ca46735b 100644
--- a/include/linux/pxa2xx_ssp.h
+++ b/include/linux/pxa2xx_ssp.h
@@ -212,8 +212,6 @@ struct ssp_device {
int type;
int use_count;
int irq;
- int drcmr_rx;
- int drcmr_tx;
struct device_node *of_node;
};
diff --git a/sound/soc/pxa/pxa-ssp.c b/sound/soc/pxa/pxa-ssp.c
index 0291c7cb64eb..e09368d89bbc 100644
--- a/sound/soc/pxa/pxa-ssp.c
+++ b/sound/soc/pxa/pxa-ssp.c
@@ -104,9 +104,8 @@ static int pxa_ssp_startup(struct snd_pcm_substream *substream,
dma = kzalloc(sizeof(struct snd_dmaengine_dai_dma_data), GFP_KERNEL);
if (!dma)
return -ENOMEM;
-
- dma->filter_data = substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
- &ssp->drcmr_tx : &ssp->drcmr_rx;
+ dma->chan_name = substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
+ "tx" : "rx";
snd_soc_dai_set_dma_data(cpu_dai, substream, dma);
--
2.11.0
^ permalink raw reply related
* [GIT PULL] pinctrl: samsung: Stuff for v4.18 (second version)
From: Linus Walleij @ 2018-05-24 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523192704.25370-1-krzk@kernel.org>
On Wed, May 23, 2018 at 9:27 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> This is updated pull request with one additional patch from Marek.
> I saw you did not pull my previous pull request for v4.18 so I hope
> this update should not be a problem.
Thanks Krzysztof, pulled this into "devel" for v4.18.
Sorry for not pulling earlier, was a bit behind on emails.
Thanks for helping out stacking up Samsung patches!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings
From: Linus Walleij @ 2018-05-24 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28c374e6-b440-f785-b371-03fe15c8bc4b@st.com>
On Fri, May 18, 2018 at 9:29 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> On 05/17/2018 08:36 AM, Lee Jones wrote:
>> On Wed, 16 May 2018, Amelie DELAUNAY wrote:
>>> On 05/16/2018 04:20 PM, Linus Walleij wrote:
>>>> On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
>>>>
>>>>> Indeed, stmfx has other functions than GPIO. But, after comments done
>>>>> here: [1] and there: [2], it has been decided to move MFD parent/GPIO
>>>>> child drivers into a single PINCTRL/GPIO driver because of the following
>>>>> reasons:
>>>>> - Other stmfx functions (IDD measurement and TouchScreen controller) are
>>>>> not used on any of the boards using an stmfx and supported by Linux, so
>>>>> no way to test these functions, and no need to maintain them while they
>>>>> are not being used.
>>>>> - But, in the case a new board will use more than GPIO function on
>>>>> stmfx, the actual implementation allow to easily extract common init
>>>>> part of stmfx and put it in an MFD driver.
>>>>>
>>>>> So I could remove gpio sub-node and put its contents in stmfx node and
>>>>> keep single PINCTRL/GPIO driver for the time being.
>>>>> Please advise,
>>>>
>>>> I would normally advice to use the right modeling from the start, create
>>>> the MFD driver and spawn the devices from there. It is confusing
>>>> if the layout of the driver(s) doesn't really match the layout of the
>>>> hardware.
>>>>
>>>> I understand that it is a pain to write new MFD drivers to get your
>>>> things going and it would be "nice to get this working really quick
>>>> now" but in my experience it is better to do it right from the start.
>>>>
>>>
>>> Hi Linus,
>>>
>>> Thanks for your advice. I understand the point.
>>> So, the right modeling would be to:
>>> - create an MFD driver with the common init part of stmfx
>>> - remove all common init part of stmfx-pinctrl driver and keep only all
>>> gpio/pinctrl functions.
>>>
>>> I will not develop the other stmfx functions (IDD measurement driver and
>>> TouchScreen controller driver) because, as explained ealier, they are
>>> not used on any of the boards using an stmfx and supported by Linux, so
>>> no way to test these functions, and no need to maintain them while they
>>> are not being used.
>>>
>>> Lee, are you OK with that ?
>>
>> I missed a lot of this conversation I think, but from what I've read,
>> it sounds fine.
>>
>
> I summarize the situation:
> - I still don't have an official datasheet for STMFX device which could
> justify the use of an MFD driver;
> - the MFD driver will contain the STMFX chip initialization stuff such
> as regmap initialization (regmap structure will be shared with the
> child), chip initialization, global interrupt management;
> - there will be only one child (GPIO/PINCTRL node) for the time being.
But there will be more devices in it. And they will invariably be put
to use later, and there will be new versions of the chip as well, and
then you will be happy about doing the MFD core, which makes it
easy to add new variants with different subdevices.
> So, is "MFD driver + GPIO/PINCTRL driver" the right modeling, and does
> it still sound fine after this summary ? :)
No I think it should use an MFD core.
Mainly because of device tree concerns.
The main reason is that the device tree bindings will be different if
you add an MFD core later, the GPIO and pinctrl driver will
move to a child node, making old device trees incompatible.
We could have a single driver in GPIO+pin control if it is a child
of an MFD node in the device tree, but it doesn't make much
sense as the I2C device need to be probing to the MFD core.
Yours,
Linus Walleij
^ 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