Re: [PATCH] ARM: Remove __ref on hotplug cpu die path
2015-09-15 8:23 GMT+08:00 Stephen Boyd <sb...@codeaurora.org>:
> Now that __cpuinit has been removed, the __ref markings on these
> functions are useless. Remove them. This also reduces the size of
> the multi_v7_defconfig image:
>
> $ size before after
>textdata bss dec hex filename
>126835781470996 348904 14503478 dd4e36 before
>126832741470996 348904 14503174 dd4d06 after
>
> presumably because now we don't have to jump to code in the
> .ref.text section and/or the noinline marking is removed.
>
> Cc: Tony Lindgren <t...@atomide.com>
> Cc: Barry Song <bao...@kernel.org>
> Cc: Andy Gross <agr...@codeaurora.org>
> Cc: Viresh Kumar <vire...@kernel.org>
> Cc: Shiraz Hashim <shiraz.linux.ker...@gmail.com>
> Cc: Stephen Warren <swar...@wwwdotorg.org>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Cc: Alexandre Courbot <gnu...@gmail.com>
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Cc: Sudeep Holla <sudeep.ho...@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Cc: Will Deacon <will.dea...@arm.com>
> Cc: Mark Rutland <mark.rutl...@arm.com>
> Cc: <linux-omap@vger.kernel.org>
> Cc: <linux-arm-...@vger.kernel.org>
> Cc: <spear-de...@list.st.com>
> Cc: <linux-te...@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
Acked-by: Barry Song <bao...@kernel.org>
> ---
>
> This patch can be broken up into per-SoC if desired.
>
> arch/arm/kernel/psci_smp.c | 4 ++--
> arch/arm/mach-omap2/omap-hotplug.c | 2 +-
> arch/arm/mach-omap2/omap-wakeupgen.c | 2 +-
> arch/arm/mach-prima2/hotplug.c | 2 +-
> arch/arm/mach-qcom/platsmp.c | 2 +-
> arch/arm/mach-realview/hotplug.c | 2 +-
> arch/arm/mach-spear/hotplug.c| 2 +-
> arch/arm/mach-tegra/hotplug.c| 2 +-
> arch/arm/mach-ux500/hotplug.c| 2 +-
> arch/arm/mach-vexpress/hotplug.c | 2 +-
> 10 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> index 61c04b02faeb..9d479b2ea40d 100644
> --- a/arch/arm/kernel/psci_smp.c
> +++ b/arch/arm/kernel/psci_smp.c
> @@ -71,7 +71,7 @@ int psci_cpu_disable(unsigned int cpu)
> return 0;
> }
>
> -void __ref psci_cpu_die(unsigned int cpu)
> +void psci_cpu_die(unsigned int cpu)
> {
> u32 state = PSCI_POWER_STATE_TYPE_POWER_DOWN <<
> PSCI_0_2_POWER_STATE_TYPE_SHIFT;
> @@ -83,7 +83,7 @@ void __ref psci_cpu_die(unsigned int cpu)
> panic("psci: cpu %d failed to shutdown\n", cpu);
> }
>
> -int __ref psci_cpu_kill(unsigned int cpu)
> +int psci_cpu_kill(unsigned int cpu)
> {
> int err, i;
>
> diff --git a/arch/arm/mach-omap2/omap-hotplug.c
> b/arch/arm/mach-omap2/omap-hotplug.c
> index 971791fe9a3f..593fec753b28 100644
> --- a/arch/arm/mach-omap2/omap-hotplug.c
> +++ b/arch/arm/mach-omap2/omap-hotplug.c
> @@ -27,7 +27,7 @@
> * platform-specific code to shutdown a CPU
> * Called with IRQs disabled
> */
> -void __ref omap4_cpu_die(unsigned int cpu)
> +void omap4_cpu_die(unsigned int cpu)
> {
> unsigned int boot_cpu = 0;
> void __iomem *base = omap_get_wakeupgen_base();
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
> b/arch/arm/mach-omap2/omap-wakeupgen.c
> index e1d2e991d17a..d9b317706e63 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -330,7 +330,7 @@ static int irq_cpu_hotplug_notify(struct notifier_block
> *self,
> return NOTIFY_OK;
> }
>
> -static struct notifier_block __refdata irq_hotplug_notifier = {
> +static struct notifier_block irq_hotplug_notifier = {
> .notifier_call = irq_cpu_hotplug_notify,
> };
>
> diff --git a/arch/arm/mach-prima2/hotplug.c b/arch/arm/mach-prima2/hotplug.c
> index 0ab2f8bae28e..a728c78b996f 100644
> --- a/arch/arm/mach-prima2/hotplug.c
> +++ b/arch/arm/mach-prima2/hotplug.c
> @@ -32,7 +32,7 @@ static inline void platform_do_lowpower(unsigned int cpu)
> *
> * Called with IRQs disabled
> */
> -void __ref sirfsoc_cpu_die(unsigned int cpu)
> +void sirfsoc_cpu_die(unsigned int cpu)
> {
> platform_do_lowpower(cpu);
> }
> diff --git a/arch/arm/mach-qcom/platsmp.c b/arch/arm/mach-qcom/platsmp.c
> index 5cde63a64b34..9b00123a315d 100644
> --- a/arch/arm/mach-qcom/platsmp.c
> +++ b/arch/arm/mach-qcom/platsmp.c
> @@ -49,7 +49,7 @@ extern void secondary_startup_arm(void);
> static DEFINE_SPINLOCK(boot_lock);
>
> #ifdef CONFIG_HOTPLUG_CPU
Re: [PATCH 04/12] drivers/mmc/host: don't use devm_pinctrl_get_select_default() in probe
2013/7/10 Wolfram Sang w...@the-dreams.de: Since commit ab78029 (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13) Signed-off-by: Wolfram Sang w...@the-dreams.de --- drivers/mmc/host/mvsdio.c |6 -- drivers/mmc/host/mxs-mmc.c |8 drivers/mmc/host/omap_hsmmc.c |7 --- drivers/mmc/host/sdhci-esdhc-imx.c |8 drivers/mmc/host/sdhci-sirf.c |8 Wolfram, this has been done for sirf, which version are you based on? 5 files changed, 37 deletions(-) -barry -- 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: find real users and drivers of rpmsg
2013/7/10 Anna, Suman s-a...@ti.com: Barry, On Mon, Jul 8, 2013 at 10:31 AM, Barry Song 21cn...@gmail.com wrote: hi Ohad/all, i am trying to find some real users of rpmsg, here i only get samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers are out of mainline? Yes where could i get them? TI maintains them in internal trees, some of which might be public. I'm looping in Suman from TI who might be able to refer you to some You will find couple of rpmsg client drivers in our product kernels. Following is a kernel used towards our Android product, you can look in the drivers/rpmsg folder. http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p- linux-omap-3.4 yes. i have repmsg-resmgr and repmsg-omx now. and i also have sysbios-rpmsg and domx. thanks! i am also trying to find source codes running in Cortex-M3 which use rpmsg and hope to find some Linux userspace codes which use rpmsg too. Thanks barry Some information from the following wiki might also be handy (kinda old, but still useful) for you to find the equivalent code running on the Cortex-M3 http://omappedia.org/wiki/Category:RPMsg DOMX(Distributed OpenMAX for OMAP4 processors) on the page seems to be based on syslink and lose maintaince for 3 years, where can i get a new version based on rpmsg? Look through the following project, http://git.omapzoom.org/?p=platform/hardware/ti/domx.git;a=shortlog;h=refs/heads/p-jb-mr1-release thanks, Anna. regards Suman -barry -barry -- 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: find real users and drivers of rpmsg
Hi Suman, 2013/7/10 Suman Anna s-a...@ti.com: Barry, On Mon, Jul 8, 2013 at 10:31 AM, Barry Song 21cn...@gmail.com wrote: hi Ohad/all, i am trying to find some real users of rpmsg, here i only get samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers are out of mainline? Yes where could i get them? TI maintains them in internal trees, some of which might be public. I'm looping in Suman from TI who might be able to refer you to some You will find couple of rpmsg client drivers in our product kernels. Following is a kernel used towards our Android product, you can look in the drivers/rpmsg folder. http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4 yes. i have repmsg-resmgr and repmsg-omx now. and i also have sysbios-rpmsg and domx. thanks! i am also trying to find source codes running in Cortex-M3 which use rpmsg and hope to find some Linux userspace codes which use rpmsg too. Thanks barry Some information from the following wiki might also be handy (kinda old, but still useful) for you to find the equivalent code running on the Cortex-M3 http://omappedia.org/wiki/Category:RPMsg DOMX(Distributed OpenMAX for OMAP4 processors) on the page seems to be based on syslink and lose maintaince for 3 years, where can i get a new version based on rpmsg? regards Suman -barry -- 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
find real users and drivers of rpmsg
hi Ohad/all, i am trying to find some real users of rpmsg, here i only get samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers are out of mainline? where could i get them? i am also trying to find source codes running in Cortex-M3 which use rpmsg and hope to find some Linux userspace codes which use rpmsg too. Thanks barry -- 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
the Usage of ROM and RAM of Cortex-M3 on OMAP4
Hi All, typically on OMAP4, Cortex-A9 will load the Cortex-M3 firmware and let M3 run from the firmware. for example, on Android, Linux kernel will use remoteproc module to load ducati-m3-core0.xem3 of Ducati. but after reading the datasheet of OMAP4, there are internal 16KB ROM and 64KB RAM for Cortex-M3. And the ROM is bootable. I'd like to know who is using the embedded ROM and RAM and how they use. and can the Cortex-M3 boot from ROM directly by itself? Thanks barry -- 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: the Usage of ROM and RAM of Cortex-M3 on OMAP4
Hi Nicolas, thanks very much for your reply. 2013/5/21 Nicolas Dechesne nde...@gmail.com: On Tue, May 21, 2013 at 12:04 PM, Barry Song 21cn...@gmail.com wrote: Hi All, typically on OMAP4, Cortex-A9 will load the Cortex-M3 firmware and let M3 run from the firmware. for example, on Android, Linux kernel will use remoteproc module to load ducati-m3-core0.xem3 of Ducati. but after reading the datasheet of OMAP4, there are internal 16KB ROM and 64KB RAM for Cortex-M3. And the ROM is bootable. I'd like to know who is using the embedded ROM and RAM and how they use. and can the Cortex-M3 boot from ROM directly by itself? i don't think the ROM is being used. at least i am not aware of anyone who would have developed a ROM code for Ducati... so i don't think you can use the ROM. as for the RAM if you refer to what's called 'SL2 memory', it's being used by the codecs (IVAHD), it's just RAM that can be used freely if you don't use IVAHD. if nobody can use the ROM, is bootrom firmware or something else in OMAP4 using it? so what's the purpose of this ROM? the ROM is said bootable, but we only boot M3 by Cortex-A9. -barry -- 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 270/493] arm: remove use of __devinit
2012/11/20 Bill Pemberton wf...@virginia.edu: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Russell King li...@arm.linux.org.uk Cc: Will Deacon will.dea...@arm.com Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: Sascha Hauer ker...@pengutronix.de Cc: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com Cc: David Brown dav...@codeaurora.org Cc: Daniel Walker dwal...@fifo99.com Cc: Bryan Huntsman bry...@codeaurora.org Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Barry Song baohua.s...@csr.com Cc: Ben Dooks ben-li...@fluff.org Cc: Kukjin Kim kgene@samsung.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-samsung-...@vger.kernel.org Cc: patc...@opensource.wolfsonmicro.com Cc: linux-te...@vger.kernel.org --- Acked-by: Barry Song baohua.s...@csr.com -- 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 207/493] i2c: remove use of __devinit
2012/11/20 Bill Pemberton wf...@virginia.edu: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Jean Delvare kh...@linux-fr.org Cc: Wolfram Sang w.s...@pengutronix.de Cc: Ben Dooks ben-li...@fluff.org Cc: Rudolf Marek r.ma...@assembler.cz Cc: Jochen Friedrich joc...@scram.de Cc: Peter Korsgaard jac...@sunsite.dk Cc: Tony Lindgren t...@atomide.com Cc: Olof Johansson o...@lixom.net Cc: Vitaly Wool vitalyw...@gmail.com Cc: Guan Xuetao g...@mprc.pku.edu.cn Cc: Barry Song baohua.s...@csr.com Cc: Mark M. Hoffman mhoff...@lightlink.com Cc: linux-...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- Acked-by: Barry Song baohua.s...@csr.com drivers/i2c/busses/i2c-ali1535.c| 4 ++-- drivers/i2c/busses/i2c-ali1563.c| 4 ++-- drivers/i2c/busses/i2c-ali15x3.c| 4 ++-- drivers/i2c/busses/i2c-amd756.c | 2 +- drivers/i2c/busses/i2c-amd8111.c| 2 +- drivers/i2c/busses/i2c-at91.c | 6 +++--- drivers/i2c/busses/i2c-au1550.c | 2 +- drivers/i2c/busses/i2c-cpm.c| 4 ++-- drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +- drivers/i2c/busses/i2c-designware-platdrv.c | 2 +- drivers/i2c/busses/i2c-eg20t.c | 2 +- drivers/i2c/busses/i2c-elektor.c| 4 ++-- drivers/i2c/busses/i2c-gpio.c | 4 ++-- drivers/i2c/busses/i2c-highlander.c | 2 +- drivers/i2c/busses/i2c-hydra.c | 2 +- drivers/i2c/busses/i2c-i801.c | 14 +++--- drivers/i2c/busses/i2c-ibm_iic.c| 4 ++-- drivers/i2c/busses/i2c-intel-mid.c | 2 +- drivers/i2c/busses/i2c-isch.c | 2 +- drivers/i2c/busses/i2c-mpc.c| 20 ++-- drivers/i2c/busses/i2c-mv64xxx.c| 12 ++-- drivers/i2c/busses/i2c-mxs.c| 2 +- drivers/i2c/busses/i2c-nforce2.c| 4 ++-- drivers/i2c/busses/i2c-nuc900.c | 2 +- drivers/i2c/busses/i2c-ocores.c | 2 +- drivers/i2c/busses/i2c-octeon.c | 6 +++--- drivers/i2c/busses/i2c-omap.c | 2 +- drivers/i2c/busses/i2c-parport-light.c | 2 +- drivers/i2c/busses/i2c-pasemi.c | 2 +- drivers/i2c/busses/i2c-pca-isa.c| 4 ++-- drivers/i2c/busses/i2c-pca-platform.c | 2 +- drivers/i2c/busses/i2c-piix4.c | 10 +- drivers/i2c/busses/i2c-pmcmsp.c | 2 +- drivers/i2c/busses/i2c-pnx.c| 2 +- drivers/i2c/busses/i2c-powermac.c | 12 ++-- drivers/i2c/busses/i2c-puv3.c | 2 +- drivers/i2c/busses/i2c-pxa-pci.c| 2 +- drivers/i2c/busses/i2c-rcar.c | 2 +- drivers/i2c/busses/i2c-s6000.c | 4 ++-- drivers/i2c/busses/i2c-sh7760.c | 4 ++-- drivers/i2c/busses/i2c-sirf.c | 2 +- drivers/i2c/busses/i2c-sis5595.c| 4 ++-- drivers/i2c/busses/i2c-sis630.c | 4 ++-- drivers/i2c/busses/i2c-sis96x.c | 2 +- drivers/i2c/busses/i2c-tegra.c | 2 +- drivers/i2c/busses/i2c-via.c| 2 +- drivers/i2c/busses/i2c-viapro.c | 2 +- drivers/i2c/busses/i2c-xiic.c | 2 +- drivers/i2c/busses/i2c-xlr.c| 2 +- drivers/i2c/busses/scx200_acb.c | 10 +- drivers/i2c/muxes/i2c-mux-gpio.c| 4 ++-- drivers/i2c/muxes/i2c-mux-pinctrl.c | 2 +- 52 files changed, 103 insertions(+), 103 deletions(-) -- 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: changing DMA slave configuration API
2012/6/10 Russell King - ARM Linux li...@arm.linux.org.uk:
Dan, Vinod,
There's a change I would like to do to the DMA slave configuration.
It's currently a pain to have the source and destination parameters in
the dma_slave_config structure as separate elements; it means when you
want to extract them, you end up with code in DMA engine drivers like:
+ if (dir == DMA_DEV_TO_MEM) {
+ dev_addr = c-src_addr;
+ dev_width = c-src_addr_width;
+ burst = c-src_maxburst;
+ } else if (dir == DMA_MEM_TO_DEV) {
+ dev_addr = c-dst_addr;
+ dev_width = c-dst_addr_width;
+ burst = c-dst_maxburst;
+ }
If we redefine the structure as below, this all becomes more simple:
+ if (dir == DMA_DEV_TO_MEM)
+ cfg = c-dev_src;
+ else if (dir == DMA_MEM_TO_DEV)
+ cfg = c-dev_dst;
it seems that might mean an union in your dma_slave_cfg, but not
co-exitense of both?
struct dma_slave_cfg {
+ union {
struct dma_dev_cfg dev_src;
struct dma_dev_cfg dev_dst;
}
bool device_fc;
};
and then we can access the data through cfg-{element} rather than having
to cache each individual elements value in a local variable.
Thoughts?
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 56377df..e6519f7 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -367,6 +367,18 @@ struct dma_slave_config {
bool device_fc;
};
+struct dma_dev_cfg {
+ dma_addr_t addr;
+ enum dma_slave_buswidth width;
+ u32 maxburst;
+};
+
+struct dma_slave_cfg {
+ struct dma_dev_cfg dev_src;
+ struct dma_dev_cfg dev_dst;
+ bool device_fc;
+};
+
static inline const char *dma_chan_name(struct dma_chan *chan)
{
return dev_name(chan-dev-device);
Thanks
barry
--
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: implementing suspend to ram on cortex A8 based on linux 3.0.8
hi yang, 在 2012年3月10日 下午10:37，yang gqyang hustgqy...@gmail.com 写道： Thanks for your comment. Finally, i find out that i made a mistake. The uart(8250) have not been restore after resume, instead, it use the configuration got from boot. The uart have not been restored correctly, so that ls can not output result correctly resulting in it seems that the busybox can not work correctly. Now, i still have a question about the uart: why the printk can work correctly, but the printf not? Before this, i believe that the printk work correctly, then the uart work ok. but now, i need more reconsidaration about the relation between the printk, printf and uart. Can anyone give me some suggestion? Any comment is welcome, thanks a lot. printk use struct console driver, it doesn't depend on a device node for userspace. printf actaully depends on uart_driver and a /dev/ttySx device node, stdout and stderr are redirected to /dev/ttySx uart is just a hardware which can be a tty or kernel console output. -barry -- 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
Is Pandaboard cpuhotplug working stably?
Hi guys, i tried cpuhotplug on pandaboard for both Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to work stably. On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well: # echo 0 /sys/devices/system/cpu/cpu1/online CPU1: shutdown if i enable the cpu1 again by echo 1 /sys/devices/system/cpu/cpu1/online, the system will restore to 3 random status: hang, normal, panic. Using Linaro 11.11 release, echo 0 /sys/devices/system/cpu/cpu1/online will make system hang and the whole system will not be able to reset by pressing reset key, the only way to reset system is pulling out AV power. i am sorry i can't get more time to debug and find more clues. just want to ask people whether this is a version the cpuhotplug works normal on? Thanks barry -- 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: Is Pandaboard cpuhotplug working stably?
2011/12/21 Russell King - ARM Linux li...@arm.linux.org.uk: On Wed, Dec 21, 2011 at 05:23:48PM +0800, Barry Song wrote: Hi guys, i tried cpuhotplug on pandaboard for both Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to work stably. On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well: # echo 0 /sys/devices/system/cpu/cpu1/online CPU1: shutdown if i enable the cpu1 again by echo 1 /sys/devices/system/cpu/cpu1/online, the system will restore to 3 random status: hang, normal, panic. Using Linaro 11.11 release, echo 0 /sys/devices/system/cpu/cpu1/online will make system hang and the whole system will not be able to reset by pressing reset key, the only way to reset system is pulling out AV power. i am sorry i can't get more time to debug and find more clues. just want to ask people whether this is a version the cpuhotplug works normal on? cpu hotplug is basically totally buggered - the preconditions placed upon the bringup code path are basically impossible to satisfy in any shape or form at the moment. There's the requirement that the secondary CPU is marked online and active before interrupts are enabled for the thread migration stuff to behave correctly. However, this is incompatible with smp_call_function() which will wait for online CPUs to respond to an IPI - which this one won't because interrupts are disabled. I think there was some discussion about how to fix this but I don't recall the details. thanks, Russell. then could i think this is an ARM-kernel-specific bug which exists on all ARM SMP chips for the moment? and that bug doesn't happen on x86: root@ubuntu:~/simple-rootfs/initrd/bin# echo 0 /sys/devices/system/cpu/cpu3/online root@ubuntu:~/simple-rootfs/initrd/bin# echo 1 /sys/devices/system/cpu/cpu3/online root@ubuntu:~/simple-rootfs/initrd/bin# echo 0 /sys/devices/system/cpu/cpu2/online root@ubuntu:~/simple-rootfs/initrd/bin# echo 1 /sys/devices/system/cpu/cpu2/online -barry -- 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: Define generic transfer request api
2011/9/13 Barry Song 21cn...@gmail.com: 2011/9/13 Jassi Brar jaswinder.si...@linaro.org: On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote: if test pass, to the patch, and even for the moment, to the API's idea Acked-by: Barry Song baohua.s...@csr.com one issue i noticed is with a device_prep_dma_genxfer, i don't need device_prep_slave_sg any more, Yeah, the damengine would need to adapt to the fact that these interleaved tranfers could be Mem-Mem as well as Mem-Dev (even though yours could be only one type, but some dmacs could do both). How about: BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask) - !device-device_prep_dma_memcpy); + !device-device_prep_dma_memcpy + !device-device_prep_dma_genxfer); BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) - !device-device_prep_slave_sg); + !device-device_prep_slave_sg + !device-device_prep_dma_genxfer); Seems ok, but please modify in a way you think is best and submit a patch on top of this new api. Then it'll be easier to evaluate everything. i think it should be handled by this patch but not a new one. and i also think xfer_template is a bad name for a structure which is an API. i'd like to add namespace for it and rename it to dma_genxfer. or have any good suggestion? i'd like to send this together with BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) !device-device_prep_dma_genxfer) as v2. -barry -- 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: Define generic transfer request api
2011/9/15 Jassi Brar jaswinder.si...@linaro.org: On 15 September 2011 12:01, Barry Song 21cn...@gmail.com wrote: 2011/9/13 Barry Song 21cn...@gmail.com: 2011/9/13 Jassi Brar jaswinder.si...@linaro.org: On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote: if test pass, to the patch, and even for the moment, to the API's idea Acked-by: Barry Song baohua.s...@csr.com one issue i noticed is with a device_prep_dma_genxfer, i don't need device_prep_slave_sg any more, Yeah, the damengine would need to adapt to the fact that these interleaved tranfers could be Mem-Mem as well as Mem-Dev (even though yours could be only one type, but some dmacs could do both). How about: BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask) - !device-device_prep_dma_memcpy); + !device-device_prep_dma_memcpy + !device-device_prep_dma_genxfer); BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) - !device-device_prep_slave_sg); + !device-device_prep_slave_sg + !device-device_prep_dma_genxfer); Seems ok, but please modify in a way you think is best and submit a patch on top of this new api. Then it'll be easier to evaluate everything. i think it should be handled by this patch but not a new one. and i also think xfer_template is a bad name for a structure which is an API. i'd like to add namespace for it and rename it to dma_genxfer. or have any good suggestion? I think xfer_template is better - which stresses the usage as having prepared templates of transfers and only change src/dst address before submitting. 'device_prep_dma_genxfer' is the API which is already named so. sorry i can't agree that. device_prep_dma_genxfer is an API, xfer_template is a data structure which will be seen by users, client drivers. it at least needs a namespace. Otherwise, people someday maybe add another xfer. i'd like to send this together with BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) !device-device_prep_dma_genxfer) as v2. Is there no change other than skipping check for SLAVE when using this api ? -- 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: Define generic transfer request api
2011/9/15 Jassi Brar jaswinder.si...@linaro.org:
On 15 September 2011 12:01, Barry Song 21cn...@gmail.com wrote:
2011/9/13 Barry Song 21cn...@gmail.com:
2011/9/13 Jassi Brar jaswinder.si...@linaro.org:
On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote:
if test pass, to the patch, and even for the moment, to the API's idea
Acked-by: Barry Song baohua.s...@csr.com
one issue i noticed is with a device_prep_dma_genxfer, i don't need
device_prep_slave_sg any more,
Yeah, the damengine would need to adapt to the fact that these
interleaved tranfers could be Mem-Mem as well as Mem-Dev
(even though yours could be only one type, but some dmacs could
do both).
How about:
BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask)
- !device-device_prep_dma_memcpy);
+ !device-device_prep_dma_memcpy
+ !device-device_prep_dma_genxfer);
BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask)
- !device-device_prep_slave_sg);
+ !device-device_prep_slave_sg
+ !device-device_prep_dma_genxfer);
Seems ok, but please modify in a way you think is best and submit a patch
on top of this new api. Then it'll be easier to evaluate everything.
i think it should be handled by this patch but not a new one.
and i also think xfer_template is a bad name for a structure which is
an API. i'd like to add namespace for it and rename it to dma_genxfer.
or have any good suggestion?
I think xfer_template is better - which stresses the usage as having prepared
templates of transfers and only change src/dst address before submitting.
'device_prep_dma_genxfer' is the API which is already named so.
i'd like to send this together with BUG_ON(dma_has_cap(DMA_SLAVE,
device-cap_mask) !device-device_prep_dma_genxfer) as v2.
Is there no change other than skipping check for SLAVE when using this api ?
another change i want to do is a simple xfer alloc helper so that
every driver doesn't need a long line to alloc this struct with a zero
length array:
struct xfer_template *alloc_xfer_template(size_t frame_size)
{
kzalloc(sizeof(struct xfer_template) +
sizeof(struct data_chunk) * frame_size);
}
Then client can fill
xt.sgl[0].size
xt.sgl[0].icg
xt.sgl[1].size
xt.sgl[1].icg
...
xt.sgl[x].size
xt.sgl[x].icg
but xfer_template and data_chunk will have namespace.
-barry
--
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: Define generic transfer request api
2011/9/13 Barry Song 21cn...@gmail.com:
2011/9/13 Jassi Brar jaswinder.si...@linaro.org:
On 12 September 2011 21:56, Barry Song 21cn...@gmail.com wrote:
Define a new api that could be used for doing fancy data transfers
like interleaved to contiguous copy and vice-versa.
Traditional SG_list based transfers tend to be very inefficient in
such cases as where the interleave and chunk are only a few bytes,
which call for a very condensed api to convey pattern of the transfer.
This api supports all 4 variants of scatter-gather and contiguous transfer.
Besides, it could also represent common operations like
device_prep_dma_{cyclic, memset, memcpy}
and maybe some more that I am not sure of.
Of course, neither can this api help transfers that don't lend to DMA by
nature, i.e, scattered tiny read/writes with no periodic pattern.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
anyway, this API needs a real user to prove why it needs to exist.
prima2 can be the 1st(?, 2nd if TI uses) user of this API. let's try
to see what the driver will be with this api. Then we might figure out
more about what it should be.
Did you discover any issue with the api?
no until now, but i need to test as i said since there is nobody else
has used it before. so i just hold the formal ACK for a moment.
Because only three days ago you said
{
Jassi, you might think my reply as an ACK to [PATCH] DMAEngine:
Define generic transfer request api.
}
if test pass, to the patch, and even for the moment, to the API's idea
Acked-by: Barry Song baohua.s...@csr.com
one issue i noticed is with a device_prep_dma_genxfer, i don't need
device_prep_slave_sg any more, then the validation check in
dma_async_device_register():
BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask)
!device-device_prep_slave_sg);
is wrong to me.
How about:
BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask)
- !device-device_prep_dma_memcpy);
+ !device-device_prep_dma_memcpy
+ !device-device_prep_dma_genxfer);
BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask)
- !device-device_prep_slave_sg);
+ !device-device_prep_slave_sg
+ !device-device_prep_dma_genxfer);
The api met your requirements easily not because I know them already,
but because I designed the api to be as generic as practically possible.
-barry
--
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: Define generic transfer request api
2011/9/13 Jassi Brar jaswinder.si...@linaro.org: On 13 September 2011 13:16, Barry Song 21cn...@gmail.com wrote: if test pass, to the patch, and even for the moment, to the API's idea Acked-by: Barry Song baohua.s...@csr.com one issue i noticed is with a device_prep_dma_genxfer, i don't need device_prep_slave_sg any more, Yeah, the damengine would need to adapt to the fact that these interleaved tranfers could be Mem-Mem as well as Mem-Dev (even though yours could be only one type, but some dmacs could do both). How about: BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask) - !device-device_prep_dma_memcpy); + !device-device_prep_dma_memcpy + !device-device_prep_dma_genxfer); BUG_ON(dma_has_cap(DMA_SLAVE, device-cap_mask) - !device-device_prep_slave_sg); + !device-device_prep_slave_sg + !device-device_prep_dma_genxfer); Seems ok, but please modify in a way you think is best and submit a patch on top of this new api. Then it'll be easier to evaluate everything. i think it should be handled by this patch but not a new one. thanks. -barry -- 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: Define generic transfer request api
Define a new api that could be used for doing fancy data transfers
like interleaved to contiguous copy and vice-versa.
Traditional SG_list based transfers tend to be very inefficient in
such cases as where the interleave and chunk are only a few bytes,
which call for a very condensed api to convey pattern of the transfer.
This api supports all 4 variants of scatter-gather and contiguous transfer.
Besides, it could also represent common operations like
device_prep_dma_{cyclic, memset, memcpy}
and maybe some more that I am not sure of.
Of course, neither can this api help transfers that don't lend to DMA by
nature, i.e, scattered tiny read/writes with no periodic pattern.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
anyway, this API needs a real user to prove why it needs to exist.
prima2 can be the 1st(?, 2nd if TI uses) user of this API. let's try
to see what the driver will be with this api. Then we might figure out
more about what it should be.
---
include/linux/dmaengine.h | 73
+
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 8fbf40e..74f3ae0 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -76,6 +76,76 @@ enum dma_transaction_type {
/* last transaction type for creation of the capabilities mask */
#define DMA_TX_TYPE_END (DMA_CYCLIC + 1)
+/**
+ * Generic Transfer Request
+ *
+ * A chunk is collection of contiguous bytes to be transfered.
+ * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
+ * ICGs may or maynot change between chunks.
+ * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
+ * that when repeated an integral number of times, specifies the transfer.
+ * A transfer template is specification of a Frame, the number of times
+ * it is to be repeated and other per-transfer attributes.
+ *
+ * Practically, a client driver would have ready a template for each
+ * type of transfer it is going to need during its lifetime and
+ * set only 'src_start' and 'dst_start' before submitting the requests.
+ *
+ *
+ * | Frame-1 | Frame-2 | ~ | Frame-'numf' |
+ * |==.===...=...|==.===...=...| ~ |==.===...=...|
+ *
+ * == Chunk size
+ * ... ICG
+ */
+
+/**
+ * struct data_chunk - Element of scatter-gather list that makes a frame.
+ * @size: Number of bytes to read from source.
+ * size_dst := fn(op, size_src), so doesn't mean much for destination.
+ * @icg: Number of bytes to jump after last src/dst address of this
+ * chunk and before first src/dst address for next chunk.
+ * Ignored for dst(assumed 0), if dst_inc is true and dst_sgl is false.
+ * Ignored for src(assumed 0), if src_inc is true and src_sgl is false.
+ */
+struct data_chunk {
+ size_t size;
+ size_t icg;
+};
+
+/**
+ * struct xfer_template - Template to convey DMAC the transfer pattern
+ * and attributes.
+ * @op: The operation to perform on source data before writing it on
+ * to destination address.
+ * @src_start: Bus address of source for the first chunk.
+ * @dst_start: Bus address of destination for the first chunk.
+ * @src_inc: If the source address increments after reading from it.
+ * @dst_inc: If the destination address increments after writing to it.
+ * @src_sgl: If the 'icg' of sgl[] applies to Source (scattered read).
+ * Otherwise, source is read contiguously (icg ignored).
+ * Ignored if src_inc is false.
+ * @dst_sgl: If the 'icg' of sgl[] applies to Destination (scattered write).
+ * Otherwise, destination is filled contiguously (icg ignored).
+ * Ignored if dst_inc is false.
+ * @frm_irq: If the client expects DMAC driver to do callback after each
frame.
+ * @numf: Number of frames in this template.
+ * @frame_size: Number of chunks in a frame i.e, size of sgl[].
+ * @sgl: Array of {chunk,icg} pairs that make up a frame.
+ */
+struct xfer_template {
+ enum dma_transaction_type op;
+ dma_addr_t src_start;
+ dma_addr_t dst_start;
+ bool src_inc;
+ bool dst_inc;
+ bool src_sgl;
+ bool dst_sgl;
+ bool frm_irq;
+ size_t numf;
+ size_t frame_size;
+ struct data_chunk sgl[0];
+};
/**
* enum dma_ctrl_flags - DMA flags to augment operation preparation,
@@ -432,6 +502,7 @@ struct dma_tx_state {
* @device_prep_dma_cyclic: prepare a cyclic dma operation suitable for audio.
* The function takes a buffer of size buf_len. The callback function will
* be called after period_len bytes have been transferred.
+ * @device_prep_dma_genxfer: Transfer expression in a generic way.
* @device_control: manipulate all pending operations on a channel, returns
* zero or error code
Re: [PATCH] DMAEngine: Define generic transfer request api
2011/9/13 Jassi Brar jaswinder.si...@linaro.org:
On 12 September 2011 21:56, Barry Song 21cn...@gmail.com wrote:
Define a new api that could be used for doing fancy data transfers
like interleaved to contiguous copy and vice-versa.
Traditional SG_list based transfers tend to be very inefficient in
such cases as where the interleave and chunk are only a few bytes,
which call for a very condensed api to convey pattern of the transfer.
This api supports all 4 variants of scatter-gather and contiguous transfer.
Besides, it could also represent common operations like
device_prep_dma_{cyclic, memset, memcpy}
and maybe some more that I am not sure of.
Of course, neither can this api help transfers that don't lend to DMA by
nature, i.e, scattered tiny read/writes with no periodic pattern.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
anyway, this API needs a real user to prove why it needs to exist.
prima2 can be the 1st(?, 2nd if TI uses) user of this API. let's try
to see what the driver will be with this api. Then we might figure out
more about what it should be.
Did you discover any issue with the api?
no until now, but i need to test as i said since there is nobody else
has used it before. so i just hold the formal ACK for a moment.
Because only three days ago you said
{
Jassi, you might think my reply as an ACK to [PATCH] DMAEngine:
Define generic transfer request api.
}
if test pass, to the patch, and even for the moment, to the API's idea
Acked-by: Barry Song baohua.s...@csr.com
The api met your requirements easily not because I know them already,
but because I designed the api to be as generic as practically possible.
-barry
--
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: Shouldn't DT preserve pdev name and id to allow platform_match to work?
auxdata passes platform_data and overrides the device name when there is no way easy way to make the driver work without it. It handles the the current implementation of clocks and regulators which aren't yet populated from the device tree. It will go away when clock regulator bindings are implemented. Yes. As OF_DEV_AUXDATA_ID still requires hardware information like 0x48000100 as below, it seems it is not consistent with the origin purpose of ARM DT. OF_DEV_AUXDATA_ID(ti,omap-i2c, 0x48000100, omap-i2c.1, 1, i2c_pdata) And the information 0x48000100 is something that doesn't want to be in kernel codes.it should be only in dts. -barry -- 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 changes for v2.6.39 merge window
2011/4/1 Arnd Bergmann a...@arndb.de: On Friday 01 April 2011, Ingo Molnar wrote: IMO the right answer is what Linus and Thomas outlined: 1) provide a small number of clean examples and clean abstractions 2) to not pull new crap from that point on 3) do this gradually but consistently I.e. make all your requirements technical and actionable - avoid sweeping, impossible to meet requirements. Do not require people to clean up all of the existing mess straight away (they cannot realistically do it), do not summarily block the flow of patches, but be firm about drawing a line in the sand and be firm about not introducing new mess in a gradually growing list of well-chosen areas of focus. Rinse, repeat. I believe getting to point 1 is the hard part here. There are a lot of things that are wrong with the mach-* (and also plat-*) implementations, and I don't think we have one today that can really serve as an example. Most decisions made in there made a lot of sense when they were introduced, and declaring code that was perfectly acceptable yesterday to be unacceptable crap today is not going to be met with much understanding by the someone who just wants to add support for one more board to 100 already existing ones in the same SoC family. I would actually suggest a different much more radical start: Fork the way that platforms are managed today, and start an alternative way of setting up boards and devices together with the proven ARM core kernel infrastructure, based on these observations (please correct me if some of them they don't make sense): 1. The core arch code is not a problem (Russell does a great job here) 2. The platform specific code contains a lot of crap that doesn't belong there (not enough reviewers to push back on crap) 3. The amount of crap in platform specfic files is growing exponentially, despite the best efforts of a handful of people to clean it up. 4. Having one source file per board does not scale any more. 5. Discoverable hardware would solve this, but is not going to happen in practice. 6. Board firmware would not solve this and is usually not present. 7. Boot loaders can not be trusted to pass valid information 8. Device tree blobs can solve a lot of the problems, and nobody has come up with a better solution. ARM BSP is still blasting! we are planning to merge our new ARM cortex-a9 SoC into kernel. So I am just wondering whether traditional ARM BSP way can still be accepted, or we must move to use device tree? but i have't seen any arm device tree codes enter mainline yet. but we can get those patches from linaro 2.6.38. So what's the plan for merging arm device tree? What i have seen is that the BSP architecture of different ARM SoC companies is even different. samsung has three levels: plat-samsung plat-s3c24xx mach-s3c2410 mach-s3c2440 plat-s5p mach-s5pv210 mach-s5pv310 TI has two levels: plat-omap mach-omap1 mach-omap2 Nvidia has one level: mach-tegra I didn't find any rule about what codes should be placed in what directories. Different companies have different ways. It looks like the only agreement is board files are in mach-xxx. Any suggestions for that? BTW, we don't want to dick around, which Linus has been very angry. we want to fix more issues this email pointed out before we send patches. 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. 10. We do not want to discontinue support for old boards that work fine. 11. Massive changes to existing platforms would cause massive breakage. 12. Supporting many different boards with a single kernel binary is a useful goal. 13. Infrastructure code should be cross-platform, not duplicated across platforms. 14. 32 bit ARM is hitting the wall in the next years (Cortex-A15 is actually adding PAE support, which has failed to solve this on other architectures). 15. We need to solve the platform problem before 64 bit support comes and adds another dimension to the complexity. Based on these assumptions, my preferred strategy would be to a new mach-nocrap directory with a documented set of rules (to be adapted when necessary): * Strictly no crap * No board files * No hardcoded memory maps * No lists of interrupts and GPIOs * All infrastructure added must be portable to all ARMv7 based SoCs. (ARMv6 can be added later) * 64 bit safe code only. * SMP safe code only. * All board specific information must come from a device tree and be run-time detected. * Must use the same device drivers as existing platforms * Should share platform drivers (interrupt controller, gpio, timer, ...) with existing platforms where appropriate. * Code quality takes priority over stability in mach-nocrap, but must not break other platforms. Until we have something
