Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

[Arnd Bergmann]

On Tuesday 05 January 2016 12:37:50 Pali Rohár wrote:
> On Monday 28 December 2015 23:27:17 Arnd Bergmann wrote:
> > On Monday 28 December 2015 13:01:22 Frank Rowand wrote:
> > > 
> > > Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision"
> > > property.
> > > 
> > > If the use of /revision is limited to being a location to hold an ATAG
> > > value to pass to the global variable system_rev, then it would make
> > > sense to just copy directly from the ATAG value into system_rev in the
> > > same board file where you are copying the ATAGs.
> > 
> > Agreed. That would be simpler, and avoid a situation where someone relies
> > on the /revision property in DT to be set from the atags compat code
> > (preventing an upgrade to a newer bootloader), or on the system_rev variable
> > to be the same across multiple boot loaders, in the absence of other
> > kernel code setting it.
> 
> So, set system_rev only for Nokia N900? At same place where is called
> save_atags()?
> 
> 

Yes.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Saturday 02 January 2016 16:22:03 Pali Rohár wrote:
> On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote:
> > On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> > > > 
> > > > I mean you can add the platform data to the omap_auxdata_lookup[]
> > > > table for this board.
> > > 
> > > But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]?
> > 
> Hm... looks like it is not possible. omap_hsmmc driver ignores any 
> supplied platform data if there are device tree data. So array 
> omap_auxdata_lookup[] does not help.

Obviously you need to the driver to work with that setting. Maybe
something as simple as

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e06b1881b6a1..4fa35fc84b8b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2006,7 +2006,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
void __iomem *base;
 
match = of_match_device(of_match_ptr(omap_mmc_of_match), >dev);
-   if (match) {
+   if (!pdata && match) {
pdata = of_get_hsmmc_pdata(>dev);
 
if (IS_ERR(pdata))


Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Sunday 03 January 2016 00:03:54 Pali Rohár wrote:
> On Saturday 02 January 2016 23:57:47 Arnd Bergmann wrote:
> > On Saturday 02 January 2016 16:22:03 Pali Rohár wrote:
> > > On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote:
> > > > On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> > > > > > I mean you can add the platform data to the
> > > > > > omap_auxdata_lookup[] table for this board.
> > > > > 
> > > > > But can I mix data from omap3-n900.dts and
> > > > > omap_auxdata_lookup[]?
> > > 
> > > Hm... looks like it is not possible. omap_hsmmc driver ignores any
> > > supplied platform data if there are device tree data. So array
> > > omap_auxdata_lookup[] does not help.
> > 
> > Obviously you need to the driver to work with that setting. Maybe
> > something as simple as
> > 
> > diff --git a/drivers/mmc/host/omap_hsmmc.c
> > b/drivers/mmc/host/omap_hsmmc.c index e06b1881b6a1..4fa35fc84b8b
> > 100644
> > --- a/drivers/mmc/host/omap_hsmmc.c
> > +++ b/drivers/mmc/host/omap_hsmmc.c
> > @@ -2006,7 +2006,7 @@ static int omap_hsmmc_probe(struct
> > platform_device *pdev) void __iomem *base;
> > 
> >   match = of_match_device(of_match_ptr(omap_mmc_of_match),
> > >dev); -if (match) {
> > + if (!pdata && match) {
> >   pdata = of_get_hsmmc_pdata(>dev);
> > 
> >   if (IS_ERR(pdata))
> > 
> 
> But in this case I must copy mmc definition from omap3-n900.dts file 
> back to board code to omap_auxdata_lookup[]. And mmc definitions in 
> omap3-n900.dts will be ignored. This is step back.
> 
> Mixing mmc definitions from DTS file together with omap_auxdata_lookup[] 
> just will not work.

As I said earlier, if you prefer to avoid the auxdata hack, you are
also welcome to work on support for named slots in the MMC core code,
it will just be more work and will take time to get consensus on.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/3] reworked soc changes for ti81xx devices and minimal dra62x j5ec-evm support

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:46 Tony Lindgren wrote:
> Add minimal SoC support for dra62x also known as j5eco. As it's closely
> related to dm814x, we can treat it as a dm814x variant for now and do
> rest of the configuration with DTS just files. And let's add hwmod
> support for MMC and USB on dm814x and dra62x.
> 

Pulled into omap/soc, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 3/3] reworked dts changes for ti81xx devices and minimal dra62x j5ec-evm support

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:47 Tony Lindgren wrote:
> Add minimal device tree support for dra62x also known j5eco. It is
> related to dm814x, just the clocks are a bit different and it has a
> different set of integrated devices. And let's get some basic dm814x
> and dra62x devices working as many of the devices are like on am33xx::
> 
> - pinctrl using the pinctrl defines as for am33xx
> 
> - Updated EDMA bindings with support for using exma_xbar
> 
> - MMC support for dm814x-evm, t410 and dra62x-j5eco-evm
> 
> - USB support for dm814x-evm, t410 and dra62x-j5eco-evm
> 
> This branch depends on an earlier omap-for-v4.5/81xx-fixes-signed
> branch that has dm814x dts fixes interlaced with SoC related fixes to
> keep things booting. The interlaced SoC and dts fixes were needed
> because of issues with the device tree defined clocks that just
> happened to work on bootloader timings for t410 earlier.
> 

Merged into next/dt, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 1/3] reworked fix for earlier ti81xx changes for v4.5 merge window

[Arnd Bergmann]

On Tuesday 22 December 2015 17:44:45 Tony Lindgren wrote:
> Here are reworked pull requests to separate the dts changes as requested
> by Olof.
> 
> The pull request below, and the third pull request in this series,
> still depend on the earlier branch omap-for-v4.5/81xx-fixes-signed.
> The pull request number two in this series does not.
> 
> My updated for-next has zero diff with these merged in compared to the
> earlier single branch merged in, so this is just regrouping of the patches
> into three separate pull requests.
> 

Merged into next/fixes-non-critical, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

[Arnd Bergmann]

On Monday 28 December 2015 13:01:22 Frank Rowand wrote:
> 
> Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision"
> property.
> 
> If the use of /revision is limited to being a location to hold an ATAG
> value to pass to the global variable system_rev, then it would make
> sense to just copy directly from the ATAG value into system_rev in the
> same board file where you are copying the ATAGs.

Agreed. That would be simpler, and avoid a situation where someone relies
on the /revision property in DT to be set from the atags compat code
(preventing an upgrade to a newer bootloader), or on the system_rev variable
to be the same across multiple boot loaders, in the absence of other
kernel code setting it.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > * Arnd Bergmann <a...@arndb.de> [150515 14:26]:
> > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > If setting up the generic binding is expected to take a while,
> > > you can naturally pass it in pdata while waiting for the generic
> > > binding to get merged.
> > 
> > Yes, good idea. So the n900 machine can use auxdata to pass this for
> > the time being, while the binding and generic implementation is
> > being worked out.
> > 
> 
> Ok, so what is needed to finish this patch series?

I don't know where we are at this point. Has either the auxdata approach
or the generic binding been worked on at all?

If not, please try to get the auxdata variant to work, it should not be hard
at all because there is no dependency on a generic binding.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Monday 28 December 2015 15:28:48 Pali Rohár wrote:
> On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote:
> > On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > > > * Arnd Bergmann <a...@arndb.de> [150515 14:26]:
> > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > > > If setting up the generic binding is expected to take a while,
> > > > > you can naturally pass it in pdata while waiting for the
> > > > > generic binding to get merged.
> > > > 
> > > > Yes, good idea. So the n900 machine can use auxdata to pass this
> > > > for the time being, while the binding and generic implementation
> > > > is being worked out.
> > > 
> > > Ok, so what is needed to finish this patch series?
> > 
> > I don't know where we are at this point. Has either the auxdata
> > approach or the generic binding been worked on at all?
> 
> What are auxdata data? 

I mean you can add the platform data to the omap_auxdata_lookup[] table
for this board.

> And what do you mean with "generic binding" approach?

Start a discussion to specify slot names and implement that in the
mmc driver core, so we can remove the hack from the OMAP driver and
make it work the same way for any machine.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

[Arnd Bergmann]

On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote:
> > On Monday 28 December 2015 15:28:48 Pali Rohár wrote:
> > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote:
> > > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote:
> > > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote:
> > > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote:
> > > > > > > * Arnd Bergmann <a...@arndb.de> [150515 14:26]:
> > > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote:
> > > > > > > If setting up the generic binding is expected to take a
> > > > > > > while, you can naturally pass it in pdata while waiting
> > > > > > > for the generic binding to get merged.
> > > > > > 
> > > > > > Yes, good idea. So the n900 machine can use auxdata to pass
> > > > > > this for the time being, while the binding and generic
> > > > > > implementation is being worked out.
> > > > > 
> > > > > Ok, so what is needed to finish this patch series?
> > > > 
> > > > I don't know where we are at this point. Has either the auxdata
> > > > approach or the generic binding been worked on at all?
> > > 
> > > What are auxdata data?
> > 
> > I mean you can add the platform data to the omap_auxdata_lookup[]
> > table for this board.
> 
> But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]?

Yes.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] OMAP: RX51: save atags data to be exported on /proc/atags

[Arnd Bergmann]

On Thursday 24 December 2015, Ivaylo Dimitrov wrote:
> Nokia N900 legacy userspace needs ATAGS passed by the bootloder to be
> available in /proc/atags. With DT booted kernel this information is
> no longer availabe. Fix that by saving ATAGS data early in the boot 
> stage so it can be exported in /proc/atags later

Looks ok to me.

Acked-by: Arnd Bergmann <a...@arndb.de>

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mtd: omap_elm: print interrupt resource using %pr

[Arnd Bergmann]

When CONFIG_LPAE is set on ARM, resource_size_t is 64-bit wide
and we get a warning about an incorrect format string for printing
the interrupt number in elm_probe:

drivers/mtd/nand/omap_elm.c: In function 'elm_probe':
drivers/mtd/nand/omap_elm.c:417:23: warning: format '%i' expects argument of 
type 'int', but argument 3 has type 'resource_size_t {aka long long unsigned 
int}' [-Wformat=]

This patch avoids the type mismatch by printing the interrupt as
a resource using the %pr format string.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
v2: pass correct pointer

diff --git a/drivers/mtd/nand/omap_elm.c b/drivers/mtd/nand/omap_elm.c
index 235ec7992b4c..a3f32f939cc1 100644
--- a/drivers/mtd/nand/omap_elm.c
+++ b/drivers/mtd/nand/omap_elm.c
@@ -414,7 +414,7 @@ static int elm_probe(struct platform_device *pdev)
ret = devm_request_irq(>dev, irq->start, elm_isr, 0,
pdev->name, info);
if (ret) {
-   dev_err(>dev, "failure requesting irq %i\n", irq->start);
+   dev_err(>dev, "failure requesting %pr\n", irq);
return ret;
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Arnd Bergmann]

On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
> This series is basically to deprecate using phy-omap-control and use
> syscon APIs to program the control module registers.
> 
> Changes from v2:
> No changes.
> 
> Changes from v1:
> *) cleanup ti_pipe3_probe in multiple steps
> *) other minor cleanups
> 
> Changes from [1] in PHY patches include
> *) cleanup ti_pipe3_probe
> *) have mask, power_on and power_off values in usb_phy_data for
>omap-usb2 phy
> 
> The patches have been pushed to
> git://git.ti.com/linux-phy/linux-phy.git syscon
> 
> [1] -> https://lkml.org/lkml/2015/6/23/189
> 
> All the testing was done both before applying the dt patches and after
> applying the dt patches (dt patches will be posted shortly).
> 

Can you explain here what the conversion is good for? Why do you
prefer the syscon mapping over a high-level driver in this case?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Tuesday 15 December 2015 10:33:25 Pali Rohár wrote:
> On Monday 30 November 2015 11:09:42 Nicolas Pitre wrote:
> > On Mon, 30 Nov 2015, Pali Rohár wrote:
> > > On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> > > > * Pali Rohár  [151129 16:16]:
> > > > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> > > In arch/arm/kernel/setup.c is function setup_arch() and it calls:
> > > 
> > >   mdesc = setup_machine_fdt(__atags_pointer);
> > >   if (!mdesc)
> > >   mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
> > > 
> > > So it looks like that on atags address is stored either atags structure
> > > or DT structure... so it is truth kernel uncompress code put DT blob to
> > > same offset where is expected atags structure?
> > 
> > No.  It doesn't put it anywhere. Those functions read DT/ATAGs from the 
> > passed address.  But you know this address won't be the one you want for 
> > the legacy ATAGs.
> > 
> > What you should do is to add a init_early hook to your mdesc structure 
> > and retrieve your ATAGs from there directly at PAGE_OFFSET + 0x100.
> > 
> > Now I suspect paging_init() marks the point where the ATAGs will be 
> > overwritten.  To prevent this, you might have to add an additional tweak 
> > in arm_mm_memblock_reserve() similar to the one already present for 
> > CONFIG_SA. Something like:
> > 
> >   memblock_reserve(PHYS_OFFSET, PAGE_SIZE);
> > 
> > And later on you can return that page back to the system.
> > 
> 
> So am I understand correctly that solution would be to hack
> arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?

I would think we can just copy the data from PAGE_OFFSET + 0x100
to a some other page from your init_early hook. IIRC you can't use
kmalloc there, but memblock_alloc() should work.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

[Arnd Bergmann]

On Tuesday 15 December 2015 16:44:41 Kishon Vijay Abraham I wrote:
> Hi Arnd,
> 
> On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
> > On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
> >> This series is basically to deprecate using phy-omap-control and use
> >> syscon APIs to program the control module registers.
> >>
> >> Changes from v2:
> >> No changes.
> >>
> >> Changes from v1:
> >> *) cleanup ti_pipe3_probe in multiple steps
> >> *) other minor cleanups
> >>
> >> Changes from [1] in PHY patches include
> >> *) cleanup ti_pipe3_probe
> >> *) have mask, power_on and power_off values in usb_phy_data for
> >>omap-usb2 phy
> >>
> >> The patches have been pushed to
> >> git://git.ti.com/linux-phy/linux-phy.git syscon
> >>
> >> [1] -> https://lkml.org/lkml/2015/6/23/189
> >>
> >> All the testing was done both before applying the dt patches and after
> >> applying the dt patches (dt patches will be posted shortly).
> >>
> > 
> > Can you explain here what the conversion is good for? Why do you
> > prefer the syscon mapping over a high-level driver in this case?
> 
> phy-omap-control driver was added when there was no proper
> infrastructure for doing control module initializations. The
> phy-omap-control driver is not an 'actual' PHY driver and it
> was just a hack to do PHY related control module initializations.
> phy-omap-control is also getting unmanageable with the number of
> platforms each having number of modules (like USB, SATA, PCIe),
> using the same driver for control module initializations.
> 
> Now with SYSCON framework being added to the kernel, phy-omap-control
> shouldn't be needed and it also provides a uniform API across all the
> modules to program the control module.

Ok, so the "phy-control" devices were really just a few registers of
a system controller device that does a lot of other things as well, right?

Can you put your description above into the cover-letter for the series,
and the merge commit?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 1/2] omap fixes for 81xx for v4.5 merge window

[Arnd Bergmann]

On Thursday 10 December 2015 16:03:08 Tony Lindgren wrote:
> Fixes for ti81xx for v4.5 merge window. We have hp t410 already booting
> in mainline kernel with it's bootloader configured clocks.  However,
> trying to boot dm814x-evm uncovered all kind of issues with the timer
> clock. To keep t410 booting, these issues need to be fixed in a specific
> order and this branch contains both device tree and code changes.
> 
> To summarize the changes, we had missing ranges for clocks to probe,
> missing aliase for clocks, wrong registers for divder clocks, and bad
> address for the control module. All these went unnoticed earlier as
> things worked without errors by luck and I did not pay much attention
> to them until I got hold of a dm814x-evm and I noticed it did not boot.
> 
> As these are fixes for features that never worked, these can wait for
> v4.5 merge window no problem.
> 

Pulled into next/fixes-non-critical, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

[Arnd Bergmann]

On Monday 14 December 2015 10:19:40 Thierry Reding wrote:
> > PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
> > Fixup region is in kernel region and this region if not updated when
> > loading a module.
> 
> Interesting, I hadn't thought about that. I suppose this means that the
> module will end up containing an unused section with the fixup code. It
> might be useful to add a way for that to trigger a warning at build
> time.
> 
> Perhaps to fix this a mechanism could be introduced to add a table of
> fixups to a host controller driver and that will get applied to all
> children of the bridge. It could be problematic to cover all of the
> different fixup stages, though.
> 


I think a lot of the fixups shouldn't really be there in the first place,
they are about stuff that we can fix up in the probe function, or that should
be fixed up in the probe function with some appropriate core support added.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V02 0/5] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Monday 14 December 2015 13:22:15 Peter Ujfalusi wrote:
> 
> Changes since v1:
> - Added Reviewed-by from Andy for patch 1-2, I decided to not add the 
> reviewed-by
>   to patch 3 due to the changes since v1
> - patch for omap-dma to support passing the filter setup to the core
> - dma_request_slave_channel_reason() remeved and it is now defines as
>   dma_request_chan()
> - Print of warning removed when DT or ACPI lookup fails and we are going to
>   Fallback to legacy lookup
> - members of struct dma_filter has been revised for simplicity.

Whole series

Reviewed-by: Arnd Bergmann <a...@arndb.de>

Looks all great to me now.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mtd: omap_elm: print interrupt resource using %pr

[Arnd Bergmann]

On Friday 11 December 2015 17:10:56 Brian Norris wrote:
> Hi Arnd,
> 
> On Tue, Dec 08, 2015 at 04:39:45PM +0100, Arnd Bergmann wrote:
> > When CONFIG_LPAE is set on ARM, resource_size_t is 64-bit wide
> > and we get a warning about an incorrect format string for printing
> > the interrupt number in elm_probe:
> > 
> > drivers/mtd/nand/omap_elm.c: In function 'elm_probe':
> > drivers/mtd/nand/omap_elm.c:417:23: warning: format '%i' expects argument 
> > of type 'int', but argument 3 has type 'resource_size_t {aka long long 
> > unsigned int}' [-Wformat=]
> > 
> > This patch avoids the type mismatch by printing the interrupt as
> > a resource using the %pr format string.
> > 
> > Signed-off-by: Arnd Bergmann <a...@arndb.de>
> > ---
> >  drivers/mtd/nand/omap_elm.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mtd/nand/omap_elm.c b/drivers/mtd/nand/omap_elm.c
> > index 235ec7992b4c..11f174b07217 100644
> > --- a/drivers/mtd/nand/omap_elm.c
> > +++ b/drivers/mtd/nand/omap_elm.c
> > @@ -414,7 +414,7 @@ static int elm_probe(struct platform_device *pdev)
> >   ret = devm_request_irq(>dev, irq->start, elm_isr, 0,
> >   pdev->name, info);
> >   if (ret) {
> > - dev_err(>dev, "failure requesting irq %i\n", 
> > irq->start);
> > + dev_err(>dev, "failure requesting %pr\n", );
> 
> drivers/mtd/nand/omap_elm.c:417 elm_probe() error: '%pr' expects argument of 
> type struct resource *, but argument 3 has type 'struct resource**' [smatch]

Ah, good catch. Do you want to fix it up yourself, or should I send a new 
version?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/2] omap device tree changes for v4.5, part 1

[Arnd Bergmann]

On Thursday 10 December 2015 16:03:09 Tony Lindgren wrote:
> Device tree changes for omaps for v4.5 merge window:
> 
> - Update all omaps to use pinctrl macros. This makes comparing the pinmux
>   settings against the documentation much earlier. Javier compared the
>   checksums of the generated dtb files to make sure nothing changed for
>   the dtb files.
> 
> - Updates for dm816x
> 
> - Add GPMC DMA channels for am437x
> 
> - Updates for LogicPD Torpedo
> 
> - Basic support for CompuLab cm-t335
> 
> - Remove tps65217.dtsi file, we're better off adding SoC generic board
>   dtsi files for the common features
> 
> - Add support for ELM on am33xx
> 
> - Add support for Bosch shc c3 board
> 
> - Add qspi aliases for am437x and dra7
> 
> - Wake-up support for dra7-evm uart1
> 
> - Basic support for CompuLab sbc-t43
> 
> - Basic support for CompuLab cl-som-am57x
> 
> - Use MMC pwrseq for libertas WLAN on igep0020 and igep0030

Pulled into next/dt, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap fixes against v4.4-rc4

[Arnd Bergmann]

On Thursday 10 December 2015 15:39:08 Tony Lindgren wrote:
> Few fixes for omaps for v4.4-rc cycle:
> 
> - Fix clock source for ARM TWD and global timers on am437x
> 
> - Always select REGULATOR_FIXED_VOLTAGE for omap2+ instead of
>   when MACH_OMAP3_PANDORA is selected
> 
> - Fix SPI DMA handles for dm816x as only some were mapped
> 
> - Fix up mbox cells for dm816x to make mailbox usable
> 

Just when I had finished pulling in all other fixes and was about
to go to bed.

Pulled into fixes, too.

Thanks,

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit

[Arnd Bergmann]

On Wednesday 09 December 2015 10:18:09 Peter Ujfalusi wrote:
> Hi,
> 
> Based on the discussion regarding to (convert am33xx to use the new eDMA
> bindings):
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> 
> This two patch will convert the new eDMA binding to not use 16bit arrays for
> memcpy channel selection and for marking slots reserved.
> The '/bits/ 16' seams to be causing confusion so it is probably better to just
> use standard type for the arrays.
> 
> The new bindings for the eDMA is introduced for 4.4 and we do not have users 
> of
> it, which means that we can still change it w/o the risk of breaking anything
> and we do not need to maintain the compatibility with 16bit arrays.
> 
> The changes in the eDMA driver is local to the DT parsing and should not
> conflict with other changes (like the filter function mapping support). Hrm,
> there might be trivial conflict in the include/linux/platform_data/edma.h with
> the "dmaengine 'universal' API".

Both patches

Acked-by: Arnd Bergmann <a...@arndb.de>

> Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches 
> are
> going to be handled? I would like to send the updated am33xx/am437x conversion
> for 4.5 based on these changes.

I'd suggest you send a pull request with these two patches on top of 4.4-rc1,
and then either Vinod or I send it to Linus, and you base your other changes
on top of the same branch.

I think Vinod's tree is slightly more fitting for the 4.4 merge, but if he
prefers me to take them instead, I will.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Arnd Bergmann]

On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote:
> On 12/04/2015 11:51 PM, Tony Lindgren wrote:
> >>
> >> Please just drop the /bits/ 16 and use normal cells.
> > 
> > Yeah agreed, makes things less confusing for sure 
> 
> 4.4 will be the first kernel where we will have the new eDMA bindings. I have
> chosen to use 16bit array for specifying the channels used for memcpy
> (ti,edma-memcpy-channels) and for the reserving paRAM slots
> (ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels and
> 512 paRAM slots. 16bit is more than enough to store this information and it
> even gives us enough room if ever in the future these numbers are going to
> increase (which  they are not).
> 
> But in order to change them to 32bit the driver needs to be changed as well.
> Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is not
> yet out, so it might be possible to change the binding document and the driver
> to use 32bit arrays. The driver internally uses 16bit type for these which I'm
> not going to change, but the code parsing the DT needs to be adjusted for the
> new data type.
> 
> If Vinod is willing to take update for the DT binding of eDMA for 4.4-rc, I
> can cook up the patch(es) to do so.

I hadn't realized that it was already in 4.4-rc. The change should be trivial
enough though, so I'd still do it. If Vinod would rather not change it now,
it's not overly important though.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Arnd Bergmann]

On Tuesday 08 December 2015 12:22:09 Peter Ujfalusi wrote:
> On 12/08/2015 11:51 AM, Arnd Bergmann wrote:
> > On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote:
> >> On 12/04/2015 11:51 PM, Tony Lindgren wrote:
> >>>>
> >>>> Please just drop the /bits/ 16 and use normal cells.
> >>>
> >>> Yeah agreed, makes things less confusing for sure 
> >>
> >> 4.4 will be the first kernel where we will have the new eDMA bindings. I 
> >> have
> >> chosen to use 16bit array for specifying the channels used for memcpy
> >> (ti,edma-memcpy-channels) and for the reserving paRAM slots
> >> (ti,edma-reserved-slot-ranges). As of now we have maximum of 64 channels 
> >> and
> >> 512 paRAM slots. 16bit is more than enough to store this information and it
> >> even gives us enough room if ever in the future these numbers are going to
> >> increase (which  they are not).
> >>
> >> But in order to change them to 32bit the driver needs to be changed as 
> >> well.
> >> Currently we do not have drivers (in 4.4) using the new bindings, 4.4 is 
> >> not
> >> yet out, so it might be possible to change the binding document and the 
> >> driver
> >> to use 32bit arrays. The driver internally uses 16bit type for these which 
> >> I'm
> >> not going to change, but the code parsing the DT needs to be adjusted for 
> >> the
> >> new data type.
> >>
> >> If Vinod is willing to take update for the DT binding of eDMA for 4.4-rc, I
> >> can cook up the patch(es) to do so.
> > 
> > I hadn't realized that it was already in 4.4-rc. The change should be 
> > trivial
> > enough though, so I'd still do it. If Vinod would rather not change it now,
> > it's not overly important though.
> 
> But this change must be done before we have actual users of these properties,
> which is the am33xx, am437x and the da850 conversion series I have sent 
> recently.
> We might want to have this changed for 4.4 since it is going to be an LTS
> release...

Yes, that's what I meant: We either get the patch into 4.4 by creating a
branch for Vinod to pull with this change, and base all other changes in your
4.5 series on the same branch, or we don't change it at all.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mtd: omap_elm: print interrupt resource using %pr

[Arnd Bergmann]

When CONFIG_LPAE is set on ARM, resource_size_t is 64-bit wide
and we get a warning about an incorrect format string for printing
the interrupt number in elm_probe:

drivers/mtd/nand/omap_elm.c: In function 'elm_probe':
drivers/mtd/nand/omap_elm.c:417:23: warning: format '%i' expects argument of 
type 'int', but argument 3 has type 'resource_size_t {aka long long unsigned 
int}' [-Wformat=]

This patch avoids the type mismatch by printing the interrupt as
a resource using the %pr format string.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 drivers/mtd/nand/omap_elm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap_elm.c b/drivers/mtd/nand/omap_elm.c
index 235ec7992b4c..11f174b07217 100644
--- a/drivers/mtd/nand/omap_elm.c
+++ b/drivers/mtd/nand/omap_elm.c
@@ -414,7 +414,7 @@ static int elm_probe(struct platform_device *pdev)
ret = devm_request_irq(>dev, irq->start, elm_isr, 0,
pdev->name, info);
if (ret) {
-   dev_err(>dev, "failure requesting irq %i\n", irq->start);
+   dev_err(>dev, "failure requesting %pr\n", );
return ret;
}
 
-- 
2.1.0.rc2


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Arnd Bergmann]

On Friday 04 December 2015 10:47:07 Tony Lindgren wrote:
> > Peter Ujfalusi  writes:
> > > @@ -174,12 +182,44 @@
> > > };
> > >  
> > > edma: edma@4900 {
> > > -   compatible = "ti,edma3";
> > > -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> > > -   reg =   <0x4900 0x1>,
> > > -   <0x44e10f90 0x40>;
> > > +   compatible = "ti,edma3-tpcc";
> > > +   ti,hwmods = "tpcc";
> > > +   reg =   <0x4900 0x1>;
> > > +   reg-names = "edma3_cc";
> > > interrupts = <12 13 14>;
> > > -   #dma-cells = <1>;
> > > +   interrupt-names = "edma3_ccint", "emda3_mperr",
> > > + "edma3_ccerrint";
> > > +   dma-requests = <64>;
> > > +   #dma-cells = <2>;
> > > +
> > > +   ti,tptcs = <_tptc0 7>, <_tptc1 5>,
> > > +  <_tptc2 0>;
> > > +
> > > +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> > 
> > can you explain this property here ? Are you setting bits 20 and 21 on a
> > 16-bit field ?
> 
> I think it's an arry of u16 dma channels.. But could it be just /bits/ 8
> instead of /bits/ 16?
> 

Please just drop the /bits/ 16 and use normal cells.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Arnd Bergmann]

On Thursday 03 December 2015 16:33:12 Peter Ujfalusi wrote:
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 0675e268d577..46b305ea0d21 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -2297,6 +2297,12 @@ static int edma_probe(struct platform_device *pdev)
> edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
> }
>  
> +   if (info->slave_map) {
> +   ecc->dma_slave.filter_map.map = info->slave_map;
> +   ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
> +   ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
> +   }
> +
> 

Just a minor comment here: I think all three assignments can be done
unconditionally. As I mentioned before, I'd also remove 'struct dma_filter'
and put the three members in struct dma_device directly. In fact, the
filter function can go with the other function pointers for consistency.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel

[Arnd Bergmann]

On Thursday 03 December 2015 16:33:11 Peter Ujfalusi wrote:
> +
> +/**
> + * dma_request_chan - try to allocate an exclusive slave channel
> + * @dev:   pointer to client device structure
> + * @name:  slave channel name
> + *
> + * Returns pointer to appropriate DMA channel on success or an error pointer.
> + */
> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
> +{
> +   struct dma_device *d, *_d;
> +   struct dma_chan *chan = NULL;
> +
> +   /* If device-tree is present get slave info from here */
> +   if (dev->of_node)
> +   chan = of_dma_request_slave_channel(dev->of_node, name);
> +
> +   /* If device was enumerated by ACPI get slave info from here */
> +   if (has_acpi_companion(dev) && !chan)
> +   chan = acpi_dma_request_slave_chan_by_name(dev, name);

I just noticed that you are creating this as a new interface, rather than
changing dma_request_slave_channel_reason() and making the old interface
a static inline wrapper. What is the reasoning behind that?

I think if we make both interfaces do the same thing, it's easier
to do the migration.

> +   if (chan) {
> +   /* Valid channel found */
> +   if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
> +   return chan;
> +
> +   pr_warn("%s: %s DMA request failed, falling back to legacy\n",
> +   __func__, dev->of_node ? "OF" : "ACPI");
> +   }

Maybe print the error code as well?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel

[Arnd Bergmann]

On Thursday 03 December 2015 17:42:31 Peter Ujfalusi wrote:
> > 
> >> +   if (chan) {
> >> +   /* Valid channel found */
> >> +   if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
> >> +   return chan;
> >> +
> >> +   pr_warn("%s: %s DMA request failed, falling back to 
> >> legacy\n",
> >> +   __func__, dev->of_node ? "OF" : "ACPI");
> >> +   }
> > 
> > Maybe print the error code as well?
> 
> Or remove the print altogether?
> In a healthy system we will either get the channel or the EPROBE_DEFER, in
> case of the platforms where the DT lookup does not work we expect errors and
> it is 'normal'.
> I think if we fail via DT/ACPI and we fail with legacy also then the client
> driver will say something about it anyways, or deal with it as it see fits.
> 

Right, that works too. It took me a while to figure out that we only get
there on systems that have ACPI or DT enabled for a particular device,
but where the normal method failed, rather than also systems with traditional
board files. Without the pr_warn, I would not have needed to think about
this ;-)

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Wednesday 02 December 2015 10:22:09 Vinod Koul wrote:
> > 
> > > > This legacy mode needs changes in platform code, in dmaengine drivers 
> > > > and
> > > > finally the dmaengine user drivers can be converted:
> > > 
> > > Are you marking the current APIs as dericated in the end of this series
> > 
> > I think we practically stopped marking things as deprecated in general.
> > Per Linus decree, whenever we want to get rid of something, we should
> > instead change all users in tree and then remove the API, expecting
> > driver maintainers to do something just because you marked it as deprecated
> > often doesn't work.
> 
> Yes but while we do conversion we don't know if new users get added which use
> old API..

We probably don't need to worry about new users of dma_request_channel(),
as we don't add new ARM platforms without DT, and other architectures
don't add a lot of new platforms. Similarly, I don't expect a whole lot
of dma_request_slave_channel_compat() users, because the conversion from
board files to DT based booting has slowed down a lot after most of the
actively maintained platforms are done with it.

If you do a one-line patch to add dma_request_chan() as an alias for
dma_request_slave_channel_reason() now, we can probably convert most
users of dma_request_slave_channel() and dma_request_slave_channel_reason()
to dma_request_chan() in the next merge window and do a patch to
replace the few remaining ones and remove the API one merge window later.

If wewant to stage out the conversion of the
dma_request_slave_channel_compat() and dma_request_channel() similarly,
it would be good to have all the interface changes for the dmaengine
core basically in place, so we can start to convert the platforms
independently for the 4.5 merge window without having a dependency on
dmaengine patches. It's probably best to not convert a slave driver
away from dma_request_channel() until the dma map has been created
for all platforms using that driver, again to avoid having too many
dependencies.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Wednesday 02 December 2015 12:51:43 Peter Ujfalusi wrote:
> On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> > On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
> >>>> static struct dma_filter_map da830_edma_map[] = {
> >>>> DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
> >>>> DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
> >>>> DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
> >>>> DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
> >>>> DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
> >>>> DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
> >>>> DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
> >>>> DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
> >>>> DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
> >>>> DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
> >>>> DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
> >>>> DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> >>>
> >>> Does this ".2" and so prevent driver to use auto ID for platform devices?
> >>
> >> Yes, as all the infra around the traditional board files with 
> >> platform_device
> >> creation does. Ideally we could have 'phandle' pointing from this table to 
> >> the
> >> device in question (or other way around), but I'm not aware of anything we 
> >> can
> >> use.
> > 
> > I was thinking that we could use a pointer to the device structure, but
> > if you have that, you can also just read the name from it.
> 
> Hrm to have pdev pointer instead of the devname string? In the core we could
> get the pdev from the caller's device with to_platform_device(dev) and simply
> compare the pointers...
> 
> One of the issue I see (in mach-davinci and mach-omap1/2) is that the pdevs
> are scattered around in the c files so gathering the pointers to a place where
> we can see them to be able to use it in the dma_filter_map is not going to be
> light weight task.
> Furthermore we have the omap_hwmod for OMAP2+ which creates the actual pdevs
> and resources from the omap_hwmod data structures so getting out the DMA event
> numbers there is not going to be easy either...
> 
> I'll hold back the RFC v3 to see if we should switch to pdev pointer or stay
> with the devname strings here.

Sorry, what I meant to say above is that I had already concluded that using
device pointers was a bad idea and we should stay with names.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Arnd Bergmann]

On Tuesday 01 December 2015 22:52:12 Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote:
> > Add support for providing device to filter_fn mapping so client drivers
> > can switch to use the dma_request_chan() API.
> 
> Any reason why we dont want to go with DT based only for edma here?

I think the OMAP2 based platforms using edma are all DT-only, but mach-davinci
would need a lot of work for that.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
> > channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
> > it will use a filter lookup table and retrieves the needed information from
> > the dma_filter_map provided by the DMA drivers.
> 
> That sounds right, for the third case would the arch, driver or someone else
> configure this?

The typical case is for the configuration to be defined in arch or platform
code and passed down to the dmaengine driver.

I just noticed that the text above (and probably the code too) should
be changed so we always fall back to this. There are cases where the
platform is booted with DT in principle, but the DMA engine does not
(yet) use DT and still wants to be converted. I think we can easily
handle that case by always trying this if the other methods fail.

> > This legacy mode needs changes in platform code, in dmaengine drivers and
> > finally the dmaengine user drivers can be converted:
> 
> Are you marking the current APIs as dericated in the end of this series

I think we practically stopped marking things as deprecated in general.
Per Linus decree, whenever we want to get rid of something, we should
instead change all users in tree and then remove the API, expecting
driver maintainers to do something just because you marked it as deprecated
often doesn't work.

I can help out converting a few platforms, maybe one interface at a time.
This is what I see:

arnd@wuerfel:~/arm-soc$ for i in dma_request_slave_channel_reason 
dma_request_slave_channel dma_request_slave_channel_compat dma_request_channel  
; do echo `git grep -wl $i drivers/  | grep -v drivers/dma | wc -l`\  $i ; 
done
14  dma_request_slave_channel_reason
27  dma_request_slave_channel
25  dma_request_slave_channel_compat
34  dma_request_channel

I would probably leave the users of dma_request_channel() while converting
the others, as that is still used by all the platforms that don't use any DT
support.

Changing dma_request_slave_channel_reason and dma_request_slave_channel is
trivial, we can probably use coccinelle for that, as it does not require
any platform changes. That brings us to the users of
dma_request_slave_channel_compat, which currently includes these files:

$ git grep -wl dma_request_slave_channel_compat drivers/ata/pata_pxa.c
drivers/crypto/atmel-aes.c
drivers/crypto/atmel-sha.c
drivers/crypto/atmel-tdes.c
drivers/crypto/omap-aes.c
drivers/crypto/omap-des.c
drivers/crypto/omap-sham.c
drivers/media/platform/omap3isp/isphist.c
drivers/mmc/host/davinci_mmc.c
drivers/mmc/host/omap.c
drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/pxamci.c
drivers/mmc/host/s3cmci.c
drivers/mmc/host/tmio_mmc_dma.c
drivers/mtd/nand/pxa3xx_nand.c
drivers/net/ethernet/smsc/smc91x.c
drivers/net/irda/pxaficp_ir.c
drivers/spi/spi-omap2-mcspi.c
drivers/spi/spi-pxa2xx-dma.c
drivers/spi/spi-rspi.c
drivers/spi/spi-s3c64xx.c
drivers/spi/spi-sh-msiof.c
drivers/tty/serial/8250/8250_dma.c
drivers/tty/serial/samsung.c
drivers/tty/serial/sh-sci.c
include/linux/dmaengine.h

In other words: arch/avr32 and arch/sh along with omap1, omap2, davinci, pxa, 
and s3c
in terms of ARM platforms.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Arnd Bergmann]

On Tuesday 01 December 2015 11:58:53 Peter Ujfalusi wrote:
> On 11/30/2015 04:11 PM, Arnd Bergmann wrote:
> > On Monday 30 November 2015 15:45:34 Peter Ujfalusi wrote:
> >> @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void 
> >> *param)
> >>  }
> >>  EXPORT_SYMBOL(edma_filter_fn);
> >>  
> >> +static bool edma_filter_for_map(struct dma_chan *chan, void *param)
> >> +{
> >> +   bool match = false;
> >> +
> >> +   if (chan->device->dev->driver == _driver.driver) {
> >> +   struct edma_chan *echan = to_edma_chan(chan);
> >> +   unsigned ch_req = (unsigned)param;
> >> +   if (ch_req == echan->ch_num) {
> >> +   /* The channel is going to be used as HW 
> >> synchronized */
> >> +   echan->hw_triggered = true;
> >> +   match = true;
> >> +   }
> >> +   }
> >> +   return match;
> >> +}
> >> +
> >>  static int edma_init(void)
> >>
> > 
> > I don't see the difference between edma_filter_fn and edma_filter_for_map.
> > Why do you need both?
> 
> edma_filter_fn:
> unsigned ch_req = *(unsigned *)param;
> 
> edma_filter_for_map:
> unsigned ch_req = (unsigned)param;

I see.

> If I want to reuse the edma_filter_fn, I would need an unsigned array for the
> eDMA event numbers in the board files to be able to provide the pointer to
> each of them.

How about this:

#define EDMA_CTLR_CHANP(ctlr, chan)  ((const int[]){ [0] = ((ctlr) << 16) | 
(chan)})

static struct dma_filter_map da830_edma_map[] = {
 { "davinci-mcasp.0", "rx", EDMA_CTLR_CHANP(0, 0)},
 { "davinci-mcasp.0", "tx", EDMA_CTLR_CHANP(0, 1)},
 { "davinci-mcasp.1", "rx", EDMA_CTLR_CHANP(0, 2)},
 ...
};

That way, you create an anonymous constant integer expression and the data
points to that.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Tuesday 01 December 2015 12:12:47 Peter Ujfalusi wrote:
> 
> We would need:
> { "da830-mmc.0", "rx", (void*)EDMA_CTLR_CHAN(0, 16) },
> { "da830-mmc.0", "tx", (void*)EDMA_CTLR_CHAN(0, 17) },
> 
> as we need to cast the param.
> It is still compact, but having to add the (void*) casting makes it a bit 
> ugly.

Right, I forgot that, but the cast could also be part of EDMA_CTLR_CHAN(),
and with the version I just posted in my other reply that part is solved
as well.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
> >> static struct dma_filter_map da830_edma_map[] = {
> >> DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
> >> DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
> >> DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
> >> DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
> >> DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
> >> DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
> >> DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
> >> DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
> >> DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
> >> DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
> >> DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
> >> DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> > 
> > Does this ".2" and so prevent driver to use auto ID for platform devices?
> 
> Yes, as all the infra around the traditional board files with platform_device
> creation does. Ideally we could have 'phandle' pointing from this table to the
> device in question (or other way around), but I'm not aware of anything we can
> use.

I was thinking that we could use a pointer to the device structure, but
if you have that, you can also just read the name from it.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/7] ARM: iop13xx: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-iop13xx
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 arch/arm/mach-iop13xx/include/mach/pci.h   | 57 -
 arch/arm/mach-iop13xx/iq81340mc.c  |  2 +-
 arch/arm/mach-iop13xx/iq81340sc.c  |  2 +-
 arch/arm/mach-iop13xx/irq.c|  2 +-
 arch/arm/mach-iop13xx/{include/mach => }/msi.h |  0
 arch/arm/mach-iop13xx/pci.c|  2 +-
 arch/arm/mach-iop13xx/pci.h| 58 ++
 7 files changed, 62 insertions(+), 61 deletions(-)
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/pci.h
 rename arch/arm/mach-iop13xx/{include/mach => }/msi.h (100%)

diff --git a/arch/arm/mach-iop13xx/include/mach/pci.h 
b/arch/arm/mach-iop13xx/include/mach/pci.h
deleted file mode 100644
index 59f42b535572..
--- a/arch/arm/mach-iop13xx/include/mach/pci.h
+++ /dev/null
@@ -1,57 +0,0 @@
-#ifndef _IOP13XX_PCI_H_
-#define _IOP13XX_PCI_H_
-#include 
-#include 
-
-struct pci_sys_data;
-struct hw_pci;
-int iop13xx_pci_setup(int nr, struct pci_sys_data *sys);
-struct pci_bus *iop13xx_scan_bus(int nr, struct pci_sys_data *);
-void iop13xx_atu_select(struct hw_pci *plat_pci);
-void iop13xx_pci_init(void);
-void iop13xx_map_pci_memory(void);
-
-#define IOP_PCI_STATUS_ERROR (PCI_STATUS_PARITY |   \
-  PCI_STATUS_SIG_TARGET_ABORT | \
-  PCI_STATUS_REC_TARGET_ABORT | \
-  PCI_STATUS_REC_TARGET_ABORT | \
-  PCI_STATUS_REC_MASTER_ABORT | \
-  PCI_STATUS_SIG_SYSTEM_ERROR | \
-  PCI_STATUS_DETECTED_PARITY)
-
-#define IOP13XX_ATUE_ATUISR_ERROR (IOP13XX_ATUE_STAT_HALT_ON_ERROR |  \
-   IOP13XX_ATUE_STAT_ROOT_SYS_ERR |   \
-   IOP13XX_ATUE_STAT_PCI_IFACE_ERR |  \
-   IOP13XX_ATUE_STAT_ERR_COR |\
-   IOP13XX_ATUE_STAT_ERR_UNCOR |  \
-   IOP13XX_ATUE_STAT_CRS |\
-   IOP13XX_ATUE_STAT_DET_PAR_ERR |\
-   IOP13XX_ATUE_STAT_EXT_REC_MABORT | \
-   IOP13XX_ATUE_STAT_SIG_TABORT | \
-   IOP13XX_ATUE_STAT_EXT_REC_TABORT | \
-   IOP13XX_ATUE_STAT_MASTER_DATA_PAR)
-
-#define IOP13XX_ATUX_ATUISR_ERROR (IOP13XX_ATUX_STAT_TX_SCEM |\
-   IOP13XX_ATUX_STAT_REC_SCEM |   \
-   IOP13XX_ATUX_STAT_TX_SERR |\
-   IOP13XX_ATUX_STAT_DET_PAR_ERR |\
-   IOP13XX_ATUX_STAT_INT_REC_MABORT | \
-   IOP13XX_ATUX_STAT_REC_SERR |   \
-   IOP13XX_ATUX_STAT_EXT_REC_MABORT | \
-   IOP13XX_ATUX_STAT_EXT_REC_TABORT | \
-   IOP13XX_ATUX_STAT_EXT_SIG_TABORT | \
-   IOP13XX_ATUX_STAT_MASTER_DATA_PAR)
-
-/* PCI interrupts
- */
-#define ATUX_INTA IRQ_IOP13XX_XINT0
-#define ATUX_INTB IRQ_IOP13XX_XINT1
-#define ATUX_INTC IRQ_IOP13XX_XINT2
-#define ATUX_INTD IRQ_IOP13XX_XINT3
-
-#define ATUE_INTA IRQ_IOP13XX_ATUE_IMA
-#define ATUE_INTB IRQ_IOP13XX_ATUE_IMB
-#define ATUE_INTC IRQ_IOP13XX_ATUE_IMC
-#define ATUE_INTD IRQ_IOP13XX_ATUE_IMD
-
-#endif /* _IOP13XX_PCI_H_ */
diff --git a/arch/arm/mach-iop13xx/iq81340mc.c 
b/arch/arm/mach-iop13xx/iq81340mc.c
index 9cd07d396093..d255ab5ad1a5 100644
--- a/arch/arm/mach-iop13xx/iq81340mc.c
+++ b/arch/arm/mach-iop13xx/iq81340mc.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "pci.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-iop13xx/iq81340sc.c 
b/arch/arm/mach-iop13xx/iq81340sc.c
index b3ec11cb707e..33eeaf1fa11d 100644
--- a/arch/arm/mach-iop13xx/iq81340sc.c
+++ b/arch/arm/mach-iop13xx/iq81340sc.c
@@ -23,7 +23,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "pci.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-iop13xx/irq.c b/arch/arm/mach-iop13xx/irq.c
index 623d85a4af2d..c702cc4092de 100644
--- a/arch/arm/mach-iop13xx/irq.c
+++ b/arch/arm/mach-iop13xx/irq.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "msi.h"
 
 /* INTCTL0 CP6 R0 Page 4
  */
diff --git a/arch/arm/mach-iop13xx/include/mach/msi.h 
b/arch/arm/mach-iop13xx/msi.h
similarity index 100%
rename from arch/arm/mach-iop13xx/include/mach/msi.h
rename to arch/arm/mach-iop13xx/msi.h
diff --git a/arch/arm/mach-iop13xx/pci.c b/arch/arm/mach-iop13xx/pci.c
index 9082b84aeeb

[PATCH 3/7] ARM: davinci: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-davinci
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 arch/arm/mach-davinci/board-da830-evm.c| 2 +-
 arch/arm/mach-davinci/board-da850-evm.c| 4 ++--
 arch/arm/mach-davinci/board-mityomapl138.c | 2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c| 2 +-
 arch/arm/mach-davinci/clock.c  | 2 +-
 arch/arm/mach-davinci/cp_intc.c| 2 +-
 arch/arm/mach-davinci/{include/mach => }/cp_intc.h | 0
 arch/arm/mach-davinci/cpuidle.c| 4 ++--
 arch/arm/mach-davinci/{include/mach => }/cpuidle.h | 0
 arch/arm/mach-davinci/da830.c  | 2 +-
 arch/arm/mach-davinci/da850.c  | 2 +-
 arch/arm/mach-davinci/da8xx-dt.c   | 2 +-
 arch/arm/mach-davinci/{include/mach => }/ddr2.h| 0
 arch/arm/mach-davinci/devices-da8xx.c  | 4 ++--
 arch/arm/mach-davinci/dm355.c  | 2 +-
 arch/arm/mach-davinci/dm365.c  | 2 +-
 arch/arm/mach-davinci/dm644x.c | 2 +-
 arch/arm/mach-davinci/dm646x.c | 2 +-
 arch/arm/mach-davinci/pm.c | 2 +-
 arch/arm/mach-davinci/psc.c| 2 +-
 arch/arm/mach-davinci/{include/mach => }/psc.h | 0
 arch/arm/mach-davinci/sleep.S  | 4 ++--
 arch/arm/mach-davinci/sram.c   | 2 +-
 arch/arm/mach-davinci/{include/mach => }/sram.h| 0
 24 files changed, 23 insertions(+), 23 deletions(-)
 rename arch/arm/mach-davinci/{include/mach => }/cp_intc.h (100%)
 rename arch/arm/mach-davinci/{include/mach => }/cpuidle.h (100%)
 rename arch/arm/mach-davinci/{include/mach => }/ddr2.h (100%)
 rename arch/arm/mach-davinci/{include/mach => }/psc.h (100%)
 rename arch/arm/mach-davinci/{include/mach => }/sram.h (100%)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index f8f62fbaa915..3d8cf8cbd98a 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -32,7 +32,7 @@
 #include 
 
 #include 
-#include 
+#include "cp_intc.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 9cc7b818fbf6..8e4539f69fdc 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -40,10 +40,10 @@
 #include 
 
 #include 
-#include 
+#include "cp_intc.h"
 #include 
 #include 
-#include 
+#include "sram.h"
 
 #include 
 #include 
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c 
b/arch/arm/mach-davinci/board-mityomapl138.c
index 8cfbfe084535..de1316bf643a 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "cp_intc.h"
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c 
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 2aac51d0e853..ee624861ca66 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -19,7 +19,7 @@
 #include 
 
 #include 
-#include 
+#include "cp_intc.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index 47281f5c12ea..a23e21aa0d8b 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -23,7 +23,7 @@
 #include 
 
 #include 
-#include 
+#include "psc.h"
 #include 
 #include "clock.h"
 
diff --git a/arch/arm/mach-davinci/cp_intc.c b/arch/arm/mach-davinci/cp_intc.c
index 507aad4b8dd9..1a68d2477de6 100644
--- a/arch/arm/mach-davinci/cp_intc.c
+++ b/arch/arm/mach-davinci/cp_intc.c
@@ -19,7 +19,7 @@
 #include 
 
 #include 
-#include 
+#include "cp_intc.h"
 
 static inline unsigned int cp_intc_read(unsigned offset)
 {
diff --git a/arch/arm/mach-davinci/include/mach/cp_intc.h 
b/arch/arm/mach-davinci/cp_intc.h
similarity index 100%
rename from arch/arm/mach-davinci/include/mach/cp_intc.h
rename to arch/arm/mach-davinci/cp_intc.h
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index 306ebc51599a..1b8f08532455 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -19,8 +19,8 @@
 #include 
 #include 
 
-#include 
-#include 
+#include "cpuidle.h"
+#include "ddr2.h"
 
 #define DAVINCI_CPUIDLE_MAX_STATES 2
 
diff --git a/arch/arm/mach-davinci/include/mach/cpuidle.h 
b/arch/arm/mach-davinci/cpuidle.h
similarity index 100%
rename from arch/arm/mach-davinci/include/mach/cpuidle.h
rename to arch/arm/mach-davinci/cpuidle.h
diff --git a/arch/arm/mach-davinci/da830.c b/arch/

[PATCH 7/7] ARM: netx: remove unused mach/param.h

[Arnd Bergmann]

I could not find any users of this file, past or present, and
it contains only a comment, so let's remove it.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 arch/arm/mach-netx/include/mach/param.h | 18 --
 1 file changed, 18 deletions(-)
 delete mode 100644 arch/arm/mach-netx/include/mach/param.h

diff --git a/arch/arm/mach-netx/include/mach/param.h 
b/arch/arm/mach-netx/include/mach/param.h
deleted file mode 100644
index a771459206aa..
--- a/arch/arm/mach-netx/include/mach/param.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- *  arch/arm/mach-netx/include/mach/param.h
- *
- * Copyright (C) 2005 Sascha Hauer <s.ha...@pengutronix.de>, Pengutronix
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-- 
2.1.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/7] ARM: omap1: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-omap1
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 arch/arm/mach-omap1/board-ams-delta.c  | 2 +-
 arch/arm/mach-omap1/board-fsample.c| 2 +-
 arch/arm/mach-omap1/board-h2.c | 2 +-
 arch/arm/mach-omap1/board-h3.c | 2 +-
 arch/arm/mach-omap1/board-innovator.c  | 2 +-
 arch/arm/mach-omap1/board-osk.c| 2 +-
 arch/arm/mach-omap1/board-palmte.c | 2 +-
 arch/arm/mach-omap1/board-palmtt.c | 2 +-
 arch/arm/mach-omap1/board-palmz71.c| 2 +-
 arch/arm/mach-omap1/board-perseus2.c   | 2 +-
 arch/arm/mach-omap1/board-sx1-mmc.c| 2 +-
 arch/arm/mach-omap1/board-sx1.c| 4 ++--
 arch/arm/mach-omap1/{include/mach => }/board-sx1.h | 0
 arch/arm/mach-omap1/{include/mach => }/camera.h| 0
 arch/arm/mach-omap1/devices.c  | 2 +-
 arch/arm/mach-omap1/flash.c| 2 +-
 arch/arm/mach-omap1/{include/mach => }/flash.h | 0
 17 files changed, 15 insertions(+), 15 deletions(-)
 rename arch/arm/mach-omap1/{include/mach => }/board-sx1.h (100%)
 rename arch/arm/mach-omap1/{include/mach => }/camera.h (100%)
 rename arch/arm/mach-omap1/{include/mach => }/flash.h (100%)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index a95499ea8706..9fc70978823b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -41,7 +41,7 @@
 
 #include 
 #include 
-#include 
+#include "camera.h"
 #include 
 
 #include "iomap.h"
diff --git a/arch/arm/mach-omap1/board-fsample.c 
b/arch/arm/mach-omap1/board-fsample.c
index 0fb51d22c8b5..fad95b74bb65 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -29,7 +29,7 @@
 
 #include 
 #include 
-#include 
+#include "flash.h"
 #include 
 
 #include 
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 8340d684d8b6..cd146ed0538d 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -42,7 +42,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "flash.h"
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 086ff34e072b..f7c8c63dd532 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -44,7 +44,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "flash.h"
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-innovator.c 
b/arch/arm/mach-omap1/board-innovator.c
index ed4e045c2ad8..ae90bd02b3bf 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -32,7 +32,7 @@
 #include 
 
 #include 
-#include 
+#include "flash.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 0efd165b8227..209aecb0df68 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -46,7 +46,7 @@
 #include 
 #include 
 
-#include 
+#include "flash.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-omap1/board-palmte.c 
b/arch/arm/mach-omap1/board-palmte.c
index 1142ae431fe0..e5288cda1a6a 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 
-#include 
+#include "flash.h"
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-palmtt.c 
b/arch/arm/mach-omap1/board-palmtt.c
index 54a547a96950..d672495f7441 100644
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 
-#include 
+#include "flash.h"
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-palmz71.c 
b/arch/arm/mach-omap1/board-palmz71.c
index 87ec04ae40dd..aaf741b0aff6 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -36,7 +36,7 @@
 #include 
 #include 
 
-#include 
+#include "flash.h"
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-perseus2.c 
b/arch/arm/mach-omap1/board-perseus2.c
index 3d76f05407f0..150b57ba42bf 100644
--- a/arch/arm/mach-omap1/board-perseus2.c
+++ b/arch/arm/mach-omap1/board-perseus2.c
@@ -30,7 +30,7 @@
 
 #include 
 #include 
-#include 
+#include "flash.h"
 
 #include 
 
diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c 
b/arch/arm/mach-omap1/board-sx1-mmc.c
index 4fcf19c78a08..a9373570bbb1 100644
--- a/arch/arm/mach-omap1/board-sx1-mmc.c
+++ b/arch/arm/mach-omap1/board-sx1-mmc.c
@@ -16,7 +16,7 @@
 #include 
 
 #include 
-#include 
+#include "board-sx1.h"
 
 #include &quo

[PATCH 6/7] ARM: mvebu: remove unused mach/gpio.h

[Arnd Bergmann]

This file was left over from a cleanup of asm/gpio.h and has
not been used in a while. Let's just remove it now, so the
arch/arm/mach-mvebu/include/ directory can also disappear.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 arch/arm/mach-mvebu/include/mach/gpio.h | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 arch/arm/mach-mvebu/include/mach/gpio.h

diff --git a/arch/arm/mach-mvebu/include/mach/gpio.h 
b/arch/arm/mach-mvebu/include/mach/gpio.h
deleted file mode 100644
index 40a8c178f10d..
--- a/arch/arm/mach-mvebu/include/mach/gpio.h
+++ /dev/null
@@ -1 +0,0 @@
-/* empty */
-- 
2.1.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] ARM: w90x900: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-w90x900
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 arch/arm/mach-w90x900/cpu.c   | 4 ++--
 arch/arm/mach-w90x900/{include/mach => }/regs-ebi.h   | 0
 arch/arm/mach-w90x900/{include/mach => }/regs-gcr.h   | 0
 arch/arm/mach-w90x900/{include/mach => }/regs-timer.h | 0
 arch/arm/mach-w90x900/{include/mach => }/regs-usb.h   | 0
 arch/arm/mach-w90x900/time.c  | 2 +-
 6 files changed, 3 insertions(+), 3 deletions(-)
 rename arch/arm/mach-w90x900/{include/mach => }/regs-ebi.h (100%)
 rename arch/arm/mach-w90x900/{include/mach => }/regs-gcr.h (100%)
 rename arch/arm/mach-w90x900/{include/mach => }/regs-timer.h (100%)
 rename arch/arm/mach-w90x900/{include/mach => }/regs-usb.h (100%)

diff --git a/arch/arm/mach-w90x900/cpu.c b/arch/arm/mach-w90x900/cpu.c
index 213230ee57d1..ca763251ffe0 100644
--- a/arch/arm/mach-w90x900/cpu.c
+++ b/arch/arm/mach-w90x900/cpu.c
@@ -33,8 +33,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include "regs-ebi.h"
+#include "regs-timer.h"
 
 #include "cpu.h"
 #include "clock.h"
diff --git a/arch/arm/mach-w90x900/include/mach/regs-ebi.h 
b/arch/arm/mach-w90x900/regs-ebi.h
similarity index 100%
rename from arch/arm/mach-w90x900/include/mach/regs-ebi.h
rename to arch/arm/mach-w90x900/regs-ebi.h
diff --git a/arch/arm/mach-w90x900/include/mach/regs-gcr.h 
b/arch/arm/mach-w90x900/regs-gcr.h
similarity index 100%
rename from arch/arm/mach-w90x900/include/mach/regs-gcr.h
rename to arch/arm/mach-w90x900/regs-gcr.h
diff --git a/arch/arm/mach-w90x900/include/mach/regs-timer.h 
b/arch/arm/mach-w90x900/regs-timer.h
similarity index 100%
rename from arch/arm/mach-w90x900/include/mach/regs-timer.h
rename to arch/arm/mach-w90x900/regs-timer.h
diff --git a/arch/arm/mach-w90x900/include/mach/regs-usb.h 
b/arch/arm/mach-w90x900/regs-usb.h
similarity index 100%
rename from arch/arm/mach-w90x900/include/mach/regs-usb.h
rename to arch/arm/mach-w90x900/regs-usb.h
diff --git a/arch/arm/mach-w90x900/time.c b/arch/arm/mach-w90x900/time.c
index cd1966ec9143..cda085245e34 100644
--- a/arch/arm/mach-w90x900/time.c
+++ b/arch/arm/mach-w90x900/time.c
@@ -31,7 +31,7 @@
 #include 
 
 #include 
-#include 
+#include "regs-timer.h"
 
 #include "nuc9xx.h"
 
-- 
2.1.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/7] ARM: ks8695: make headers more local

[Arnd Bergmann]

Some header files are never included outside of a mach-ks8695
directory and do not need to be made visible in include/mach,
so let's just move them all down one level.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
 arch/arm/mach-ks8695/board-acs5k.c  | 2 +-
 arch/arm/mach-ks8695/board-dsm320.c | 2 +-
 arch/arm/mach-ks8695/board-micrel.c | 2 +-
 arch/arm/mach-ks8695/board-og.c | 2 +-
 arch/arm/mach-ks8695/board-sg.c | 2 +-
 arch/arm/mach-ks8695/cpu.c  | 2 +-
 arch/arm/mach-ks8695/devices.c  | 6 +++---
 arch/arm/mach-ks8695/{include/mach => }/devices.h   | 0
 arch/arm/mach-ks8695/pci.c  | 4 ++--
 arch/arm/mach-ks8695/{include/mach => }/regs-hpna.h | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-lan.h  | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-mem.h  | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-pci.h  | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-sys.h  | 0
 arch/arm/mach-ks8695/{include/mach => }/regs-wan.h  | 0
 15 files changed, 11 insertions(+), 11 deletions(-)
 rename arch/arm/mach-ks8695/{include/mach => }/devices.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-hpna.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-lan.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-mem.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-pci.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-sys.h (100%)
 rename arch/arm/mach-ks8695/{include/mach => }/regs-wan.h (100%)

diff --git a/arch/arm/mach-ks8695/board-acs5k.c 
b/arch/arm/mach-ks8695/board-acs5k.c
index 9f9c0441a917..e4d709c8ed32 100644
--- a/arch/arm/mach-ks8695/board-acs5k.c
+++ b/arch/arm/mach-ks8695/board-acs5k.c
@@ -33,7 +33,7 @@
 #include 
 #include 
 
-#include 
+#include "devices.h"
 #include 
 
 #include "generic.h"
diff --git a/arch/arm/mach-ks8695/board-dsm320.c 
b/arch/arm/mach-ks8695/board-dsm320.c
index d37c218c3584..13537e9c5485 100644
--- a/arch/arm/mach-ks8695/board-dsm320.c
+++ b/arch/arm/mach-ks8695/board-dsm320.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#include 
+#include "devices.h"
 #include 
 
 #include "generic.h"
diff --git a/arch/arm/mach-ks8695/board-micrel.c 
b/arch/arm/mach-ks8695/board-micrel.c
index 3acbdfd31391..69cfb9935fc1 100644
--- a/arch/arm/mach-ks8695/board-micrel.c
+++ b/arch/arm/mach-ks8695/board-micrel.c
@@ -19,7 +19,7 @@
 #include 
 
 #include 
-#include 
+#include "devices.h"
 
 #include "generic.h"
 
diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
index f2658168eeff..1f4f2f4f25bb 100644
--- a/arch/arm/mach-ks8695/board-og.c
+++ b/arch/arm/mach-ks8695/board-og.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "devices.h"
 #include 
 #include 
 #include "generic.h"
diff --git a/arch/arm/mach-ks8695/board-sg.c b/arch/arm/mach-ks8695/board-sg.c
index fdf2352d2cf8..46e455c3821b 100644
--- a/arch/arm/mach-ks8695/board-sg.c
+++ b/arch/arm/mach-ks8695/board-sg.c
@@ -16,7 +16,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "devices.h"
 #include "generic.h"
 
 /*
diff --git a/arch/arm/mach-ks8695/cpu.c b/arch/arm/mach-ks8695/cpu.c
index ddb24222918e..474a050da85b 100644
--- a/arch/arm/mach-ks8695/cpu.c
+++ b/arch/arm/mach-ks8695/cpu.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 
-#include 
+#include "regs-sys.h"
 #include 
 
 
diff --git a/arch/arm/mach-ks8695/devices.c b/arch/arm/mach-ks8695/devices.c
index 47399bc3c024..61cf20beb45f 100644
--- a/arch/arm/mach-ks8695/devices.c
+++ b/arch/arm/mach-ks8695/devices.c
@@ -24,9 +24,9 @@
 #include 
 
 #include 
-#include 
-#include 
-#include 
+#include "regs-wan.h"
+#include "regs-lan.h"
+#include "regs-hpna.h"
 #include 
 #include 
 
diff --git a/arch/arm/mach-ks8695/include/mach/devices.h 
b/arch/arm/mach-ks8695/devices.h
similarity index 100%
rename from arch/arm/mach-ks8695/include/mach/devices.h
rename to arch/arm/mach-ks8695/devices.h
diff --git a/arch/arm/mach-ks8695/pci.c b/arch/arm/mach-ks8695/pci.c
index c1bc4c3716ed..577a35f75c8a 100644
--- a/arch/arm/mach-ks8695/pci.c
+++ b/arch/arm/mach-ks8695/pci.c
@@ -33,8 +33,8 @@
 #include 
 #include 
 
-#include 
-#include 
+#include "devices.h"
+#include "regs-pci.h"
 
 
 static int pci_dbg;
diff --git a/arch/arm/mach-ks8695/include/mach/regs-hpna.h 
b/arch/arm/mach-ks8695/regs-hpna.h
similarity index 100%
rename from arch/arm/mach-ks8695/include/mach/regs-hpna.h
rename to arch/arm/mach-ks8695/regs-hpna.h
diff --git a/arch/arm/mach-ks8695/include/mach/regs-lan.h 
b/arch/arm/mach-ks8695/regs-lan.h
similarity index 100%
rename from arch/arm/mach-ks8695/include/mach/regs-lan.h
rename to arch/arm/mach-ks8695/regs-lan.h
diff --git

[PATCH 0/7] ARM: make mach/*.h headers more local

[Arnd Bergmann]

I've already posted the mach-pxa cleanup along the same lines,
here is another bunch of patches. I'd like to put them into
the next/multiplatform branch in arm-soc.

They come from an old script of mine to look for headers that
are not used by drivers, and I've done thousands of randconfig
builds with them applied, so I'm rather sure that they are all
harmless.

Arnd Bergmann (7):
  ARM: omap1: make headers more local
  ARM: ks8695: make headers more local
  ARM: davinci: make headers more local
  ARM: iop13xx: make headers more local
  ARM: w90x900: make headers more local
  ARM: mvebu: remove unused mach/gpio.h
  ARM: netx: remove unused mach/param.h

 arch/arm/mach-davinci/board-da830-evm.c|  2 +-
 arch/arm/mach-davinci/board-da850-evm.c|  4 +-
 arch/arm/mach-davinci/board-mityomapl138.c |  2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c|  2 +-
 arch/arm/mach-davinci/clock.c  |  2 +-
 arch/arm/mach-davinci/cp_intc.c|  2 +-
 arch/arm/mach-davinci/{include/mach => }/cp_intc.h |  0
 arch/arm/mach-davinci/cpuidle.c|  4 +-
 arch/arm/mach-davinci/{include/mach => }/cpuidle.h |  0
 arch/arm/mach-davinci/da830.c  |  2 +-
 arch/arm/mach-davinci/da850.c  |  2 +-
 arch/arm/mach-davinci/da8xx-dt.c   |  2 +-
 arch/arm/mach-davinci/{include/mach => }/ddr2.h|  0
 arch/arm/mach-davinci/devices-da8xx.c  |  4 +-
 arch/arm/mach-davinci/dm355.c  |  2 +-
 arch/arm/mach-davinci/dm365.c  |  2 +-
 arch/arm/mach-davinci/dm644x.c |  2 +-
 arch/arm/mach-davinci/dm646x.c |  2 +-
 arch/arm/mach-davinci/pm.c |  2 +-
 arch/arm/mach-davinci/psc.c|  2 +-
 arch/arm/mach-davinci/{include/mach => }/psc.h |  0
 arch/arm/mach-davinci/sleep.S  |  4 +-
 arch/arm/mach-davinci/sram.c   |  2 +-
 arch/arm/mach-davinci/{include/mach => }/sram.h|  0
 arch/arm/mach-iop13xx/include/mach/pci.h   | 57 -
 arch/arm/mach-iop13xx/iq81340mc.c  |  2 +-
 arch/arm/mach-iop13xx/iq81340sc.c  |  2 +-
 arch/arm/mach-iop13xx/irq.c|  2 +-
 arch/arm/mach-iop13xx/{include/mach => }/msi.h |  0
 arch/arm/mach-iop13xx/pci.c|  2 +-
 arch/arm/mach-iop13xx/pci.h| 58 ++
 arch/arm/mach-ks8695/board-acs5k.c |  2 +-
 arch/arm/mach-ks8695/board-dsm320.c|  2 +-
 arch/arm/mach-ks8695/board-micrel.c|  2 +-
 arch/arm/mach-ks8695/board-og.c|  2 +-
 arch/arm/mach-ks8695/board-sg.c|  2 +-
 arch/arm/mach-ks8695/cpu.c |  2 +-
 arch/arm/mach-ks8695/devices.c |  6 +--
 arch/arm/mach-ks8695/{include/mach => }/devices.h  |  0
 arch/arm/mach-ks8695/pci.c |  4 +-
 .../arm/mach-ks8695/{include/mach => }/regs-hpna.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-lan.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-mem.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-pci.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-sys.h |  0
 arch/arm/mach-ks8695/{include/mach => }/regs-wan.h |  0
 arch/arm/mach-mvebu/include/mach/gpio.h|  1 -
 arch/arm/mach-netx/include/mach/param.h| 18 ---
 arch/arm/mach-omap1/board-ams-delta.c  |  2 +-
 arch/arm/mach-omap1/board-fsample.c|  2 +-
 arch/arm/mach-omap1/board-h2.c |  2 +-
 arch/arm/mach-omap1/board-h3.c |  2 +-
 arch/arm/mach-omap1/board-innovator.c  |  2 +-
 arch/arm/mach-omap1/board-osk.c|  2 +-
 arch/arm/mach-omap1/board-palmte.c |  2 +-
 arch/arm/mach-omap1/board-palmtt.c |  2 +-
 arch/arm/mach-omap1/board-palmz71.c|  2 +-
 arch/arm/mach-omap1/board-perseus2.c   |  2 +-
 arch/arm/mach-omap1/board-sx1-mmc.c|  2 +-
 arch/arm/mach-omap1/board-sx1.c|  4 +-
 arch/arm/mach-omap1/{include/mach => }/board-sx1.h |  0
 arch/arm/mach-omap1/{include/mach => }/camera.h|  0
 arch/arm/mach-omap1/devices.c  |  2 +-
 arch/arm/mach-omap1/flash.c|  2 +-
 arch/arm/mach-omap1/{include/mach => }/flash.h |  0
 arch/arm/mach-w90x900/cpu.c|  4 +-
 .../arm/mach-w90x900/{include/mach => }/regs-ebi.h |  0
 .../arm/mach-w90x900/{include/mach => }/regs-gcr.h |  0
 .../mach-w90x900/{include/mach => }/regs-timer.h   |  0
 .../arm/mach-w90x900/{include/mach => }/regs-usb.h |  0
 arch/arm/mach-w90x900/time.c   |  2 +-
 71 files changed, 114 i

Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Arnd Bergmann]

On Monday 30 November 2015 15:45:33 Peter Ujfalusi wrote:
>   const char *name);
>  struct dma_chan *dma_request_slave_channel(struct device *dev, const char 
> *name);
> +
> +struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> +struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
> +
>  void dma_release_channel(struct dma_chan *chan);
>  int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps);
>  #else
> @@ -1268,6 +1291,14 @@ static inline struct dma_chan 
> *dma_request_slave_channel(struct device *dev,
>  {
> return NULL;
>  }
> +static inline struct dma_chan *dma_request_chan(struct device *dev)
> +{
> +   return ERR_PTR(-ENODEV);
> +}
> 

The prototypes for dma_request_chan() don't match, otherwise looks good.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Arnd Bergmann]

On Monday 30 November 2015 15:45:34 Peter Ujfalusi wrote:
> @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void *param)
>  }
>  EXPORT_SYMBOL(edma_filter_fn);
>  
> +static bool edma_filter_for_map(struct dma_chan *chan, void *param)
> +{
> +   bool match = false;
> +
> +   if (chan->device->dev->driver == _driver.driver) {
> +   struct edma_chan *echan = to_edma_chan(chan);
> +   unsigned ch_req = (unsigned)param;
> +   if (ch_req == echan->ch_num) {
> +   /* The channel is going to be used as HW synchronized 
> */
> +   echan->hw_triggered = true;
> +   match = true;
> +   }
> +   }
> +   return match;
> +}
> +
>  static int edma_init(void)
> 

I don't see the difference between edma_filter_fn and edma_filter_for_map.
Why do you need both?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Monday 30 November 2015 15:45:30 Peter Ujfalusi wrote:
> Changes since RFC v01:
>- dma_request_chan(); lost the mask parameter
>- The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
>  will be used to provide the needed information to the filter function in
>  legacy mode
>- Extended the example patches to convert most of daVinci to use the new API to
>  request the DMA channels.

Very nice overall. Just a few minor comments.

> static struct dma_filter_map da830_edma_map[] = {
> DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
> DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
> DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
> DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
> DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
> DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
> DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
> DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
> DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
> DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
> DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
> DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> };

I wonder if we should mandate that the lookup table is 'const'.

We could also drop the DMA_FILTER_ENTRY() macro above, and open-code the
table like

static struct dma_filter_map da830_edma_map[] = {
 { "davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)},
 { "davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)},
 { "davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)},
 ...
};

which is a little more compact and more obvious, but loses the
named initializers.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Friday 27 November 2015 18:28:50 Nicolas Pitre wrote:
> On Fri, 27 Nov 2015, Arnd Bergmann wrote:
> 
> > I don't mind creating the /proc/atags compatibility hack from the kernel
> > for a DT based N700 kernel, as long as we limit it as much as we can
> > to the machines that need it. Leaving a board file for the N700 in place
> > that contains the procfs code (and not much more) seems reasonable
> > here, as we are talking about a board specific hack and the whole point
> > appears to be running unmodified user space.
> > 
> > Regarding how to get the data into the kernel in the first place, my
> > preferred choice would still be to have an intermediate bootloader
> > such as pxa-impedance-matcher, but I won't complain if others are
> > happy enough about putting it into the ATAGS compat code we already
> > have, as long as it's limited to the boards we know need it.
> 
> Assuming you have a N700 board file for special procfs code, then why 
> not getting at the atags in memory where the bootloader has put them 
> directly from that same board file? This way it'll really be limited to 
> the board we know needs it and the special exception will be contained 
> to that one file.  Amongst the machine specific hooks, there is one that 
> gets invoked early during boot before those atags are overwritten.

I didn't realize this was possible, as we don't know the atags pointer
when we instead get a DTB pointer. However you are right: the board
file knows exactly that the atag_offset is 0x100, so we can grab it
from there, and that will make the implementation really easy and
contained to a single file that has access to the atags and that
can create the /proc/atags file for it.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/6] dmaengine: core: Introduce new, universal API to request a channel

[Arnd Bergmann]

On Friday 27 November 2015 13:16:37 Peter Ujfalusi wrote:
> On 11/27/2015 01:00 PM, Arnd Bergmann wrote:
> > On Friday 27 November 2015 10:29:39 Peter Ujfalusi wrote:
> >> struct dma_chan *dma_request_chan(struct device *dev, const char *name,
> >>const dma_cap_mask_t *mask);
> >> To request a slave channel. The mask parameter is optional and it is used
> >> to check if the received channel's capabilities can satisfy the requested
> >> mask. The dma_request_chan() will try to find the channel via DT, ACPI or
> >> in case if the kernel booted in non DT/ACPI mode it will use a filter
> >> lookup table and retrieves the RESOURCE_DMA from the requester's device.
> >> This legacy mode needs changes in platform code, in dmaengine drivers and
> >> finally the dmaengine user drivers can be converted:
> > 
> > I think we should not introduce the mask parameter at all. In the rare
> > case that we actually need to pass a mask other than DMA_SLAVE today,
> > we should be able to encode that in the data we pass to the filter
> > function.
> 
> I have seen that drivers check the capabilities themselves after getting the
> channel, so I thought that if we move that also to the core we can save on
> duplicated lines around the kernel. It is not needed to get the channel. As
> you can see in the mmc patch, I pass NULL and the channel I got is the correct
> one.
> Sure, I can remove it.

Ok.

> >> RESOURCE_DMA needs to be added to the platform devices with names
> >>
> >> For each dmaengine driver a string array listing the devices handled by the
> >> given DMA driver:
> >>
> >> static char *da8xx_edma0_devices[] = {
> >>  "davinci-mcasp.0",
> >>  "da830-mmc.0",
> >> };
> >>
> >> This information is going to be needed by the dmaengine driver, so
> >> modification to the platform_data is needed, and the driver map should be
> >> added to the pdata of the DMA driver:
> > 
> > However, a lot of drivers definitely need to pass a data pointer for
> > each device. I see that you currently rely on the IORESOURCE_DMA
> > method that a couple of platforms use today, but I think it would
> > be backwards to do it that way for the platforms that require passing
> > more than an integer number today.
> > 
> > Having a pointer as the filter function argument is intentional and I'd
> > prefer to change the platforms that currently use IORESOURCE_DMA (davinci,
> > pxa, omap1, blackfin, alchemy) to stop doing it instead, and return
> > IORESOURCE_DMA to its original meaning that was limited to ISAPNP style
> > devices not using the dmaengine API.
> 
> Something like this:
> 
> /* include/linux/dmaengine.h */
> 
> struct dma_filter_map {
> char *devname;
> char *slave;
> void *param;
> };
> 
> struct dma_filter {
> dma_filter_fn filter_fn;
> int mapcnt;
> struct dma_filter_map *map;
> };
> 
> /* arch/arm/mach-davinci/devices-da8xx.c */
> 
> static struct dma_filter_map da8xx_edma0_map[] = {
> {
> .devname = "davinci-mcasp.0",
> .slave = "tx",
> .param = (void*)DAVINCI_DA8XX_DMA_MCASP0_AXEVT,
> },
> {
> .devname = "davinci-mcasp.0",
> .slave = "rx",
> .param = (void*)DAVINCI_DA8XX_DMA_MCASP0_AREVT,
> },
> {
> .devname = "da830-mmc.0",
> .slave = "tx",
> .param = (void*)DA8XX_DMA_MMCSD0_TX,
> },
> {
> .devname = "da830-mmc.0",
> .slave = "rx",
> .param = (void*)DA8XX_DMA_MMCSD0_RX,
> },
> };
> 
> I had this version first, but decided to go with a simpler one present in this
> RFC series.

Yes, that is what I had in mind. Let's see what others think about the two
options.

I would also avoid the 'struct dma_filter' entirely by using a zero-terminated
list and passing the filter function and map table separately, but your approach
seems reasonable as well.

In my initial suggestion, the idea was to do the registration of the filter map
separately from registering the dmaengine device to give us a little more
flexibility in converting existing code, but it requires listing both the
dmaengine device and the slave devname in the map, so your approach is probably
better in the long run even if it requires a little more work for doing the
conversion.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/6] dmaengine: core: Introduce new, universal API to request a channel

[Arnd Bergmann]

On Friday 27 November 2015 10:29:39 Peter Ujfalusi wrote:
> struct dma_chan *dma_request_chan(struct device *dev, const char *name,
> const dma_cap_mask_t *mask);
> To request a slave channel. The mask parameter is optional and it is used
> to check if the received channel's capabilities can satisfy the requested
> mask. The dma_request_chan() will try to find the channel via DT, ACPI or
> in case if the kernel booted in non DT/ACPI mode it will use a filter
> lookup table and retrieves the RESOURCE_DMA from the requester's device.
> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:

I think we should not introduce the mask parameter at all. In the rare
case that we actually need to pass a mask other than DMA_SLAVE today,
we should be able to encode that in the data we pass to the filter
function.

> RESOURCE_DMA needs to be added to the platform devices with names
> 
> For each dmaengine driver a string array listing the devices handled by the
> given DMA driver:
> 
> static char *da8xx_edma0_devices[] = {
>   "davinci-mcasp.0",
>   "da830-mmc.0",
> };
> 
> This information is going to be needed by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:

However, a lot of drivers definitely need to pass a data pointer for
each device. I see that you currently rely on the IORESOURCE_DMA
method that a couple of platforms use today, but I think it would
be backwards to do it that way for the platforms that require passing
more than an integer number today.

Having a pointer as the filter function argument is intentional and I'd
prefer to change the platforms that currently use IORESOURCE_DMA (davinci,
pxa, omap1, blackfin, alchemy) to stop doing it instead, and return
IORESOURCE_DMA to its original meaning that was limited to ISAPNP style
devices not using the dmaengine API.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Friday 27 November 2015 19:51:48 Russell King - ARM Linux wrote:
> On Fri, Nov 27, 2015 at 01:27:23PM +, Russell King - ARM Linux wrote:
> > It is possible to redirect any program to open any other file.  You can
> > do it via a LD preload, and intercepting the open(), and possibly the
> > read() calls if you want to do something more fancy.  The down-side is
> > that you have to arrange for the preloaded object to be used by the
> > linker, and the additional overhead it places on the intercepted
> > functions.
> 
> Another idea if people don't like the preload idea.
> 
> We could create a zero-sized /proc/atags, and then use a bind mount in
> userspace to bind some other file containing the required information
> on top.  That could even be the atag blob from /sys/firmware/whatever.
> The N700 (or whatever platform needs it) could be responsible for
> creating the zero-sized /proc/atags so that we don't have it everywhere.

I don't mind creating the /proc/atags compatibility hack from the kernel
for a DT based N700 kernel, as long as we limit it as much as we can
to the machines that need it. Leaving a board file for the N700 in place
that contains the procfs code (and not much more) seems reasonable
here, as we are talking about a board specific hack and the whole point
appears to be running unmodified user space.

Regarding how to get the data into the kernel in the first place, my
preferred choice would still be to have an intermediate bootloader
such as pxa-impedance-matcher, but I won't complain if others are
happy enough about putting it into the ATAGS compat code we already
have, as long as it's limited to the boards we know need it.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap fixes against v4.4-rc2

[Arnd Bergmann]

On Wednesday 25 November 2015 14:37:04 Tony Lindgren wrote:
> Fixes for omaps for v4.4-rc cycle:
> 
> - A series of audio changes for dra7 that missed the merge window but turned
>   out to be necessary to fix a boot time imprecise external abort error and to
>   getaudio working
> 
> - Fix l4 related boot time errors for dm81xx
> 
> - Use lockless cldm/pwrdm api in omap4_boot_secondary
> 
> - Remove t410 custom abort handler that is no longer needed and may
>   hide other critical errors
> 
> - Mark cpuidle tracepoints as _rcuidle
> 
> - Fix module alias for omap-ocp2scp
> 

Merged into fixes, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> * Pali Rohár  [151123 06:46]:
> > On Sunday 22 November 2015 07:51:46 Pavel Machek wrote:
> > > On Wed 2015-11-11 17:10:46, Frank Rowand wrote:
> > > > Adding devicetree list.
> > > > 
> > > > Thread starts at
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html
> > > > 
> > > > On 11/5/2015 8:17 AM, Tony Lindgren wrote:
> > > > > * Pali Rohár  [151105 03:41]:
> > > > >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote:
> > > > >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote:
> > > >  * Pali Rohár  [151012 13:29]:
> > > > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote:
> > > > >>
> > > > >> Pali, any news on posting an updated series with the comments
> > > > >> addressed in this thread? It seems that we all pretty much agree
> > > > >> what needs to be done.
> > > > 
> > > > I'm not real happy with the concept of patches 4 and 5 in this series.
> > > > My concern is that those two patches are using the FDT as a transport
> > > > mechanism for a binary blob (the atags object).
> > > 
> > > Umm. Ok. Do you have alternative proposal that works for everyone?
> > > 
> > > I mean. This discussion was going for quite a long time, and it would
> > > be nice to have some solution... patch proposal... something.
> > > Pavel
> > 
> > Yes, discussion is going for a long time! So should I spend time for
> > adding documentation to my solution (this is last one thing which is
> > missing)? Or my solution is wrong and somebody else will propose new?
> > I do not want to spend time on something which will be rejected and
> > discarded.
> 
> At least I don't have better solutions in mind.

I would be happier if we could restrict this as much as possible to the
boards that need it, as an opt-in. That way it doesn't become an ABI
for people that don't already rely in this information. How about
adding a check the code adds the linux,atags property to do it
only for a whitelist of board numbers?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote:
> 
> Arnd, my question about proper solution reminds... Proprietary 
> bootloader which cannot be replaced (e.g. it is signed or do unknown 
> magic) provides information to booted kernel via custom specific ATAGs 
> fields. How userspace could properly read those custom information from 
> bootloader?

The typical solution for nonstandard bootloaders is to have a boot wrapper
like the one from https://github.com/zonque/pxa-impedance-matcher that
translates whatever information we have at the bootloader level into
DT properties.

As I understand, the reason we are not doing that here is that we also
have proprietary user space that we can't fix to look in a different
place, i.e. the interface is between the bootloader and some user
binary, not bootloader to kernel.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

[Arnd Bergmann]

On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote:
> * Arnd Bergmann <a...@arndb.de> [151125 11:50]:
> > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote:
> > > At least I don't have better solutions in mind.
> > 
> > I would be happier if we could restrict this as much as possible to the
> > boards that need it, as an opt-in. That way it doesn't become an ABI
> > for people that don't already rely in this information. How about
> > adding a check the code adds the linux,atags property to do it
> > only for a whitelist of board numbers?
> 
> Or populate /proc/atags only for the ones that need it from machine
> specific init_early?

That would also address my main concern about /proc/atags, but still
leave the atags in /proc/device-tree/chosen/linux,atags, and it would
be bad if someone who currently uses /proc/atags changes their code
to use the other file instead of finding a proper solution.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Friday 20 November 2015 14:52:03 Peter Ujfalusi wrote:
> 
> >> For legacy the filter function is pretty much needed to handle the 
> >> differences
> >> between the platforms as not all of them does the filtering in a same way. 
> >> So
> >> the first type of map would be feasible IMHO.
> > 
> > It certainly makes the transition to a map table much easier.
> 
> And the aim anyway is to convert everything to DT, right?

We won't be able to do that. Some architectures (avr32 and sh for instance)
use the dmaengine API but will likely never support DT. On ARM, at
least sa1100 is in the same category, probably also ep93xx and portions
of pxa, omap1 and davinci.

> > int dmam_register_platform_map(struct device *dev, dma_filter_fn filter, 
> > struct dma_chan_map *map)
> > {
> >   struct dma_map_list *list = kmalloc(sizeof(*list), GFP_KERNEL);
> > 
> >   if (!list)
> >   return -ENOMEM;
> > 
> >   list->dev = dev;
> >   list->filter = filter;
> >   list->map = map;
> > 
> >   mutex_lock(_map_mutex);
> >   list_add(_map_list, >node);
> >   mutex_unlock(_map_mutex);
> > }
> > 
> > Now we can completely remove the dependency on the filter function 
> > definition
> > from platform code and slave drivers.
> 
> Sounds feasible for OMAP and daVinci and for others as well. I think 
> I would go with this if someone asks my opinion 

Ok.

> The core change to add the new API + the dma_map support should be pretty
> straight forward. It can live alongside with the old API and we can phase out
> the users of the old one.
> The legacy support would need more time since we need to modify the arch codes
> and the corresponding DMA drivers to get the map registered, but after that
> the remaining drivers can be converted to use the new API.

Right. It's not urgent and as long as we agree on the overall approach, we can
always do the platform support first and wait for the following merge window
before moving over the slave drivers.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote:
> On 11/19/2015 01:25 PM, Arnd Bergmann wrote:
> >> dma_request_channel(mask); /* memcpy. etc, non slave mostly */
> >>
> >> Not sure how to name this as reusing existing (good, descriptive) function
> >> names would mean changes all over the kernel to start off this.
> >>
> >> Not used and
> >> request_dma_channel(); /* as _irq/_mem_region/_resource, etc */
> >> request_dma();
> >> dma_channel_request();
> > 
> > dma_request_slavechan();
> > dma_request_slave();
> > dma_request_mask();
> 
> Let me think aloud here a bit...
> 1. To request slave channel which will return you the channel your device is
> bind via DT/ACPI or the platform map table you propose later:
> 
> dma_request_chan(struct device *dev, const char *name);
> 
> 2. To request a channel (any channel) matching with the capabilities the
> driver needs, like memcpy, memset, etc:
> 
> #define dma_request_chan_by_mask(mask) __dma_request_chan_by_mask(&(mask))
> __dma_request_chan_by_mask(const dma_cap_mask_t *mask);
> 
> I think the dma_request_chan() does not need mask to be passed, since via this
> we request a specific channel which has been defined/set by DT/ACPI or the
> lookup map. We could add a mask parameter which could be used to sanity check
> the channel we got against the capabilities the driver needs from the channel.
> We currently do this in the drivers where the author wanted to make sure that
> the channel is capable of what it should be capable.
> 
> So two API to request channel:
> struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
> 
> Both will return with the valid channel pointer or in case of failure with
> ERR_PTR().
> 
> We need to go through the code in regards to return codes also to have sane
> mapping.

Right.
> > That way the vast majority of drivers can use one of the two nice interfaces
> > and the rest can be converted to use __dma_request_chan().
> > 
> > On a related topic, we had in the past considered providing a way for
> > platform code to register a lookup table of some sort, to associate
> > a device/name pair with a configuration. That would let us use the
> > simplified dma_request_slavechan(dev, name) pair everywhere. We could
> > use the same method that we have for clk_register_clkdevs() or
> > pinctrl_register_map().
> > 
> > Something like either
> > 
> > static struct dma_chan_map myplatform_dma_map[] = {
> > { .devname = "omap-aes0", .slave = "tx", .filter = omap_dma_filter_fn, 
> > .arg = (void *)65, },
> > { .devname = "omap-aes0", .slave = "rx", .filter = omap_dma_filter_fn, 
> > .arg = (void *)66, },
> > };
> > 
> > or
> > 
> > static struct dma_chan_map myplatform_dma_map[] = {
> > { .devname = "omap-aes0", .slave = "tx", .master = "omap-dma-engine0", 
> > .req = 65, },
> > { .devname = "omap-aes0", .slave = "rx", .master = "omap-dma-engine0", 
> > .req = 66, },
> 
> sa11x0-dma expects the fn_param as string :o

Some of them do, but the new API requires changes in both the DMA master and
slave drivers, so that could be changed if we wanted to, or we just allow 
both methods indefinitely and let sa11x0-dma pass the filterfn+data rather than
a number.

> > };
> 
> Basically we are deprecating the use of IORESOURCE_DMA?

I thought we already had ;-)

> For legacy the filter function is pretty much needed to handle the differences
> between the platforms as not all of them does the filtering in a same way. So
> the first type of map would be feasible IMHO.

It certainly makes the transition to a map table much easier.

> > we could even allow a combination of the two, so the simple case just 
> > specifies
> > master and req number, which requires changes to the dmaengine driver, but 
> > we could
> > also do a mass-conversion to the .filter/.arg variant.
> 
> This will get rid of the need for the fn and fn_param parameters when
> requesting dma channel, but it will not get rid of the exported function from
> the dma engine drivers since in arch code we need to have visibility to the
> filter_fn.

Correct. A lot of dmaengine drivers already need to be built-in so the platform
code can put a pointer to the filter function, so it would not be worse for 
them.

Another idea would be to remove the filter function from struct dma_chan_map
and pass the map through platform data to the dmaengine driver, which then
r

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Thursday 19 November 2015 12:34:22 Peter Ujfalusi wrote:
> 
> I think we can go with a single API, but I don't really like that:
> dma_request_channel(dev, name, *mask, fn, fn_param);
> 
> This would cover all current uses being legacy, DT/ACPI, compat, etc:
> dma_request_channel(NULL, NULL, , fn, fn_param); /* Legacy slave */
> dma_request_channel(NULL, NULL, , NULL, NULL); /* memcpy. etc */
> dma_request_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current slave */
> dma_request_channel(dev, name, , fn, fn_param); /* current compat */
> 
> Note, that we need "const dma_cap_mask_t *mask" to be able to make the mask
> optional.

Right, that would work, but I also don't really like it.

> If we have two main APIs, one to request slave channels and one to get any
> channel with given capability
> dma_request_slave_channel(NULL, NULL, , fn, fn_param); /* Legacy slave */
> dma_request_slave_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current
>slave */
> dma_request_slave_channel(dev, name, , fn, fn_param); /* current compat*/
> 
> This way we can omit the mask also in cases when the client only want to get
> DMA_SLAVE, we can just build up the mask within the function. If the mask is
> provided we would copy the bits from the provided mask, so for example if you
> want to have DMA_SLAVE+DMA_CYCLIC, the driver only needs to pass DMA_CYCLIC,
> the DMA_SLAVE is going to be set anyways.

I think it's more logical here to have mask=NULL mean that we want DMA_SLAVE,
but otherwise pass the full mask as DMA_SLAVE|DMA_CYCLIC etc.

> dma_request_channel(mask); /* memcpy. etc, non slave mostly */
> 
> Not sure how to name this as reusing existing (good, descriptive) function
> names would mean changes all over the kernel to start off this.
> 
> Not used and
> request_dma_channel(); /* as _irq/_mem_region/_resource, etc */
> request_dma();
> dma_channel_request();

dma_request_slavechan();
dma_request_slave();
dma_request_mask();

> All in all, not sure which way would be better...

I think I would prefer the simplest API to have only the dev+name
arguments, as we tend to move that way for all platforms anyway, and it
seems silly to have all drivers pass three NULL arguments all the time.
At the moment, there are 139 references to dma_request_slave_channel_*
in the kernel, and only 46 of them are dma_request_slave_channel_compat.
Out of those 46, a couple can already be converted back to use
dma_request_slave_channel() because the platform now only supports
devicetree based boots and will not go back to platform data.

How about something like

extern struct dma_chan *
__dma_request_chan(struct device *dev, const char *name,
const dma_cap_mask_t *mask, dma_filter_fn fn, void 
*fn_param);

static inline struct dma_chan *
dma_request_slavechan(struct device *dev, const char *name)
{
return __dma_request_chan(dev, name, NULL, NULL, NULL);
}

static inline struct dma_chan *
dma_request_chan(const dma_cap_mask_t *mask)
{
return __dma_request_chan(NULL, NULL, mask, NULL, NULL);
}

That way the vast majority of drivers can use one of the two nice interfaces
and the rest can be converted to use __dma_request_chan().

On a related topic, we had in the past considered providing a way for
platform code to register a lookup table of some sort, to associate
a device/name pair with a configuration. That would let us use the
simplified dma_request_slavechan(dev, name) pair everywhere. We could
use the same method that we have for clk_register_clkdevs() or
pinctrl_register_map().

Something like either

static struct dma_chan_map myplatform_dma_map[] = {
{ .devname = "omap-aes0", .slave = "tx", .filter = omap_dma_filter_fn, 
.arg = (void *)65, },
{ .devname = "omap-aes0", .slave = "rx", .filter = omap_dma_filter_fn, 
.arg = (void *)66, },
};

or

static struct dma_chan_map myplatform_dma_map[] = {
{ .devname = "omap-aes0", .slave = "tx", .master = "omap-dma-engine0", 
.req = 65, },
{ .devname = "omap-aes0", .slave = "rx", .master = "omap-dma-engine0", 
.req = 66, },
};

we could even allow a combination of the two, so the simple case just specifies
master and req number, which requires changes to the dmaengine driver, but we 
could
also do a mass-conversion to the .filter/.arg variant.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2: use correct timer function for AM43XX and TI81XX

[Arnd Bergmann]

On Monday 16 November 2015 15:13:55 Felipe Balbi wrote:
> Arnd Bergmann <a...@arndb.de> writes:
> > AM43XX and TI81XX use omap3_gptimer_timer_init(), but that is only
> > built into the kernel for OMAP3 and AM33XX, otherwise we get:
> >
> > arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x124): undefined reference 
> > to `omap3_gptimer_timer_init'
> >
> > This changes the Kconfig logic for building the function to
> > match the callers. Consequently, we no longer need to build
> > the omap3_secure_sync32k_timer_init and omap4_local_timer_init
> > for the platforms that have been moved over to other functions.
> >
> > Signed-off-by: Arnd Bergmann <a...@arndb.de>
> 
> no, AM43xx uses omap4_local_timer_init(), there's already a fix in
> Tony's tree IIRC.
...
 
> care to provide a defconfig which would cause a build error ?

My mistake, the code has changed several times and I adapted it to
the latest version each time, but the version I sent out is indeed
useless.

The only hunk that still makes sense is

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b18ebbefae09..b7ab09cc5ca2 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -494,7 +494,7 @@ void __init omap_init_time(void)
clocksource_probe();
 }
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
+#if defined(CONFIG_ARCH_OMAP3)
 void __init omap3_secure_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",


but that is harmless as it does not cause a build error, just a few extra
bytes for an unused function in a AM43XX-only configuration.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote:
> On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
> >> 2. non slave channel requests, where only the functionality matters, like
> >> memcpy, interleaved, memset, etc.
> >> We could have a simple:
> >> dma_request_channel(mask);
> >>
> >> But looking at the drivers using dmaengine legacy dma_request_channel() 
> >> API:
> >> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
> >> drivers/misc/carma/carma-fpga.c 
> >> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
> >> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
> >> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
> >> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
> >>
> >> as examples.
> >> Not sure how valid are these...

I just had a look myself. carma has been removed fortunately in linux-next,
so we don't have to worry about that any more.

I assume that the sst-firmware.c case is a mistake, it should just use a
plain DMA_SLAVE and not DMA_MEMCPY.

Aside from these, everyone else uses either DMA_CYCLIC in addition to
DMA_SLAVE, which seems valid, or they use DMA_PRIVATE, which I think is
redundant in slave drivers and can be removed.

> > It's usually not much harder to separate out the legacy case from
> > the normal dma_request_slave_channel_reason(), so those drivers don't
> > really need to use the unified compat API.
> 
> The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
> Currently there is no way to get the reason why the dma channel request fails
> when using the _compat() version of the API, which is used by drivers which
> can be used in DT or in legacy mode as well. Sure, they all could have local
> if(){}else{} for handling this, but it is not a nice thing.
> 
> As it was discussed instead of adding the _reason() version for the _compat
> call, we should simplify the dmaengine API for getting the channel and at the
> same time we will have ERR_PTR returned instead of NULL.

What I meant was that we don't need to handle them with the unified
simple interface. The users of DMA_CYCLIC can just keep using
an internal helper that only deals with the legacy case, or use
dma_request_slave() or whatever is the new API for the DT case.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote:
> >
> > I assume that the sst-firmware.c case is a mistake, it should just use a
> > plain DMA_SLAVE and not DMA_MEMCPY.
> 
> Other way around.
> 

Ok, I see. In that case I guess it also shouldn't call
dmaengine_slave_config(), right? I don't think that's valid
on a MEMCPY channel.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
> 2. non slave channel requests, where only the functionality matters, like
> memcpy, interleaved, memset, etc.
> We could have a simple:
> dma_request_channel(mask);
> 
> But looking at the drivers using dmaengine legacy dma_request_channel() API:
> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
> drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG
> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
> 
> as examples.
> Not sure how valid are these...

It's usually not much harder to separate out the legacy case from
the normal dma_request_slave_channel_reason(), so those drivers don't
really need to use the unified compat API.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] [media] include/media: move platform_data to linux/platform_data/media

[Arnd Bergmann]

On Monday 16 November 2015 09:00:45 Mauro Carvalho Chehab wrote:
> Let's not mix platform_data headers with the core headers. Instead, let's
> create a subdir at linux/platform_data and move the headers to that
> common place, adding it to MAINTAINERS.
> 

Acked-by: Arnd Bergmann <a...@arndb.de>

I think we can also move some of the existing platform data headers to the same
place, but that could be a separate patch:

$ git grep linux/platform_data drivers/media/
drivers/media/platform/coda/coda-common.c:#include 
drivers/media/platform/soc_camera/mx2_camera.c:#include 

drivers/media/platform/soc_camera/mx3_camera.c:#include 

drivers/media/platform/soc_camera/mx3_camera.c:#include 

drivers/media/platform/soc_camera/pxa_camera.c:#include 

drivers/media/platform/soc_camera/rcar_vin.c:#include 


Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP2: use correct timer function for AM43XX and TI81XX

[Arnd Bergmann]

AM43XX and TI81XX use omap3_gptimer_timer_init(), but that is only
built into the kernel for OMAP3 and AM33XX, otherwise we get:

arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x124): undefined reference to 
`omap3_gptimer_timer_init'

This changes the Kconfig logic for building the function to
match the callers. Consequently, we no longer need to build
the omap3_secure_sync32k_timer_init and omap4_local_timer_init
for the platforms that have been moved over to other functions.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
---
The code has changed a couple of times, but this version no longer
produces build errors for me.

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b18ebbefae09..b07dd70b2de1 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -494,7 +494,7 @@ void __init omap_init_time(void)
clocksource_probe();
 }
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
+#if defined(CONFIG_ARCH_OMAP3)
 void __init omap3_secure_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
@@ -502,7 +502,7 @@ void __init omap3_secure_sync32k_timer_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || 
defined(CONFIG_SOC_TI81XX)
 void __init omap3_gptimer_timer_init(void)
 {
__omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
@@ -510,8 +510,7 @@ void __init omap3_gptimer_timer_init(void)
 }
 #endif
 
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
-   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || 
defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
 static void __init omap4_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Arnd Bergmann]

On Friday 13 November 2015 17:13:41 Mauro Carvalho Chehab wrote:
> Em Wed, 11 Nov 2015 21:26:31 +0100
> Arnd Bergmann <a...@arndb.de> escreveu:
> 

>  include/media/{ => drv-intf}/cx2341x.h   | 0
>  include/media/{ => drv-intf}/cx25840.h   | 0
>  include/media/{ => drv-intf}/exynos-fimc.h   | 0
>  include/media/{ => drv-intf}/msp3400.h   | 0
>  include/media/{ => drv-intf}/s3c_camif.h | 0
>  include/media/{ => drv-intf}/saa7146.h   | 0
>  include/media/{ => drv-intf}/saa7146_vv.h| 2 +-
>  include/media/{ => drv-intf}/sh_mobile_ceu.h | 0
>  include/media/{ => drv-intf}/sh_mobile_csi2.h| 0
>  include/media/{ => drv-intf}/sh_vou.h| 0
>  include/media/{ => drv-intf}/si476x.h| 0
>  include/media/{ => drv-intf}/soc_mediabus.h  | 0
>  include/media/{ => drv-intf}/tea575x.h   | 0
>  include/media/i2c/tw9910.h   | 2 +-
>  include/media/{ => platform_data}/gpio-ir-recv.h | 0
>  include/media/{ => platform_data}/ir-rx51.h  | 0
>  include/media/{ => platform_data}/mmp-camera.h   | 0
>  include/media/{ => platform_data}/omap1_camera.h | 0
>  include/media/{ => platform_data}/omap4iss.h | 0
>  include/media/{ => platform_data}/s5p_hdmi.h | 0
>  include/media/{ => platform_data}/si4713.h   | 0
>  include/media/{ => platform_data}/sii9234.h  | 0
>  include/media/{ => platform_data}/smiapp.h   | 0
>  include/media/{ => platform_data}/soc_camera.h   | 0
>  include/media/{ => platform_data}/soc_camera_platform.h  | 2 +-
>  include/media/{ => platform_data}/timb_radio.h   | 0
>  include/media/{ => platform_data}/timb_video.h   | 0
>  sound/pci/es1968.c   | 2 +-
>  sound/pci/fm801.c| 2 +-
>  155 files changed, 158 insertions(+), 158 deletions(-)

As Geert said, include/linux/platform_data/media/ would be nicer for
consistency with other subsystems.

> diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c 
> b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
> index ede2bdbb5dd5..44ba1f28bb34 100644
> --- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
> +++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
> @@ -33,7 +33,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 

This looks like a mistake: the header contains the string 'platform_data',
but it is not actually a platform data header file in the sense
that it defines the interface between platform and driver.

Maybe soc_camera.h is important enough to still leave it as a core
file in the existing location? Or possibly a separate directory for
media/soc_camera/*.h

> @@ -24,7 +24,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  #include "cx25840-core.h"

For this case, I think the original patch to move it into include/media/i2c
was more logical as it mirrors the file structure. I was mainly talking
about the platform_data being different from the rest.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

[Arnd Bergmann]

On Wednesday 11 November 2015 15:14:48 Mauro Carvalho Chehab wrote:
>  rename include/media/{ => platform}/exynos-fimc.h (100%)
>  rename include/media/{ => platform}/mmp-camera.h (100%)
>  rename include/media/{ => platform}/omap1_camera.h (100%)
>  rename include/media/{ => platform}/omap4iss.h (100%)
>  rename include/media/{ => platform}/s3c_camif.h (100%)
>  rename include/media/{ => platform}/s5p_hdmi.h (100%)
>  rename include/media/{ => platform}/sh_mobile_ceu.h (100%)
>  rename include/media/{ => platform}/sh_mobile_csi2.h (100%)
>  rename include/media/{ => platform}/sh_vou.h (100%)
>  rename include/media/{ => platform}/sii9234.h (100%)
>  rename include/media/{ => platform}/soc_camera.h (100%)
>  rename include/media/{ => platform}/soc_camera_platform.h (98%)
>  rename include/media/{ => platform}/soc_mediabus.h (100%)

This still seems to be a mix of various things. Some of these are interfaces
between drivers, while others declare a foo_platform_data structure that
is used to interface between platform code and the driver.

I think the latter should go into include/linux/platform_data/media/*.h instead.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF

[Arnd Bergmann]

On Wednesday 04 November 2015 09:42:35 Peter Ujfalusi wrote:
> On 11/03/2015 04:00 PM, Arnd Bergmann wrote:
> > During the edma rework, a build error was introduced for the
> > case that CONFIG_OF is disabled:
> > 
> > drivers/built-in.o: In function `edma_tc_set_pm_state':
> > :(.text+0x43bf0): undefined reference to `of_find_device_by_node'
> > 
> > As the edma_tc_set_pm_state() function does nothing in case
> > we are running without OF, this adds an IS_ENABLED() check
> > that turns the function into an empty stub then and avoids the
> > link error.
> > 
> > Signed-off-by: Arnd Bergmann <a...@arndb.de>
> > Fixes: ca304fa9bb76 ("ARM/dmaengine: edma: Public API to use private struct 
> > pointer")
> 
> The actual commit this patch is fixing is:
> 1be5336bc7ba dmaengine: edma: New device tree binding

That's what I first thought, but it seems to just move around the
call to of_find_device_by_node that was first introduced in the
commit I mentioned. Did you build-test it successfully with
ca304fa9bb76 and CONFIG_OF enabled? I have to admit that I
was just guessing from the contents and did not bisect this
fully.

> > ---
> > Found on ARM randconfig builds with today's linux-next
> 
> I have sanity built the kernel with omap2plus_defconfig and
> davinci_all_defconfig since eDMA is used by these platforms and did not faced
> with this issue, as obviously these defconfigs will result OF to be enabled.

Right. The defconfigs were all fine, and this is hard to hit
even in the randconfig builds.

> > diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> > index 31722d436a42..16713a93da10 100644
> > --- a/drivers/dma/edma.c
> > +++ b/drivers/dma/edma.c
> > @@ -1560,7 +1560,7 @@ static void edma_tc_set_pm_state(struct edma_tc *tc, 
> > bool enable)
> >   struct platform_device *tc_pdev;
> >   int ret;
> >  
> > - if (!tc)
> > + if (!IS_ENABLED(CONFIG_OF) || !tc)
> >   return;
> 
> Should we instead put the function inside of:
> #if IS_ENABLED(CONFIG_OF)
> static void edma_tc_set_pm_state(struct edma_tc *tc, bool enable)
> {
> ...
> }
> #else
> static inline void edma_tc_set_pm_state(struct edma_tc *tc, bool enable)
> {
> }
> #endif /* IS_ENABLED(CONFIG_OF) */

I think that would be less readable, and gives no compile-time coverage
to the contents of the edma_tc_set_pm_state function.

The effect is the same, so I'd rather stay with my version.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF

[Arnd Bergmann]

On Wednesday 04 November 2015 11:05:54 Peter Ujfalusi wrote:
> > 
> > I think that would be less readable, and gives no compile-time coverage
> > to the contents of the edma_tc_set_pm_state function.
> 
> Hrm, if the compiler knows that there is no need to compile the code after 
> the:
> if (!IS_ENABLED(CONFIG_OF) || !tc)
> when OF is disabled, then it does not give more compile coverage then have
> empty inline function in case of !OF.

No, the way it works (simplified but close enough here) is that gcc parses
all the source code first and throws warnings or errors for everything that
looks wrong to it, and only later throws out all code that it knows is never
used before emitting the object code.

The difference to the #ifdef is that the preprocessor here throws out all
disabled code before it gets parsed, so we don't get warnings for it.

> Not sure about it, but if we disable all optimization in gcc, then we might
> get the same missing symbol?

It's impossible to build the kernel with inlining disabled, because we
rely on the same kind of optimization in lots of places.

> > The effect is the same, so I'd rather stay with my version.
> 
> I'm fine with both. It is up to Vinod to decide which one he prefers (I prefer
> the #if #else #endif version).
> 
> Anyways:
> Acked-by: Peter Ujfalusi 

Thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dmaengine: edma: fix build without CONFIG_OF

[Arnd Bergmann]

During the edma rework, a build error was introduced for the
case that CONFIG_OF is disabled:

drivers/built-in.o: In function `edma_tc_set_pm_state':
:(.text+0x43bf0): undefined reference to `of_find_device_by_node'

As the edma_tc_set_pm_state() function does nothing in case
we are running without OF, this adds an IS_ENABLED() check
that turns the function into an empty stub then and avoids the
link error.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
Fixes: ca304fa9bb76 ("ARM/dmaengine: edma: Public API to use private struct 
pointer")
---
Found on ARM randconfig builds with today's linux-next

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 31722d436a42..16713a93da10 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1560,7 +1560,7 @@ static void edma_tc_set_pm_state(struct edma_tc *tc, bool 
enable)
struct platform_device *tc_pdev;
int ret;
 
-   if (!tc)
+   if (!IS_ENABLED(CONFIG_OF) || !tc)
return;
 
tc_pdev = of_find_device_by_node(tc->node);

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap dts changes for v4.4 merge window, part 2

[Arnd Bergmann]

On Tuesday 20 October 2015 12:35:02 Tony Lindgren wrote:
> Few more omap dts changes for v4.4 merge window, mostly to fix and clean
> up some omap5 issues to allow adding other omap5 boards. Also some other
> fixes and clean-up:
> 
> - Fix SDIO WLAN for omap5 that's been broken for a while. As further
>   patches are still needed for wl18xx, no need for stable on this one.
> 
> - Move most of omap5 support into omap5-board-common.dtsi as most omap5
>   boards seem to share the same basic set of devices.
> 
> - Add minimal IGEPv5 support using based on omap5-board-common.dtsi
> 
> - Remove now unneedes gpio hogging for dra72-evm
> 
> - Update Javier Martinez Canillas email address
> 
> - Change earlier IGEP boards to use IOPAD pinmux macros
> 

Pulled into next/dt, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] two omap fixes for v4.3-rc cycle

[Arnd Bergmann]

On Tuesday 20 October 2015 12:34:01 Tony Lindgren wrote:
> The following changes since commit d8e1f5ed11a39a68da00f05000466c4f6db4456e:
> 
>   Documentation: ARM: List new omap MMC requirements (2015-10-12 16:23:34 
> -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> tags/omap-for-v4.3/fixes-rc6
> 
> for you to fetch changes up to 57df5380853460bc66b59a46273ce113c923d39c:
> 
>   ARM: OMAP2+: Fix imprecise external abort caused by bogus SRAM init 
> (2015-10-19 08:55:46 -0700)
> 
> 
> Fixes for omaps for v4.3-rc cycle:
> 
> - Fix oops with LPAE and moew than 2GB of memory by enabling
>   ZONE_DMA for LPAE. Probably no need for stable on this one as we
>   only recently ran into this with the mainline kernel
> 
> - Fix imprecise external abort caused by bogus SRAM init. This affects
>   dm814x recently merged, so no need for stable on this one AFAIK

Applied to fixes, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/2] omap device tree changes for v4.4

[Arnd Bergmann]

On Thursday 15 October 2015 14:04:26 Tony Lindgren wrote:
> * Arnd Bergmann <a...@arndb.de> [151015 13:40]:
> > On Wednesday 14 October 2015 14:38:59 Tony Lindgren wrote:
> > 
> > > Note that this branch is against v4.3-rc4 as that contains critical
> > > MMC related fixes to boot with MMC working on most omaps.
> > 
> > While we are lucky this time as I based the branch on -rc4 anyway,
> > a nicer way to do this would be to ensure that a fix you want
> > to base on is based an older -rc, and then you base your own branch
> > on top of that fix, to minimize the number of back-merged patches.
> 
> Sure that would be doable too at the cost of a few extra merges.

You can always look at our existing next/* branches to see what they are
based on. If we already have the commit you need (like this time), it's
not a problem at all to use the same base.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap fixes against v4.3-rc5

[Arnd Bergmann]

On Wednesday 14 October 2015 13:03:36 Tony Lindgren wrote:
> Fixes for omap against v4.3-rc5:
> 
> - Regulator fix for beagle-x15 to fix HDMI without a SD card being
>   inserted
> 
> - GPMC fix for showing proper timings and to allow enabling debug
>   options that somehow was unselectable earlier
> 
> - Add minimal documentation for new MMC1 dependency on
>   REGULATOR_PBIAS as it may not be obvious for people with
>   targeted .config files
> 

Pulled into fixes, thanks!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/2] omap device tree changes for v4.4

[Arnd Bergmann]

On Wednesday 14 October 2015 14:38:59 Tony Lindgren wrote:
> Device tree changes for omaps for v4.4 merge window:
> 
> - DCAN sleep pins for am437x-gp-evm
> 
> - A series of changes to add audio support for dra7
> 
> - Add support for gpio keys and LEDs on dra7
> 
> - Regulator clean-up for am335x-wega
> 
> - A series of changes to enable IOMMUs and mailboxes for dra7
>   accelerators
> 
> - Add support for am335x-bonegreen
> 
> - Fix up GPIO flags where 0 was used instead of GPIO_ACTIVE_HIGH
> 
> - Fix omap3-lilly-am33x IRQ level flag
> 
> - Remove duplicate uart2 pinmux for igep and fix indentation and
>   update igep to use pinctrl macros for the register offsets
> 
> - Fix MMC cd-gpios usage

Pulled into next/dt, thanks!

> Note that this branch is against v4.3-rc4 as that contains critical
> MMC related fixes to boot with MMC working on most omaps.

While we are lucky this time as I based the branch on -rc4 anyway,
a nicer way to do this would be to ensure that a fix you want
to base on is based an older -rc, and then you base your own branch
on top of that fix, to minimize the number of back-merged patches.

Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 1/2] omap clean-up for v4.4

[Arnd Bergmann]

On Wednesday 14 October 2015 14:38:58 Tony Lindgren wrote:
> Clean-up for omaps for v4.4 merge window:
> 
> - Remove legacy omap3 ISP code as the driver is DT only
> 
> - Remove VoiceBlue board support as it's been unused over
>   10 years now
> 
> - Remove unused polarity control macros for TWL
> 
> - Remove two unneeded semicolons
> 
> - Remove unused core dpll code for reprogramming the rates

Nice!
 
> Note that this branch is against v4.3-rc4 as that contains critical
> MMC related fixes to boot with MMC working on most omaps.

That is fine, we had a late start and everything is based on -rc4 this
time.

Applied to next/cleanup.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Arnd Bergmann]

On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote:
> On boards with more than 2GB of RAM booting goes wrong with things not working
> and we're getting lots of l3 warnings:
> 
> WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> l3_interrupt_handler+0x260/0x384()
> 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access in 
> User mode during Functional access
> ...
> [] (scsi_add_host_with_dma) from [] 
> (ata_scsi_add_hosts+0x5c/0x18c)
> [] (ata_scsi_add_hosts) from [] 
> (ata_host_register+0x150/0x2cc)
> [] (ata_host_register) from [] 
> (ata_host_activate+0xd4/0x124)
> [] (ata_host_activate) from [] 
> (ahci_host_activate+0x5c/0x194)
> [] (ahci_host_activate) from [] 
> (ahci_platform_init_host+0x1f0/0x3f0)
> [] (ahci_platform_init_host) from [] 
> (ahci_probe+0x70/0x98)
> [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
> 
> Let's fix the issue by enabling ZONE_DMA for LPAE.
> 
> Signed-off-by: Tony Lindgren 
> 

I suspect this is not the correct fix, even if it works around the problem.

Am I right that the AHCI device can access the first 4GB of address space
using 32-bit DMA, and that any RAM beyond 2GB is above that limit?

Does the ZONE_DMA have the same size? If not, you get more bounce buffers
than you want, which is bad for performance/

Another problem here is that it only works with the SCSI and net subsystems
that have a hack in there to create manual bounce buffers, but other drivers
that can do DMA to high addresses will not know about this.

The right solution would be to force the use of an IOMMU, and if that not
works, add support for SWIOTLB on ARM.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Arnd Bergmann]

On Wednesday 14 October 2015 09:17:56 Tony Lindgren wrote:
> * Arnd Bergmann <a...@arndb.de> [151014 02:20]:
> > On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote:
> > > On boards with more than 2GB of RAM booting goes wrong with things not 
> > > working
> > > and we're getting lots of l3 warnings:
> > > 
> > > WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> > > l3_interrupt_handler+0x260/0x384()
> > > 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access 
> > > in User mode during Functional access
> > > ...
> > > [] (scsi_add_host_with_dma) from [] 
> > > (ata_scsi_add_hosts+0x5c/0x18c)
> > > [] (ata_scsi_add_hosts) from [] 
> > > (ata_host_register+0x150/0x2cc)
> > > [] (ata_host_register) from [] 
> > > (ata_host_activate+0xd4/0x124)
> > > [] (ata_host_activate) from [] 
> > > (ahci_host_activate+0x5c/0x194)
> > > [] (ahci_host_activate) from [] 
> > > (ahci_platform_init_host+0x1f0/0x3f0)
> > > [] (ahci_platform_init_host) from [] 
> > > (ahci_probe+0x70/0x98)
> > > [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
> > > 
> > > Let's fix the issue by enabling ZONE_DMA for LPAE.
> > > 
> > > Signed-off-by: Tony Lindgren <t...@atomide.com>
> > > 
> > 
> > I suspect this is not the correct fix, even if it works around the problem.
> > 
> > Am I right that the AHCI device can access the first 4GB of address space
> > using 32-bit DMA, and that any RAM beyond 2GB is above that limit?
> 
> Yes the memory above 2GB is at 0x3. The same problem is there at least
> with MMC too.
> 
> > Does the ZONE_DMA have the same size? If not, you get more bounce buffers
> > than you want, which is bad for performance/
> 
> Hmm good question. I guess we should set .dma_zone_size  = SZ_2G in this
> case then as only 2GB of RAM can directly be accessed.

I think you need ".dma_zone_size  = SZ_4G", but I'm not completely sure
whether this takes PHYS_OFFSET into account or not.

> > Another problem here is that it only works with the SCSI and net subsystems
> > that have a hack in there to create manual bounce buffers, but other drivers
> > that can do DMA to high addresses will not know about this.
> 
> OK good to know.
> 
> > The right solution would be to force the use of an IOMMU, and if that not
> > works, add support for SWIOTLB on ARM.
> 
> Suman might have some accelerators in mind we could use for DMA.
> 
> For SWIOTLB, It seems we have it for arm64 but not for arm?

Correct. A number of people have run into problems with this before, but
it has never been added to the kernel. At some point, I tried to help
Peter Senna Tschudin get it implemented, but I think he gave up when it
turned out that the platform he was using to test this did not need it
after all.

The reason we have it on ARM64 is that you are completely screwed there
if you have no IOMMU but use a 32-bit DMA master, while on 32-bit platforms
most of the time you don't have memory above 4GB, and if you do then most
of the time you don't have any DMA masters other than network and scsi
(including sata) on them, or you have an IOMMU for each one.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] genirq: export handle_bad_irq

[Arnd Bergmann]

A cleanup of the omap gpio driver introduced a use of the
handle_bad_irq() function in a device driver that can be
a loadable module.

This broke the ARM allmodconfig build:

ERROR: "handle_bad_irq" [drivers/gpio/gpio-omap.ko] undefined!

This patch exports the handle_bad_irq symbol in order to
allow the use in modules.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
Fixes: 450fa54cfd66 ("gpio: omap: convert to use generic irq handler")

diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index ea7b5fd99ba5..142bbf3b607f 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -35,6 +35,7 @@ void handle_bad_irq(struct irq_desc *desc)
kstat_incr_irqs_this_cpu(desc);
ack_bad_irq(irq);
 }
+EXPORT_SYMBOL_GPL(handle_bad_irq);
 
 /*
  * Special, empty irq handler:

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] genirq: fix handle_bad_irq kerneldoc comment

[Arnd Bergmann]

A recent cleanup removed the 'irq' parameter from many functions, but
left the documentation for this in place for at least one function.

This removes it.

Signed-off-by: Arnd Bergmann <a...@arndb.de>
Fixes: bd0b9ac405e1 ("genirq: Remove irq argument from irq flow handlers")
---
On Wednesday 07 October 2015 04:51:56 kbuild test robot wrote:
> [auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please 
> ignore]
> 
> reproduce: make htmldocs
> 
> All warnings (new ones prefixed by >>):
> 
>kernel/irq/handle.c:31: warning: Excess function parameter 'irq' 
> description in 'handle_bad_irq'
> >> kernel/irq/handle.c:1: warning: no structured comments found

This seems to be an unrelated bug, not sure why it wasn't caught earlier:

diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 142bbf3b607f..a302cf9a2126 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -22,7 +22,6 @@
 
 /**
  * handle_bad_irq - handle spurious and unhandled irqs
- * @irq:   the interrupt number
  * @desc:  description of the interrupt
  *
  * Handles spurious and unhandled IRQ's. It also prints a debugmessage.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

[Arnd Bergmann]

On Monday 05 October 2015 14:41:07 Felipe Balbi wrote:
> 
> /**
>  * omap_get_timer_dt - get a timer using device-tree
>  * @match   - device-tree match structure for matching a device type
>  * @property- optional timer property to match
>  *
>  * Helper function to get a timer during early boot using device-tree for use
>  * as kernel system timer. Optionally, the property argument can be used to
>  * select a timer with a specific property. Once a timer is found then mark
>  * the timer node in device-tree as disabled, to prevent the kernel from
>  * registering this timer as a platform device and so no one else can use it.
>  */
> static struct device_node * __init omap_get_timer_dt(const struct 
> of_device_id *match,
>  const char *property)
> {
> struct device_node *np;
> 
> for_each_matching_node(np, match) {
> if (!of_device_is_available(np))
> continue;
> 
> if (property && !of_get_property(np, property, NULL))
> continue;
> 
> if (!property && (of_get_property(np, "ti,timer-alwon", NULL) 
> ||
>   of_get_property(np, "ti,timer-dsp", NULL) ||
>   of_get_property(np, "ti,timer-pwm", NULL) ||
>   of_get_property(np, "ti,timer-secure", 
> NULL)))
> continue;
> 
> of_add_property(np, _disabled);
> return np;
> }
> 
> return NULL;
> }
> 
> I'll patch this up and drop $subject
> 

Ah, good.

I'm seeing the "ti,timer-alwon" property here, we probably need to take
that into account when setting the CLOCK_SOURCE_SUSPEND_NONSTOP flag, if
that isn't how it gets done already.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

On Monday 05 October 2015 04:13:41 Tony Lindgren wrote:
> * Arnd Bergmann <a...@arndb.de> [151005 04:08]:
> > On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:
> > > * Daniel Lezcano <daniel.lezc...@linaro.org> [151001 15:16]:
> > > > On 09/30/2015 04:49 PM, Arnd Bergmann wrote:
> > > > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> > > > >>
> > > > >>TEGRA folks: the tegra_read_persistent_clock() implementation 
> > > > >>apparently
> > > > >>predates the Tegra RTC driver and I wonder if they actually do the
> > > > >>right thing in combination. Could it be that the wall time forwards
> > > > >>twice as fast as it should during resume when the RTC driver is 
> > > > >>loaded?
> > > > >>Could it be that we can simply remove  tegra_read_persistent_clock()
> > > > >>and the register_persistent_clock() infrastructure?
> > > > >>
> > > > >
> > > > >I found the 'sleeptime_injected' variable now, which takes care of
> > > > >forwarding the clock by the correct amount.
> > > > >
> > > > >I also found the CLOCK_SOURCE_SUSPEND_NONSTOP flag next to it, which
> > > > >should let us use the counter32k driver to provide the correct
> > > > >time during suspend without the omap_read_persistent_clock() function.
> > > > >We should be able to just delete that code.
> > > > >
> > > > >If we decide to also delete the tegra_read_persistent_clock()
> > > > >function, we can remove the registration too.
> > > > 
> > > > 
> > > > +1
> > > 
> > > We could maybe have read_persistent_clock() just check for the
> > > CLOCK_SOURCE_SUSPEND_NONSTOP flag?
> > 
> > timekeeping_resume() already ignores the persistent clock values if
> > the clocksource has this set. Do you mean we should additionally
> > not call the read_persistent_clock() function at all to safe a
> > few cycles reading that value?
> 
> Hmm no I mean if we have CLOCK_SOURCE_SUSPEND_NONSTOP we can
> automatically make read_persistent_clock() use that if nothing
> else got registered.

Ok, so we don't need to change anything here then.

> > How expensive is the function?
> 
> Usually the persistent clock is on some interconnect, so it is
> way slower compared to a local timer. It doubt it makes a
> difference in timekeeping_resume() though 

Right.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

On Monday 05 October 2015 03:55:55 Tony Lindgren wrote:
> * Daniel Lezcano <daniel.lezc...@linaro.org> [151001 15:16]:
> > On 09/30/2015 04:49 PM, Arnd Bergmann wrote:
> > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> > >>
> > >>TEGRA folks: the tegra_read_persistent_clock() implementation apparently
> > >>predates the Tegra RTC driver and I wonder if they actually do the
> > >>right thing in combination. Could it be that the wall time forwards
> > >>twice as fast as it should during resume when the RTC driver is loaded?
> > >>Could it be that we can simply remove  tegra_read_persistent_clock()
> > >>and the register_persistent_clock() infrastructure?
> > >>
> > >
> > >I found the 'sleeptime_injected' variable now, which takes care of
> > >forwarding the clock by the correct amount.
> > >
> > >I also found the CLOCK_SOURCE_SUSPEND_NONSTOP flag next to it, which
> > >should let us use the counter32k driver to provide the correct
> > >time during suspend without the omap_read_persistent_clock() function.
> > >We should be able to just delete that code.
> > >
> > >If we decide to also delete the tegra_read_persistent_clock()
> > >function, we can remove the registration too.
> > 
> > 
> > +1
> 
> We could maybe have read_persistent_clock() just check for the
> CLOCK_SOURCE_SUSPEND_NONSTOP flag?

timekeeping_resume() already ignores the persistent clock values if
the clocksource has this set. Do you mean we should additionally
not call the read_persistent_clock() function at all to safe a
few cycles reading that value?

How expensive is the function?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

[Arnd Bergmann]

On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote:
> All devices should have a default status. Ignoring
> the arguments if it should be 'okay' or 'disabled'
> by default, let's set them all the 'disabled' and
> have boards enable 32k counter.
> 
> Signed-off-by: Felipe Balbi 
> 

The patch looks good, but the description is slightly incorrect:
There is no reason to list "status='okay'" other than overriding
the 'disabled' status.

I'd phrase it something like:

"We want the use of the 32k counter to be a per-board setting,
so let's disable it by default in each dtsi file and override the
setting in the boards. Any board that does not wire up the counter
should leave it disabled".

However, if you really want all boards to provide the counter all
the time, I'd argue that we're better off dropping this patch. We
use the status="disabled" trick for anything that may or may not
be working based on the board design, but things that are present
everywhere don't need this.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

On Tuesday 29 September 2015 15:43:55 Felipe Balbi wrote:
> 
> the following patches de-obfuscate arch/arm/mach-omap2/timer.c
> and start moving code to drivers/clocksource. So far only counter32k
> has been moved over.
> 
> Note that we can't get rid of all the code (yet) because there are
> still platforms relying to legacy boot and because of the strong
> coupling with OMAP's hwmod layer.
> 
> This is, for now, an RFC and has be written on top of [1]. Boot tested
> with AM335x and AM437x.
> 
> [1] http://marc.info/?l=linux-omap=144354336924308=2

Looks very nice!

> ps: if anybody has a good idea on how to get rid of
> register_persistent_clock(), please let me know

I don't think we want to get rid of that, because it is the more
accurate interface. IIRC systems that have an RTC will use
timekeeping_inject_sleeptime64() in rtc_resume(). I don't know however
how the two methods are coordinated, i.e. how the kernel ensures that
exactly one of the two is used, but never both.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

[Arnd Bergmann]

On Wednesday 30 September 2015 09:12:09 Felipe Balbi wrote:
> On Wed, Sep 30, 2015 at 10:15:25AM +0200, Arnd Bergmann wrote:
> > On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote:
> > > All devices should have a default status. Ignoring
> > > the arguments if it should be 'okay' or 'disabled'
> > > by default, let's set them all the 'disabled' and
> > > have boards enable 32k counter.
> > > 
> > > Signed-off-by: Felipe Balbi <ba...@ti.com>
> > > 
> > 
> > The patch looks good, but the description is slightly incorrect:
> > There is no reason to list "status='okay'" other than overriding
> > the 'disabled' status.
> > 
> > I'd phrase it something like:
> > 
> > "We want the use of the 32k counter to be a per-board setting,
> > so let's disable it by default in each dtsi file and override the
> > setting in the boards. Any board that does not wire up the counter
> > should leave it disabled".
> > 
> > However, if you really want all boards to provide the counter all
> > the time, I'd argue that we're better off dropping this patch. We
> > use the status="disabled" trick for anything that may or may not
> > be working based on the board design, but things that are present
> > everywhere don't need this.
> 
> okay, so here's the thing. While fiddling with the 32k counter, I noticed
> that even though there was no status listed, the thing still initializes
> fine. However, when moving 32k to drivers/clocksource and using
> CLOCKSOURCE_OF_DECLARE(), 32k would *NOT* probe unless I had an explicit
> status = "okay" in DT.

Very strange, that sounds like a bug in the clocksource probe code.
Can you check how this happens?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote:
> 
> TEGRA folks: the tegra_read_persistent_clock() implementation apparently
> predates the Tegra RTC driver and I wonder if they actually do the
> right thing in combination. Could it be that the wall time forwards
> twice as fast as it should during resume when the RTC driver is loaded?
> Could it be that we can simply remove  tegra_read_persistent_clock()
> and the register_persistent_clock() infrastructure?
> 

I found the 'sleeptime_injected' variable now, which takes care of
forwarding the clock by the correct amount.

I also found the CLOCK_SOURCE_SUSPEND_NONSTOP flag next to it, which
should let us use the counter32k driver to provide the correct
time during suspend without the omap_read_persistent_clock() function.
We should be able to just delete that code.

If we decide to also delete the tegra_read_persistent_clock()
function, we can remove the registration too.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

[Arnd Bergmann]

On Wednesday 30 September 2015 09:13:38 Felipe Balbi wrote:
> On Wed, Sep 30, 2015 at 10:22:46AM +0200, Arnd Bergmann wrote:
> > On Tuesday 29 September 2015 15:43:55 Felipe Balbi wrote:
> > > 
> > > the following patches de-obfuscate arch/arm/mach-omap2/timer.c
> > > and start moving code to drivers/clocksource. So far only counter32k
> > > has been moved over.
> > > 
> > > Note that we can't get rid of all the code (yet) because there are
> > > still platforms relying to legacy boot and because of the strong
> > > coupling with OMAP's hwmod layer.
> > > 
> > > This is, for now, an RFC and has be written on top of [1]. Boot tested
> > > with AM335x and AM437x.
> > > 
> > > [1] http://marc.info/?l=linux-omap=144354336924308=2
> > 
> > Looks very nice!
> > 
> > > ps: if anybody has a good idea on how to get rid of
> > > register_persistent_clock(), please let me know
> > 
> > I don't think we want to get rid of that, because it is the more
> > accurate interface. IIRC systems that have an RTC will use
> > timekeeping_inject_sleeptime64() in rtc_resume(). I don't know however
> > how the two methods are coordinated, i.e. how the kernel ensures that
> > exactly one of the two is used, but never both.
> 
> however register_persistent_clock() is an ARM-only thing, the question
> was more towards that. Do we want to continue using the ARM-only
> register_persistent_clock() or is there a more generic version of it ?

Ah, got it.

I wouldn't worry about it at the moment, the read_persistent_clock64
interface is very rarely used: only arm, ia64, mips/lasat and s390
define it at all, only arm has more than one implementation (omap
and tegra) and the tegra, ia64 and mips implementations should really
use timekeeping_inject_sleeptime64() instead.

read_boot_clock64() is even rarer: only s390 defines it, apparently
because it is the only architecture that uses a single register for
wall-clock time and high-resolution time (it has a 96-bit
quarternanosecond register that is synchronized before booting Linux).  

TEGRA folks: the tegra_read_persistent_clock() implementation apparently
predates the Tegra RTC driver and I wonder if they actually do the
right thing in combination. Could it be that the wall time forwards
twice as fast as it should during resume when the RTC driver is loaded?
Could it be that we can simply remove  tegra_read_persistent_clock()
and the register_persistent_clock() infrastructure?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/21] ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers

[Arnd Bergmann]

On Thursday 10 September 2015 11:37:37 Peter Ujfalusi wrote:
> bla-bla and bla
> 
> Signed-off-by: Peter Ujfalusi 

You may want to expand on that a bit.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] dmaengine/ARM: Merge the edma drivers into one

[Arnd Bergmann]

On Thursday 10 September 2015 11:37:29 Peter Ujfalusi wrote:
> 
> with this series the edma two driver setup will be changed to have only one
> driver to support eDMA3. The legacy edma interface will be removed and eDMA 
> can
> only be used via dmaengine API from this point on.
> In order to do the merge the following improvements has been done:
> - One driver instance per eDMA:
>  - Any number of eDMA instances are supported (both legacy and DT boot)
> - Not relying on global variables, arrays, etc
> - Code simplification and optimizations in several places
> 
> This change will also help us to do bigger changes in the eDMA driver since,
> since now we have only one driver to work with.
> 

Very nice series, thanks for addressing this long-standing issue!

I've briefly read over the series and did not see anything major
sticking out, but I did not attempt to do a thorough review.

I found two minor things that I commented on that could be improved.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/21] ARM: davinci: Add set dma_mask to eDMA devices

[Arnd Bergmann]

On Thursday 10 September 2015 11:37:38 Peter Ujfalusi wrote:
> +static u64 da8xx_edma0_dmamask = DMA_BIT_MASK(32);
> +
>  static struct platform_device da8xx_edma0_device = {
> .name   = "edma",
> .id = 0,
> .dev = {
> .platform_data = _edma0_pdata,
> +   .dma_mask = _edma0_dmamask,
> +   .coherent_dma_mask = DMA_BIT_MASK(32),
> },
> .num_resources  = ARRAY_SIZE(da8xx_edma0_resources),
> .resource   = da8xx_edma0_resources,
>  };

While this is technically correct for all I can tell, could you
convert it to use __initconst platform_device_info and
platform_device_register_full() instead?

statically declaring platform_devices has been frowned upon for a long
time (even though a lot of arm platforms still do it), and statically
declaring the dma mask seems worse to me (and yes, I realize we also
do that elsewhere).

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 24 June 2015 21:54:01 Vinod Koul wrote:
  It would be nice to find another name for the
  dma_request_slave_channel_compat() so with the new name we could have chance
  to rearrange the parameters: (dev, name, mask, fn, fn_param)
  
  We would end up with the following APIs, all returning with error code on 
  failure:
  dma_request_slave_channel(dev, name);
  dma_request_channel_legacy(mask, fn, fn_param);
  dma_request_slave_channel_compat(mask, fn, fn_param, dev, name);
  dma_request_any_channel(mask);
 This is good idea but still we end up with 4 APIs. Why not just converge to
 two API, one legacy + memcpy + filer fn and one untimate API for slave?
 
 Internally we may have 4 APIs for cleaner handling...
 

Not sure if it's realistic, but I think it would be nice to have
a way for converting the current slave drivers that use the
mask/filter/param API to the dev/name based API. We should
be able to do this by registering a lookup table from platform
code that translates one to the other, like we do with the
clkdev lookup to find a device clock based on a local identifier.

The main downside of this is that it's a lot of work if we want
to completely remove dma_request_channel() for slave drivers,
but it could be done more gradually.

Another upside is that we could come up with a mechanism to
avoid the link-time dependency on the filter-function that
causes problems when that filter is defined in a loadable
module for the dmaengine driver.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9

[Arnd Bergmann]

On Wednesday 03 June 2015 15:32:45 Felipe Balbi wrote:
 
 Hi Tony and Russell,
 
 AM43xx, even though it's a single processor A9, it still has TWD and global
 timer. I was doing some profiling with RT v4.0 and latency is 3.5x lower just
 by switching from gptimer to twd/global.
 
 The only problem is that currently, is_smp() check prevents me from using twd
 with AM43xx (that's why it's commented below, for testing purposes).
 
 In the hopes that we can start a, hopefully, small thread around the subject,
 I'm sending this HACK which I used to get TWD and global timer enabled so I
 could measure latencies with cyclictest.
 
 Is it so that TWD shouldn't be available on UP integrations of ARM's Cortex-A
 processors ?
 
 

I wondered about this recently when looking at something unrelated
and noticed that the check had been introduced as part of
904464b91eca8 (ARM: 7655/1: smp_twd: make twd_local_timer_of_register()
no-op for nosmp).

I suspect this was just the wrong fix at the time, and that the
real culprit is either alloc_percpu() or request_percpu_irq()
getting called too early on a machine without SMP support.

Possibly the problem is already resolved independently, if you
didn't run into it.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] omap device tree changes for v4.2, part 1

[Arnd Bergmann]

On Friday 22 May 2015 13:20:28 Tony Lindgren wrote:
 
 Device tree related changes for omaps:
 
 - Configure MMC data lines 4..8 for 1.8V IO on boards that
   are using them as GPIOs instead of MMC data lines
 
 - Add support for Baltos IR5221
 
 - Add device tree support for LogicPD Torpedo devkit
 
 - Add 3717 core pinctrl region
 
 - Add gta04 1w and GSM audio support
 
 - Add wilink and ov2659 support for am437x-gp-evm
 
 - Add am335x-evm bluetooth and mmc3 support
 
 - Enable omap5-uevm uart wakeup interrupt
 
 - Enable I2C2 on BeagleBone as it's used for the capes
 
 - Use defines for LDP GPIO keys
 
 

Pulled into next/dt, thanks!

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Fix omap3 booting with thumb2 compiled kernel

[Arnd Bergmann]

On Thursday 28 May 2015 09:36:05 Tony Lindgren wrote:
 * Dave Martin dave.mar...@arm.com [150528 09:19]:
  On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote:
   --- a/arch/arm/mach-omap2/sleep34xx.S
   +++ b/arch/arm/mach-omap2/sleep34xx.S
   @@ -203,23 +203,8 @@ save_context_wfi:
*/
   ldr r1, kernel_flush
   blx r1
   -   /*
   -* The kernel doesn't interwork: v7_flush_dcache_all in particluar 
   will
   -* always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled.
   -* This sequence switches back to ARM.  Note that .align may insert a
   -* nop: bx pc needs to be word-aligned in order to work.
   -*/
   - THUMB(.thumb  )
   - THUMB(.align  )
   - THUMB(bx  pc  )
   - THUMB(nop )
   -   .arm
   -
  
  ^ This looks unrelated to the issue?  This code is simply unnecessary
  after Russell introduced the ret macro in commit 6ebbf2ce43.  That
  made v7_flush_dcache_all do a proper interworking return.
  
  It should probably be in a separate commit, or at least mentioned
  explicitly in the commit log.
 
 Thanks, I've updated the description with the commit info above.
 
 I'll keep the removal of the duplicate code in this patch, as it's
 all related to the mode switching and we don't want to do it twice.

I would have thought that the change is actually necessary after
6ebbf2ce43, because it now returns in ARM mode, which will cause the
bx pc; nop thumb instruction sequence be misinterpreted as an 
ARM instruction.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2.1/2] fixed up omap1 sparse irq support for v4.2

[Arnd Bergmann]

On Thursday 21 May 2015 15:59:38 Tony Lindgren wrote:
 Here's this pull request updated for the randconfig errors found
 by Arnd.
 
 The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736:
 
   Linux 4.1-rc3 (2015-05-10 15:12:29 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v4.2/omap1-v2
 
 for you to fetch changes up to 7bf15c4360b384e34d685616a77a8abf7dd8aea5:
 
   ARM: OMAP1: Fix section mismatch warnings for omap_cfg_reg (2015-05-21 
 14:50:23 -0700)
 
 
 Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
 to making omap1 support multiarch. After this series we still need to
 make omap1 use the common clock framework and fix up the drivers to not
 rely on includes from mach and plat directories.

Pulled into next/soc
 
 Note that this branch depends on a GPIO driver fix in v4.1-rc3
 d2d05c65c40e (gpio: omap: Fix regression for MPUIO interrupts).

The branch is already based on 4.1-rc3, so we should be fine.

Thanks,

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] video: omap/h3: fix tps65010 dependency

[Arnd Bergmann]

The h3 LCD driver fails to link when tps65010 is configured
as a loadable module:

drivers/built-in.o: In function `h3_panel_disable':
debugfs.c:(.text+0x206ac): undefined reference to `tps65010_set_gpio_out_value'
debugfs.c:(.text+0x206cc): undefined reference to `tps65010_set_gpio_out_value'
drivers/built-in.o: In function `h3_panel_enable':
debugfs.c:(.text+0x206e0): undefined reference to `tps65010_set_gpio_out_value'
debugfs.c:(.text+0x20704): undefined reference to `tps65010_set_gpio_out_value'

This clarifies the dependency so we can only select it if
the dependnecy is built-in.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/drivers/video/fbdev/omap/Kconfig b/drivers/video/fbdev/omap/Kconfig
index 18c4cb0d5690..29d250da8a3e 100644
--- a/drivers/video/fbdev/omap/Kconfig
+++ b/drivers/video/fbdev/omap/Kconfig
@@ -42,7 +42,7 @@ config FB_OMAP_LCD_MIPID
 config FB_OMAP_LCD_H3
bool TPS65010 LCD controller on OMAP-H3
depends on MACH_OMAP_H3
-   depends on TPS65010
+   depends on TPS65010=y
default y
help
  Say Y here if you want to have support for the LCD on the

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 1/2] omap clean-up for v4.2

[Arnd Bergmann]

On Wednesday 20 May 2015 15:36:04 Tony Lindgren wrote:
 Clean-up for omaps for v4.2 merge window:
 
 Drop more omap3 legacy board-*.c files for v4.2. This time we're
 dropping the board files for beagle, overo and cm-t35.
 
 The reason for dropping these now rather than later is that now
 we can simply revert the patches in case of unexpected issues as
 we are not dropping any platform data at this point.
 
 This leaves us with only the following board-*.c files:
 
 BOARD   REASON NEEDED
 board-ldp.c Still used in RMKs boot test system
 board-omap3logic.c  Getting a .dts file for v4.2
 board-omap3pandora.cGot a .dts file for v4.1
 board-rx51-*.c  Needs /proc/atags support for user space
 
 I'm hoping we can drop the remaining board-*.c for v4.3 merge
 window, then keep the platform data around for one more merge
 window in case of reverting needed, then drop the platform data
 too for v4.4 if no issues needing reverting are found.

Sounds good. 

Pulled into next/cleanup, thanks!

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2

[Arnd Bergmann]

On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
 Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
 to making omap1 support multiarch. After this series we still need to
 make omap1 use the common clock framework and fix up the drivers to not
 rely on includes from mach and plat directories.
 
 Note that this branch depends on a GPIO driver fix in v4.1-rc3
 d2d05c65c40e (gpio: omap: Fix regression for MPUIO interrupts).
 

I'm getting lots of build errors in linux-next, which I think are
caused by this series.

Here is my fixup. Unfortunately, this again gets us a little further
from making the drivers standalone, or at least it documents the
dependencies.

Arnd

diff --git a/arch/arm/mach-omap1/board-htcherald.c 
b/arch/arm/mach-omap1/board-htcherald.c
index 9525ef9bc6c0..ac9bd88c6b05 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -42,6 +42,7 @@
 #include asm/mach-types.h
 #include asm/mach/arch.h
 
+#include mach/hardware.h
 #include mach/omap7xx.h
 #include mmc.h
 
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 6e6ec93dcbb3..404f3f55726f 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -19,6 +19,7 @@
 #include linux/gpio.h
 #include linux/platform_data/gpio-omap.h
 
+#include mach/soc.h
 #include mach/irqs.h
 
 #define OMAP1610_GPIO1_BASE0xfffbe400
diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
index 4612d2506a2d..1bb38a4aec8f 100644
--- a/arch/arm/mach-omap1/gpio7xx.c
+++ b/arch/arm/mach-omap1/gpio7xx.c
@@ -19,6 +19,7 @@
 #include linux/gpio.h
 #include linux/platform_data/gpio-omap.h
 
+#include mach/soc.h
 #include mach/irqs.h
 
 #define OMAP7XX_GPIO1_BASE 0xfffbc000
diff --git a/arch/arm/mach-omap1/iomap.h b/arch/arm/mach-omap1/iomap.h
index f4e2d7a21365..23686204df45 100644
--- a/arch/arm/mach-omap1/iomap.h
+++ b/arch/arm/mach-omap1/iomap.h
@@ -27,6 +27,7 @@
  * Omap1 specific IO mapping
  * 
  */
+#include mach/hardware.h
 
 #define OMAP1_IO_PHYS  0xFFFB
 #define OMAP1_IO_SIZE  0x4
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index d1ac08016f0b..652ba6b9385e 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -22,6 +22,7 @@
 
 #include asm/mach-types.h
 
+#include mach/soc.h
 #include mach/mux.h
 
 #include pm.h
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 4118db50d5e8..1f28b5e8d6ca 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -26,6 +26,7 @@
 
 #include asm/irq.h
 
+#include mach/hardware.h
 #include mach/mux.h
 
 #include mach/usb.h
diff --git a/drivers/input/keyboard/omap-keypad.c 
b/drivers/input/keyboard/omap-keypad.c
index 7502e46165fa..32c8fc0fdc15 100644
--- a/drivers/input/keyboard/omap-keypad.c
+++ b/drivers/input/keyboard/omap-keypad.c
@@ -38,6 +38,10 @@
 #include linux/platform_data/gpio-omap.h
 #include linux/platform_data/keypad-omap.h
 
+#ifdef CONFIG_ARCH_OMAP1
+#include mach/hardware.h
+#endif
+
 #undef NEW_BOARD_LEARNING_MODE
 
 static void omap_kp_tasklet(unsigned long);
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index c43f74c53cd9..c73297bd7ed4 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -15,6 +15,10 @@
 #include linux/serial_reg.h
 #include linux/dmaengine.h
 
+#ifdef CONFIG_ARCH_OMAP1
+#include mach/soc.h
+#endif
+
 struct uart_8250_dma {
int (*tx_dma)(struct uart_8250_port *p);
int (*rx_dma)(struct uart_8250_port *p, unsigned int iir);
diff --git a/drivers/usb/phy/phy-isp1301-omap.c 
b/drivers/usb/phy/phy-isp1301-omap.c
index 3af263cc0caa..1c05541bbeee 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -36,6 +36,7 @@
 #include asm/irq.h
 #include asm/mach-types.h
 
+#include mach/hardware.h
 #include mach/mux.h
 
 #include mach/usb.h
diff --git a/drivers/video/fbdev/omap/lcdc.c b/drivers/video/fbdev/omap/lcdc.c
index 6efa2591eaa8..4e01fbbeb52f 100644
--- a/drivers/video/fbdev/omap/lcdc.c
+++ b/drivers/video/fbdev/omap/lcdc.c
@@ -30,6 +30,7 @@
 #include linux/clk.h
 #include linux/gfp.h
 
+#include mach/hardware.h
 #include mach/lcdc.h
 #include linux/omap-dma.h
 
diff --git a/drivers/video/fbdev/omap/sossi.c b/drivers/video/fbdev/omap/sossi.c
index d4e7684e7045..39d9d7050d78 100644
--- a/drivers/video/fbdev/omap/sossi.c
+++ b/drivers/video/fbdev/omap/sossi.c
@@ -27,6 +27,8 @@
 
 #include linux/omap-dma.h
 
+#include mach/hardware.h
+
 #include omapfb.h
 #include lcdc.h
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2

[Arnd Bergmann]

On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
 Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
 to making omap1 support multiarch. After this series we still need to
 make omap1 use the common clock framework and fix up the drivers to not
 rely on includes from mach and plat directories.
 
 Note that this branch depends on a GPIO driver fix in v4.1-rc3
 d2d05c65c40e (gpio: omap: Fix regression for MPUIO interrupts).
 

fwiw, I have another patch in my 'multiplatform' series that will add
another baby step.

8---
ARM: OMAP1: make header files local if possible

A number of header files in mach-omap1 are never included from outside
of mach-omap1, so we can move them directly to that directory.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index a95499ea8706..9fc70978823b 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -41,7 +41,7 @@
 
 #include mach/hardware.h
 #include mach/ams-delta-fiq.h
-#include mach/camera.h
+#include camera.h
 #include mach/usb.h
 
 #include iomap.h
diff --git a/arch/arm/mach-omap1/board-fsample.c 
b/arch/arm/mach-omap1/board-fsample.c
index 0fb51d22c8b5..fad95b74bb65 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -29,7 +29,7 @@
 
 #include mach/tc.h
 #include mach/mux.h
-#include mach/flash.h
+#include flash.h
 #include linux/platform_data/keypad-omap.h
 
 #include mach/hardware.h
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 8340d684d8b6..cd146ed0538d 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -42,7 +42,7 @@
 #include linux/omap-dma.h
 #include mach/tc.h
 #include linux/platform_data/keypad-omap.h
-#include mach/flash.h
+#include flash.h
 
 #include mach/hardware.h
 #include mach/usb.h
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 086ff34e072b..f7c8c63dd532 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -44,7 +44,7 @@
 #include mach/tc.h
 #include linux/platform_data/keypad-omap.h
 #include linux/omap-dma.h
-#include mach/flash.h
+#include flash.h
 
 #include mach/hardware.h
 #include mach/irqs.h
diff --git a/arch/arm/mach-omap1/board-innovator.c 
b/arch/arm/mach-omap1/board-innovator.c
index ed4e045c2ad8..ae90bd02b3bf 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -32,7 +32,7 @@
 #include asm/mach/map.h
 
 #include mach/mux.h
-#include mach/flash.h
+#include flash.h
 #include mach/tc.h
 #include linux/platform_data/keypad-omap.h
 
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 0efd165b8227..209aecb0df68 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -46,7 +46,7 @@
 #include asm/mach/arch.h
 #include asm/mach/map.h
 
-#include mach/flash.h
+#include flash.h
 #include mach/mux.h
 #include mach/tc.h
 
diff --git a/arch/arm/mach-omap1/board-palmte.c 
b/arch/arm/mach-omap1/board-palmte.c
index 1142ae431fe0..e5288cda1a6a 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -34,7 +34,7 @@
 #include asm/mach/arch.h
 #include asm/mach/map.h
 
-#include mach/flash.h
+#include flash.h
 #include mach/mux.h
 #include mach/tc.h
 #include linux/omap-dma.h
diff --git a/arch/arm/mach-omap1/board-palmtt.c 
b/arch/arm/mach-omap1/board-palmtt.c
index 54a547a96950..d672495f7441 100644
--- a/arch/arm/mach-omap1/board-palmtt.c
+++ b/arch/arm/mach-omap1/board-palmtt.c
@@ -34,7 +34,7 @@
 #include asm/mach/arch.h
 #include asm/mach/map.h
 
-#include mach/flash.h
+#include flash.h
 #include mach/mux.h
 #include linux/omap-dma.h
 #include mach/tc.h
diff --git a/arch/arm/mach-omap1/board-palmz71.c 
b/arch/arm/mach-omap1/board-palmz71.c
index 87ec04ae40dd..aaf741b0aff6 100644
--- a/arch/arm/mach-omap1/board-palmz71.c
+++ b/arch/arm/mach-omap1/board-palmz71.c
@@ -36,7 +36,7 @@
 #include asm/mach/arch.h
 #include asm/mach/map.h
 
-#include mach/flash.h
+#include flash.h
 #include mach/mux.h
 #include linux/omap-dma.h
 #include mach/tc.h
diff --git a/arch/arm/mach-omap1/board-perseus2.c 
b/arch/arm/mach-omap1/board-perseus2.c
index 3d76f05407f0..150b57ba42bf 100644
--- a/arch/arm/mach-omap1/board-perseus2.c
+++ b/arch/arm/mach-omap1/board-perseus2.c
@@ -30,7 +30,7 @@
 
 #include mach/tc.h
 #include mach/mux.h
-#include mach/flash.h
+#include flash.h
 
 #include mach/hardware.h
 
diff --git a/arch/arm/mach-omap1/board-sx1-mmc.c 
b/arch/arm/mach-omap1/board-sx1-mmc.c
index 4fcf19c78a08..a9373570bbb1 100644
--- a/arch/arm/mach-omap1/board-sx1-mmc.c
+++ b/arch/arm/mach-omap1/board-sx1-mmc.c
@@ -16,7 +16,7 @@
 #include linux/platform_device.h
 
 #include mach/hardware.h
-#include mach/board-sx1.h
+#include board-sx1.h
 
 #include mmc.h
 
diff --git a/arch/arm/mach-omap1/board-sx1.c b/arch

Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2

[Arnd Bergmann]

On Thursday 21 May 2015 14:14:12 Arnd Bergmann wrote:
 On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote:
  Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer
  to making omap1 support multiarch. After this series we still need to
  make omap1 use the common clock framework and fix up the drivers to not
  rely on includes from mach and plat directories.
  
  Note that this branch depends on a GPIO driver fix in v4.1-rc3
  d2d05c65c40e (gpio: omap: Fix regression for MPUIO interrupts).
  
 
 fwiw, I have another patch in my 'multiplatform' series that will add
 another baby step.
 
 8---
 ARM: OMAP1: make header files local if possible
 
 A number of header files in mach-omap1 are never included from outside
 of mach-omap1, so we can move them directly to that directory.
 
 Signed-off-by: Arnd Bergmann a...@arndb.de

and three more:

diff --git a/arch/arm/mach-omap1/board-h3.h b/arch/arm/mach-omap1/board-h3.h
index 78de535be3c5..f70c42801969 100644
--- a/arch/arm/mach-omap1/board-h3.h
+++ b/arch/arm/mach-omap1/board-h3.h
@@ -27,6 +27,8 @@
 #ifndef __ASM_ARCH_OMAP_H3_H
 #define __ASM_ARCH_OMAP_H3_H
 
+#include mach/irqs.h
+
 #define H3_TPS_GPIO_BASE   (OMAP_MAX_GPIO_LINES + 16 /* MPUIO */)
 #  define H3_TPS_GPIO_MMC_PWR_EN   (H3_TPS_GPIO_BASE + 4)
 
diff --git a/drivers/usb/gadget/udc/omap_udc.c 
b/drivers/usb/gadget/udc/omap_udc.c
index e2fcdb8e5596..8a3690b2acbd 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -45,6 +45,7 @@
 
 #include linux/omap-dma.h
 
+#include mach/hardware.h
 #include mach/usb.h
 
 #include omap_udc.h
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 6bb623a2a4df..1f6c8d91f738 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -34,6 +34,7 @@
 #include sound/omap-pcm.h
 
 #ifdef CONFIG_ARCH_OMAP1
+#include mach/soc.h
 #define pcm_omap1510() cpu_is_omap1510()
 #else
 #define pcm_omap1510() 0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html