RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
[...] > arch/arm/boot/dts/Makefile|1 + > arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 + > 2 files changed, 124 insertions(+) > create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts > >diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile >index 0320303..c5e9bfa 100644 >--- a/arch/arm/boot/dts/Makefile >+++ b/arch/arm/boot/dts/Makefile >@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ > am335x-evmsk.dtb \ > am335x-bone.dtb \ > am335x-boneblack.dtb \ >+ am335x-bone-memory-cape.dtb\ > am335x-nano.dtb \ > am335x-base0033.dtb \ > am3517-evm.dtb \ >diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts >b/arch/arm/boot/dts/am335x-bone-memory-cape.dts >new file mode 100644 >index 000..7ab088d >--- /dev/null >+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts > >From discussions, option I could think are.. (a) NAND cape node added in both 'am335x-bone.dts' and 'am335x-boneblack.dts' but "disabled" by default. (b) NAND cape node in new '.dts' file (as mentioned above), and generate a separate blob individual for cape. (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled" by default. But there is no guarantee that future boards remain compatible and same 'common_xx.dtsi' can be reused later. I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the ones who have to maintain all these. Tony ? with regards, pekon -- 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: [PATCHv3 1/2] arm: dts: dra7: Add qspi device.
Tony, On Wednesday 12 March 2014 11:04 PM, Tony Lindgren wrote: * Sourav Poddar [140310 04:54]: These add device tree entry for qspi controller driver on dra7-evm. It seems that we need to wait for the crossbar dependencies to get cleared in the mainline kernel before we can apply this as otherwise the interrupts will be wrong in omap-for-v3.15/dt branch. Regards, Tony Ok. Can patch2 of this series be picked? It does not depend on crossbar and is targetted for a different SOC(AM43x). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
On Thursday 13 March 2014 06:07 AM, Nishanth Menon wrote: > On 03/12/2014 04:59 PM, Santosh Shilimkar wrote: >> On Thursday 13 March 2014 05:43 AM, Nishanth Menon wrote: >>> Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if >>> CONFIG_PM is enabled, else, disabling CONFIG_PM results in build >>> failure complaining about the following: >>> arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary': >>> :(.text+0x8a70): undefined reference to `pm44xx_errata' >>> >> Not entirely accurate since CPU hotplug doesn't depend on CONFIG_PM > > Just reporting the build error here. >> >>> Fixes: c962184 (ARM: OMAP4: PM: add errata support) >>> Reported-by: Tony Lindgren >>> Signed-off-by: Nishanth Menon >>> --- >>> >>> Patch based on: v3.14-rc6 >>> Reported originally with a randconfig defconfig: >>> http://slexy.org/view/s21U7eF4k1 >>> >> But without the PM sleep code, hotplug won't work either. > yep - agreed, >> SO I think its ok assumption in this particular case > > Can I take that as an Ack here? or would you suggest any improvements? > yep. Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
On 03/12/2014 04:59 PM, Santosh Shilimkar wrote:
> On Thursday 13 March 2014 05:43 AM, Nishanth Menon wrote:
>> Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
>> CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
>> failure complaining about the following:
>> arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
>> :(.text+0x8a70): undefined reference to `pm44xx_errata'
>>
> Not entirely accurate since CPU hotplug doesn't depend on CONFIG_PM
Just reporting the build error here.
>
>> Fixes: c962184 (ARM: OMAP4: PM: add errata support)
>> Reported-by: Tony Lindgren
>> Signed-off-by: Nishanth Menon
>> ---
>>
>> Patch based on: v3.14-rc6
>> Reported originally with a randconfig defconfig:
>> http://slexy.org/view/s21U7eF4k1
>>
> But without the PM sleep code, hotplug won't work either.
yep - agreed,
> SO I think its ok assumption in this particular case
Can I take that as an Ack here? or would you suggest any improvements?
>
>> arch/arm/mach-omap2/pm.h |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
>> index 7bdd22a..d4d0fce 100644
>> --- a/arch/arm/mach-omap2/pm.h
>> +++ b/arch/arm/mach-omap2/pm.h
>> @@ -103,7 +103,7 @@ static inline void
>> enable_omap3630_toggle_l2_on_restore(void) { }
>>
>> #define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 << 0)
>>
>> -#if defined(CONFIG_ARCH_OMAP4)
>> +#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
>> extern u16 pm44xx_errata;
>> #define IS_PM44XX_ERRATUM(id) (pm44xx_errata & (id))
>> #else
>>
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
On Thursday 13 March 2014 05:43 AM, Nishanth Menon wrote:
> Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
> CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
> failure complaining about the following:
> arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
> :(.text+0x8a70): undefined reference to `pm44xx_errata'
>
Not entirely accurate since CPU hotplug doesn't depend on CONFIG_PM
> Fixes: c962184 (ARM: OMAP4: PM: add errata support)
> Reported-by: Tony Lindgren
> Signed-off-by: Nishanth Menon
> ---
>
> Patch based on: v3.14-rc6
> Reported originally with a randconfig defconfig:
> http://slexy.org/view/s21U7eF4k1
>
But without the PM sleep code, hotplug won't work either.
SO I think its ok assumption in this particular case
> arch/arm/mach-omap2/pm.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 7bdd22a..d4d0fce 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -103,7 +103,7 @@ static inline void
> enable_omap3630_toggle_l2_on_restore(void) { }
>
> #define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 << 0)
>
> -#if defined(CONFIG_ARCH_OMAP4)
> +#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
> extern u16 pm44xx_errata;
> #define IS_PM44XX_ERRATUM(id)(pm44xx_errata & (id))
> #else
>
--
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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 16:13-20140312, Gupta, Pekon wrote:
> I think this is different discussion from previous one ..
> "common DTS file" v/s "replicated DTS entries in individual board files"
> because 'uncomment' issue will remain in both scenarios. (please read below)
see below patch to highlight what I was mentioning: The build generates the dtb
that can be used with
nand cape without any hand modification. the "easy" part I mentioned is
just knowing to select the right dtb corresponding to the cape. There is
no replication, just overriding the default board behavior.
>From b573d557aa09e34b1b587943dfea73bac480286d Mon Sep 17 00:00:00 2001
From: DUMMY AUTHOR
Date: Wed, 12 Mar 2014 16:47:15 -0500
Subject: [REFERENCE PATCH] ARM: dts: am335x-bone: add support for beaglebone
NAND cape
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
---
arch/arm/boot/dts/Makefile|1 +
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 123 +
2 files changed, 124 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..c5e9bfa 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -226,6 +226,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+ am335x-bone-memory-cape.dtb\
am335x-nano.dtb \
am335x-base0033.dtb \
am3517-evm.dtb \
diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts
b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
new file mode 100644
index 000..7ab088d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,123 @@
+#include "am335x-bone.dts"
+
+&am33xx_pinmux {
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins = <
+ 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
*/
+ 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
*/
+ 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
*/
+ 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc
[PATCH] ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
failure complaining about the following:
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
:(.text+0x8a70): undefined reference to `pm44xx_errata'
Fixes: c962184 (ARM: OMAP4: PM: add errata support)
Reported-by: Tony Lindgren
Signed-off-by: Nishanth Menon
---
Patch based on: v3.14-rc6
Reported originally with a randconfig defconfig:
http://slexy.org/view/s21U7eF4k1
arch/arm/mach-omap2/pm.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7bdd22a..d4d0fce 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -103,7 +103,7 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 << 0)
-#if defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
extern u16 pm44xx_errata;
#define IS_PM44XX_ERRATUM(id) (pm44xx_errata & (id))
#else
--
1.7.9.5
--
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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
>-Original Message-
>From: Menon, Nishanth
>Sent: Thursday, March 13, 2014 2:21 AM
>To: Tony Lindgren; Robert Nelson
>Cc: Gupta, Pekon; bcous...@baylibre.com; linux-omap; linux-mtd
>Subject: Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone
>NAND cape
>
>On 03/12/2014 02:28 PM, Tony Lindgren wrote:
>> * Robert Nelson [140312 12:11]:
>>> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon wrote:
On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon wrote:
> Hi,
>
>> From: Menon, Nishanth
>>> On 03/12/2014 05:49 AM, Pekon Gupta wrote:
>>> Beaglebone Board can be connected to expansion boards to add devices to
>>> them.
>>> These expansion boards are called 'capes'. This patch adds support for
>>> following versions of Beaglebone(AM335x) NAND capes
>>> (a) NAND Device with bus-width=16, block-size=128k, page-size=2k,
>>> oob-size=64
>>> (b) NAND Device with bus-width=16, block-size=256k, page-size=4k,
>>> oob-size=224
>>> Further information and datasheets can be found at [1] and [2]
> [...]
>>> [1]
>>> http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
>>> [2]
>>> http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
>>>
>>> Signed-off-by: Pekon Gupta
>>> ---
>>> arch/arm/boot/dts/am335x-bone.dts | 123
>>> ++
>>> 1 file changed, 123 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts
>>> b/arch/arm/boot/dts/am335x-bone.dts
>>> index 94ee427..be2c572 100644
>>> --- a/arch/arm/boot/dts/am335x-bone.dts
>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
>>
>> better to make a nand_cape dts which includes the am335x-bone.dts?
>>
> Actually, I'm not in favor of having too many "xx_board_common.dts" files,
> because it un-necessarily complexes things.
>
> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just
> saves
> some lines common to DTS of both Beaglebone-LT(white) and
> Beaglebone-Black.
> And, there is no guarantee that Beaglebone-LT(white) will remain
> compatible to
> Beaglebone-black in future.
> Example: some capes are not compatible to beaglebone-black [1], [2].
>
> So, I prefer to keep separate GPMC NAND nodes separately in both DTS,
> unless there is a strong convincing reason otherwise.
>
>
> [1] http://elinux.org/CircuitCo:BeagleBoardToys
> [2] http://elinux.org/BeagleBone_Black_Capes
Right, and adding NAND, GPMC nodes and asking folks to uncomment
sections into a generic board file (which by default has none) makes
more sense? I dont use NAND capes or might create my own cape. overo
has the same challenges as bone family has.I dont see asking folks to
uncomment entries to use the cape is a nicer alternative to having
more dts entries.
I think this is different discussion from previous one ..
"common DTS file" v/s "replicated DTS entries in individual board files"
because 'uncomment' issue will remain in both scenarios. (please read below)
>>>
>>> This is just going to get more messy with every cape addition. Should
>>> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in
>>> mainline kernel.org.
>>>
>>> Then create a repo on github.com/beagleboard/ with every
>>> -.dts option?
>>
>> Or just include all devices on the most common capes but have their
>> status as disabled by default.
>>
>> For the pinctrl, we need to make sure the pins for a device are not
>> muxed if it's set to disabled state.
Yes, this is exactly what I intended. Therefore if you revisit the
"uncomment" section, then you would find that there is mmc2=disabled
because on beaglebone-black eMMC (MMC2) pinctrl conflicts with
NAND pin-ctrl.
> +/*
> + * uncomment following to enable NAND cape support
> + * &mmc2 {
> + * status = "disabled";
> + * };
> + * &elm {
> + * status = "okay";
> + * };
> + * &gpmc {
> + * status = "okay";
> + * };
And I agree 'uncommenting' is not cleaner approach here, so if everyone
agrees, I can remove the above comment and just keep NAND DT node
"disabled" by default.
>
>You do have a bunch of "if you want nand, disable mmc2" configuration
>in the usage of cape configurations such as this patch, or in the case
>of [1] (audio cape), different regulator usage etc. Maintaining out of
>tree cape dts might be an option, but that is prone to maintenance
>burden as device tree conversion goes on (yeah, all the dt as ABI
>stuff aside).
>
>Keeping aside the subjective nature of what entitles a cape being a
>"common cape",even introducing nodes that belong to three or four
>different first level capes will definitely have it's own sets of
>problems.
>
>The ideal solution would be some folks pitching in on what Matt
>pointed in [2] - basically "ups
Re: [PATCH v3 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails
* Santosh Shilimkar [140312 14:08]:
> On Thursday 13 March 2014 01:28 AM, Tony Lindgren wrote:
> > * Peter Ujfalusi [140304 23:14]:
> >> On 03/04/2014 04:37 PM, Santosh Shilimkar wrote:
> >>> On Tuesday 04 March 2014 08:48 PM, Peter Ujfalusi wrote:
> Use dev_err() which will going to print the driver's name as well and the
> KERN_ERR level is sufficient in this case (we also print via dev_err when
> there is an error with the mem resources)
>
> Signed-off-by: Peter Ujfalusi
> Reviewed-by: Santosh Shilimkar
> ---
> drivers/bus/omap_l3_noc.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
> index 0eff48585ae3..972691a668a3 100644
> --- a/drivers/bus/omap_l3_noc.c
> +++ b/drivers/bus/omap_l3_noc.c
> @@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device
> *pdev)
> ret = devm_request_irq(&pdev->dev, l3->debug_irq,
> l3_interrupt_handler,
> IRQF_DISABLED, "l3-dbg-irq", l3);
> if (ret) {
> -pr_crit("L3: request_irq failed to register for 0x%x\n",
> -l3->debug_irq);
> +dev_err(&pdev->dev, "request_irq failed for %d\n",
> +l3->debug_irq);
> return ret;
> }
>
> @@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device
> *pdev)
> ret = devm_request_irq(&pdev->dev, l3->app_irq,
> l3_interrupt_handler,
> IRQF_DISABLED, "l3-app-irq", l3);
> if (ret)
> -pr_crit("L3: request_irq failed to register for 0x%x\n",
> -l3->app_irq);
> +dev_err(&pdev->dev, "request_irq failed for %d\n",
> l3->app_irq);
>
> return ret;
> }
>
> >>> So this one change in the log level. If I look at now, may be dev_err
> >>> is fine but the change is not same.
> >>
> >> Not sure what you mean by 'the change is not same'?
> >> I just picked the old series and rebased it on linux-next, the patch is the
> >> same as it was back in May 2013:
> >> https://lkml.org/lkml/2013/5/2/205
> >>
> >> And yes, I have shortened the texts in the print, but the meaning of the
> >> prints have not changed.
> >
> > Santosh, got any more comments on this series?
> >
> Nope. looks good
OK probably best that Arnd or Olof picks these directly:
Acked-by: Tony Lindgren
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails
On Thursday 13 March 2014 01:28 AM, Tony Lindgren wrote:
> * Peter Ujfalusi [140304 23:14]:
>> On 03/04/2014 04:37 PM, Santosh Shilimkar wrote:
>>> On Tuesday 04 March 2014 08:48 PM, Peter Ujfalusi wrote:
Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)
Signed-off-by: Peter Ujfalusi
Reviewed-by: Santosh Shilimkar
---
drivers/bus/omap_l3_noc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 0eff48585ae3..972691a668a3 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, l3->debug_irq, l3_interrupt_handler,
IRQF_DISABLED, "l3-dbg-irq", l3);
if (ret) {
- pr_crit("L3: request_irq failed to register for 0x%x\n",
- l3->debug_irq);
+ dev_err(&pdev->dev, "request_irq failed for %d\n",
+ l3->debug_irq);
return ret;
}
@@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(&pdev->dev, l3->app_irq, l3_interrupt_handler,
IRQF_DISABLED, "l3-app-irq", l3);
if (ret)
- pr_crit("L3: request_irq failed to register for 0x%x\n",
- l3->app_irq);
+ dev_err(&pdev->dev, "request_irq failed for %d\n", l3->app_irq);
return ret;
}
>>> So this one change in the log level. If I look at now, may be dev_err
>>> is fine but the change is not same.
>>
>> Not sure what you mean by 'the change is not same'?
>> I just picked the old series and rebased it on linux-next, the patch is the
>> same as it was back in May 2013:
>> https://lkml.org/lkml/2013/5/2/205
>>
>> And yes, I have shortened the texts in the print, but the meaning of the
>> prints have not changed.
>
> Santosh, got any more comments on this series?
>
Nope. looks good
--
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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 03/12/2014 02:28 PM, Tony Lindgren wrote: > * Robert Nelson [140312 12:11]: >> On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon wrote: >>> On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon wrote: Hi, > From: Menon, Nishanth >> On 03/12/2014 05:49 AM, Pekon Gupta wrote: >> Beaglebone Board can be connected to expansion boards to add devices to >> them. >> These expansion boards are called 'capes'. This patch adds support for >> following versions of Beaglebone(AM335x) NAND capes >> (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, >> oob-size=64 >> (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, >> oob-size=224 >> Further information and datasheets can be found at [1] and [2] [...] >> [1] >> http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion >> [2] >> http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module >> >> Signed-off-by: Pekon Gupta >> --- >> arch/arm/boot/dts/am335x-bone.dts | 123 >> ++ >> 1 file changed, 123 insertions(+) >> >> diff --git a/arch/arm/boot/dts/am335x-bone.dts >> b/arch/arm/boot/dts/am335x-bone.dts >> index 94ee427..be2c572 100644 >> --- a/arch/arm/boot/dts/am335x-bone.dts >> +++ b/arch/arm/boot/dts/am335x-bone.dts > > better to make a nand_cape dts which includes the am335x-bone.dts? > Actually, I'm not in favor of having too many "xx_board_common.dts" files, because it un-necessarily complexes things. We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. And, there is no guarantee that Beaglebone-LT(white) will remain compatible to Beaglebone-black in future. Example: some capes are not compatible to beaglebone-black [1], [2]. So, I prefer to keep separate GPMC NAND nodes separately in both DTS, unless there is a strong convincing reason otherwise. [1] http://elinux.org/CircuitCo:BeagleBoardToys [2] http://elinux.org/BeagleBone_Black_Capes >>> >>> >>> >>> Right, and adding NAND, GPMC nodes and asking folks to uncomment >>> sections into a generic board file (which by default has none) makes >>> more sense? I dont use NAND capes or might create my own cape. overo >>> has the same challenges as bone family has.I dont see asking folks to >>> uncomment entries to use the cape is a nicer alternative to having >>> more dts entries. >> >> This is just going to get more messy with every cape addition. Should >> we maybe just leave a basic BeagleBone & BeagleBone Black dts file in >> mainline kernel.org. >> >> Then create a repo on github.com/beagleboard/ with every >> -.dts option? > > Or just include all devices on the most common capes but have their > status as disabled by default. > > For the pinctrl, we need to make sure the pins for a device are not > muxed if it's set to disabled state. You do have a bunch of "if you want nand, disable mmc2" configuration in the usage of cape configurations such as this patch, or in the case of [1] (audio cape), different regulator usage etc. Maintaining out of tree cape dts might be an option, but that is prone to maintenance burden as device tree conversion goes on (yeah, all the dt as ABI stuff aside). Keeping aside the subjective nature of what entitles a cape being a "common cape",even introducing nodes that belong to three or four different first level capes will definitely have it's own sets of problems. The ideal solution would be some folks pitching in on what Matt pointed in [2] - basically "upstream a resource manager on top of the basic overlay support that's in progress" and introduce capes as part of that overlay support once it is upstream. Failing which, keeping the base bone dts to basic stuff that bare board supports and having per "first level cape" dts which includes relevant dts sounds to me the only rationale and easily usable (as in: without much device tree knowledge) - again, I admit "easily" is subjective here. [1] https://lkml.org/lkml/2014/2/5/183 [2] https://lkml.org/lkml/2014/2/5/247 -- Regards, Nishanth Menon -- 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Robert Nelson [140312 12:11]: > On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon wrote: > > On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon wrote: > >> Hi, > >> > >>>From: Menon, Nishanth > On 03/12/2014 05:49 AM, Pekon Gupta wrote: > Beaglebone Board can be connected to expansion boards to add devices to > them. > These expansion boards are called 'capes'. This patch adds support for > following versions of Beaglebone(AM335x) NAND capes > (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, > oob-size=64 > (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, > oob-size=224 > Further information and datasheets can be found at [1] and [2] > >> [...] > [1] > http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion > [2] > http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module > > Signed-off-by: Pekon Gupta > --- > arch/arm/boot/dts/am335x-bone.dts | 123 > ++ > 1 file changed, 123 insertions(+) > > diff --git a/arch/arm/boot/dts/am335x-bone.dts > b/arch/arm/boot/dts/am335x-bone.dts > index 94ee427..be2c572 100644 > --- a/arch/arm/boot/dts/am335x-bone.dts > +++ b/arch/arm/boot/dts/am335x-bone.dts > >>> > >>>better to make a nand_cape dts which includes the am335x-bone.dts? > >>> > >> Actually, I'm not in favor of having too many "xx_board_common.dts" files, > >> because it un-necessarily complexes things. > >> > >> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just > >> saves > >> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. > >> And, there is no guarantee that Beaglebone-LT(white) will remain > >> compatible to > >> Beaglebone-black in future. > >> Example: some capes are not compatible to beaglebone-black [1], [2]. > >> > >> So, I prefer to keep separate GPMC NAND nodes separately in both DTS, > >> unless there is a strong convincing reason otherwise. > >> > >> > >> [1] http://elinux.org/CircuitCo:BeagleBoardToys > >> [2] http://elinux.org/BeagleBone_Black_Capes > > > > > > > > Right, and adding NAND, GPMC nodes and asking folks to uncomment > > sections into a generic board file (which by default has none) makes > > more sense? I dont use NAND capes or might create my own cape. overo > > has the same challenges as bone family has.I dont see asking folks to > > uncomment entries to use the cape is a nicer alternative to having > > more dts entries. > > This is just going to get more messy with every cape addition. Should > we maybe just leave a basic BeagleBone & BeagleBone Black dts file in > mainline kernel.org. > > Then create a repo on github.com/beagleboard/ with every > -.dts option? Or just include all devices on the most common capes but have their status as disabled by default. For the pinctrl, we need to make sure the pins for a device are not muxed if it's set to disabled state. Regards, Tony -- 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Wed, Mar 12, 2014 at 1:57 PM, Nishanth Menon wrote: > On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon wrote: >> Hi, >> >>>From: Menon, Nishanth On 03/12/2014 05:49 AM, Pekon Gupta wrote: Beaglebone Board can be connected to expansion boards to add devices to them. These expansion boards are called 'capes'. This patch adds support for following versions of Beaglebone(AM335x) NAND capes (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64 (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224 Further information and datasheets can be found at [1] and [2] >> [...] [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion [2] http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module Signed-off-by: Pekon Gupta --- arch/arm/boot/dts/am335x-bone.dts | 123 ++ 1 file changed, 123 insertions(+) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index 94ee427..be2c572 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts >>> >>>better to make a nand_cape dts which includes the am335x-bone.dts? >>> >> Actually, I'm not in favor of having too many "xx_board_common.dts" files, >> because it un-necessarily complexes things. >> >> We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves >> some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. >> And, there is no guarantee that Beaglebone-LT(white) will remain compatible >> to >> Beaglebone-black in future. >> Example: some capes are not compatible to beaglebone-black [1], [2]. >> >> So, I prefer to keep separate GPMC NAND nodes separately in both DTS, >> unless there is a strong convincing reason otherwise. >> >> >> [1] http://elinux.org/CircuitCo:BeagleBoardToys >> [2] http://elinux.org/BeagleBone_Black_Capes > > > > Right, and adding NAND, GPMC nodes and asking folks to uncomment > sections into a generic board file (which by default has none) makes > more sense? I dont use NAND capes or might create my own cape. overo > has the same challenges as bone family has.I dont see asking folks to > uncomment entries to use the cape is a nicer alternative to having > more dts entries. This is just going to get more messy with every cape addition. Should we maybe just leave a basic BeagleBone & BeagleBone Black dts file in mainline kernel.org. Then create a repo on github.com/beagleboard/ with every -.dts option? Regards, -- Robert Nelson http://www.rcn-ee.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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Wed, Mar 12, 2014 at 1:26 PM, Gupta, Pekon wrote: > Hi, > >>From: Menon, Nishanth >>>On 03/12/2014 05:49 AM, Pekon Gupta wrote: >>> Beaglebone Board can be connected to expansion boards to add devices to >>> them. >>> These expansion boards are called 'capes'. This patch adds support for >>> following versions of Beaglebone(AM335x) NAND capes >>> (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, >>> oob-size=64 >>> (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, >>> oob-size=224 >>> Further information and datasheets can be found at [1] and [2] > [...] >>> [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion >>> [2] >>> http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module >>> >>> Signed-off-by: Pekon Gupta >>> --- >>> arch/arm/boot/dts/am335x-bone.dts | 123 >>> ++ >>> 1 file changed, 123 insertions(+) >>> >>> diff --git a/arch/arm/boot/dts/am335x-bone.dts >>> b/arch/arm/boot/dts/am335x-bone.dts >>> index 94ee427..be2c572 100644 >>> --- a/arch/arm/boot/dts/am335x-bone.dts >>> +++ b/arch/arm/boot/dts/am335x-bone.dts >> >>better to make a nand_cape dts which includes the am335x-bone.dts? >> > Actually, I'm not in favor of having too many "xx_board_common.dts" files, > because it un-necessarily complexes things. > > We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves > some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. > And, there is no guarantee that Beaglebone-LT(white) will remain compatible to > Beaglebone-black in future. > Example: some capes are not compatible to beaglebone-black [1], [2]. > > So, I prefer to keep separate GPMC NAND nodes separately in both DTS, > unless there is a strong convincing reason otherwise. > > > [1] http://elinux.org/CircuitCo:BeagleBoardToys > [2] http://elinux.org/BeagleBone_Black_Capes Right, and adding NAND, GPMC nodes and asking folks to uncomment sections into a generic board file (which by default has none) makes more sense? I dont use NAND capes or might create my own cape. overo has the same challenges as bone family has.I dont see asking folks to uncomment entries to use the cape is a nicer alternative to having more dts entries. Regards, Nishanth Menon -- 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi, >From: Menon, Nishanth >>On 03/12/2014 05:49 AM, Pekon Gupta wrote: >> Beaglebone Board can be connected to expansion boards to add devices to them. >> These expansion boards are called 'capes'. This patch adds support for >> following versions of Beaglebone(AM335x) NAND capes >> (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64 >> (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, >> oob-size=224 >> Further information and datasheets can be found at [1] and [2] [...] >> [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion >> [2] >> http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module >> >> Signed-off-by: Pekon Gupta >> --- >> arch/arm/boot/dts/am335x-bone.dts | 123 >> ++ >> 1 file changed, 123 insertions(+) >> >> diff --git a/arch/arm/boot/dts/am335x-bone.dts >> b/arch/arm/boot/dts/am335x-bone.dts >> index 94ee427..be2c572 100644 >> --- a/arch/arm/boot/dts/am335x-bone.dts >> +++ b/arch/arm/boot/dts/am335x-bone.dts > >better to make a nand_cape dts which includes the am335x-bone.dts? > Actually, I'm not in favor of having too many "xx_board_common.dts" files, because it un-necessarily complexes things. We already have "arch/arm/boot/dts/am335x-bone-common.dtsi" which just saves some lines common to DTS of both Beaglebone-LT(white) and Beaglebone-Black. And, there is no guarantee that Beaglebone-LT(white) will remain compatible to Beaglebone-black in future. Example: some capes are not compatible to beaglebone-black [1], [2]. So, I prefer to keep separate GPMC NAND nodes separately in both DTS, unless there is a strong convincing reason otherwise. [1] http://elinux.org/CircuitCo:BeagleBoardToys [2] http://elinux.org/BeagleBone_Black_Capes with regards, pekon -- 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 v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
>From: Menon, Nishanth >>On 03/12/2014 05:49 AM, Pekon Gupta wrote: >> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on >> am437x-gp-evm board. >> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either >> eMMC or NAND can be enabled. Selection between eMMC and NAND is >> controlled: >> (a) By dynamically driving following GPIO pin from software >> SPI2_CS0(GPIO) == 0 NAND is selected (default) >> SPI2_CS0(GPIO) == 1 eMMC is selected >> (b) By statically using Jumper (J89) on the board >> >> (2) As NAND device connnected to this board has page-size=4K and >> oob-size=224, >> So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for >> NAND boot. >> >> Signed-off-by: Pekon Gupta >> --- >> arch/arm/boot/dts/am437x-gp-evm.dts | 107 >> >> 1 file changed, 107 insertions(+) >> >> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts >> b/arch/arm/boot/dts/am437x-gp-evm.dts >> index df8798e..0027ea7 100644 >> --- a/arch/arm/boot/dts/am437x-gp-evm.dts >> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts > >which branch does this apply on? I assume you mean this for Tony's >omap-for-v3.15/dt branch? it would be nice if you'd make that clear in >cover letter. > Sorry, I missed that. I'll keep a note of this next time. Yes, this patch series is rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap-for-v3.15/dt with regards, pekon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add USB nodes for am43xx epos and gp evm
* George Cherian [140311 22:02]: > Hi Tony, > > On 3/7/2014 5:26 PM, George Cherian wrote: > >The patch series adds USB dt nodes for am43xx epos and gp evm > > > >Boot tested with Benoit's for_3.15 + following patches > > > >https://patchwork.kernel.org/patch/3600821/ > >https://patchwork.kernel.org/patch/3600831/ > >https://patchwork.kernel.org/patch/3600851/ > >https://patchwork.kernel.org/patch/3600841/ > > > > > >Changes from v1 -> v2 > > * Reorder "doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue" > > * Address v1 coments on "ARM: dts: AM4372: Add USB nodes" > > > >Changes from v2 -> v3 > > * Removed unwanted dwc3_1 and dwc3_2 nodes from am437x-gp-evm.dts > > and am43x-epos-evm.dts > > > >George Cherian (5): > > doc: Add "ti,am437x-dwc3" comaptible for dwc3 glue > > ARM: dts: am43xx clock data > > ARM: dts: AM4372: Add USB nodes > > ARM: dts: am437x-gp-evm: Enable USB > > ARM: dts: am43x-epos-evm: Enable USB > > > > Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +- > > arch/arm/boot/dts/am4372.dtsi | 95 > > ++ > > arch/arm/boot/dts/am437x-gp-evm.dts| 18 > > arch/arm/boot/dts/am43x-epos-evm.dts | 18 > > arch/arm/boot/dts/am43xx-clocks.dtsi | 17 > > 5 files changed, 151 insertions(+), 1 deletion(-) > Can you please take this series. > The whole series Reviewed-by: Roger Quadros Hmm I only see ack from Roger on patch 3? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/8] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods
* Roger Quadros [140307 02:18]:
> From: Keshava Munegowda
>
> Create hwmods for ocp2scp3 and sata modules.
Paul, does this look OK to you?
Regards,
Tony
> [Roger Q] Clean up.
>
> CC: Benoit Cousson
> CC: Paul Walmsley
> CC: Tony Lindgren
> Signed-off-by: Balaji T K
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73
> ++
> 1 file changed, 73 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> index e297d62..227a69f 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -1726,6 +1726,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
> },
> };
>
> +/*
> + * 'ocp2scp' class
> + * bridge to transform ocp interface protocol to scp (serial control port)
> + * protocol
> + */
> +/* ocp2scp3 */
> +static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
> +/* l4_cfg -> ocp2scp3 */
> +static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
> + .master = &omap54xx_l4_cfg_hwmod,
> + .slave = &omap54xx_ocp2scp3_hwmod,
> + .clk= "l4_root_clk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
> + .name = "ocp2scp3",
> + .class = &omap54xx_ocp2scp_hwmod_class,
> + .clkdm_name = "l3init_clkdm",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs =
> OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
> + .context_offs =
> OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
> + },
> + },
> +};
> +
> +/*
> + * 'sata' class
> + * sata: serial ata interface gen2 compliant ( 1 rx/ 1 tx)
> + */
> +
> +static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
> + .sysc_offs = 0x,
> + .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
> +MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> + .sysc_fields= &omap_hwmod_sysc_type2,
> +};
> +
> +static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
> + .name = "sata",
> + .sysc = &omap54xx_sata_sysc,
> +};
> +
> +/* sata */
> +static struct omap_hwmod omap54xx_sata_hwmod = {
> + .name = "sata",
> + .class = &omap54xx_sata_hwmod_class,
> + .clkdm_name = "l3init_clkdm",
> + .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> + .main_clk = "func_48m_fclk",
> + .mpu_rt_idx = 1,
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
> + .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +/* l4_cfg -> sata */
> +static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
> + .master = &omap54xx_l4_cfg_hwmod,
> + .slave = &omap54xx_sata_hwmod,
> + .clk= "l3_iclk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
>
> /*
> * Interfaces
> @@ -2399,6 +2470,8 @@ static struct omap_hwmod_ocp_if
> *omap54xx_hwmod_ocp_ifs[] __initdata = {
> &omap54xx_l4_cfg__usb_tll_hs,
> &omap54xx_l4_cfg__usb_otg_ss,
> &omap54xx_l4_wkup__wd_timer2,
> + &omap54xx_l4_cfg__ocp2scp3,
> + &omap54xx_l4_cfg__sata,
> NULL,
> };
>
> --
> 1.8.3.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap: cm-t3530: Add MMC2/SDIO/WLAN support
* Stefan Roese [140312 03:52]:
> Add support for the MMC2/SDIO WiFi Libertas (Marvell) module available
> on the CM-T3530 SOM.
>
> Signed-off-by: Stefan Roese
> Cc: Dmitry Lifshitz
> Cc: Igor Grinberg
> Cc: Tony Lindgren
> ---
> This patch is based on current mainline (v3.14-rc6) plus this compulab patch
> series from Dmitry:
>
> [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
> http://www.spinics.net/lists/arm-kernel/msg300078.html
Thanks applying into omap-for-v3.15/dt, no guarantees it gets merged though
as it's getting so close to the merge window.
Regards,
Tony
> arch/arm/boot/dts/omap3-cm-t3530.dts | 36
>
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
> b/arch/arm/boot/dts/omap3-cm-t3530.dts
> index 9faf1cd..d145849 100644
> --- a/arch/arm/boot/dts/omap3-cm-t3530.dts
> +++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
> @@ -9,4 +9,40 @@
> / {
> model = "CompuLab CM-T3530";
> compatible = "compulab,omap3-cm-t3530", "ti,omap34xx", "ti,omap3";
> +
> + /* Regulator to trigger the reset signal of the Wifi module */
> + mmc2_sdio_reset: regulator-mmc2-sdio-reset {
> + compatible = "regulator-fixed";
> + regulator-name = "regulator-mmc2-sdio-reset";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&twl_gpio 2 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +};
> +
> +&omap3_pmx_core {
> + mmc2_pins: pinmux_mmc2_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
> /* sdmmc2_clk.sdmmc2_clk */
> + OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
> /* sdmmc2_cmd.sdmmc2_cmd */
> + OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0)
> /* sdmmc2_dat0.sdmmc2_dat0 */
> + OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0)
> /* sdmmc2_dat1.sdmmc2_dat1 */
> + OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0)
> /* sdmmc2_dat2.sdmmc2_dat2 */
> + OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0)
> /* sdmmc2_dat3.sdmmc2_dat3 */
> + OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1)
> /* sdmmc2_dat4.sdmmc2_dir_dat0 */
> + OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1)
> /* sdmmc2_dat5.sdmmc2_dir_dat1 */
> + OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1)
> /* sdmmc2_dat6.sdmmc2_dir_cmd */
> + OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)
> /* sdmmc2_dat7.sdmmc2_clkin */
> + >;
> + };
> +};
> +
> +&mmc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_pins>;
> + vmmc-supply = <&mmc2_sdio_reset>;
> + non-removable;
> + bus-width = <4>;
> + cap-power-off-card;
> };
> --
> 1.8.5.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am335x-evmsk: enable DMA controller for USB
* yegorsli...@googlemail.com [140310 08:30]:
> From: Yegor Yefremov
>
> Signed-off-by: Yegor Yefremov
> ---
> arch/arm/boot/dts/am335x-evmsk.dts |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
> b/arch/arm/boot/dts/am335x-evmsk.dts
> index fa19271..ec08f6f 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -384,6 +384,10 @@
> status = "okay";
> dr_mode = "host";
> };
> +
> + dma-controller@07402000 {
> + status = "okay";
> + };
> };
>
> &epwmss2 {
Thanks applying into omap-for-v.15/dt with the subject line as
the description also. No guarantees this will get merged as we're
so close to the merge window already.
Regards,
Tony
--
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] dma: omap-dma: Implement device_slave_caps callback
* Peter Ujfalusi [140307 05:39]:
> With the callback implemented omap-dma can provide information to client
> drivers regarding to supported address widths, directions, residue
> granularity, etc.
This may need some testing against linux next with Russell's
omap-dma.c clean-up series merged there. Peter, care to check
if this patch is still valid against linux next?
Regards,
Tony
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/dma/omap-dma.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 64ceca2920b8..b19f04f4390b 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -1088,6 +1088,23 @@ static void omap_dma_free(struct omap_dmadev *od)
> }
> }
>
> +#define OMAP_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
> +
> +static int omap_dma_device_slave_caps(struct dma_chan *dchan,
> + struct dma_slave_caps *caps)
> +{
> + caps->src_addr_widths = OMAP_DMA_BUSWIDTHS;
> + caps->dstn_addr_widths = OMAP_DMA_BUSWIDTHS;
> + caps->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
> + caps->cmd_pause = true;
> + caps->cmd_terminate = true;
> + caps->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
> +
> + return 0;
> +}
> +
> static int omap_dma_probe(struct platform_device *pdev)
> {
> struct omap_dmadev *od;
> @@ -1118,6 +1135,7 @@ static int omap_dma_probe(struct platform_device *pdev)
> od->ddev.device_prep_slave_sg = omap_dma_prep_slave_sg;
> od->ddev.device_prep_dma_cyclic = omap_dma_prep_dma_cyclic;
> od->ddev.device_control = omap_dma_control;
> + od->ddev.device_slave_caps = omap_dma_device_slave_caps;
> od->ddev.dev = &pdev->dev;
> INIT_LIST_HEAD(&od->ddev.channels);
> INIT_LIST_HEAD(&od->pending);
> --
> 1.9.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/2] arm: dts: dra7: Add qspi device.
* Sourav Poddar [140310 04:54]: > These add device tree entry for qspi controller driver on dra7-evm. It seems that we need to wait for the crossbar dependencies to get cleared in the mainline kernel before we can apply this as otherwise the interrupts will be wrong in omap-for-v3.15/dt branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] arch/arm OMAP IOMMU patches for 3.15
* Suman Anna [140312 10:25]: > On 03/12/2014 12:04 PM, Tony Lindgren wrote: > > > >For the pdata-quirks.c changes, I assume you are working on > >implementing the reset driver mentioned in the related patch? > > > > Dan Murphy is currently working on this, and there is still some > work to be done before it can be posted to the lists. OK thanks for the update, good to hear. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails
* Peter Ujfalusi [140304 23:14]:
> On 03/04/2014 04:37 PM, Santosh Shilimkar wrote:
> > On Tuesday 04 March 2014 08:48 PM, Peter Ujfalusi wrote:
> >> Use dev_err() which will going to print the driver's name as well and the
> >> KERN_ERR level is sufficient in this case (we also print via dev_err when
> >> there is an error with the mem resources)
> >>
> >> Signed-off-by: Peter Ujfalusi
> >> Reviewed-by: Santosh Shilimkar
> >> ---
> >> drivers/bus/omap_l3_noc.c | 7 +++
> >> 1 file changed, 3 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
> >> index 0eff48585ae3..972691a668a3 100644
> >> --- a/drivers/bus/omap_l3_noc.c
> >> +++ b/drivers/bus/omap_l3_noc.c
> >> @@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
> >>ret = devm_request_irq(&pdev->dev, l3->debug_irq, l3_interrupt_handler,
> >> IRQF_DISABLED, "l3-dbg-irq", l3);
> >>if (ret) {
> >> - pr_crit("L3: request_irq failed to register for 0x%x\n",
> >> - l3->debug_irq);
> >> + dev_err(&pdev->dev, "request_irq failed for %d\n",
> >> + l3->debug_irq);
> >>return ret;
> >>}
> >>
> >> @@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
> >>ret = devm_request_irq(&pdev->dev, l3->app_irq, l3_interrupt_handler,
> >> IRQF_DISABLED, "l3-app-irq", l3);
> >>if (ret)
> >> - pr_crit("L3: request_irq failed to register for 0x%x\n",
> >> - l3->app_irq);
> >> + dev_err(&pdev->dev, "request_irq failed for %d\n", l3->app_irq);
> >>
> >>return ret;
> >> }
> >>
> > So this one change in the log level. If I look at now, may be dev_err
> > is fine but the change is not same.
>
> Not sure what you mean by 'the change is not same'?
> I just picked the old series and rebased it on linux-next, the patch is the
> same as it was back in May 2013:
> https://lkml.org/lkml/2013/5/2/205
>
> And yes, I have shortened the texts in the print, but the meaning of the
> prints have not changed.
Santosh, got any more comments on this series?
Regards,
Tony
> > Apart from above comment, rest of the series looks fine to me.
> > Feel free to add my ack...
>
> Thanks.
>
> --
> Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] ARM: dts: overo: Add new expansion boards
* Florian Vaussard [140311 05:24]: > Hi, > > This series adds the support for 5 new expansion boards from Gumstix: > - Palo43 > - Gallop43 > - Chestnut43 > - Alto35 > - Summit > > The 1st patch is a preparatory work, in order to factorize some > peripherals that are common to most Gumstix expansion boards. Patch 2 > adds the support for an accelerometer that is present on most boards. > > Palo43, Gallop43 and Chestnut43 are all pretty similar. I tested > on a Gallop43 (with both OMAP35xx and OMAP36xx Overo). > > Alto35 is slightly different. Again, I tested with both OMAP35xx and > OMAP36xx Overo. > > Summit is pretty similar to Tobi. I do not have a Summit at hand, > but given the similarity with Tobi, it should work fine. > > To avoid unnecessary duplications, I put all the common stuff for each > board inside an omap3-overo-xxx-common.dsti include file. By doing so, > I can have minimal SoC-specific omap3-overo-xxx.dts (omap34xx based) > and omap3-overo-storm-xxx.dts (omap36xx based) device trees. > > This series depends on my previous Overo series [1]. A complete testing > tree (including the graphics support, soon to be posted) is available > at [2]. Thanks, applying the whole series into omap-for-v3.15/dt-overo. As it's this close to the merge window, no guarantees anything will get pulled in though. Regards, Tony > [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/111558 > [2] https://github.com/vaussard/linux.git (overo/for-3.15/review1) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] arch/arm OMAP IOMMU patches for 3.15
On 03/12/2014 12:04 PM, Tony Lindgren wrote: * Suman Anna [140311 14:52]: Hi Paul, On 03/05/2014 06:24 PM, Suman Anna wrote: Hi Paul, Benoit, This is a repost as per Tony's request [3] of all the OMAP IOMMU DT support patches that are under arch/arm. The series just assimilates patches 8 through 13 from the v3 OMAP IOMMU DT adaptation for 3.15 series [1], and all the v2 patches from the OMAP IOMMU DTS nodes [2]. The only change made with respect to the patches above is in the OMAP4 and OMAP5 DTS nodes - I have adjusted the reg sizes from 0xff to 0x100. Can you please provide your acks on the hwmod patches and DTS patches? Ping. Can you review and provide your acks for Patches 2 and 5 (the hwmod patches) for Tony to pick up all the patches in the series? Applied all with Paul's acks into omap-for-v3.15/dt. As it's getting so late to the merge window, no guarantees it will actually get pulled. Thanks Tony. For the pdata-quirks.c changes, I assume you are working on implementing the reset driver mentioned in the related patch? Dan Murphy is currently working on this, and there is still some work to be done before it can be posted to the lists. regards Suman -- 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 v4 5/9] ARM: dts: omap3-overo: Add HSUSB PHY
* Roger Quadros [140311 02:46]: > > Any sane design would maintain register offsets but it doesn't seem so with > omap34xx vs omap36xx. So my assumption was wrong. > > I'll ack this patch. OK thanks, I'll apply the whole series with your ack to omap-for-v3.15/dt-overo. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] arch/arm OMAP IOMMU patches for 3.15
* Suman Anna [140311 14:52]: > Hi Paul, > > On 03/05/2014 06:24 PM, Suman Anna wrote: > >Hi Paul, Benoit, > > > >This is a repost as per Tony's request [3] of all the OMAP IOMMU DT support > >patches that are under arch/arm. The series just assimilates patches 8 > >through 13 from the v3 OMAP IOMMU DT adaptation for 3.15 series [1], and > >all the v2 patches from the OMAP IOMMU DTS nodes [2]. > > > >The only change made with respect to the patches above is in the OMAP4 > >and OMAP5 DTS nodes - I have adjusted the reg sizes from 0xff to 0x100. > > > >Can you please provide your acks on the hwmod patches and DTS > >patches? > > Ping. Can you review and provide your acks for Patches 2 and 5 (the > hwmod patches) for Tony to pick up all the patches in the series? Applied all with Paul's acks into omap-for-v3.15/dt. As it's getting so late to the merge window, no guarantees it will actually get pulled. For the pdata-quirks.c changes, I assume you are working on implementing the reset driver mentioned in the related patch? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] base: platform: add generic clock handling for platform-bus
Hi Felipe,
(CC'ing Geert Uytterhoeven as we happen to discuss runtime PM and clock
handling for the Renesas SoCs at the moment)
Thank you for the patch. This is a bit of a late reply, but that's better than
no reply I suppose. Please see below for a small comment.
On Friday 31 January 2014 12:12:45 Felipe Balbi wrote:
> Still TODO a commit log. Not for merging!
>
> NYET-Signed-off-by: Felipe Balbi
> ---
>
> This patch is an idea I've had recently in order to combine several
> different PM implementations into the platform-bus.
>
> This patch is bare minimum for platforms which need to handle functional and
> interface clocks but the whole thing is made optional.
>
> Note that this patch makes sure that by the time a platform_driver's probe
> is called, we already have clocks enabled and pm_runtime_set_active() has
> been called, thus making sure that a device driver's pm_runtime_get_sync()
> will solely increase the pm usage counter.
>
> I have *NOT* tested this anywhere *YET*, but I suppose it shouldn't cause
> any issues since the clock API has ref counting too.
>
> Would really like to get some review from several folks involved with ARM
> SoC PM so that's the reason for the wide audience. If I have missed
> anybody, please add them to Cc.
>
> As mentioned above, this is *NOT* meant for merging, but serves as a
> starting point for discussing some convergence of several PM domain
> implementations on different arch/arm/mach-* directories.
>
> For OMAP, this has the added benefit of removing clock handling from
> omap_device/omap_hwmod and, thus, dropping the need for so many DT_CLK()
> tables under drivers/clk/ti/
>
> drivers/base/platform.c | 169 +++--
> include/linux/platform_device.h | 9 +++
> 2 files changed, 173 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 3a94b79..86aeb5b 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -484,6 +484,21 @@ static int platform_drv_probe(struct device *_dev)
> if (ACPI_HANDLE(_dev))
> acpi_dev_pm_attach(_dev, true);
>
> + dev->fck = devm_clk_get(_dev, "fck");
> + dev->ick = devm_clk_get(_dev, "ick");
My concern with this that some devices might want to handle their functional
and interface clocks manually if they have exotic requirements. They would
thus need a way to signal that the platform bus core should not try to perform
clock management on its own.
One possible way would be to name the clocks differently for those devices,
but we might then have a backward compatibility issue with DT.
Another concern is how to handle the DT backward compatibility for devices
that would benefit from core management of their functional and interface
clocks, but that currently don't name those clocks "fck" and "ick". Renaming
those clocks in DT wouldn't be a problem for the future, but backward
compatibility needs to be handled. Maybe platforms could provide aliases in
that case.
> + if (!IS_ERR(dev->fck))
> + clk_prepare_enable(dev->fck);
> + else
> + dev->fck = NULL;
> +
> + if (!IS_ERR(dev->ick))
> + clk_prepare_enable(dev->ick);
> + else
> + dev->ick = NULL;
> +
> + pm_runtime_set_active(_dev);
> +
> ret = drv->probe(dev);
> if (ret && ACPI_HANDLE(_dev))
> acpi_dev_pm_detach(_dev, true);
> @@ -507,6 +522,14 @@ static int platform_drv_remove(struct device *_dev)
> struct platform_device *dev = to_platform_device(_dev);
> int ret;
>
> + if (!IS_ERR(dev->ick))
> + clk_disable_unprepare(dev->ick);
> +
> + if (!IS_ERR(dev->fck))
> + clk_disable_unprepare(dev->fck);
> +
> + pm_runtime_set_suspended(_dev);
> +
> ret = drv->remove(dev);
> if (ACPI_HANDLE(_dev))
> acpi_dev_pm_detach(_dev, true);
> @@ -780,6 +803,59 @@ static int platform_legacy_resume(struct device *dev)
>
> #endif /* CONFIG_PM_SLEEP */
>
> +#ifdef CONFIG_PM_RUNTIME
> +int platform_pm_runtime_suspend(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + struct platform_driver *pdrv = to_platform_driver(drv);
> + struct platform_device *pdev = to_platform_device(dev);
> + int ret;
> +
> + ret = pm_generic_runtime_suspend(dev);
> + if (ret)
> + return ret;
> +
> + if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_ICK, &pdrv->flags))
> + clk_disable(pdev->ick);
> +
> + if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_FCK, &pdrv->flags))
> + clk_disable(pdev->fck);
> +
> + return ret;
> +}
> +
> +int platform_pm_runtime_resume(struct device *dev)
> +{
> + struct device_driver *drv = dev->driver;
> + struct platform_driver *pdrv = to_platform_driver(drv);
> + struct platform_device *pdev = to_platform_device(dev);
> + int ret;
> +
> + if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_IC
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hello, Suman, Florian, any opinion regarding this patch series ? Your opinion on the architecture-related question below would be appreciated as well, but I'd like to get this merged first (and especially patch 5/5) in the not too distant future to push OMAP3 ISP patches that depend on it. On Saturday 08 March 2014 01:46:09 Laurent Pinchart wrote: > Hello, > > This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found > when trying to port the OMAP3 ISP away from omap-iovmm to the ARM DMA API. > The biggest issue is fixed by patch 5/5, while the other patches fix > smaller problems that I've noticed when reading the code, without > experiencing them at runtime. > > I'd like to take this as an opportunity to discuss OMAP IOMMU integration > with the ARM DMA mapping implementation. The idea is to hide the IOMMU > completely behind the DMA mapping API, making it completely transparent to > drivers. > > A drivers will only need to allocate memory with dma_alloc_*, and behind the > scene the ARM DMA mapping implementation will find out that the device is > behind an IOMMU and will map the buffers through the IOMMU, returning an > I/O VA address to the driver. No direct call to the OMAP IOMMU driver or to > the IOMMU core should be necessary anymore. > > To use the IOMMU the ARM DMA implementation requires a VA mapping to be > created with a call to arm_iommu_create_mapping() and to then be attached to > the device with arm_iommu_attach_device(). This is currently not performed > by the OMAP IOMMU driver, I have thus added that code to the OMAP3 ISP > driver for now. I believe this to still be an improvement compared to the > current situation, as it allows getting rid of custom memory allocation > code in the OMAP3 ISP driver and custom I/O VA space management in > omap-iovmm. However, that code should ideally be removed from the driver. > The question is, where should it be moved to ? > > One possible solution would be to add the code to the OMAP IOMMU driver. > However, this would require all OMAP IOMMU users to be converted to the ARM > DMA API. I assume there would be issues that I don't foresee though. > > I'm not even sure whether the OMAP IOMMU driver would be the best place to > put that code. Ideally VA spaces should be created by the platform somehow, > and mapping of devices to IOMMUs should be handled by the IOMMU core > instead of the IOMMU drivers. We're not there yet, and the path might not > be straightforward, hence this attempt to start a constructive discussion. > > A second completely unrelated problem that I'd like to get feedback on is > the suspend/resume support in the OMAP IOMMU driver, or rather the lack > thereof. The driver exports omap_iommu_save_ctx() and > omap_iommu_restore_ctx() functions and expects the IOMMU users to call them > directly. This is really hackish to say the least. A proper suspend/resume > implementation shouldn't be difficult to implement, and I'm wondering > whether the lack of proper power management support comes from historical > reasons only, or if there are problems I might not have considered. > > Last but not least, the patches are available at > > git://linuxtv.org/pinchartl/media.git omap3isp/dma > > along with a patch series that ports the OMAP3 ISP driver to the DMA API. I > will submit that one for review once the IOMMU patches get accepted and > after fixing a couple of remaining bugs (I'm aware that I have broken > userspace PFNMAP buffers). > > Laurent Pinchart (5): > iommu/omap: Use the cache cleaning API > iommu/omap: Fix 'no page for' debug message in flush_iotlb_page() > iommu/omap: Flush the TLB only after updating translation table > entries > iommu/omap: Remove comment about supporting single page mappings only > iommu/omap: Fix map protection value handling > > drivers/iommu/omap-iommu.c | 68 +-- > 1 file changed, 23 insertions(+), 45 deletions(-) -- Regards, Laurent Pinchart -- 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 05/10] ARM: OMAP5: hwmod data: add mmu data for ipu & dsp
On Wed, 5 Mar 2014, Suman Anna wrote: > A new MMU hwmod class and data structures are created > to represent the MMUs within the IPU and DSP processor > subsystems in OMAP5. The MMUs in OMAP5 are identical to > those in OMAP4. > > Cc: Paul Walmsley > Cc: Benoit Cousson > Signed-off-by: Suman Anna Acked-by: Paul Walmsley - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] ARM: OMAP3: fix iva mmu programming issues
On Wed, 5 Mar 2014, Suman Anna wrote: > The IVA MMU is not functional when used through the hwmod and > omap_device layers. Add fixes to clockdomain and hwmod data > to have it functional. The hwmod changes are needed to enable > the clock, and the SWSUP change is needed to wakeup the domain > because the power domain is programmed to be in RET, and there > is no automatic power domain switching to ON. > > Cc: Paul Walmsley > Signed-off-by: Suman Anna Acked-by: Paul Walmsley - Paul -- 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: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver
On Fri, Mar 7, 2014 at 6:29 AM, Jenny TC wrote:
> +enum psy_charger_cable_type {
> + PSY_CHARGER_CABLE_TYPE_NONE = 0,
> + PSY_CHARGER_CABLE_TYPE_USB_SDP = 1 << 0,
> + PSY_CHARGER_CABLE_TYPE_USB_DCP = 1 << 1,
> + PSY_CHARGER_CABLE_TYPE_USB_CDP = 1 << 2,
> + PSY_CHARGER_CABLE_TYPE_USB_ACA = 1 << 3,
> + PSY_CHARGER_CABLE_TYPE_AC = 1 << 4,
> + PSY_CHARGER_CABLE_TYPE_ACA_DOCK = 1 << 5,
> + PSY_CHARGER_CABLE_TYPE_ACA_A = 1 << 6,
> + PSY_CHARGER_CABLE_TYPE_ACA_B = 1 << 7,
> + PSY_CHARGER_CABLE_TYPE_ACA_C = 1 << 8,
> + PSY_CHARGER_CABLE_TYPE_SE1 = 1 << 9,
> + PSY_CHARGER_CABLE_TYPE_MHL = 1 << 10,
> + PSY_CHARGER_CABLE_TYPE_B_DEVICE = 1 << 11,
> +};
I still disagree with using an enum as bitfield.
Atleast
#include
and use BIT(0), BIT(1) etc to define the bits.
Yours,
Linus Walleij
--
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 v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
> am437x-gp-evm board.
> (1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
> eMMC or NAND can be enabled. Selection between eMMC and NAND is
> controlled:
> (a) By dynamically driving following GPIO pin from software
> SPI2_CS0(GPIO) == 0 NAND is selected (default)
> SPI2_CS0(GPIO) == 1 eMMC is selected
> (b) By statically using Jumper (J89) on the board
>
> (2) As NAND device connnected to this board has page-size=4K and oob-size=224,
> So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
> NAND boot.
>
> Signed-off-by: Pekon Gupta
> ---
> arch/arm/boot/dts/am437x-gp-evm.dts | 107
>
> 1 file changed, 107 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
> b/arch/arm/boot/dts/am437x-gp-evm.dts
> index df8798e..0027ea7 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
which branch does this apply on? I assume you mean this for Tony's
omap-for-v3.15/dt branch? it would be nice if you'd make that clear in
cover letter.
> @@ -81,6 +81,27 @@
> 0x164 MUX_MODE0 /*
> eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
> >;
> };
> +
> + nand_flash_x8: nand_flash_x8 {
> + pinctrl-single,pins = <
> + 0x26C(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
> spi2_cs0.gpio/eMMCorNANDsel */
> + 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
> + 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
> + 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
> + 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
> + 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
> + 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
> + 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
> + 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
> + 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
> gpmc_wait0.gpmc_wait0 */
> + 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
> gpmc_wpn.gpmc_wpn */
> + 0x7c (PIN_OUTPUT | MUX_MODE0) /*
> gpmc_csn0.gpmc_csn0 */
> + 0x90 (PIN_OUTPUT | MUX_MODE0) /*
> gpmc_advn_ale.gpmc_advn_ale */
> + 0x94 (PIN_OUTPUT | MUX_MODE0) /*
> gpmc_oen_ren.gpmc_oen_ren */
> + 0x98 (PIN_OUTPUT | MUX_MODE0) /*
> gpmc_wen.gpmc_wen */
> + 0x9c (PIN_OUTPUT | MUX_MODE0) /*
> gpmc_be0n_cle.gpmc_be0n_cle */
> + >;
> + };
> };
>
> &i2c0 {
> @@ -125,3 +146,89 @@
> pinctrl-0 = <&mmc1_pins>;
> cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> };
> +
> +&elm {
> + status = "okay";
> +};
> +
> +&gpmc {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_flash_x8>;
> + ranges = <0 0 0x0800 0x1000>; /* CS0: NAND */
> + nand@0,0 {
> + reg = <0 0 0>; /* CS0, offset 0 */
> + ti,nand-ecc-opt = "bch8";
> + ti,elm-id = <&elm>;
> + nand-bus-width = <8>;
> + gpmc,device-width = <1>;
> + gpmc,sync-clk-ps = <0>;
> + gpmc,cs-on-ns = <0>;
> + gpmc,cs-rd-off-ns = <40>;
> + gpmc,cs-wr-off-ns = <40>;
> + gpmc,adv-on-ns = <0>;
> + gpmc,adv-rd-off-ns = <25>;
> + gpmc,adv-wr-off-ns = <25>;
> + gpmc,we-on-ns = <0>;
> + gpmc,we-off-ns = <20>;
> + gpmc,oe-on-ns = <3>;
> + gpmc,oe-off-ns = <30>;
> + gpmc,access-ns = <30>;
> + gpmc,rd-cycle-ns = <40>;
> + gpmc,wr-cycle-ns = <40>;
> + gpmc,wait-on-read = "true";
> + gpmc,wait-on-write = "true";
> + gpmc,bus-turnaround-ns = <0>;
> + gpmc,cycle2cycle-delay-ns = <0>;
> + gpmc,clk-activation-ns = <0>;
> + gpmc,wait-monitoring-ns = <0>;
> + gpmc,wr-access-ns = <40>;
> + gpmc,wr-data-mux-bus-ns = <0>;
> + /* MTD partition table */
> + /* All SPL-* partitions are sized to minimal length
> + * which can be independently programmable. For
> + * NAND flash this is equal to size of erase-block */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "NAND.SPL";
> + reg = <0x 0x0004>;
> + };
> + partition@1 {
> + label = "NAND.SPL.backup1";
> + reg = <
Re: [PATCH 2/4] power_supply: Introduce generic psy charging driver
On Fri, Mar 7, 2014 at 9:10 PM, Pavel Machek wrote: > On Fri 2014-03-07 11:04:59, Linus Walleij wrote: >> On Fri, Feb 28, 2014 at 6:01 PM, Pavel Machek wrote: >> > On Thu 2014-02-27 21:08:01, Linus Walleij wrote: >> >> On Thu, Feb 20, 2014 at 6:53 AM, Jenny TC wrote: >> >> >> >> > +++ b/include/linux/power/power_supply_charger.h >> >> >> >> > +#define MAX_CUR_VOLT_SAMPLES 3 >> >> > +#define DEF_CUR_VOLT_SAMPLE_JIFF (30*HZ) >> >> >> >> Why are things defined in Jiffies like this insead of seconds, >> >> milliseconds >> >> etc? This will vary with the current operating frequency of the system, >> >> why should physical measurements do that? >> > >> > It is actually ok. The define is relative to jiffies, and that's what >> > interface expects. >> >> So consider the option that the interface is wrong. >> >> Stating something like a sample period in system-specific jiffies >> instead of period time T is just weird. What control systems >> guy would understand this? > > 30*HZ means 30 seconds in the kernel... what is hard to understand > about it? Well I might be picky, but since it is a charging algorithm dealing with ampères, volts, constant-current/constant-voltage, watchdogs and timeouts, all stated in SI units, it would be nice if all such constants were specified in simple units instead of kernel-specific terms. One reason is that this kind of code actually needs review from non-programmers, people like chemists and physicists. I know it may be far fetched so no strong preference for sure. Yours, Linus Walleij -- 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On 03/12/2014 05:49 AM, Pekon Gupta wrote:
> Beaglebone Board can be connected to expansion boards to add devices to them.
> These expansion boards are called 'capes'. This patch adds support for
> following versions of Beaglebone(AM335x) NAND capes
> (a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
> (b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
> Further information and datasheets can be found at [1] and [2]
>
> * How to boot from NAND using Memory Expander + NAND Cape ? *
> - Important: As BOOTSEL values are sampled only at POR, so after changing any
>setting on SW2 (DIP switch), disconnect and reconnect all board power
> supply
>(including mini-USB console port) to POR the beaglebone.
>
> - Selection of ECC scheme
> for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
> for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
>
> - Selction of boot modes can be controlled via DIP switch(SW2) present on
>Memory Expander cape.
>SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART ->
> USB
>SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
>So to flash NAND, first boot via MMC or other sources and then switch to
>SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
>
> - For NAND boot following switch settings need to be followed
>SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
>SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
>SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
>SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
>SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
>SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
>SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
>SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
>SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
>
> [1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
> [2]
> http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
>
> Signed-off-by: Pekon Gupta
> ---
> arch/arm/boot/dts/am335x-bone.dts | 123
> ++
> 1 file changed, 123 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index 94ee427..be2c572 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
better to make a nand_cape dts which includes the am335x-bone.dts?
> @@ -10,6 +10,36 @@
> #include "am33xx.dtsi"
> #include "am335x-bone-common.dtsi"
>
> +&am33xx_pinmux {
> + nand_flash_x16: nand_flash_x16 {
> + pinctrl-single,pins = <
> + 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
> + 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
> + 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
> + 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
> + 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
> + 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
> + 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
> + 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
> + 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
> + 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
> + 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
> */
> + 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
> */
> + 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
> */
> + 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13
> */
> + 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14
> */
> + 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15
> */
> + 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/*
> gpmc_wait0.gpmc_wait0 */
> + 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/*
> gpmc_wpn.gpio0_30 */
> + 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/*
> gpmc_csn0.gpmc_csn0 */
> + 0x90 (MUX_MODE0 | PIN_OUTPUT) /*
> gpmc_advn_ale.gpmc_advn_ale */
> + 0x94 (MUX_MODE0 | PIN_OUTPUT) /*
> gpmc_oen_ren.gpmc_oen_ren */
> + 0x98 (MUX_MODE0 | PIN_OUTPUT) /*
> gpmc_wen.gpmc_wen */
> + 0x9c (MUX_MODE0 | PIN_OUTPUT) /*
> gpmc_be0n_cle.gpmc_be0n_cle */
> + >;
> + };
> +};
> +
> &ldo3_reg {
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <330>;
> @@ -27,3 +57,96 @@
> &aes {
> status = "okay";
> };
> +
> +/*
> + * uncomment following to enable NAND cape support
> + * &mmc2 {
> + * s
Re: [PATCHv8 2/4] power_supply: Introduce generic psy charging driver
On Mon, Mar 10, 2014 at 5:33 AM, Jenny Tc wrote: > On Fri, Mar 07, 2014 at 09:25:20PM +0100, Pavel Machek wrote: >> > + /* sort based on priority. 0 has the highest priority */ >> > + for (i = 0; i < cnt; ++i) >> > + for (j = 0; j < cnt; ++j) >> > + if (psy_prioirty(psy_lst[j]) > >> > psy_prioirty(psy_lst[i])) >> > + swap(psy_lst[j], psy_lst[i]); >> > + >> >> WTF? Bubble sort in kernel? > > Yes, it's bubble sort. Since the number of power supply objects in real > systems > (max 4) are limited, I feel the complexity would be as same as any other > sorting algorithms. Any suggestions? You already have a kernel quicksort implementation in lib/sort.c. Please restructure the code to make use of this as it is already compiled into every kernel. Yours, Linus Walleij -- 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: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling
On Wed, Mar 12, 2014 at 01:00:02PM +0800, Richard Lee wrote:
> But, IMO, if you want the CPU DAI be CBS_CFS and CODEC be CBM_CFM,
> you could just do it like this:
> simple-audio-card,cpu {
> ...
> };
>
> simple-audio-card,codec {
> ...
> bitclock-master;
> frame-master;
> };
> and vice versa.
> Thanks,
> (I could find this mails in my Freescale acount, so I will reply it here.)
Yes, that'd been what I'd thought the binding did (and it's what Jyri's
patch makes it do).
signature.asc
Description: Digital signature
[PATCH v1 0/3] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)
This patch-set adds parallel NAND support on following TI platforms - AM335x (am335x-bone LT, am335x-boneblack): - AM43xx (am437x-gp-evm) Pekon Gupta (3): ARM: dts: am335x-bone: add support for beaglebone NAND cape ARM: dts: am335x-boneblack: add support for beaglebone NAND cape ARM: dts: am437x-gp-evm: add support for parallel NAND flash arch/arm/boot/dts/am335x-bone.dts | 123 + arch/arm/boot/dts/am335x-boneblack.dts | 120 arch/arm/boot/dts/am437x-gp-evm.dts| 107 3 files changed, 350 insertions(+) -- 1.8.5.1.163.gd7aced9 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/am335x-bone.dts | 123 ++
1 file changed, 123 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 94ee427..be2c572 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -10,6 +10,36 @@
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
+&am33xx_pinmux {
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins = <
+ 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
*/
+ 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
*/
+ 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
*/
+ 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13
*/
+ 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14
*/
+ 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15
*/
+ 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/*
gpmc_wpn.gpio0_30 */
+ 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_wen.gpmc_wen */
+ 0x9c (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ >;
+ };
+};
+
&ldo3_reg {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
@@ -27,3 +57,96 @@
&aes {
status = "okay";
};
+
+/*
+ * uncomment following to enable NAND cape support
+ * &mmc2 {
+ * status = "disabled";
+ * };
+ * &elm {
+ * status = "okay";
+ * };
+ * &gpmc {
+ * status = "okay";
+ * };
+ */
+&gpmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x0800 0x1000>; /* CS0: NAND */
+ n
[PATCH v1 2/3] ARM: dts: am335x-boneblack: add support for beaglebone NAND cape
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selction of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
So to flash NAND, first boot via MMC or other sources and then switch to
SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/am335x-boneblack.dts | 120 +
1 file changed, 120 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6b71ad9..596cfec 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -60,6 +60,33 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
AM33XX_PIN_OUTPUT */
>;
};
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins = <
+ 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
*/
+ 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
*/
+ 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
*/
+ 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13
*/
+ 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14
*/
+ 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15
*/
+ 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/*
gpmc_wpn.gpio0_30 */
+ 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_wen.gpmc_wen */
+ 0x9c (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ >;
+ };
};
&lcdc {
@@ -76,3 +103,96 @@
status = "okay";
};
};
+
+/*
+ * uncomment following to enable NAND cape support
+ * &mmc2 {
+ * status = "disabled";
+ * };
+ * &elm {
+ * status = "okay";
+ * };
+ * &gpmc {
+ * status = "okay";
+ * };
+ */
+&gpmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x0800 0x1000>; /* CS0: NAND */
+ nand@0,0 {
+
[PATCH v1 3/3] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
(a) By dynamically driving following GPIO pin from software
SPI2_CS0(GPIO) == 0 NAND is selected (default)
SPI2_CS0(GPIO) == 1 eMMC is selected
(b) By statically using Jumper (J89) on the board
(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
NAND boot.
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/am437x-gp-evm.dts | 107
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e..0027ea7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -81,6 +81,27 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
>;
};
+
+ nand_flash_x8: nand_flash_x8 {
+ pinctrl-single,pins = <
+ 0x26C(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
spi2_cs0.gpio/eMMCorNANDsel */
+ 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_wpn.gpmc_wpn */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ >;
+ };
};
&i2c0 {
@@ -125,3 +146,89 @@
pinctrl-0 = <&mmc1_pins>;
cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x8>;
+ ranges = <0 0 0x0800 0x1000>; /* CS0: NAND */
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ nand-bus-width = <8>;
+ gpmc,device-width = <1>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <40>;
+ gpmc,cs-wr-off-ns = <40>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <25>;
+ gpmc,adv-wr-off-ns = <25>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <20>;
+ gpmc,oe-on-ns = <3>;
+ gpmc,oe-off-ns = <30>;
+ gpmc,access-ns = <30>;
+ gpmc,rd-cycle-ns = <40>;
+ gpmc,wr-cycle-ns = <40>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this is equal to size of erase-block */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "NAND.SPL";
+ reg = <0x 0x0004>;
+ };
+ partition@1 {
+ label = "NAND.SPL.backup1";
+ reg = <0x0004 0x0004>;
+ };
+ partition@2 {
+ label = "NAND.SPL.backup2";
+ reg = <0x0008 0x0004>;
+ };
+ partition@3 {
+ label = "NAND.SPL.backup3";
+
[PATCH] arm: omap: cm-t3530: Add MMC2/SDIO/WLAN support
Add support for the MMC2/SDIO WiFi Libertas (Marvell) module available
on the CM-T3530 SOM.
Signed-off-by: Stefan Roese
Cc: Dmitry Lifshitz
Cc: Igor Grinberg
Cc: Tony Lindgren
---
This patch is based on current mainline (v3.14-rc6) plus this compulab patch
series from Dmitry:
[PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
http://www.spinics.net/lists/arm-kernel/msg300078.html
Thanks,
Stefan
arch/arm/boot/dts/omap3-cm-t3530.dts | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-cm-t3530.dts
b/arch/arm/boot/dts/omap3-cm-t3530.dts
index 9faf1cd..d145849 100644
--- a/arch/arm/boot/dts/omap3-cm-t3530.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3530.dts
@@ -9,4 +9,40 @@
/ {
model = "CompuLab CM-T3530";
compatible = "compulab,omap3-cm-t3530", "ti,omap34xx", "ti,omap3";
+
+ /* Regulator to trigger the reset signal of the Wifi module */
+ mmc2_sdio_reset: regulator-mmc2-sdio-reset {
+ compatible = "regulator-fixed";
+ regulator-name = "regulator-mmc2-sdio-reset";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&twl_gpio 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&omap3_pmx_core {
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_clk.sdmmc2_clk */
+ OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_cmd.sdmmc2_cmd */
+ OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat0.sdmmc2_dat0 */
+ OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat1.sdmmc2_dat1 */
+ OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat2.sdmmc2_dat2 */
+ OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP | MUX_MODE0)
/* sdmmc2_dat3.sdmmc2_dat3 */
+ OMAP3_CORE1_IOPAD(0x2164, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat4.sdmmc2_dir_dat0 */
+ OMAP3_CORE1_IOPAD(0x2166, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat5.sdmmc2_dir_dat1 */
+ OMAP3_CORE1_IOPAD(0x2168, PIN_OUTPUT | MUX_MODE1)
/* sdmmc2_dat6.sdmmc2_dir_cmd */
+ OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE1)
/* sdmmc2_dat7.sdmmc2_clkin */
+ >;
+ };
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ vmmc-supply = <&mmc2_sdio_reset>;
+ non-removable;
+ bus-width = <4>;
+ cap-power-off-card;
};
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: DSS hwmod data
On 12/03/14 12:26, Tomi Valkeinen wrote: > Hi, > > This patch adds hwmod data for omap5 display subsystem. I have tested this on > omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as > the > mainline is missing omap5 HDMI driver. > > I do see this when booting: > > omap_hwmod: dss_dispc: cannot be enabled for reset (3) > omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > > But at least DSI works just fine. Oh, I forgot to say that I tested this on top of the DSS DT branch, and unpublished omap5 and omap5-uevm display patches. So if applied to the current mainline, the hwmods are not used at all (except the reset at boot time, I think). But if this gets merged for 3.15, it'll make adding omap5 DSS support easier for 3.16 as the HWMOD data is already there. Tomi signature.asc Description: OpenPGP digital signature
[PATCH] ARM: OMAP5: Add omap5 DSS related hwmod data
From: Archit Taneja
Add hwmod data for dss core, dispc dsi1, dsi2, rfbi and hdmi. It's more or less
similar to omap4 hwmod data.
Signed-off-by: Archit Taneja
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +
1 file changed, 283 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d6231c3a..c7d33ae26282 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -334,6 +334,235 @@ static struct omap_hwmod omap54xx_dmic_hwmod = {
};
/*
+ * 'dss' class
+ * display sub-system
+ */
+static struct omap_hwmod_class_sysconfig omap54xx_dss_sysc = {
+ .rev_offs = 0x,
+ .syss_offs = 0x0014,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+};
+
+static struct omap_hwmod_class omap54xx_dss_hwmod_class = {
+ .name = "dss",
+ .sysc = &omap54xx_dss_sysc,
+ .reset = omap_dss_reset,
+};
+
+/* dss */
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = "32khz_clk", .clk = "dss_32khz_clk" },
+ { .role = "sys_clk", .clk = "dss_sys_clk" },
+ { .role = "hdmi_clk", .clk = "dss_48mhz_clk" },
+};
+
+static struct omap_hwmod omap54xx_dss_hwmod = {
+ .name = "dss_core",
+ .class = &omap54xx_dss_hwmod_class,
+ .clkdm_name = "dss_clkdm",
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+ .main_clk = "dss_dss_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dispc_hwmod_class = {
+ .name = "dispc",
+ .sysc = &omap54xx_dispc_sysc,
+};
+
+/* dss_dispc */
+static struct omap_hwmod_opt_clk dss_dispc_opt_clks[] = {
+ { .role = "sys_clk", .clk = "dss_sys_clk" },
+};
+
+/* dss_dispc dev_attr */
+static struct omap_dss_dispc_dev_attr dss_dispc_dev_attr = {
+ .has_framedonetv_irq= 1,
+ .manager_count = 4,
+};
+
+static struct omap_hwmod omap54xx_dss_dispc_hwmod = {
+ .name = "dss_dispc",
+ .class = &omap54xx_dispc_hwmod_class,
+ .clkdm_name = "dss_clkdm",
+ .main_clk = "dss_dss_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ },
+ },
+ .opt_clks = dss_dispc_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_dispc_opt_clks),
+ .dev_attr = &dss_dispc_dev_attr,
+};
+
+/*
+ * 'dsi1' class
+ * display serial interface controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dsi1_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dsi1_hwmod_class = {
+ .name = "dsi1",
+ .sysc = &omap54xx_dsi1_sysc,
+};
+
+/* dss_dsi1_a */
+static struct omap_hwmod_opt_clk dss_dsi1_a_opt_clks[] = {
+ { .role = "sys_clk", .clk = "dss_sys_clk" },
+};
+
+static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = {
+ .name = "dss_dsi1",
+ .class = &omap54xx_dsi1_hwmod_class,
+ .clkdm_name = "dss_clkdm",
+ .main_clk = "dss_dss_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ },
+ },
+ .opt_clks = dss_dsi1_a_opt_clks,
+ .opt_clks_c
[PATCH] ARM: OMAP5: DSS hwmod data
Hi, This patch adds hwmod data for omap5 display subsystem. I have tested this on omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the mainline is missing omap5 HDMI driver. I do see this when booting: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_dsi1: cannot be enabled for reset (3) omap_hwmod: dss_dsi2: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) omap_hwmod: dss_rfbi: cannot be enabled for reset (3) But at least DSI works just fine. Tomi Archit Taneja (1): ARM: OMAP5: Add omap5 DSS related hwmod data arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 + 1 file changed, 283 insertions(+) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition
MTD NAND partition for file-system should start at offset=0xA0
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8..d09e6fb 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -341,7 +341,7 @@
};
partition@9 {
label = "NAND.file-system";
- reg = <0x0080 0x1F60>;
+ reg = <0x00A0 0x1F60>;
};
};
};
--
1.8.5.1.163.gd7aced9
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: dts: dra7: add support for parallel NAND flash
From: Minal Shah
DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
So following board settings are required for NAND device detection:
SW5.9 (GPMC_WPN) = LOW
SW5.1 (NAND_BOOTn) = HIGH
Signed-off-by: Minal Shah
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/dra7-evm.dts | 117 +
arch/arm/boot/dts/dra7.dtsi| 20 +++
2 files changed, 137 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5babba0..7b4e6f5 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -93,6 +93,37 @@
0x24c (PIN_INPUT_SLEW | MUX_MODE0) /* uart3_txd */
>;
};
+
+ nand_flash_x16: nand_flash_x16 {
+ /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+* So NAND flash requires following switch settings:
+* SW5.9 (GPMC_WPN) = LOW
+* SW5.1 (NAND_BOOTn) = HIGH */
+ pinctrl-single,pins = <
+ 0x0 (PIN_INPUT | MUX_MODE0)/* gpmc_ad0
*/
+ 0x4 (PIN_INPUT | MUX_MODE0)/* gpmc_ad1
*/
+ 0x8 (PIN_INPUT | MUX_MODE0)/* gpmc_ad2
*/
+ 0xc (PIN_INPUT | MUX_MODE0)/* gpmc_ad3
*/
+ 0x10(PIN_INPUT | MUX_MODE0)/* gpmc_ad4
*/
+ 0x14(PIN_INPUT | MUX_MODE0)/* gpmc_ad5
*/
+ 0x18(PIN_INPUT | MUX_MODE0)/* gpmc_ad6
*/
+ 0x1c(PIN_INPUT | MUX_MODE0)/* gpmc_ad7
*/
+ 0x20(PIN_INPUT | MUX_MODE0)/* gpmc_ad8
*/
+ 0x24(PIN_INPUT | MUX_MODE0)/* gpmc_ad9
*/
+ 0x28(PIN_INPUT | MUX_MODE0)/* gpmc_ad10
*/
+ 0x2c(PIN_INPUT | MUX_MODE0)/* gpmc_ad11
*/
+ 0x30(PIN_INPUT | MUX_MODE0)/* gpmc_ad12
*/
+ 0x34(PIN_INPUT | MUX_MODE0)/* gpmc_ad13
*/
+ 0x38(PIN_INPUT | MUX_MODE0)/* gpmc_ad14
*/
+ 0x3c(PIN_INPUT | MUX_MODE0)/* gpmc_ad15
*/
+ 0xD8(PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0
*/
+ 0xCC(PIN_OUTPUT | MUX_MODE0)/* gpmc_wen
*/
+ 0xB4(PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0
*/
+ 0xC4(PIN_OUTPUT | MUX_MODE0)/*
gpmc_advn_ale */
+ 0xC8(PIN_OUTPUT | MUX_MODE0)/* gpmc_oen_ren
*/
+ 0xD0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
+ >;
+ };
};
&i2c1 {
@@ -273,3 +304,89 @@
&cpu0 {
cpu0-supply = <&smps123_reg>;
};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0x0800 0x1000>;
+ nand@0,0 {
+ reg = <0 0 0>;
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <40>;
+ gpmc,cs-wr-off-ns = <40>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <30>;
+ gpmc,adv-wr-off-ns = <30>;
+ gpmc,we-on-ns = <5>;
+ gpmc,we-off-ns = <25>;
+ gpmc,oe-on-ns = <2>;
+ gpmc,oe-off-ns = <20>;
+ gpmc,access-ns = <20>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,rd-cycle-ns = <40>;
+ gpmc,wr-cycle-ns = <40>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this is equal to size of erase-block */
+ #address-cells = <1>;
+ #size-cells = <1>;
+
[PATCH v2 0/2] add parallel NAND support for TI's new OMAPx and AMxx platforms
*changes v1 -> v2* - AM335x (am335x-evm): - DRA7xx (dra7-evm): resending - AM43xx (am43X-epos-evm): fix MTD NAND.filesystem partition offset *Original v1* This patch-set adds and updates parallel NAND support on following TI platforms - AM335x (am335x-evm) - DRA7xx (dra7-evm - AM43xx (am43X-epos-evm) In addition, following OMAP2+/GPMC patch is also added in this series as it add checks DRA7xx and AM43xxx platforms for non-DT kernels. ARM: OMAP2+: gpmc: update gpmc_hwecc_bch_capable() for new platforms Minal Shah (1): ARM: dts: dra7: add support for parallel NAND flash Pekon Gupta (1): ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition arch/arm/boot/dts/am43x-epos-evm.dts | 2 +- arch/arm/boot/dts/dra7-evm.dts | 117 +++ arch/arm/boot/dts/dra7.dtsi | 20 ++ 3 files changed, 138 insertions(+), 1 deletion(-) -- 1.8.5.1.163.gd7aced9 -- 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: [alsa-devel] [PATCH RFC v2 0/2] Fix simple-card *-master DT parameter handling
On 03/12/2014 08:11 AM, Kuninori Morimoto wrote:
Hi Richard
but anyway, if my understanding is correct,
simple-audio-card,cpu {
...
bitclock-master;
frame-master;
};
simple-audio-card,codec {
...
bitclock-master;
frame-master;
};
This will be
cpu : SND_SOC_DAIFMT_CBS_CFS
codec : SND_SOC_DAIFMT_CBM_CFM
Yes, That's also what my understanding of this patches.
Thank you. I understand.
(and I need to send fixup patches :)
# "codec-is-bitclock-master" seems understandable than
# current "bitclock-master"...
Sounds great to me!
Best regards,
Jyri
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: dts: overo: Add graphics output
On 11/03/14 14:34, Florian Vaussard wrote: > Hi, > > This series enables the DVI / LCD graphics present on some of > the Overo expansion boards. > > DVI output: > - Tobi > - Summit > > LCD (3.5''): > - Alto35 > > LCD (4.3''): > - Chestnut43 > - Palo43 > - Gallop43 > > I tested on Tobi, Alto35 and Gallop43 using both OMAP35xx and OMAP36xx > Overo boards. > > This series depends on Tomi's DSS patches [1] that are not yet merged. > It also depends on previous Overo series [2] and [3] that are under > review. A complete testing tree is available [4]. Looks good to me. Unfortunately the video bindings are still being discussed (mainly the ports/endpoints), so there might be changes needed when some kind of conclusion is reached. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/3] ARM: dts: overo: Add support for DVI output
On 11/03/14 14:34, Florian Vaussard wrote:
> Summit and Tobi expansion boards have a HDMI connector with a TFP410
> encoder. Add a common include file for this configuration, and then
> use it for Summit and Tobi.
>
> Signed-off-by: Florian Vaussard
> ---
> arch/arm/boot/dts/omap3-overo-common-dvi.dtsi| 109
> +++
> arch/arm/boot/dts/omap3-overo-summit-common.dtsi | 1 +
> arch/arm/boot/dts/omap3-overo-tobi-common.dtsi | 1 +
> 3 files changed, 111 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap3-overo-common-dvi.dtsi
> +&dss {
> + status = "ok";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&dss_dpi_pins
> + &i2c3_pins>;
The i2c3 pins don't belong here, they are not related to dss. The
dvi-connector uses i2c3, but I don't think they belong there either, as
the i2c3 bus can be used by multiple devices. So I guess they should be
set in &i2c3 node.
Tomi
signature.asc
Description: OpenPGP digital signature
