* [PATCH] dma: add new DMA control commands
From: Huang Shijie @ 2012-10-18 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210181251.15116.marex@denx.de>
On Thu, Oct 18, 2012 at 6:51 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Huang Shijie,
>
>> ? 2012?10?18? 16:49, Marek Vasut ??:
>> > Dear Huang Shijie,
>> >
>> >> ? 2012?10?18? 16:16, Marek Vasut ??:
>> >>> So we can't stream data from the chip? About time to adjust the MTD
>> >>> framework to allow that. Maybe implement a command queue?
>> >>
>> >> IMHO, it's not possible. Because the READ-PAGE(00h-30h) command needs to
>> >> check the busy status
>> >> which means we have to stop in the middle, so we can not chain the all
>> >> the read-pages DMA commands.
>> >
>> > Can the DMA not branch?
>>
>> it's too complicated to the MTD layer, as well as the gpmi driver.
>
> Can you please elaborate ?
could you read the nand spec about how to read a page out with the
READ-PAGE(00-30) command,
and tell me how to make the DMA branch?
I really have no idea about how to make the DMA branch.
thanks
Huang Shijie
.
> Best regards,
> Marek Vasut
^ permalink raw reply
* [PATCH v4 1/7] uio: uio_pruss: replace private SRAM API with genalloc
From: Matt Porter @ 2012-10-18 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349456686-22736-2-git-send-email-mporter@ti.com>
On Fri, Oct 05, 2012 at 01:04:40PM -0400, Matt Porter wrote:
> Remove the use of the private DaVinci SRAM API in favor
> of genalloc. The pool to be used is provided by platform
> data.
>
> Signed-off-by: Matt Porter <mporter@ti.com>
Hans,
Any additional concerns on this patch? Sekhar is holding off on applying
parts 4,5,7 for davinci until this is accepted.
Thanks,
Matt
> ---
> drivers/uio/Kconfig | 1 +
> drivers/uio/uio_pruss.c | 24 +++++++++++++++++-------
> include/linux/platform_data/uio_pruss.h | 3 ++-
> 3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 6f3ea9b..c48b938 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -97,6 +97,7 @@ config UIO_NETX
> config UIO_PRUSS
> tristate "Texas Instruments PRUSS driver"
> depends on ARCH_DAVINCI_DA850
> + select GENERIC_ALLOCATOR
> help
> PRUSS driver for OMAPL138/DA850/AM18XX devices
> PRUSS driver requires user space components, examples and user space
> diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c
> index 33a7a27..f8738de 100644
> --- a/drivers/uio/uio_pruss.c
> +++ b/drivers/uio/uio_pruss.c
> @@ -25,7 +25,7 @@
> #include <linux/clk.h>
> #include <linux/dma-mapping.h>
> #include <linux/slab.h>
> -#include <mach/sram.h>
> +#include <linux/genalloc.h>
>
> #define DRV_NAME "pruss_uio"
> #define DRV_VERSION "1.0"
> @@ -65,10 +65,11 @@ struct uio_pruss_dev {
> dma_addr_t sram_paddr;
> dma_addr_t ddr_paddr;
> void __iomem *prussio_vaddr;
> - void *sram_vaddr;
> + unsigned long sram_vaddr;
> void *ddr_vaddr;
> unsigned int hostirq_start;
> unsigned int pintc_base;
> + struct gen_pool *sram_pool;
> };
>
> static irqreturn_t pruss_handler(int irq, struct uio_info *info)
> @@ -106,7 +107,9 @@ static void pruss_cleanup(struct platform_device *dev,
> gdev->ddr_paddr);
> }
> if (gdev->sram_vaddr)
> - sram_free(gdev->sram_vaddr, sram_pool_sz);
> + gen_pool_free(gdev->sram_pool,
> + gdev->sram_vaddr,
> + sram_pool_sz);
> kfree(gdev->info);
> clk_put(gdev->pruss_clk);
> kfree(gdev);
> @@ -152,10 +155,17 @@ static int __devinit pruss_probe(struct platform_device *dev)
> goto out_free;
> }
>
> - gdev->sram_vaddr = sram_alloc(sram_pool_sz, &(gdev->sram_paddr));
> - if (!gdev->sram_vaddr) {
> - dev_err(&dev->dev, "Could not allocate SRAM pool\n");
> - goto out_free;
> + if (pdata->sram_pool) {
> + gdev->sram_pool = pdata->sram_pool;
> + gdev->sram_vaddr =
> + gen_pool_alloc(gdev->sram_pool, sram_pool_sz);
> + if (!gdev->sram_vaddr) {
> + dev_err(&dev->dev, "Could not allocate SRAM pool\n");
> + goto out_free;
> + }
> + gdev->sram_paddr =
> + gen_pool_virt_to_phys(gdev->sram_pool,
> + gdev->sram_vaddr);
> }
>
> gdev->ddr_vaddr = dma_alloc_coherent(&dev->dev, extram_pool_sz,
> diff --git a/include/linux/platform_data/uio_pruss.h b/include/linux/platform_data/uio_pruss.h
> index f39140a..3d47d21 100644
> --- a/include/linux/platform_data/uio_pruss.h
> +++ b/include/linux/platform_data/uio_pruss.h
> @@ -20,6 +20,7 @@
>
> /* To configure the PRUSS INTC base offset for UIO driver */
> struct uio_pruss_pdata {
> - u32 pintc_base;
> + u32 pintc_base;
> + struct gen_pool *sram_pool;
> };
> #endif /* _UIO_PRUSS_H_ */
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH 1/8] [media] s5p-fimc: Use clk_prepare_enable and clk_disable_unprepare
From: Sachin Kamat @ 2012-10-18 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507ED56E.1000406@samsung.com>
On 17 October 2012 21:27, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
> On 10/17/2012 05:35 PM, Sachin Kamat wrote:
>>> Most of the s5p-* drivers have already added support for clk_(un)prepare.
>>> Thus most of your changes in this patch are not needed. I seem to have only
>>> missed fimc-mdevice.c, other modules are already reworked
>>
>> I did not find these changes in your tree. Please let me know the
>> branch where these changes are available.
>
> Are in Linus' tree, for quite long already, commits:
>
> 11a37c709797cc56f48905e68a3099b79cf08850
> [media] s5p-g2d: Added support for clk_prepare
>
> bd7d8888e99d67f778f4ee272346322c0b9cb378
> [media] s5p-fimc: convert to clk_prepare()/clk_unprepare()
>
> eb732518e0db585376f95256b18b2149240e3ad3
> [media] s5p-mfc: Added support for clk_prepare
Oh I see.. I dunno how i missed to notice this..
>
> Please note there was the media drivers reorganization recently, e.g.
> drivers/media/video/s5p-* changed to drivers/media/platform/s5p-*.
Right. I am aware of that.
>
>>> $ git grep -5 clk_prepare -- drivers/media/platform/s5p-fimc
>>> drivers/media/platform/s5p-fimc/fimc-core.c-
>>> drivers/media/platform/s5p-fimc/fimc-core.c- for (i = 0; i < MAX_FIMC_CLOCKS; i++) {
>>> drivers/media/platform/s5p-fimc/fimc-core.c- fimc->clock[i] = clk_get(&fimc->pdev->dev, fimc_clocks[i]);
>>> drivers/media/platform/s5p-fimc/fimc-core.c- if (IS_ERR(fimc->clock[i]))
>>
>>>> I would prefer you have added the required changes at fimc_md_get_clocks()
>>> and fimc_md_put_clocks() functions.
>>
>> Ok. I will check this.
>
> Thanks.
>
> --
> Regards,
> Sylwester
Thanks Sylwester.
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH] ARM: OMAP2+: clockdomain: Fix OMAP4 ISS clk domain to support only SWSUP
From: Paul Walmsley @ 2012-10-18 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50800679.2030202@ti.com>
On Thu, 18 Oct 2012, Benoit Cousson wrote:
> From: Miguel Vadillo <vadillo@ti.com>
>
> Since CAM domain (ISS) has no module wake-up dependency
> with any other clock domain of the device and the dynamic
> dependency from L3_main_2 is always disabled, the domain
> needs to be in force wakeup in order to be able to access
> it for configure (sysconfig) it or use it.
>
> Also since there is no clock in the domain managed automatically
> by the hardware, there is no use to configure automatic
> clock domain transition. SW should keep the SW_WKUP domain
> transition as long as a module in the domain is required to
> be functional.
>
> Signed-off-by: Miguel Vadillo <vadillo@ti.com>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Thanks queued for 3.7-rc.
- Paul
^ permalink raw reply
* [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used
From: Felipe Balbi @ 2012-10-18 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350571199.2143.53.camel@sokoban>
On Thu, Oct 18, 2012 at 05:39:59PM +0300, Tero Kristo wrote:
> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> > hi,
> >
> > On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > > > +static int __init omap4430_phy_power_down(void)
> > > > > +{
> > > > > + void __iomem *ctrl_base;
> > > > > +
> > > > > + if (!cpu_is_omap44xx())
> > > > > + return 0;
> > > > > +
> > > > > + ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
> > > > > + if (!ctrl_base) {
> > > > > + pr_err("control module ioremap failed\n");
> > > > > + return -ENOMEM;
> > > > > + }
> > > > > +
> > > > > + /* Power down the phy */
> > > > > + __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
> > > > > +
> > > > > + iounmap(ctrl_base);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +early_initcall(omap4430_phy_power_down);
> > > > > +#endif
> > > >
> > > > I think you could do it even if the driver is enabled.
> > >
> > > Actually not at least now, it looks like the driver is not controlling
> > > this bit at all, so the driver would fail if we do this.
> >
> > then we can consider that a bug in the driver. Kishon, I thought you had
> > added SCM address space to PHY driver for this particular reason until
> > we get SCM driver, wasn't it ??
>
> Yes, I would say its a bug in the driver. However we need this disable
> mechanism for the case where we don't have the driver also (which is the
> default config for omap.)
sure, of course. But I'd like to see it unconditionally done, meaning
that there needs to be a counterpart in the driver to make sure you can
run this unconditionally during early phases of boot up ;-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121018/e5a68533/attachment.sig>
^ permalink raw reply
* [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used
From: Tero Kristo @ 2012-10-18 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018135352.GC2739@arwen.pp.htv.fi>
On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> hi,
>
> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > > +static int __init omap4430_phy_power_down(void)
> > > > +{
> > > > + void __iomem *ctrl_base;
> > > > +
> > > > + if (!cpu_is_omap44xx())
> > > > + return 0;
> > > > +
> > > > + ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
> > > > + if (!ctrl_base) {
> > > > + pr_err("control module ioremap failed\n");
> > > > + return -ENOMEM;
> > > > + }
> > > > +
> > > > + /* Power down the phy */
> > > > + __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
> > > > +
> > > > + iounmap(ctrl_base);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +early_initcall(omap4430_phy_power_down);
> > > > +#endif
> > >
> > > I think you could do it even if the driver is enabled.
> >
> > Actually not at least now, it looks like the driver is not controlling
> > this bit at all, so the driver would fail if we do this.
>
> then we can consider that a bug in the driver. Kishon, I thought you had
> added SCM address space to PHY driver for this particular reason until
> we get SCM driver, wasn't it ??
Yes, I would say its a bug in the driver. However we need this disable
mechanism for the case where we don't have the driver also (which is the
default config for omap.)
-Tero
> > > Just to make sure I understand the issue right: is the PHY enabled by
> > > default or did bootloader left this enabled ?
> >
> > The reset value for the register is zero (at least according to TRM), so
> > it is enabled from boot. Also, I couldn't find any code from the u-boot
> > that would touch this bit with a quick look.
>
> ok, so it looks like we must do this anyway, thanks ;-)
>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: OMAP: Add counter-32k nodes
From: Jon Hunter @ 2012-10-18 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508010E1.6010102@ti.com>
On 10/18/2012 09:23 AM, Benoit Cousson wrote:
> Hi Jon,
>
> This looks good to me, I just have a minor nit comment.
>
> On 10/17/2012 08:33 PM, Jon Hunter wrote:
>> Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
>> device-tree binding documentation for OMAP counter-32k.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/counter32k.txt | 15 +++++++++++++++
>> arch/arm/boot/dts/omap2420.dtsi | 6 ++++++
>> arch/arm/boot/dts/omap2430.dtsi | 6 ++++++
>> arch/arm/boot/dts/omap3.dtsi | 6 ++++++
>> arch/arm/boot/dts/omap4.dtsi | 6 ++++++
>> 5 files changed, 39 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/omap/counter32k.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/counter32k.txt b/Documentation/devicetree/bindings/arm/omap/counter32k.txt
>> new file mode 100644
>> index 0000000..1983fae
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/counter32k.txt
>> @@ -0,0 +1,15 @@
>> +OMAP Counter-32K bindings
>> +
>> +Required properties:
>> +- compatible: Must be "ti,omap-counter32k" for OMAP controllers
>> +- reg: Contains timer register address range (base address and length)
>> +- ti,hwmods: Name of the hwmod associated to the counter, which is typically
>> + "counter_32k"
>> +
>> +Example:
>> +
>> +counter32k: counter32k at 4a304000 {
>> + compatible = "ti,omap-counter32k";
>> + reg = <0x4a304000 0x001f>;
>> + ti,hwmods = "counter_32k";
>> +};
>> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
>> index 5f68a70..082193f 100644
>> --- a/arch/arm/boot/dts/omap2420.dtsi
>> +++ b/arch/arm/boot/dts/omap2420.dtsi
>> @@ -14,6 +14,12 @@
>> compatible = "ti,omap2420", "ti,omap2";
>>
>> ocp {
>> + counter32k: counter32k at 48004000 {
>
> I'd rather use "counter" as generic type to be consistent with the timer
> type we are already using.
>
> + counter32k: counter at 48004000 {
Sounds good. Will update.
Cheers
Jon
^ permalink raw reply
* [PATCH 1/2] ARM: dts: OMAP: Add counter-32k nodes
From: Benoit Cousson @ 2012-10-18 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350498803-22150-2-git-send-email-jon-hunter@ti.com>
Hi Jon,
This looks good to me, I just have a minor nit comment.
On 10/17/2012 08:33 PM, Jon Hunter wrote:
> Adds the counter-32k timers nodes present in OMAP2/3/4 devices and
> device-tree binding documentation for OMAP counter-32k.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
> .../devicetree/bindings/arm/omap/counter32k.txt | 15 +++++++++++++++
> arch/arm/boot/dts/omap2420.dtsi | 6 ++++++
> arch/arm/boot/dts/omap2430.dtsi | 6 ++++++
> arch/arm/boot/dts/omap3.dtsi | 6 ++++++
> arch/arm/boot/dts/omap4.dtsi | 6 ++++++
> 5 files changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/counter32k.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/counter32k.txt b/Documentation/devicetree/bindings/arm/omap/counter32k.txt
> new file mode 100644
> index 0000000..1983fae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/counter32k.txt
> @@ -0,0 +1,15 @@
> +OMAP Counter-32K bindings
> +
> +Required properties:
> +- compatible: Must be "ti,omap-counter32k" for OMAP controllers
> +- reg: Contains timer register address range (base address and length)
> +- ti,hwmods: Name of the hwmod associated to the counter, which is typically
> + "counter_32k"
> +
> +Example:
> +
> +counter32k: counter32k at 4a304000 {
> + compatible = "ti,omap-counter32k";
> + reg = <0x4a304000 0x001f>;
> + ti,hwmods = "counter_32k";
> +};
> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
> index 5f68a70..082193f 100644
> --- a/arch/arm/boot/dts/omap2420.dtsi
> +++ b/arch/arm/boot/dts/omap2420.dtsi
> @@ -14,6 +14,12 @@
> compatible = "ti,omap2420", "ti,omap2";
>
> ocp {
> + counter32k: counter32k at 48004000 {
I'd rather use "counter" as generic type to be consistent with the timer
type we are already using.
+ counter32k: counter at 48004000 {
Regards,
Benoit
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Rob Herring @ 2012-10-18 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018135444.GT21164@n2100.arm.linux.org.uk>
On 10/18/2012 08:54 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 18, 2012 at 08:47:56AM -0500, Rob Herring wrote:
>> Here is what I mentioned previously. This removes the static mapping from
>> the platforms. This is untested and probably breaks on different DEBUG_LL
>> options. For now, platforms call debug_ll_io_init, but once all platforms
>> are converted, this can be called from devicemaps_init.
>
> There's a problem with this approach. What if the platform specifically
> sets the debug addresses to be within one of it's existing mappings (which
> is definitely what you'd want to do with 8250-based UARTs attached to a
> PCI bus.)
>
> This isn't going to work in that case unless we split the debug mapping
> from the PCI IO space mapping.
It is opt-in, so we may never get to the last step. We're still better
off than now. Is there a platform that is doing this? If so, I didn't
move any DEBUG_LL users to the fixed i/o space so they would still be
using their old i/o space address. Having 2 mappings would work, right?
You use the debug mapping initially and when PCI bus and the real
console driver are up, you switch to the fixed i/o space.
This isn't just a PCI issue. You could also have a mapping that covers a
block of SOC peripherals including the uart and you don't want a
separate mapping.
Rob
^ permalink raw reply
* [PATCH 2/2] ARM: dts: cfa10049: Add the i2c muxer buses to the CFA-10049
From: Maxime Ripard @ 2012-10-18 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350569623-4699-1-git-send-email-maxime.ripard@free-electrons.com>
This will allow to add the 3 Nuvoton NAU7802 ADCs and the NXP PCA9555
GPIO expander eventually.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/imx28-cfa10049.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 97ee098..2cda823 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -76,6 +76,30 @@
status = "okay";
};
+ i2cmux {
+ compatible = "i2c-mux-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
+ i2c-parent = <&i2c1>;
+
+ i2c at 0 {
+ reg = <0>;
+ };
+
+ i2c at 1 {
+ reg = <1>;
+ };
+
+ i2c at 2 {
+ reg = <2>;
+ };
+
+ i2c at 3 {
+ reg = <3>;
+ };
+ };
+
usbphy1: usbphy at 8007e000 {
status = "okay";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver
From: Maxime Ripard @ 2012-10-18 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350569623-4699-1-git-send-email-maxime.ripard@free-electrons.com>
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.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
.../devicetree/bindings/i2c/i2c-mux-gpio.txt | 81 ++++++++++
drivers/i2c/muxes/i2c-mux-gpio.c | 169 +++++++++++++++-----
2 files changed, 211 insertions(+), 39 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
new file mode 100644
index 0000000..2cddc41
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
@@ -0,0 +1,81 @@
+GPIO-based I2C Bus Mux
+
+This binding describes an I2C bus multiplexer that uses GPIOs to
+route the I2C signals.
+
+ +-----+ +-----+
+ | dev | | dev |
+ +------------+ +-----+ +-----+
+ | SoC | | |
+ | | /--------+--------+
+ | +------+ | +------+ child bus A, on GPIO value set to 0
+ | | I2C |-|--| Mux |
+ | +------+ | +--+---+ child bus B, on GPIO value set to 1
+ | | | \----------+--------+--------+
+ | +------+ | | | | |
+ | | GPIO |-|-----+ +-----+ +-----+ +-----+
+ | +------+ | | dev | | dev | | dev |
+ +------------+ +-----+ +-----+ +-----+
+
+Required properties:
+- compatible: i2c-mux-gpio
+- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
+ port is connected to.
+- mux-gpios: list of gpios to use to control the muxer
+* Standard I2C mux properties. See mux.txt in this directory.
+* I2C child bus nodes. See mux.txt in this directory.
+
+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.
+
+For each i2c child node, an I2C child bus will be created. They will
+be numbered based on the reg property of each node.
+
+Whenever an access is made to a device on a child bus, the value set
+in the revelant node's reg property will be output using the list of
+GPIOs, the first in the list holding the most-significant value.
+
+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.
+
+Example:
+ i2cmux {
+ compatible = "i2c-mux-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
+ i2c-parent = <&i2c1>;
+
+ i2c at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ssd1307: oled at 3c {
+ compatible = "solomon,ssd1307fb-i2c";
+ reg = <0x3c>;
+ pwms = <&pwm 4 3000>;
+ reset-gpios = <&gpio2 7 1>;
+ reset-active-low;
+ };
+ };
+
+ i2c at 3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pca9555: pca9555 at 20 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+ };
+ };
+ };
diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
index 566a675..7ebef01 100644
--- a/drivers/i2c/muxes/i2c-mux-gpio.c
+++ b/drivers/i2c/muxes/i2c-mux-gpio.c
@@ -16,11 +16,13 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/gpio.h>
+#include <linux/of_i2c.h>
+#include <linux/of_gpio.h>
struct gpiomux {
struct i2c_adapter *parent;
struct i2c_adapter **adap; /* child busses */
- struct i2c_mux_gpio_platform_data data;
+ struct i2c_mux_gpio_platform_data *data;
unsigned gpio_base;
};
@@ -28,8 +30,8 @@ static void i2c_mux_gpio_set(const struct gpiomux *mux, unsigned val)
{
int i;
- for (i = 0; i < mux->data.n_gpios; i++)
- gpio_set_value(mux->gpio_base + mux->data.gpios[i],
+ for (i = 0; i < mux->data->n_gpios; i++)
+ gpio_set_value(mux->gpio_base + mux->data->gpios[i],
val & (1 << i));
}
@@ -37,7 +39,7 @@ static int i2c_mux_gpio_select(struct i2c_adapter *adap, void *data, u32 chan)
{
struct gpiomux *mux = data;
- i2c_mux_gpio_set(mux, mux->data.values[chan]);
+ i2c_mux_gpio_set(mux, mux->data->values[chan]);
return 0;
}
@@ -46,7 +48,7 @@ static int i2c_mux_gpio_deselect(struct i2c_adapter *adap, void *data, u32 chan)
{
struct gpiomux *mux = data;
- i2c_mux_gpio_set(mux, mux->data.idle);
+ i2c_mux_gpio_set(mux, mux->data->idle);
return 0;
}
@@ -57,29 +59,118 @@ static int __devinit match_gpio_chip_by_label(struct gpio_chip *chip,
return !strcmp(chip->label, data);
}
+#ifdef CONFIG_OF
+static int __devinit i2c_mux_gpio_probe_dt(struct gpiomux *mux,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *adapter_np, *child;
+ struct i2c_adapter *adapter;
+ unsigned *values, *gpios;
+ int i = 0;
+
+ if (!np)
+ return 0;
+
+ mux->data = devm_kzalloc(&pdev->dev, sizeof(*mux->data),
+ GFP_KERNEL);
+ if (!mux->data) {
+ dev_err(&pdev->dev, "Cannot allocate platform_data");
+ return -ENOMEM;
+ }
+
+ adapter_np = of_parse_phandle(np, "i2c-parent", 0);
+ if (!adapter_np) {
+ dev_err(&pdev->dev, "Cannot parse i2c-parent\n");
+ return -ENODEV;
+ }
+ adapter = of_find_i2c_adapter_by_node(adapter_np);
+ if (!adapter) {
+ dev_err(&pdev->dev, "Cannot find parent bus\n");
+ return -ENODEV;
+ }
+ mux->data->parent = i2c_adapter_id(adapter);
+ put_device(&adapter->dev);
+
+ mux->data->n_values = of_get_child_count(np);
+
+ values = devm_kzalloc(&pdev->dev,
+ sizeof(*mux->data->values) * mux->data->n_values,
+ GFP_KERNEL);
+ if (!values) {
+ dev_err(&pdev->dev, "Cannot allocate values array");
+ return -ENOMEM;
+ }
+
+ for_each_child_of_node(np, child) {
+ of_property_read_u32(child, "reg", values + i);
+ i++;
+ }
+ mux->data->values = values;
+
+ if (of_property_read_u32(np, "idle-state", &mux->data->idle))
+ mux->data->idle = I2C_MUX_GPIO_NO_IDLE;
+
+ mux->data->n_gpios = of_gpio_named_count(np, "mux-gpios");
+ if (mux->data->n_gpios < 0) {
+ dev_err(&pdev->dev, "Missing mux-gpios property in the DT.\n");
+ return -EINVAL;
+ }
+
+ gpios = devm_kzalloc(&pdev->dev,
+ sizeof(*mux->data->gpios) * mux->data->n_gpios,
+ GFP_KERNEL);
+ if (!gpios) {
+ dev_err(&pdev->dev, "Cannot allocate gpios array");
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < mux->data->n_gpios; i++)
+ gpios[i] = of_get_named_gpio(np, "mux-gpios", i);
+
+ mux->data->gpios = gpios;
+
+ return 0;
+}
+#else
+static int __devinit i2c_mux_gpio_probe_dt(struct gpiomux *mux,
+ struct platform_device *pdev)
+{
+ return 0;
+}
+#endif
+
static int __devinit i2c_mux_gpio_probe(struct platform_device *pdev)
{
struct gpiomux *mux;
- struct i2c_mux_gpio_platform_data *pdata;
struct i2c_adapter *parent;
int (*deselect) (struct i2c_adapter *, void *, u32);
unsigned initial_state, gpio_base;
int i, ret;
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev, "Missing platform data\n");
- return -ENODEV;
+ mux = devm_kzalloc(&pdev->dev, sizeof(*mux), GFP_KERNEL);
+ if (!mux) {
+ dev_err(&pdev->dev, "Cannot allocate gpiomux structure");
+ return -ENOMEM;
+ }
+
+ platform_set_drvdata(pdev, mux);
+
+ mux->data = pdev->dev.platform_data;
+ if (!mux->data) {
+ ret = i2c_mux_gpio_probe_dt(mux, pdev);
+ if (ret < 0)
+ return ret;
}
/*
* If a GPIO chip name is provided, the GPIO pin numbers provided are
* relative to its base GPIO number. Otherwise they are absolute.
*/
- if (pdata->gpio_chip) {
+ if (mux->data->gpio_chip) {
struct gpio_chip *gpio;
- gpio = gpiochip_find(pdata->gpio_chip,
+ gpio = gpiochip_find(mux->data->gpio_chip,
match_gpio_chip_by_label);
if (!gpio)
return -EPROBE_DEFER;
@@ -89,49 +180,44 @@ static int __devinit i2c_mux_gpio_probe(struct platform_device *pdev)
gpio_base = 0;
}
- parent = i2c_get_adapter(pdata->parent);
+ parent = i2c_get_adapter(mux->data->parent);
if (!parent) {
dev_err(&pdev->dev, "Parent adapter (%d) not found\n",
- pdata->parent);
+ mux->data->parent);
return -ENODEV;
}
- mux = devm_kzalloc(&pdev->dev, sizeof(*mux), GFP_KERNEL);
- if (!mux) {
- ret = -ENOMEM;
- goto alloc_failed;
- }
-
mux->parent = parent;
- mux->data = *pdata;
mux->gpio_base = gpio_base;
+
mux->adap = devm_kzalloc(&pdev->dev,
- sizeof(*mux->adap) * pdata->n_values,
+ sizeof(*mux->adap) * mux->data->n_values,
GFP_KERNEL);
if (!mux->adap) {
+ dev_err(&pdev->dev, "Cannot allocate i2c_adapter structure");
ret = -ENOMEM;
goto alloc_failed;
}
- if (pdata->idle != I2C_MUX_GPIO_NO_IDLE) {
- initial_state = pdata->idle;
+ if (mux->data->idle != I2C_MUX_GPIO_NO_IDLE) {
+ initial_state = mux->data->idle;
deselect = i2c_mux_gpio_deselect;
} else {
- initial_state = pdata->values[0];
+ initial_state = mux->data->values[0];
deselect = NULL;
}
- for (i = 0; i < pdata->n_gpios; i++) {
- ret = gpio_request(gpio_base + pdata->gpios[i], "i2c-mux-gpio");
+ for (i = 0; i < mux->data->n_gpios; i++) {
+ ret = gpio_request(gpio_base + mux->data->gpios[i], "i2c-mux-gpio");
if (ret)
goto err_request_gpio;
- gpio_direction_output(gpio_base + pdata->gpios[i],
+ gpio_direction_output(gpio_base + mux->data->gpios[i],
initial_state & (1 << i));
}
- for (i = 0; i < pdata->n_values; i++) {
- u32 nr = pdata->base_nr ? (pdata->base_nr + i) : 0;
- unsigned int class = pdata->classes ? pdata->classes[i] : 0;
+ for (i = 0; i < mux->data->n_values; i++) {
+ u32 nr = mux->data->base_nr ? (mux->data->base_nr + i) : 0;
+ unsigned int class = mux->data->classes ? mux->data->classes[i] : 0;
mux->adap[i] = i2c_add_mux_adapter(parent, &pdev->dev, mux, nr,
i, class,
@@ -144,19 +230,17 @@ static int __devinit i2c_mux_gpio_probe(struct platform_device *pdev)
}
dev_info(&pdev->dev, "%d port mux on %s adapter\n",
- pdata->n_values, parent->name);
-
- platform_set_drvdata(pdev, mux);
+ mux->data->n_values, parent->name);
return 0;
add_adapter_failed:
for (; i > 0; i--)
i2c_del_mux_adapter(mux->adap[i - 1]);
- i = pdata->n_gpios;
+ i = mux->data->n_gpios;
err_request_gpio:
for (; i > 0; i--)
- gpio_free(gpio_base + pdata->gpios[i - 1]);
+ gpio_free(gpio_base + mux->data->gpios[i - 1]);
alloc_failed:
i2c_put_adapter(parent);
@@ -168,11 +252,11 @@ static int __devexit i2c_mux_gpio_remove(struct platform_device *pdev)
struct gpiomux *mux = platform_get_drvdata(pdev);
int i;
- for (i = 0; i < mux->data.n_values; i++)
+ for (i = 0; i < mux->data->n_values; i++)
i2c_del_mux_adapter(mux->adap[i]);
- for (i = 0; i < mux->data.n_gpios; i++)
- gpio_free(mux->gpio_base + mux->data.gpios[i]);
+ for (i = 0; i < mux->data->n_gpios; i++)
+ gpio_free(mux->gpio_base + mux->data->gpios[i]);
platform_set_drvdata(pdev, NULL);
i2c_put_adapter(mux->parent);
@@ -180,12 +264,19 @@ static int __devexit i2c_mux_gpio_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id i2c_mux_gpio_of_match[] __devinitconst = {
+ { .compatible = "i2c-mux-gpio", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, i2c_mux_gpio_of_match);
+
static struct platform_driver i2c_mux_gpio_driver = {
.probe = i2c_mux_gpio_probe,
.remove = __devexit_p(i2c_mux_gpio_remove),
.driver = {
.owner = THIS_MODULE,
.name = "i2c-mux-gpio",
+ .of_match_table = of_match_ptr(i2c_mux_gpio_of_match),
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCHv4 0/2] ARM: I2C: Add device tree bindings to i2c-mux-gpio
From: Maxime Ripard @ 2012-10-18 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This patchset adds the device tree entry to the CFA-10049 board of its i2c
muxer. This muxer controls sub-buses that contains three Nuvoton NAU7802
ADCs and a NXP PCA955 GPIO expander. Support for these will be added
eventually.
Thanks,
Maxime
Changes from v3:
- Rebased on top of 3.7-rc1
Maxime Ripard (2):
i2c: mux: Add dt support to i2c-mux-gpio driver
ARM: dts: cfa10049: Add the i2c muxer buses to the CFA-10049
.../devicetree/bindings/i2c/i2c-mux-gpio.txt | 81 ++++++++++
arch/arm/boot/dts/imx28-cfa10049.dts | 24 +++
drivers/i2c/muxes/i2c-mux-gpio.c | 169 +++++++++++++++-----
3 files changed, 235 insertions(+), 39 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
--
1.7.9.5
^ permalink raw reply
* PDF documentation
From: Grant Edwards @ 2012-10-18 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1TOqZc-0005Wc-Oj@jdl.com>
On 2012-10-18, Jon Loeliger <jdl@jdl.com> wrote:
>>
>> I would prefer if the source for the (PDF-)documentation would be
>> available in some open, free and widely used meta-language, e.g. LaTeX
>> (or XML or txt2tags or ..., but I'm oldschool and prefer LaTeX ;) ). So
>> everyone could build it's copy in whatever format he prefers or needs.
>
> Perhaps DocBook? It is readily rendered as PDF or HTML.
Unfortunately DocBook can't be read/edited by a human. IMO, Docbook
is only suitable as a machine-generated intermediate format.
I'd recommend one of the lightweight markup languages like asciidoc or
reStructuredText. They're easy to read/write, perfectly usable in the
source form and can be rendered into PDF, HTML, ODT, DocBook, whatever.
--
Grant Edwards grant.b.edwards Yow! Don't SANFORIZE me!!
at
gmail.com
^ permalink raw reply
* [PATCH 2/2] ARM: dts: cfa10049: Add spidev to drive the DAC on SSP3
From: Maxime Ripard @ 2012-10-18 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350568768-4374-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/imx28-cfa10049.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index 05c892e..d91d16c 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -29,6 +29,7 @@
0x01c1 /* MX28_PAD_GPMI_RESETN__SSP3_CMD */
0x0111 /* MX28_PAD_GPMI_CE1N__SSP3_D3 */
0x01a2 /* MX28_PAD_GPMI_ALE__SSP3_D4 */
+ 0x01b2 /* MX28_PAD_GPMI_CLE__SSP3_D5 */
>;
fsl,drive-strength = <1>;
fsl,voltage = <1>;
@@ -60,6 +61,11 @@
spi-max-frequency = <100000>;
};
+ spidev: spidev at 2 {
+ compatible = "linux,spidev";
+ reg = <2>;
+ spi-max-frequency = <100000>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] spi: spidev: Add device tree bindings
From: Maxime Ripard @ 2012-10-18 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350568768-4374-1-git-send-email-maxime.ripard@free-electrons.com>
This will allow to probe spidev from device tree
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/spi/spidev.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 830adbe..8ae0660 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -31,6 +31,8 @@
#include <linux/mutex.h>
#include <linux/slab.h>
#include <linux/compat.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/spi/spi.h>
#include <linux/spi/spidev.h>
@@ -642,10 +644,18 @@ static int __devexit spidev_remove(struct spi_device *spi)
return 0;
}
+static const struct of_device_id spidev_dt_ids[] = {
+ { .compatible = "linux,spidev" },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, spidev_dt_ids);
+
static struct spi_driver spidev_spi_driver = {
.driver = {
.name = "spidev",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(spidev_dt_ids),
},
.probe = spidev_probe,
.remove = __devexit_p(spidev_remove),
--
1.7.9.5
^ permalink raw reply related
* [RESEND][PATCH 0/2] Add spidev to the CFA-10049
From: Maxime Ripard @ 2012-10-18 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This patchset probes spidev on the SSP3 bus where on the CFA-10049 there is
a DAC.
It first adds the dt bindings for the spidev driver, and the proper node in
the CFA-10049 device tree file.
Maxime
Maxime Ripard (2):
spi: spidev: Add device tree bindings
ARM: dts: cfa10049: Add spidev to drive the DAC on SSP3
arch/arm/boot/dts/imx28-cfa10049.dts | 6 ++++++
drivers/spi/spidev.c | 10 ++++++++++
2 files changed, 16 insertions(+)
--
1.7.9.5
^ permalink raw reply
* PDF documentation
From: Jon Loeliger @ 2012-10-18 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508003AA.8010409@ahsoftware.de>
>
> I would prefer if the source for the (PDF-)documentation would be
> available in some open, free and widely used meta-language, e.g. LaTeX
> (or XML or txt2tags or ..., but I'm oldschool and prefer LaTeX ;) ). So
> everyone could build it's copy in whatever format he prefers or needs.
Perhaps DocBook? It is readily rendered as PDF or HTML.
jdl
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Russell King - ARM Linux @ 2012-10-18 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5080088C.9090607@gmail.com>
On Thu, Oct 18, 2012 at 08:47:56AM -0500, Rob Herring wrote:
> Here is what I mentioned previously. This removes the static mapping from
> the platforms. This is untested and probably breaks on different DEBUG_LL
> options. For now, platforms call debug_ll_io_init, but once all platforms
> are converted, this can be called from devicemaps_init.
There's a problem with this approach. What if the platform specifically
sets the debug addresses to be within one of it's existing mappings (which
is definitely what you'd want to do with 8250-based UARTs attached to a
PCI bus.)
This isn't going to work in that case unless we split the debug mapping
from the PCI IO space mapping.
^ permalink raw reply
* [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used
From: Felipe Balbi @ 2012-10-18 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350562684.2143.52.camel@sokoban>
hi,
On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > +static int __init omap4430_phy_power_down(void)
> > > +{
> > > + void __iomem *ctrl_base;
> > > +
> > > + if (!cpu_is_omap44xx())
> > > + return 0;
> > > +
> > > + ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
> > > + if (!ctrl_base) {
> > > + pr_err("control module ioremap failed\n");
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + /* Power down the phy */
> > > + __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
> > > +
> > > + iounmap(ctrl_base);
> > > +
> > > + return 0;
> > > +}
> > > +early_initcall(omap4430_phy_power_down);
> > > +#endif
> >
> > I think you could do it even if the driver is enabled.
>
> Actually not at least now, it looks like the driver is not controlling
> this bit at all, so the driver would fail if we do this.
then we can consider that a bug in the driver. Kishon, I thought you had
added SCM address space to PHY driver for this particular reason until
we get SCM driver, wasn't it ??
> > Just to make sure I understand the issue right: is the PHY enabled by
> > default or did bootloader left this enabled ?
>
> The reset value for the register is zero (at least according to TRM), so
> it is enabled from boot. Also, I couldn't find any code from the u-boot
> that would touch this bit with a quick look.
ok, so it looks like we must do this anyway, thanks ;-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121018/51556c03/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/5] ARM: bcm476x: Add platform infrastructure
From: Arnd Bergmann @ 2012-10-18 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121014223023.611069832@gmail.com>
On Sunday 14 October 2012, Domenico Andreoli wrote:
> From: Domenico Andreoli <domenico.andreoli@linux.com>
>
> Platform infrastructure for the Broadcom BCM476x ARMv6 SoCs.
Hi Domenico,
All your patches look good to me now, except for one thing throughout
the bindings:
> Index: b/Documentation/devicetree/bindings/arm/bcm476x.txt
> ===================================================================
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/bcm476x.txt
> @@ -0,0 +1,15 @@
> +Broadcom BCM4760 and BCM4761 SoCs device tree bindings
> +------------------------------------------------------
> +
> +Boards with the BCM4760 SoC shall have the following properties:
> +
> +Required root node property:
> +
> +compatible = "brcm,bcm4760";
> +
> +
> +Boards with the BCM4761 SoC shall have the following properties:
> +
> +Required root node property:
> +
> +compatible = "brcm,bcm4761";
I probably wasn't clear enough with my request to have specific
chip identifiers in the device tree "compatible" nodes. The idea
generally is that for completely identical hardware blocks, you
just need to put the first known variant into the driver, e.g.
"brcm,bcm4760-system-timer", and in case of a later chip that
is compatible with it, you list both "brcm,bcm4760-system-timer"
and "brcm,bcm4761-system-timer" in the compatible property of the
device tree. The way you did it is also correct and works, but
is a bit less common.
How do you want to merge your patches? The preferred way from
our side is to get a pull request from you sent to arm at kernel.org
with Cc to the linux-arm-kernel mailing list, but we can also
pick up the patches separately if necessary.
For the patches that go into different directories like the clk
and the clocksource drivers, please Cc the respective subsystem
maintainers and ask them for an Ack. It certainly makes sense
for a new platform port to get merged through the arm-soc tree,
but any future improvements should normally just go through the
subsystem trees.
Arnd
^ permalink raw reply
* [PATCH V2 3/3] ARM: tegra: move debug-macro.S to include/debug
From: Rob Herring @ 2012-10-18 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507F1F31.2060503@wwwdotorg.org>
On 10/17/2012 04:12 PM, Stephen Warren wrote:
> On 10/17/2012 10:22 AM, Stephen Warren wrote:
snip
> That implies we really do need to keep the two pieces of code completely
> in sync, so a shared header is the right way to go. It also implies that
> having duplicate mappings of the same physical address doesn't cause any
> immediate obvious catastrophic problems.
>
> Ways we might avoid files in arch/arm/include/debug having to use
> relative include paths to pick up that header are:
>
> a) Move mach-${mach}/include/mach/iomap.h to iomap-${mach}.h in some
> standard include path.
>
Your goal should be to get rid of iomap.h though...
> b) Rework debug-macro.S so that it isn't an include file, but rather a
> regular top-level file. In other words, rather than compiling
> arch/arm/kernel/debug.S, and having that #include DEBUG_LL_INCLUDE,
> instead compile DEBUG_LL_SOURCE (i.e. arch/arm/mach-${mach}/debug.S by
> default), and have that #include any common parts (e.g. implementation
> of printhex8). This has benefits of:
>
> b1) arch/arm/mach-${mach}/debug.S is in the mach directory that owns it,
> rather than having them all dumped into a common location.
>
> b2) Can use #include "iomap.h", a non-relative include, to pick up the
> shared header
>
> b3) Perhaps we can simplify the current debug.S e.g. have a common
> debug-semihosting.S that contains the semihosting stuff, and only
> include that from mach-*/debug.S if that machine uses semihosting, or
> similar?
>
> (b) seems like a lot of work. I don't see any advantage of (a) over just
> using the relative include.
Agreed.
Here is what I mentioned previously. This removes the static mapping from
the platforms. This is untested and probably breaks on different DEBUG_LL
options. For now, platforms call debug_ll_io_init, but once all platforms
are converted, this can be called from devicemaps_init.
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 195ac2f..2ece92c 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -40,6 +40,9 @@ extern void iotable_init(struct map_desc *, int);
extern void vm_reserve_area_early(unsigned long addr, unsigned long size,
void *caller);
+extern void debug_ll_addr(unsigned long *paddr, unsigned long *vaddr);
+extern void debug_ll_io_init(void);
+
struct mem_type;
extern const struct mem_type *get_mem_type(unsigned int type);
/*
diff --git a/arch/arm/kernel/debug.S b/arch/arm/kernel/debug.S
index 66f711b..93883ed 100644
--- a/arch/arm/kernel/debug.S
+++ b/arch/arm/kernel/debug.S
@@ -100,6 +100,13 @@ ENTRY(printch)
b 1b
ENDPROC(printch)
+ENTRY(debug_ll_addr)
+ addruart r2, r3, ip
+ str r2, [r0]
+ str r3, [r1]
+ mov pc, lr
+ENDPROC(debug_ll_addr)
+
#else
ENTRY(printascii)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 941dfb9..1c8c7be 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -876,6 +876,20 @@ static void __init pci_reserve_io(void)
#define pci_reserve_io() do { } while (0)
#endif
+void __init debug_ll_io_init(void)
+{
+ struct map_desc map;
+
+ if (!IS_ENABLED(CONFIG_DEBUG_LL))
+ return;
+
+ debug_ll_addr(&map.pfn, &map.virtual);
+ map.pfn = __phys_to_pfn(map.pfn);
+ map.length = PAGE_SIZE;
+ map.type = MT_DEVICE;
+ create_mapping(&map);
+}
+
static void * __initdata vmalloc_min =
(void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
^ permalink raw reply related
* [PATCH 3/4] ARM: OMAP2+: Move iommu/iovmm headers to platform_data
From: Laurent Pinchart @ 2012-10-18 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016003640.19701.51749.stgit@muffinssi.local>
Hi,
On Monday 15 October 2012 17:36:40 Tony Lindgren wrote:
> From: Ido Yariv <ido@wizery.com>
>
> Move iommu/iovmm headers from plat/ to platform_data/ as part of the
> single zImage work.
Is that really where those headers belong ? iommu-omap.h contains far more
than platform data, and iovmm-omap.h contains no platform data at all.
> Cc: Joerg Roedel <joerg.roedel@amd.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> Signed-off-by: Ido Yariv <ido@wizery.com>
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/devices.c | 2 +-
> arch/arm/mach-omap2/iommu2.c | 2 +-
> arch/arm/mach-omap2/omap-iommu.c | 2 +-
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
> drivers/iommu/omap-iommu-debug.c | 4 ++--
> drivers/iommu/omap-iommu.c | 2 +-
> drivers/iommu/omap-iovmm.c | 4 ++--
> drivers/media/platform/omap3isp/isp.h | 5 +++--
> drivers/media/platform/omap3isp/ispvideo.c | 5 ++---
> include/linux/platform_data/iommu-omap.h | 0
> include/linux/platform_data/iovmm-omap.h | 0
> 12 files changed, 15 insertions(+), 15 deletions(-)
> rename arch/arm/plat-omap/include/plat/iommu.h =>
> include/linux/platform_data/iommu-omap.h (100%) rename
> arch/arm/plat-omap/include/plat/iovmm.h =>
> include/linux/platform_data/iovmm-omap.h (100%)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index c8c2117..6cd0c2a 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -126,7 +126,7 @@ static struct platform_device omap2cam_device = {
>
> #if defined(CONFIG_IOMMU_API)
>
> -#include <plat/iommu.h>
> +#include <linux/platform_data/iommu-omap.h>
>
> static struct resource omap3isp_resources[] = {
> {
> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
> index c986880..82f9174 100644
> --- a/arch/arm/mach-omap2/iommu2.c
> +++ b/arch/arm/mach-omap2/iommu2.c
> @@ -18,7 +18,7 @@
> #include <linux/slab.h>
> #include <linux/stringify.h>
>
> -#include <plat/iommu.h>
> +#include <linux/platform_data/iommu-omap.h>
>
> /*
> * omap2 architecture specific register bit definitions
> diff --git a/arch/arm/mach-omap2/omap-iommu.c
> b/arch/arm/mach-omap2/omap-iommu.c index df298d4..a6a4ff8 100644
> --- a/arch/arm/mach-omap2/omap-iommu.c
> +++ b/arch/arm/mach-omap2/omap-iommu.c
> @@ -13,7 +13,7 @@
> #include <linux/module.h>
> #include <linux/platform_device.h>
>
> -#include <plat/iommu.h>
> +#include <linux/platform_data/iommu-omap.h>
>
> #include "soc.h"
> #include "common.h"
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index f67b7ee..621bc71 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -26,8 +26,8 @@
> #include <plat/mmc.h>
> #include <linux/platform_data/asoc-ti-mcbsp.h>
> #include <linux/platform_data/spi-omap2-mcspi.h>
> +#include <linux/platform_data/iommu-omap.h>
> #include <plat/dmtimer.h>
> -#include <plat/iommu.h>
>
> #include "am35xx.h"
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 652d028..5850b3e 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -27,10 +27,10 @@
> #include <plat/dma.h>
> #include <linux/platform_data/spi-omap2-mcspi.h>
> #include <linux/platform_data/asoc-ti-mcbsp.h>
> +#include <linux/platform_data/iommu-omap.h>
> #include <plat/mmc.h>
> #include <plat/dmtimer.h>
> #include <plat/common.h>
> -#include <plat/iommu.h>
>
> #include "omap_hwmod_common_data.h"
> #include "cm1_44xx.h"
> diff --git a/drivers/iommu/omap-iommu-debug.c
> b/drivers/iommu/omap-iommu-debug.c index a0b0309..8c1e30b 100644
> --- a/drivers/iommu/omap-iommu-debug.c
> +++ b/drivers/iommu/omap-iommu-debug.c
> @@ -19,8 +19,8 @@
> #include <linux/platform_device.h>
> #include <linux/debugfs.h>
>
> -#include <plat/iommu.h>
> -#include <plat/iovmm.h>
> +#include <linux/platform_data/iommu-omap.h>
> +#include <linux/platform_data/iovmm-omap.h>
>
> #include <plat/iopgtable.h>
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index 80844b3..6100334 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -24,7 +24,7 @@
>
> #include <asm/cacheflush.h>
>
> -#include <plat/iommu.h>
> +#include <linux/platform_data/iommu-omap.h>
>
> #include <plat/iopgtable.h>
>
> diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
> index b362fb5..b5ac2cd 100644
> --- a/drivers/iommu/omap-iovmm.c
> +++ b/drivers/iommu/omap-iovmm.c
> @@ -21,8 +21,8 @@
> #include <asm/cacheflush.h>
> #include <asm/mach/map.h>
>
> -#include <plat/iommu.h>
> -#include <plat/iovmm.h>
> +#include <linux/platform_data/iommu-omap.h>
> +#include <linux/platform_data/iovmm-omap.h>
>
> #include <plat/iopgtable.h>
>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index 8be7487..62c76f9 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -34,8 +34,9 @@
> #include <linux/platform_device.h>
> #include <linux/wait.h>
> #include <linux/iommu.h>
> -#include <plat/iommu.h>
> -#include <plat/iovmm.h>
> +
> +#include <linux/platform_data/iommu-omap.h>
> +#include <linux/platform_data/iovmm-omap.h>
>
> #include "ispstat.h"
> #include "ispccdc.h"
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c index a0b737fe..75ecfc8 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -34,9 +34,8 @@
> #include <linux/vmalloc.h>
> #include <media/v4l2-dev.h>
> #include <media/v4l2-ioctl.h>
> -#include <plat/iommu.h>
> -#include <plat/iovmm.h>
> -#include <plat/omap-pm.h>
> +#include <linux/platform_data/iommu-omap.h>
> +#include <linux/platform_data/iovmm-omap.h>
>
> #include "ispvideo.h"
> #include "isp.h"
> diff --git a/arch/arm/plat-omap/include/plat/iommu.h
> b/include/linux/platform_data/iommu-omap.h similarity index 100%
> rename from arch/arm/plat-omap/include/plat/iommu.h
> rename to include/linux/platform_data/iommu-omap.h
> diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
> b/include/linux/platform_data/iovmm-omap.h similarity index 100%
> rename from arch/arm/plat-omap/include/plat/iovmm.h
> rename to include/linux/platform_data/iovmm-omap.h
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] ARM: OMAP2+: clockdomain: Fix OMAP4 ISS clk domain to support only SWSUP
From: Benoit Cousson @ 2012-10-18 13:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Miguel Vadillo <vadillo@ti.com>
Since CAM domain (ISS) has no module wake-up dependency
with any other clock domain of the device and the dynamic
dependency from L3_main_2 is always disabled, the domain
needs to be in force wakeup in order to be able to access
it for configure (sysconfig) it or use it.
Also since there is no clock in the domain managed automatically
by the hardware, there is no use to configure automatic
clock domain transition. SW should keep the SW_WKUP domain
transition as long as a module in the domain is required to
be functional.
Signed-off-by: Miguel Vadillo <vadillo@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
---
Hi Tony,
Here is a fix that Miguel sent me some time back and that I forgot until
I face the crash again while trying to enable the ISS for test.
Regards,
Benoit
arch/arm/mach-omap2/clockdomains44xx_data.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index b56d06b..95192a0 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -359,7 +359,7 @@ static struct clockdomain iss_44xx_clkdm = {
.clkdm_offs = OMAP4430_CM2_CAM_CAM_CDOFFS,
.wkdep_srcs = iss_wkup_sleep_deps,
.sleepdep_srcs = iss_wkup_sleep_deps,
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_SWSUP,
};
static struct clockdomain l3_dss_44xx_clkdm = {
--
1.7.0.4
^ permalink raw reply related
* PDF documentation
From: Alexander Holler @ 2012-10-18 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com>
Am 16.10.2012 15:22, schrieb Constantine Shulyupin:
> Questions:
> - have same issues with PDF documentation and datasheets?
No.
> - do you think documentation and datasheets in HTML format on a site
> can be more useful than PDF?
I would prefer if the source for the (PDF-)documentation would be
available in some open, free and widely used meta-language, e.g. LaTeX
(or XML or txt2tags or ..., but I'm oldschool and prefer LaTeX ;) ). So
everyone could build it's copy in whatever format he prefers or needs.
Regards,
Alexander
^ permalink raw reply
* [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
From: Matt Porter @ 2012-10-18 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350566815-409-1-git-send-email-mporter@ti.com>
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Signed-off-by: Matt Porter <mporter@ti.com>
---
arch/arm/boot/dts/am335x-bone.dts | 17 +++++++++++++++
arch/arm/boot/dts/am335x-evm.dts | 9 ++++++++
arch/arm/boot/dts/am33xx.dtsi | 43 +++++++++++++++++++++++++++++++++++++
3 files changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
index 5510979..23edfd8 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,17 @@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
+ am3358_pinmux: pinmux at 44e10800 {
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins = <
+ 0x190 0x13 /* mcasp0_aclkx.spi1_sclk, OUTPUT_PULLUP | MODE3 */
+ 0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
+ 0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
+ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
+ >;
+ };
+ };
+
ocp {
uart1: serial at 44e09000 {
status = "okay";
@@ -84,3 +95,9 @@
&mmc1 {
vmmc-supply = <&ldo3_reg>;
};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d63fce8..8d5f660 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -124,3 +124,12 @@
&mmc1 {
vmmc-supply = <&vmmc_reg>;
};
+
+&spi0 {
+ status = "okay";
+ spi-flash at 0 {
+ compatible = "spansion,s25fl064k", "m25p80";
+ spi-max-frequency = <24000000>;
+ reg = <0>;
+ };
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 26a6af7..063ecea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux at 44e10800 {
+ compatible = "pinctrl-single";
+ reg = <0x44e10800 0x0238>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x7f>;
+ };
+
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
@@ -261,6 +270,40 @@
status = "disabled";
};
+ spi0: spi at 48030000 {
+ compatible = "ti,omap4-mcspi";
+ ti,hwmods = "spi0";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x48030000 0x400>;
+ interrupt-parent = <&intc>;
+ interrupt = <65>;
+ dmas = <&edma 16
+ &edma 17
+ &edma 18
+ &edma 19>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ ti,spi-num-cs = <2>;
+ status = "disabled";
+ };
+
+ spi1: spi at 481a0000 {
+ compatible = "ti,omap4-mcspi";
+ ti,hwmods = "spi1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x481a0000 0x400>;
+ interrupt-parent = <&intc>;
+ interrupt = <125>;
+ dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+ dma-names = "tx0", "rx0", "tx1", "rx1";
+ ti,spi-num-cs = <2>;
+ status = "disabled";
+ };
+
wdt2: wdt at 44e35000 {
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
--
1.7.9.5
^ permalink raw reply related
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