* [PATCH v2 2/2] mfd: Kconfig: Let MFD_SYSCON select REGMAP
From: Mark Brown @ 2012-10-19 1:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350605046-21358-2-git-send-email-festevam@gmail.com>
On Thu, Oct 18, 2012 at 09:04:06PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Building multi_v7_defconfig for mx6 causes the following build error:
> Fix it by selecting REGMAP option.
No, this is silly - selecting MMIO ought to do the right thing. There's
a patch queued for Linus which will resolve this.
^ permalink raw reply
* [PATCH 05/10] i2c: pxa: use devm_kzalloc
From: Haojian Zhuang @ 2012-10-19 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5080826D.6040108@wwwdotorg.org>
On Fri, Oct 19, 2012 at 6:27 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/18/2012 03:06 AM, Haojian Zhuang wrote:
>> Use devm_kzalloc & add checking in probe() function.
>
> This patch seems unrelated to this series. In fact, the series touches a
> bunch of different subsystems; would you expect all these patches to be
> merged through a single tree? If so, which?
Yes, I expect all these patches could be merged by pinctrl subtree.
Regards
Haojian
^ permalink raw reply
* [PATCH v2 2/2] mfd: Kconfig: Let MFD_SYSCON select REGMAP
From: Fabio Estevam @ 2012-10-19 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350605046-21358-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
Building multi_v7_defconfig for mx6 causes the following build error:
CC drivers/mfd/syscon.o
drivers/mfd/syscon.c:94: error: variable 'syscon_regmap_config' has initializer but incomplete type
drivers/mfd/syscon.c:95: error: unknown field 'reg_bits' specified in initializer
drivers/mfd/syscon.c:95: warning: excess elements in struct initializer
drivers/mfd/syscon.c:95: warning: (near initialization for 'syscon_regmap_config')
drivers/mfd/syscon.c:96: error: unknown field 'val_bits' specified in initializer
drivers/mfd/syscon.c:96: warning: excess elements in struct initializer
drivers/mfd/syscon.c:96: warning: (near initialization for 'syscon_regmap_config')
drivers/mfd/syscon.c:97: error: unknown field 'reg_stride' specified in initializer
drivers/mfd/syscon.c:97: warning: excess elements in struct initializer
drivers/mfd/syscon.c:97: warning: (near initialization for 'syscon_regmap_config')
drivers/mfd/syscon.c: In function 'syscon_probe':
drivers/mfd/syscon.c:124: error: invalid use of undefined type 'struct regmap_config'
drivers/mfd/syscon.c:125: error: implicit declaration of function 'devm_regmap_init_mmio'
drivers/mfd/syscon.c:126: warning: assignment makes pointer from integer without a cast
Fix it by selecting REGMAP option.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- No changes. Newly introduced in this series
drivers/mfd/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index acab3ef..ef56515 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1030,6 +1030,7 @@ config MFD_SYSCON
bool "System Controller Register R/W Based on Regmap"
depends on OF
select REGMAP_MMIO
+ select REGMAP
help
Select this option to enable accessing system control registers
via regmap.
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/2] ARM: multi_v7_defconfig: Add ARCH_MXC
From: Fabio Estevam @ 2012-10-19 0:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Let ARCH_MXC be covered by multi_v7_defconfig.
Allow booting mx6 via NFS.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Provide a more complete config that allows booting mx6 via NFS
arch/arm/configs/multi_v7_defconfig | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 159f75f..df1e563 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -5,6 +5,8 @@ CONFIG_ARCH_MVEBU=y
CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_XP=y
CONFIG_ARCH_HIGHBANK=y
+CONFIG_ARCH_MXC=y
+CONFIG_SOC_IMX6Q=y
CONFIG_ARCH_SOCFPGA=y
# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set
CONFIG_ARM_ERRATA_754322=y
@@ -17,18 +19,29 @@ CONFIG_ARM_APPENDED_DTB=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
CONFIG_ATA=y
CONFIG_SATA_HIGHBANK=y
CONFIG_NETDEVICES=y
CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DW=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_IMX=y
+CONFIG_SERIAL_IMX_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_IPMI_HANDLER=y
CONFIG_IPMI_SI=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
From: Tony Lindgren @ 2012-10-18 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALLhW=5Fmjhd+w57Dmm2BLmBoHuC7_jprJndkw1dHoVzVu4TOg@mail.gmail.com>
Omar,
* Omar Ramirez Luna <omar.luna@linaro.org> [121017 16:54]:
> On 16 October 2012 12:22, Tony Lindgren <tony@atomide.com> wrote:
>
> > These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu
> > when I have that pushed out as that removes plat/*iommu*.h files.
>
> Ok, will wait and rebase on top of it.
Thanks, the related patches are now posted in thread
"[PATCH v3 0/6] omap iommu changes to remove plat includes".
Also, can you please take a look at the "Updated status of the removal
of plat headers" thread?
I've tagged you to remove the omap plat/mailbox.h :)
Regards,
Tony
^ permalink raw reply
* [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
From: Mark A. Greer @ 2012-10-18 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018233335.GC28061@n2100.arm.linux.org.uk>
On Fri, Oct 19, 2012 at 12:33:35AM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 18, 2012 at 04:24:05PM -0700, Mark A. Greer wrote:
> > On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > > > This patch seems fairly stable but I've only tested omap-sham (crypto)
> > > > and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
> > > > that made the system unstable when exercising either omap-sham or
> > > > omap_hsmmc. I'm unaware of any errata that would make this an unwanted
> > > > modification but I haven't checked all of the SoCs. Are there other
> > > > reasons that this should be applied??
> > >
> > > It definitely needs checking with audio, because it will affect the
> > > pointer position in relation to audio output, and it will have an
> > > effect on how much audio data is lost over a pause/resume event.
> > >
> > > Unfortunately, the OMAP DMA hardware has no way to do a proper "pause",
> > > it can only do a "stop" which involves dumping its FIFOs on the floor
> > > in the case of anything but a DEV->MEM transfer. So the more data
> > > held in the DMA hardware, the more is lost on pause.
> >
> > Hmm, interesting.
> >
> > Is there a way to tweak DMA params like this on a per logical channel
> > basis using the dmaengine API? I don't see any but I could have missed it.
> >
> > If not, are you open to adding such a thing (e.g., extend 'enum dma_ctrl_flags'
> > with DMA_ENABL_PREFETCH)?
>
> I would suggest getting some feedback from the ASoC people first, before
> trying to invent new APIs to work around this stuff. If they can live
> with having prefetch enabled on OMAP then there isn't an issue here. If
> not, we need a solution to this.
>
> I do not believe that precisely stopping and starting playback across a
> suspend/resume event is really necessary (it's desirable but the world
> doesn't collapse if you miss a few samples.) It could be more of an
> issue for pause/resume though, but as I say, that's for ASoC people to
> comment on.
>
> I'm merely pointing out here that we need their feedback here before
> deciding if there's anything further that needs to happen.
Thanks, I will do that.
^ permalink raw reply
* [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
From: Russell King - ARM Linux @ 2012-10-18 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018232405.GA29064@animalcreek.com>
On Thu, Oct 18, 2012 at 04:24:05PM -0700, Mark A. Greer wrote:
> On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > > This patch seems fairly stable but I've only tested omap-sham (crypto)
> > > and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
> > > that made the system unstable when exercising either omap-sham or
> > > omap_hsmmc. I'm unaware of any errata that would make this an unwanted
> > > modification but I haven't checked all of the SoCs. Are there other
> > > reasons that this should be applied??
> >
> > It definitely needs checking with audio, because it will affect the
> > pointer position in relation to audio output, and it will have an
> > effect on how much audio data is lost over a pause/resume event.
> >
> > Unfortunately, the OMAP DMA hardware has no way to do a proper "pause",
> > it can only do a "stop" which involves dumping its FIFOs on the floor
> > in the case of anything but a DEV->MEM transfer. So the more data
> > held in the DMA hardware, the more is lost on pause.
>
> Hmm, interesting.
>
> Is there a way to tweak DMA params like this on a per logical channel
> basis using the dmaengine API? I don't see any but I could have missed it.
>
> If not, are you open to adding such a thing (e.g., extend 'enum dma_ctrl_flags'
> with DMA_ENABL_PREFETCH)?
I would suggest getting some feedback from the ASoC people first, before
trying to invent new APIs to work around this stuff. If they can live
with having prefetch enabled on OMAP then there isn't an issue here. If
not, we need a solution to this.
I do not believe that precisely stopping and starting playback across a
suspend/resume event is really necessary (it's desirable but the world
doesn't collapse if you miss a few samples.) It could be more of an
issue for pause/resume though, but as I say, that's for ASoC people to
comment on.
I'm merely pointing out here that we need their feedback here before
deciding if there's anything further that needs to happen.
^ permalink raw reply
* [PATCH] pinctrl: reserve pins when states are activated
From: Stephen Warren @ 2012-10-18 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350554487-7914-1-git-send-email-linus.walleij@stericsson.com>
On 10/18/2012 04:01 AM, Linus Walleij wrote:
> This switches the way that pins are reserved for multiplexing:
The conceptual change makes perfect sense to me.
> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
> void pinmux_free_setting(struct pinctrl_setting const *setting)
...
> + /*
> + * If a setting is active, disable it so that all pins are released
> + */
> + pinmux_disable_setting(setting);
"*If* a setting is active ..." implies there should be a C if statement
here to check if the setting is actually active before trying to disable it?
^ permalink raw reply
* [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
From: Mark A. Greer @ 2012-10-18 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018225540.GB28061@n2100.arm.linux.org.uk>
On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > This patch seems fairly stable but I've only tested omap-sham (crypto)
> > and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
> > that made the system unstable when exercising either omap-sham or
> > omap_hsmmc. I'm unaware of any errata that would make this an unwanted
> > modification but I haven't checked all of the SoCs. Are there other
> > reasons that this should be applied??
>
> It definitely needs checking with audio, because it will affect the
> pointer position in relation to audio output, and it will have an
> effect on how much audio data is lost over a pause/resume event.
>
> Unfortunately, the OMAP DMA hardware has no way to do a proper "pause",
> it can only do a "stop" which involves dumping its FIFOs on the floor
> in the case of anything but a DEV->MEM transfer. So the more data
> held in the DMA hardware, the more is lost on pause.
Hmm, interesting.
Is there a way to tweak DMA params like this on a per logical channel
basis using the dmaengine API? I don't see any but I could have missed it.
If not, are you open to adding such a thing (e.g., extend 'enum dma_ctrl_flags'
with DMA_ENABL_PREFETCH)?
Mark
--
^ permalink raw reply
* [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
From: Russell King - ARM Linux @ 2012-10-18 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018222046.GA28541@animalcreek.com>
On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> This patch seems fairly stable but I've only tested omap-sham (crypto)
> and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
> that made the system unstable when exercising either omap-sham or
> omap_hsmmc. I'm unaware of any errata that would make this an unwanted
> modification but I haven't checked all of the SoCs. Are there other
> reasons that this should be applied??
It definitely needs checking with audio, because it will affect the
pointer position in relation to audio output, and it will have an
effect on how much audio data is lost over a pause/resume event.
Unfortunately, the OMAP DMA hardware has no way to do a proper "pause",
it can only do a "stop" which involves dumping its FIFOs on the floor
in the case of anything but a DEV->MEM transfer. So the more data
held in the DMA hardware, the more is lost on pause.
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Paul Walmsley @ 2012-10-18 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50806B18.1010502@ti.com>
On Fri, 19 Oct 2012, Vaibhav Hiremath wrote:
> 2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
> needs special handling for this. I already have patch for this, which I
> will submit it to the list.
>
> http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11
OK, will drop the original patch and wait for you to post the updated one.
- Paul
^ permalink raw reply
* [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
From: Mark A. Greer @ 2012-10-18 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018222046.GA28541@animalcreek.com>
On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> This patch seems fairly stable but I've only tested omap-sham (crypto)
> and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
> that made the system unstable when exercising either omap-sham or
> omap_hsmmc. I'm unaware of any errata that would make this an unwanted
> modification but I haven't checked all of the SoCs. Are there other
> reasons that this should be applied??
^not
^ permalink raw reply
* [PATCH 3/5] ARM: tegra: fix clock entry of slink controller
From: Stephen Warren @ 2012-10-18 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350557795-31487-4-git-send-email-ldewangan@nvidia.com>
On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
> Fix the driver name, connection name and clock name
> for slink controller clocks in clock table of
> Tegra20 and Tegra30.
The patch subject isn't entirely accurate here; this patch isn't just
about fixing clock entries.
> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c b/arch/arm/mach-tegra/board-dt-tegra20.c
> @@ -90,6 +90,10 @@ struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
> &tegra_ehci3_pdata),
> OF_DEV_AUXDATA("nvidia,tegra20-apbdma", TEGRA_APB_DMA_BASE, "tegra-apbdma", NULL),
> OF_DEV_AUXDATA("nvidia,tegra20-pwm", TEGRA_PWFM_BASE, "tegra-pwm", NULL),
> + OF_DEV_AUXDATA("nvidia,tegra20-slink", TEGRA_SLINK1_BASE, "spi-tegra-slink.0", NULL),
Here, can't we just use the existing device names in the clock files...
So we can completely drop the changes to these two files:
> diff --git a/arch/arm/mach-tegra/tegra20_clocks_data.c b/arch/arm/mach-tegra/tegra20_clocks_data.c
> diff --git a/arch/arm/mach-tegra/tegra30_clocks_data.c b/arch/arm/mach-tegra/tegra30_clocks_data.c
The device names will hopefully be irrelevant once we're able to use
DT-based clock lookups.
^ permalink raw reply
* [PATCH 2/5] ARM: tegra: dts: add slink controller dt entry
From: Stephen Warren @ 2012-10-18 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350557795-31487-3-git-send-email-ldewangan@nvidia.com>
On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
> Add slink controller details in the dts file of
> Tegra20 and Tegra30.
> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
> + slink at 7000d400 {
> + compatible = "nvidia,tegra20-slink";
> + reg = <0x7000d400 0x200>;
> + interrupts = <0 59 0x04>;
> + nvidia,dma-req-sel = <15>;
I thought the common DT DMA bindings were going to be in 3.7, and hence
we could just use them here rather than inventing another custom
property for this purpose?
^ permalink raw reply
* [PATCH 1/5] ARM: tegra: Add slink controller base address
From: Stephen Warren @ 2012-10-18 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350557795-31487-2-git-send-email-ldewangan@nvidia.com>
On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
> Add base address of all slink controller of Tegra20
> and tegra30.
Lets not add anything to iomap.h; we're trying to remove it. Instead,
just put the raw address in the AUXDATA; I assume that's the only place
these defines end up being used...
^ permalink raw reply
* [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver
From: Stephen Warren @ 2012-10-18 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350569623-4699-2-git-send-email-maxime.ripard@free-electrons.com>
On 10/18/2012 08:13 AM, Maxime Ripard wrote:
> Allow the i2c-mux-gpio to be used by a device tree enabled device. The
> bindings are inspired by the one found in the i2c-mux-pinctrl driver.
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
> +Optional properties:
> +- idle-state: value to set to the muxer when idle. When no value is
> + given, it defaults to the first value in the array.
That's inconsistent with the following text that appears later (and
describes what the driver actually does):
> +If an idle state is defined, using the idle-state (optional) property,
> +whenever an access is not being made to a device on a child bus, the
> +idle value will be programmed into the GPIOs.
> +
> +If an idle state is not defined, the most recently used value will be
> +left programmed into hardware whenever no access is being made of a
> +device on a child bus.
^ permalink raw reply
* [PATCH 08/10] pinctrl: single: support pinconf generic
From: Tony Lindgren @ 2012-10-18 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda0QLkdKns3CXNOijYBjaDtW1QyhNYjTqDvRH-in8pvZQ@mail.gmail.com>
* Linus Walleij <linus.walleij@linaro.org> [121018 11:32]:
> On Thu, Oct 18, 2012 at 11:07 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>
> > Add pinconf generic support with POWER SOURCE, BIAS PULL.
> >
> > Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
>
> I really like the looks of this, good job Haojian!
>
> Now we just need to hear what Tony says about it...
Hey that's cool, maybe I'll find some use for those too :)
I'll take a closer look tonigh or on Friday.
Regards,
Tony
^ permalink raw reply
* [PATCH 01/10] pinctrl: use postcore_initcall
From: Tony Lindgren @ 2012-10-18 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5080802B.3000209@wwwdotorg.org>
* Stephen Warren <swarren@wwwdotorg.org> [121018 15:20]:
> On 10/18/2012 03:06 AM, Haojian Zhuang wrote:
> > Since pins are configured in device driver, pinctrl driver should be
> > loaded by those device driver. module_platform_driver() only declares
> > pinctrl driver is in module_initcall privilege. Use postcore_initcall
> > privilege instead.
>
> I'm not convinced this is needed; doesn't deferred probe sort out the
> dependencies correctly?
I'm a bit concerned about this need too as the trend is towards
initializing things later than earlier. The drivers/Makefile order
and deferred probe should be already enough?
Specifically could you decribe the cases where this issue happens?
Also check if one of your client drivers has some early initcall
that's no longer needed.
Regards,
Tony
^ permalink raw reply
* [PATCH 05/10] i2c: pxa: use devm_kzalloc
From: Stephen Warren @ 2012-10-18 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350551224-12857-5-git-send-email-haojian.zhuang@gmail.com>
On 10/18/2012 03:06 AM, Haojian Zhuang wrote:
> Use devm_kzalloc & add checking in probe() function.
This patch seems unrelated to this series. In fact, the series touches a
bunch of different subsystems; would you expect all these patches to be
merged through a single tree? If so, which?
^ permalink raw reply
* [PATCH 07/10] pinctrl: remove mutex lock in groups show
From: Stephen Warren @ 2012-10-18 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350551224-12857-7-git-send-email-haojian.zhuang@gmail.com>
On 10/18/2012 03:07 AM, Haojian Zhuang wrote:
> Mutex is locked duplicatly by pinconf_groups_show() and
> pin_config_group_get(). It results dead lock. So avoid to lock mutex
> in pinconf_groups_show().
With this outer lock removed, how do we ensure that the pinctrl driver
that is being called into remains loaded? Does the existence of the
debugfs file ensure this, such that if it's open, the pinctrl driver
can't be removed?
Related, I wonder if much of the variable setup at the start of the
function shouldn't happen inside the lock instead of outside:
static int pinconf_groups_show(struct seq_file *s, void *what)
{
struct pinctrl_dev *pctldev = s->private;
const struct pinctrl_ops *pctlops = pctldev->desc->pctlops;
const struct pinconf_ops *ops = pctldev->desc->confops;
unsigned ngroups = pctlops->get_groups_count(pctldev);
since what if s->private is unregistered/destroyed while this function
is running?
^ permalink raw reply
* [PATCH 03/10] tty: pxa: configure pin
From: Stephen Warren @ 2012-10-18 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350551224-12857-3-git-send-email-haojian.zhuang@gmail.com>
On 10/18/2012 03:06 AM, Haojian Zhuang wrote:
> Configure pins by pinctrl driver.
In general, it seems better to use pinctrl "hogs" if the driver is only
going to statically set up one pinctrl state and never change it. The
alternative is make every single driver execute these pinctrl calls,
which could be tedious.
However, that does raise one question: If all the pinctrl setup is done
by hogs, then how do we ensure that the pinctrl driver is probed first,
and hence sets up the pins before any driver relies on them being set
up? If a driver explicitly enables a pinctrl state (as in this patch),
then deferred probe ensures that, but without any explicit pinctrl
action, it'll only work by luck.
LinusW, what are your thoughts on that?
^ permalink raw reply
* [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
From: Mark A. Greer @ 2012-10-18 22:20 UTC (permalink / raw)
To: linux-arm-kernel
Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
flag whenever there is a destination synchronized DMA transfer.
Prefetching is not allowed on source synchronized DMA transfers.
Enabling prefetch significantly improves DMA performance.
For example, running 'modprobe tcrypt sec=2 mode=403' which
exercises the omap-sham driver on an am37x EVM yeilds the
following results:
a) With prefetch disabled
testing speed of async sha1
test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 24049 opers/sec, 384784 bytes/sec
test 1 ( 64 byte blocks, 16 bytes per update, 4 updates): 22030 opers/sec, 1409920 bytes/sec
test 2 ( 64 byte blocks, 64 bytes per update, 1 updates): 24055 opers/sec, 1539520 bytes/sec
test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 7648 opers/sec, 1958016 bytes/sec
test 4 ( 256 byte blocks, 64 bytes per update, 4 updates): 7918 opers/sec, 2027008 bytes/sec
test 5 ( 256 byte blocks, 256 bytes per update, 1 updates): 8000 opers/sec, 2048000 bytes/sec
test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 3295 opers/sec, 3374080 bytes/sec
test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 3602 opers/sec, 3688960 bytes/sec
test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 3753 opers/sec, 3843072 bytes/sec
test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 3239 opers/sec, 6633472 bytes/sec
test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 3557 opers/sec, 7284736 bytes/sec
test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 3591 opers/sec, 7354368 bytes/sec
test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 3598 opers/sec, 7369728 bytes/sec
test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 1751 opers/sec, 7174144 bytes/sec
test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 2302 opers/sec, 9431040 bytes/sec
test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 2087 opers/sec, 8548352 bytes/sec
test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 2050 opers/sec, 8398848 bytes/sec
test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 864 opers/sec, 7077888 bytes/sec
test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 993 opers/sec, 8138752 bytes/sec
test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 936 opers/sec, 7671808 bytes/sec
test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 1048 opers/sec, 8589312 bytes/sec
test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 1274 opers/sec, 10436608 bytes/sec
b) With prefetch enabled
testing speed of async sha1
test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 23868 opers/sec, 381888 bytes/sec
test 1 ( 64 byte blocks, 16 bytes per update, 4 updates): 21928 opers/sec, 1403424 bytes/sec
test 2 ( 64 byte blocks, 64 bytes per update, 1 updates): 23910 opers/sec, 1530272 bytes/sec
test 3 ( 256 byte blocks, 16 bytes per update, 16 updates): 7664 opers/sec, 1962112 bytes/sec
test 4 ( 256 byte blocks, 64 bytes per update, 4 updates): 7924 opers/sec, 2028672 bytes/sec
test 5 ( 256 byte blocks, 256 bytes per update, 1 updates): 8006 opers/sec, 2049536 bytes/sec
test 6 ( 1024 byte blocks, 16 bytes per update, 64 updates): 3276 opers/sec, 3355136 bytes/sec
test 7 ( 1024 byte blocks, 256 bytes per update, 4 updates): 3856 opers/sec, 3949056 bytes/sec
test 8 ( 1024 byte blocks, 1024 bytes per update, 1 updates): 3634 opers/sec, 3721728 bytes/sec
test 9 ( 2048 byte blocks, 16 bytes per update, 128 updates): 3257 opers/sec, 6670336 bytes/sec
test 10 ( 2048 byte blocks, 256 bytes per update, 8 updates): 3604 opers/sec, 7380992 bytes/sec
test 11 ( 2048 byte blocks, 1024 bytes per update, 2 updates): 3604 opers/sec, 7380992 bytes/sec
test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates): 3624 opers/sec, 7422976 bytes/sec
test 13 ( 4096 byte blocks, 16 bytes per update, 256 updates): 2698 opers/sec, 11051008 bytes/sec
test 14 ( 4096 byte blocks, 256 bytes per update, 16 updates): 3500 opers/sec, 14336000 bytes/sec
test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 3596 opers/sec, 14729216 bytes/sec
test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 3588 opers/sec, 14698496 bytes/sec
test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): 1319 opers/sec, 10809344 bytes/sec
test 18 ( 8192 byte blocks, 256 bytes per update, 32 updates): 1550 opers/sec, 12701696 bytes/sec
test 19 ( 8192 byte blocks, 1024 bytes per update, 8 updates): 1164 opers/sec, 9539584 bytes/sec
test 20 ( 8192 byte blocks, 4096 bytes per update, 2 updates): 1802 opers/sec, 14766080 bytes/sec
test 21 ( 8192 byte blocks, 8192 bytes per update, 1 updates): 1720 opers/sec, 14094336 bytes/sec
CC: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---
This patch seems fairly stable but I've only tested omap-sham (crypto)
and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but
that made the system unstable when exercising either omap-sham or
omap_hsmmc. I'm unaware of any errata that would make this an unwanted
modification but I haven't checked all of the SoCs. Are there other
reasons that this should be applied??
The different types of hardware that I have is somewhat limited so if
you have some different platforms/SoCs, please give this patch a try.
It should apply cleanly against recent k.o. kernels.
Note that the current omap-sham driver doesn't use the dmaengine API
but I have a set of patches to convert it which is what I used when
testing. I will submit those patches once they're ready (next day or so).
Also note that an am37xx GP actually does have sham hardware and yours
might too if you look closely. If so, you'll have hack omap_sham_mod_init()
to use it.
Thanks,
Mark
drivers/dma/omap-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..aadddb2 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
dev_addr = c->cfg.dst_addr;
dev_width = c->cfg.dst_addr_width;
burst = c->cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
} else {
dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
return NULL;
@@ -387,7 +387,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
dev_addr = c->cfg.dst_addr;
dev_width = c->cfg.dst_addr_width;
burst = c->cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
} else {
dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
return NULL;
--
1.7.12
^ permalink raw reply related
* [PATCH 01/10] pinctrl: use postcore_initcall
From: Stephen Warren @ 2012-10-18 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350551224-12857-1-git-send-email-haojian.zhuang@gmail.com>
On 10/18/2012 03:06 AM, Haojian Zhuang wrote:
> Since pins are configured in device driver, pinctrl driver should be
> loaded by those device driver. module_platform_driver() only declares
> pinctrl driver is in module_initcall privilege. Use postcore_initcall
> privilege instead.
I'm not convinced this is needed; doesn't deferred probe sort out the
dependencies correctly?
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Tony Lindgren @ 2012-10-18 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018175659.431fe0b1@redhat.com>
* Mauro Carvalho Chehab <mchehab@redhat.com> [121018 13:58]:
> Tony,
>
> Em Thu, 18 Oct 2012 13:28:42 -0700
> Tony Lindgren <tony@atomide.com> escreveu:
>
> > Looks like the iommu framework does not have generic functions
> > exported for all the needs yet. The hardware specific functions
> > are defined in files like intel-iommu.h and amd-iommu.h. Follow
> > the same standard for omap-iommu.h.
> >
> > This is needed because we are removing plat and mach includes
> > for ARM common zImage support. Further work should continue
> > in the iommu framework context as only pure platform data will
> > be communicated from arch/arm/*omap*/* code to the iommu
> > framework.
> >
> > Cc: Joerg Roedel <joerg.roedel@amd.com>
> > Cc: Ohad Ben-Cohen <ohad@wizery.com>
> > Cc: Ido Yariv <ido@wizery.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
> > Cc: Omar Ramirez Luna <omar.luna@linaro.org>
> > Cc: linux-media at vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > arch/arm/mach-omap2/iommu2.c | 1
> > arch/arm/plat-omap/include/plat/iommu.h | 10 +--
> > arch/arm/plat-omap/include/plat/iovmm.h | 89 ----------------------------
> > drivers/iommu/omap-iommu-debug.c | 2 -
> > drivers/iommu/omap-iommu.c | 1
> > drivers/iommu/omap-iovmm.c | 46 ++++++++++++++
> > drivers/media/platform/omap3isp/isp.c | 1
> > drivers/media/platform/omap3isp/isp.h | 2 -
> > drivers/media/platform/omap3isp/ispccdc.c | 1
> > drivers/media/platform/omap3isp/ispstat.c | 1
> > drivers/media/platform/omap3isp/ispvideo.c | 2 -
>
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> It is better if you send this entire series through the ARM tree, keeping
> this hole series altogether (and avoiding the risk of breaking bisectability
> if it goes through separate trees). So, you can add my ack for those header
> moves for drivers/media/platform/*.
Yes thanks. Once people are happy with these, I will push just these
patches on v3.7-rc1 alone into omap-for-v3.8/cleanup-headers-iommu so
both media and iommu tree can merge them in too as needed.
Regards,
Tony
^ permalink raw reply
* [RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq
From: Kevin Hilman @ 2012-10-18 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018193440.GA8609@arwen.pp.htv.fi>
Felipe Balbi <balbi@ti.com> writes:
[...]
> ps: I'll continue reading the code and further test my series to see
> if I can understand what you say here.
OK. And please get it working in cases where drivers are using I2C in
their suspend/resume (and even late/early) paths, and also where device
runtime PM is disabled from userspace. All of that works with today's
code and will not work with your proposed code.
Kevin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox