Re: [PATCH 0/2] ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
Hi Nishanth, On Tuesday 22 July 2014 10:15 PM, Nishanth Menon wrote: > On 07/16/2014 03:36 AM, Lokesh Vutla wrote: >> This series add seperate ocp interface lists that are specific to dra74x >> and dra72x, and moving USB OTG SS4 to dra74x only since its not present >> in dra72x. Without this USB OTG SS4 hwmod gives an abort on dra72x. >> >> Adding support for soc_is_dra74x() and soc_is_dra72x() in order to >> differentiate >> between dra74x and dra72x and pass the respective ocp interface lists. >> >> Verified on dra74x evm and dra72x evm using 3.16-rc5 based mainline kernel. >> >> Before: >> dra74x : http://paste.ubuntu.com/7802364/ >> dra72x : http://paste.ubuntu.com/7802334/ (Kernel panic) >> >> After- >> dra74x : http://paste.ubuntu.com/7802340/ >> dra72x : http://paste.ubuntu.com/7802338/ (booted) >> >> Rajendra Nayak (2): >> ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() >> varients >> ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists >> >> arch/arm/mach-omap2/omap_hwmod.c |3 +++ >> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 -- >> arch/arm/mach-omap2/soc.h |7 +++ >> 3 files changed, 30 insertions(+), 2 deletions(-) >> > Tested-by: Nishanth Menon Thanks.. > > BUT, I suggest a follow up series to do exactly the same (moving stuff > that are not common from dra7.dtsi to dra72x.dtsi and 74x.dtsi) as > well to ensure that dts indicates exactly the same information (only > the applicable IPs are present in dts). The separation of dra72x.dtsi and dra74x.dtsi is already happened and the patch is already present in mainline[1]. Looks like usb_otg_ss4 is still present in dra7.dtsi, but this should go into dra74x.dtsi. I ll take it up. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=38b248db60e32734417534b57f9ab687c445113a Thanks and regards, Lokesh > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
Hi Nishanth,
On Tuesday 22 July 2014 10:20 PM, Nishanth Menon wrote:
> On 07/16/2014 03:36 AM, Lokesh Vutla wrote:
>> From: Rajendra Nayak
>>
>> To deal with IPs which are specific to dra74x and dra72x, maintain seperate
>> ocp interface lists, while keeping the common list for all common IPs.
>>
>> Move USB OTG SS4 to dra74x only list since its unavailable in
>> dra72x and is giving an abort during boot. The dra72x only list
>> is empty for now and a placeholder for future hwmod additions which
>> are specific to dra72x.
>>
>> Fixes: d904b38 ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
>
> please use a format as following:
> Fixes: d904b38df0db13 ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss")
>
>> Reported-by: Keerthy
>> Signed-off-by: Rajendra Nayak
>> Signed-off-by: Lokesh Vutla
>> ---
>> arch/arm/mach-omap2/omap_hwmod.c |3 +++
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 --
>> 2 files changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
>> b/arch/arm/mach-omap2/omap_hwmod.c
>> index 6c074f3..14f8370 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -3345,6 +3345,9 @@ int __init omap_hwmod_register_links(struct
>> omap_hwmod_ocp_if **ois)
>> if (!ois)
>> return 0;
>>
>> +if (ois[0] == NULL) /*empty list*/
> /* Empty list */ ?
>> +return 0;
>> +
>
> This change looks like a different patch?
Since we are introducing empty lists in this patch, I guess
this can go in the same patch.
>
>> if (!linkspace) {
>> if (_alloc_linkspace(ois)) {
>> pr_err("omap_hwmod: could not allocate link space\n");
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 284324f..c95033c 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -35,6 +35,7 @@
>> #include "i2c.h"
>> #include "mmc.h"
>> #include "wd_timer.h"
>> +#include "soc.h"
>>
>> /* Base offset for all DRA7XX interrupts external to MPUSS */
>> #define DRA7XX_IRQ_GIC_START32
>> @@ -2705,7 +2706,6 @@ static struct omap_hwmod_ocp_if
>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>> &dra7xx_l4_per3__usb_otg_ss1,
>> &dra7xx_l4_per3__usb_otg_ss2,
>> &dra7xx_l4_per3__usb_otg_ss3,
>> -&dra7xx_l4_per3__usb_otg_ss4,
>> &dra7xx_l3_main_1__vcp1,
>> &dra7xx_l4_per2__vcp1,
>> &dra7xx_l3_main_1__vcp2,
>> @@ -2714,8 +2714,26 @@ static struct omap_hwmod_ocp_if
>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>> NULL,
>> };
>>
>> +static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
>> +&dra7xx_l4_per3__usb_otg_ss4,
>> +NULL,
>> +};
>> +
>> +static struct omap_hwmod_ocp_if *dra72x_hwmod_ocp_ifs[] __initdata = {
>> +NULL,
>> +};
>> +
>> int __init dra7xx_hwmod_init(void)
>> {
>> +int ret;
>> +
>> omap_hwmod_init();
>> -return omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
>> +ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
> if (ret)
> goto out;
>> +
>> +if (!ret && soc_is_dra74x())
> no need of !ret
>> +return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
> ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
>> +else if (!ret && soc_is_dra72x())
> no need of else and !ret
>> +return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
> ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
>> +
>
> out:
Ok. Will do this and repost.
Thanks and regards,
Lokesh
>> +return ret;
>> }
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
Hi Joerg, (Your attention is kindly requested in time for v3.17, please see below) On Monday 21 July 2014 23:19:29 Tony Lindgren wrote: > * Laurent Pinchart [140721 11:17]: > > On Monday 21 July 2014 02:33:36 Tony Lindgren wrote: > >> * Laurent Pinchart [140721 02:16]: > >>> On Friday 18 July 2014 11:53:56 Suman Anna wrote: > On 07/18/2014 05:49 AM, Laurent Pinchart wrote: > > Hello, > > > > The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now > > that is has been ported to the DMA API, remove the unused virtual > > memory manager. > > > > The removal is split in three patches to ease upstream merge. The > > first patch removes the omap-iovmm driver, the second patch > > removes setting of now unused platform data fields from arch code, > > and the last patch cleans up the platform data structure. > > Thanks for the revised series, it looks good. I have also tested the > series on OMAP3, OMAP4 and OMAP5. > > For the changes in the entire series, > Acked-by: Suman Anna > >>> > >>> Thank you. > >>> > > I'd like to get at least the first patch merged in v3.17. To avoid > > splitting the series across three kernel versions, it would be > > nice to also merge at least the second patch for v3.17. If there's > > no risk of conflict everything could be merged in one go through > > the ARM SoC tree. Otherwise a stable branch with patch 1/3 will be > > needed to base the arch change on. > > > > Joerg, Tony, how would you like to proceed ? > >>> > >>> The v3.17 merge window is getting close, it's probably too late to > >>> merge patch 2/3. Joerg, could you please take 1/3 in your tree for > >>> v3.17 ? 2/3 and 3/3 would then get in v3.18. Tony, how would you like > >>> to proceed for those ? > >> > >> How about Joerg maybe do an immutable branch against v3.16-rc1 > >> with just these three patches and merge it into your tree? > >> > >> That way I too can merge the minimal branch in if there are conflics. > >> If that works for Joerg, then for arch/arm/*omap* changes: > >> > >> Acked-by: Tony Lindgren > > > > I've created an immutable branch (or, rather, immutable until the changes > > reach mainline, at which point I will remove the branch) on top of > > v3.16-rc1 with just the three patches from this series. You can find it > > at. > > > > git://linuxtv.org/pinchartl/media.git omap/iommu > > > > Tony, is there still time to get this (and especially patch 2/3, which > > touches arch/ code) in v3.17 ? > > Yes as long as Joerg is OK to merge that branch in :) Are you ? :-) -- 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] drivers/misc/ti-st: Load firmware from ti-connectivity directory.
On Tue, Jul 22, 2014 at 01:08:38PM +0200, Enric Balletbo i Serra wrote: > Looks like the default location for TI firmware is inside the ti-connectivity > directory, to be coherent with other firmware request used by TI drivers, load > the TIInit firmware from this directory instead of /lib/firmware directly. > > Signed-off-by: Enric Balletbo i Serra > --- > drivers/misc/ti-st/st_kim.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c > index 9d3dbb2..fa6a900 100644 > --- a/drivers/misc/ti-st/st_kim.c > +++ b/drivers/misc/ti-st/st_kim.c > @@ -244,7 +244,8 @@ static long read_local_version(struct kim_data_s > *kim_gdata, char *bts_scr_name) > if (version & 0x8000) > maj_ver |= 0x0008; > > - sprintf(bts_scr_name, "TIInit_%d.%d.%d.bts", chip, maj_ver, min_ver); > + sprintf(bts_scr_name, "ti-connectivity/TIInit_%d.%d.%d.bts", > + chip, maj_ver, min_ver); Can I get an ack from a ti.com address to verify that this is where the driver really is? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia N900 FB regression?
On Tue, Jul 22, 2014 at 6:02 PM, Nick Krause wrote:
> On Tue, Jul 22, 2014 at 5:23 PM, Aaro Koskinen wrote:
>> Hi,
>>
>> Somewhere between 3.16-rc2 and rc6 (I was on holidays...) I noticed
>> the framebuffer stopped working on N900 (nothing on screen).
>>
>> I bisected this to 913fd66e9809e93e06d5bbd49cf99a6cdbee (ARM: dts:
>> Enable twl4030 off-idle configuration for selected omaps).
>> With this commit reverted, I can see the Tux again with 3.16-rc6.
>>
>> Any ideas?
>>
>> A.
>> --
>> 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
>
>
> I am new to the kernel but I can take a look into this this commit.
> Cheers Nick
+
+ twl_power: power {
+ compatible = "ti,twl4030-power-n900",
"ti,twl4030-power-idle-osc-off";
+ ti,use_poweroff;
+ };
};
This seems to be the case of no boot. Perhaps compatible functions are
incorrect?
I am new so asking a maintainer may be better but seems the idle function set
here turns off your frame butter. I would also test this on the beagleboard xm
as this patch may affect it too.
Nick
--
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: Nokia N900 FB regression?
On Tue, Jul 22, 2014 at 5:23 PM, Aaro Koskinen wrote: > Hi, > > Somewhere between 3.16-rc2 and rc6 (I was on holidays...) I noticed > the framebuffer stopped working on N900 (nothing on screen). > > I bisected this to 913fd66e9809e93e06d5bbd49cf99a6cdbee (ARM: dts: > Enable twl4030 off-idle configuration for selected omaps). > With this commit reverted, I can see the Tux again with 3.16-rc6. > > Any ideas? > > A. > -- > 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 I am new to the kernel but I can take a look into this this commit. Cheers Nick -- 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
Nokia N900 FB regression?
Hi, Somewhere between 3.16-rc2 and rc6 (I was on holidays...) I noticed the framebuffer stopped working on N900 (nothing on screen). I bisected this to 913fd66e9809e93e06d5bbd49cf99a6cdbee (ARM: dts: Enable twl4030 off-idle configuration for selected omaps). With this commit reverted, I can see the Tux again with 3.16-rc6. Any ideas? A. -- 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
[GIT PULL] ARM: OMAP2+: first set of hwmod data patches for v3.17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee: Linux 3.16-rc2 (2014-06-21 19:02:54 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.17/omap-hwmod-a for you to fetch changes up to c913c8a15a02e91c1f0302d68bebf66838a9689d: ARM: DRA7: hwmod: Add data for RTC (2014-07-22 14:35:06 -0600) - OMAP hwmod data additions for v3.17. Most of these are DRA7xx-related, although one patch adds DSS hwmods for AM43xx. Basic build, boot, and PM test results are available here: http://www.pwsan.com/omap/testlogs/hwmod-a-v3.17/20140722143514/ - Kishon Vijay Abraham I (2): arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems Lokesh Vutla (1): ARM: DRA7: hwmod: Add data for RTC Mugunthan V N (1): arm: dra7xx: Add hwmod data for MDIO and CPSW Roger Quadros (1): ARM: DRA7: hwmod: Add OCP2SCP3 module Sathya Prakash M R (1): ARM: AM43xx: hwmod: add DSS hwmod data arch/arm/mach-omap2/Makefile | 1 + arch/arm/mach-omap2/cm2_7xx.h | 4 + .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 40 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 100 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 260 + .../mach-omap2/omap_hwmod_common_ipblock_data.c| 55 + arch/arm/mach-omap2/prcm43xx.h | 1 + arch/arm/mach-omap2/prm7xx.h | 4 + 8 files changed, 425 insertions(+), 40 deletions(-) create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJTztWUAAoJEMePsQ0LvSpLjF4P/0PEGsq8ctRAQNaIKsVNtsDg 2plzao0Zk0hJjwTQ1HfcrGOiaMRwBpulmvb/hkFu4y7GDBiY2WEJn8d6qHDzbzLJ 2XJxfY69wtrQBs5SG587xNJSmDVoZXKZRbghM0fqJi3ip41bge5HtRD19VXVN5Rj KZbKZVHWxtyVyZD1Lzl5lTufBgIgLG3nJUrkpIR5nPa0R9k2KtJMeFs88U578Nfs XT6rQwKyFULqXCYoOOE1Kl2Wmo9mdeVEByx6GYUf0Qz5KES+3+2hiCBsc4FylVSO tW695bfMgOQ186UZXSYxnQ2pDU/D1meVQ2IQVvlKyG7q+BPslWOgoeFgr1yVZkCz wRPILUn6G6JRyJ/cCN8nYfrTnFXmV6Ve+Tb2BroHHkiJLPuxNEenFHkVHDaZgwYK 1zDoi1QAVUfy9cnic5yv2/Wd+5rxWwW2V9RCoAU4CT/sRrbH+kqMD1kR0U/Gr06k L9nowkGwvTUO6aKtUjdsCRXKlThZLcjZcj+yGbDaF7V9UhGS1ys5bTgIXqGU8CDT ZNg17MpslWTfL2NG6WFkSjU7DO2H8oO3D+o6pETSN6+h2SRkfLhxTjkILm6wSQVQ HFgPE0fKNLWCRZZk8klAOiG6S4GlxK9S7lDAbVEgr4ivTShdH1p0EsjqDRu+ckPX AJ8zX9YSxfEqcW/f08LX =I+wx -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: AM43xx: hwmod: add DSS hwmod data
On Tue, 17 Jun 2014, Tomi Valkeinen wrote:
> From: Sathya Prakash M R
>
> Add DSS hwmod data for AM43xx.
>
> Signed-off-by: Sathya Prakash M R
> [tomi.valkei...@ti.com: added missing dispc flags]
> Signed-off-by: Tomi Valkeinen
> Acked-by: Rajendra Nayak
This one didn't compile on an AM43xx-only build:
arch/arm/mach-omap2/built-in.o:(.data+0x3f2c): undefined reference to
`omap2_dss_hwmod_class'
arch/arm/mach-omap2/built-in.o:(.data+0x405c): undefined reference to
`omap2_rfbi_hwmod_class'
make: *** [vmlinux] Error 1
test_build: Tue Jul 22 13:48:50 MDT 2014: FAILED on
omap2plus_defconfig_am43xx_only hwmod-a-v3.17
Have queued the following patch instead.
- Paul
From: Sathya Prakash M R
Date: Sat, 5 Jul 2014 17:44:57 -0600
Subject: [PATCH] ARM: AM43xx: hwmod: add DSS hwmod data
Add DSS hwmod data for AM43xx.
Signed-off-by: Sathya Prakash M R
[tomi.valkei...@ti.com: added missing dispc flags]
Signed-off-by: Tomi Valkeinen
Acked-by: Rajendra Nayak
Acked-by: Tony Lindgren
Tested-by: Felipe Balbi # on linux-next 5f295cdf5c5d
[p...@pwsan.com: fixed build break on AM43xx-only config]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/Makefile | 1 +
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 40 -
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 100 +
.../mach-omap2/omap_hwmod_common_ipblock_data.c| 55
arch/arm/mach-omap2/prcm43xx.h | 1 +
5 files changed, 157 insertions(+), 40 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8421f38cf445..75c73f253604 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -200,6 +200,7 @@ obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o
obj-$(CONFIG_SOC_OMAP2430) += opp2430_data.o
# hwmod data
+obj-y += omap_hwmod_common_ipblock_data.o
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_ipblock_data.o
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_3xxx_ipblock_data.o
obj-$(CONFIG_SOC_OMAP2420) += omap_hwmod_2xxx_interconnect_data.o
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
index 5da7a42a6d90..c6c6384de867 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c
@@ -37,46 +37,6 @@ struct omap_hwmod_class omap2_uart_class = {
};
/*
- * 'dss' class
- * display sub-system
- */
-
-static struct omap_hwmod_class_sysconfig omap2_dss_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
- SYSS_HAS_RESET_STATUS),
- .sysc_fields= &omap_hwmod_sysc_type1,
-};
-
-struct omap_hwmod_class omap2_dss_hwmod_class = {
- .name = "dss",
- .sysc = &omap2_dss_sysc,
- .reset = omap_dss_reset,
-};
-
-/*
- * 'rfbi' class
- * remote frame buffer interface
- */
-
-static struct omap_hwmod_class_sysconfig omap2_rfbi_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .syss_offs = 0x0014,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
- SYSC_HAS_AUTOIDLE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
- .sysc_fields= &omap_hwmod_sysc_type1,
-};
-
-struct omap_hwmod_class omap2_rfbi_hwmod_class = {
- .name = "rfbi",
- .sysc = &omap2_rfbi_sysc,
-};
-
-/*
* 'venc' class
* video encoder
*/
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c2cc8083fdd..fea01aa3ef42 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
#include "omap_hwmod.h"
#include "omap_hwmod_33xx_43xx_common_data.h"
#include "prcm43xx.h"
+#include "omap_hwmod_common_data.h"
+
/* IP blocks */
static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,72 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+/* dss */
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+ .name = "dss_core",
+ .class = &omap2_dss_hwmod_class,
+ .clkdm_name = "dss_clkdm",
+ .main_clk = "disp_clk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* dispc */
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+ .manager_count = 1,
+ .has_framedonetv_irq= 0
+};
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc =
omap-wakeupgen.c: Remove function for fix me
static void __init irq_pm_init(void)
382 {
383 /* FIXME: Remove this when MPU OSWR support is added */
384 if (!soc_is_omap54xx())
385 cpu_pm_register_notifier(&irq_notifier_block);
386 }
I am wondering is this omap supported now if it is can I remove it?
Cheers Nick
--
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: [v3 PATCH 1/6] drivers: reset: TI: SoC reset controller support.
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> The TI SoC reset controller support utilizes the
> reset controller framework to give device drivers or
> function drivers a common set of APIs to call to reset
> a module.
>
> The reset-ti is a common interface to the reset framework.
> The register data is retrieved during initialization
> of the reset driver through the reset-ti-data
> file. The array of data is associated with the compatible from the
> respective DT entry.
Outdated commit description, this is no longer correct.
>
> Once the data is available then this is derefenced within the common
> interface.
>
> The device driver has the ability to assert, deassert or perform a
> complete reset.
>
> This code was derived from previous work by Rajendra Nayak and Afzal Mohammed.
> The code was changed to adopt to the reset core and abstract away the SoC
> information.
>
> Signed-off-by: Dan Murphy
> ---
>
> v3 - Resolved comments from v2. To many to call out here -
> https://patchwork.kernel.org/patch/4116941/
Please add a cover letter for the series next time and make sure you cc
the reset driver maintainer.
>
> drivers/reset/Kconfig|9 ++
> drivers/reset/Makefile |1 +
> drivers/reset/reset-ti.c | 373
> ++
> 3 files changed, 383 insertions(+)
> create mode 100644 drivers/reset/reset-ti.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 0615f50..31a5a79 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -12,4 +12,13 @@ menuconfig RESET_CONTROLLER
>
> If unsure, say no.
>
> +config RESET_TI
> + depends on RESET_CONTROLLER && ARCH_OMAP || COMPILE_TEST
> + bool "TI reset controller"
> + help
> + Reset controller support for TI SoC's
> +
> + Reset controller found in TI's AM series of SoC's like
> + AM335x and AM43x and OMAP SoC's like OMAP5 and DRA7
> +
> source "drivers/reset/sti/Kconfig"
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 60fed3d..a5986b9 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_RESET_CONTROLLER) += core.o
> obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
> obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
> +obj-$(CONFIG_RESET_TI) += reset-ti.o
> obj-$(CONFIG_ARCH_STI) += sti/
> diff --git a/drivers/reset/reset-ti.c b/drivers/reset/reset-ti.c
> new file mode 100644
> index 000..e9d4039
> --- /dev/null
> +++ b/drivers/reset/reset-ti.c
> @@ -0,0 +1,373 @@
> +/*
> + * reset-ti.c - PRCM reset driver for TI SoC's
> + *
> + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
> + *
> + * Author: Dan Murphy
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
This header is no longer needed, now that you are not using of_iomap.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "prcm_reset_ti"
> +#define MAX_RESET_SIGNALS 255
This sounds like a lot, I think you should reduce this to not waste
memory. Start with a small number, and add a trace for increasing this
if you run out of the current slots.
> +
> +/**
> + * struct ti_reset_reg_data - Structure of the reset register information
> + * for a particular SoC.
> + * @rstctrl_offs: This is the reset control offset value from
> + * from the parent reset node.
> + * @rstst_offs: This is the reset status offset value from
> + * from the parent reset node.
> + * @rstctrl_bit: This is the reset control bit for the module.
> + * @rstst_bit: This is the reset status bit for the module.
> + *
> + * Longer description of this structure.
> + */
> +struct ti_reset_reg_data {
> + phandle handle;
> + u32 rstctrl_offs;
> + u32 rstst_offs;
> + u32 rstctrl_bit;
> + u32 rstst_bit;
> +};
> +
> +/**
> + * struct ti_reset_data - Structure that contains the reset register data
> + * as well as the total number of resets for a particular SoC.
> + * @ti_data: Pointer to this structure to be dereferenced
> + * @reg_data:Pointer to the register data structure.
> + * @rcdev: Reset controller device instance
> + * @dev: Pointer to the devive structure
> + * @ti_reg_data: Array of register data. Only reset signal with valid
> + * phandles will be stored in this array.
> + * @reg_base:Parent register base address
> + * @lock:Spinlock for accessing the registers
> + * @nr_resets: Total number of resets for the SoC in the reset array.
> + *
> + * This structure contains a pointer to the register data and the modules
> + * register base. The number of re
[PATCH v2 2/7] arm: dts: omap3-gta04: Fix magnetometer model
gta04 is using hmc5883l not hmc5843 so fix wrong compatible
entry.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-gta04.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 7d7ddd7..4067495 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -220,7 +220,7 @@
/* compass aka magnetometer */
hmc5843@1e {
- compatible = "honeywell,hmc5843";
+ compatible = "honeywell,hmc5883l";
reg = <0x1e>;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] arm: dts: omap3-gta04: Fix magnetometer model
On Tue, Jul 22, 2014 at 9:46 PM, Peter Meerwald wrote:
>
>> gta04 is using hmc5843l not hmc5843 so fix wrong compatible
>> entry.
>
> I guess you mean hmc5883l
Ah right. Thanks. I'll post update version.
>
>> Signed-off-by: Marek Belisko
>> ---
>> arch/arm/boot/dts/omap3-gta04.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3-gta04.dts
>> b/arch/arm/boot/dts/omap3-gta04.dts
>> index 7d7ddd7..6d1a8d8 100644
>> --- a/arch/arm/boot/dts/omap3-gta04.dts
>> +++ b/arch/arm/boot/dts/omap3-gta04.dts
>> @@ -220,7 +220,7 @@
>>
>> /* compass aka magnetometer */
>> hmc5843@1e {
>> - compatible = "honeywell,hmc5843";
>> + compatible = "honeywell,hmc5843l";
>> reg = <0x1e>;
>> };
>>
>>
>
> --
>
> Peter Meerwald
> +43-664-218 (mobile)
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.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 v2 2/7] arm: dts: omap3-gta04: Fix magnetometer model
> gta04 is using hmc5843l not hmc5843 so fix wrong compatible
> entry.
I guess you mean hmc5883l
> Signed-off-by: Marek Belisko
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dts
> b/arch/arm/boot/dts/omap3-gta04.dts
> index 7d7ddd7..6d1a8d8 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dts
> +++ b/arch/arm/boot/dts/omap3-gta04.dts
> @@ -220,7 +220,7 @@
>
> /* compass aka magnetometer */
> hmc5843@1e {
> - compatible = "honeywell,hmc5843";
> + compatible = "honeywell,hmc5843l";
> reg = <0x1e>;
> };
>
>
--
Peter Meerwald
+43-664-218 (mobile)
--
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 5/7] arm: dts: omap3-gta04: Add USB host support
Define USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-gta04.dts | 45 +++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 4ca1277..370c08b 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -74,9 +74,30 @@
};
};
};
+
+ hsusb2_phy: hsusb2_phy {
+ compatible = "usb-nop-xceiv";
+ reset-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
+ };
};
&omap3_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusb2_pins
+ >;
+
+ hsusb2_pins: pinmux_hsusb2_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x21d4, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* mcspi1_cs3.hsusb2_data2 */
+ OMAP3_CORE1_IOPAD(0x21d6, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* mcspi2_clk.hsusb2_data7 */
+ OMAP3_CORE1_IOPAD(0x21d8, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* mcspi2_simo.hsusb2_data4 */
+ OMAP3_CORE1_IOPAD(0x21da, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* mcspi2_somi.hsusb2_data5 */
+ OMAP3_CORE1_IOPAD(0x21dc, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* mcspi2_cs0.hsusb2_data6 */
+ OMAP3_CORE1_IOPAD(0x21de, PIN_INPUT_PULLDOWN |
MUX_MODE3) /* mcspi2_cs1.hsusb2_data3 */
+ >;
+ };
+
uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
0x152 (PIN_INPUT | MUX_MODE0) /*
uart1_rx.uart1_rx */
@@ -144,6 +165,22 @@
};
&omap3_pmx_core2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &hsusb2_2_pins
+ >;
+
+ hsusb2_2_pins: pinmux_hsusb2_2_pins {
+ pinctrl-single,pins = <
+ OMAP3630_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
/* etk_d10.hsusb2_clk */
+ OMAP3630_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
/* etk_d11.hsusb2_stp */
+ OMAP3630_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d12.hsusb2_dir */
+ OMAP3630_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d13.hsusb2_nxt */
+ OMAP3630_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d14.hsusb2_data0 */
+ OMAP3630_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN |
MUX_MODE3)/* etk_d15.hsusb2_data1 */
+ >;
+ };
+
spi_gpio_pins: spi_gpio_pinmux {
pinctrl-single,pins = <
OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /*
clk */
@@ -259,6 +296,14 @@
power = <50>;
};
+&usbhshost {
+ port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+ phys = <0 &hsusb2_phy>;
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
--
1.9.1
--
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 3/7] arm: dts: omap3-gta04: Add wifi reset node
Define gpio node in tca6507 which will be used as
wifi reset pin.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-gta04.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 6d1a8d8..5b08d93 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -196,6 +196,9 @@
#size-cells = <0>;
reg = <0x45>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
gta04_led0: red_aux@0 {
label = "gta04:red:aux";
reg = <0x0>;
@@ -216,6 +219,11 @@
label = "gta04:green:power";
reg = <0x4>;
};
+
+ wifi_reset: wifi_reset@6 {
+ reg = <0x6>;
+ compatible = "gpio";
+ };
};
/* compass aka magnetometer */
--
1.9.1
--
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/7] arm: dts: omap3-gta04: Fix magnetometer model
gta04 is using hmc5843l not hmc5843 so fix wrong compatible
entry.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-gta04.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 7d7ddd7..6d1a8d8 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -220,7 +220,7 @@
/* compass aka magnetometer */
hmc5843@1e {
- compatible = "honeywell,hmc5843";
+ compatible = "honeywell,hmc5843l";
reg = <0x1e>;
};
--
1.9.1
--
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 4/7] arm: dts: omap3-gta04: Move spi gpio pins to pmx_core2
Because of commit: 3d495383648a7cda3ea51a1e2fa5d288581479aa
spi_gpio_pins node isn't valid anymore. Move to pmx_core2 node.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-gta04.dts | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 5b08d93..4ca1277 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -141,12 +141,15 @@
0x0da (PIN_OUTPUT | MUX_MODE0) /*
dss_data23.dss_data23 */
>;
};
+};
+&omap3_pmx_core2 {
spi_gpio_pins: spi_gpio_pinmux {
- pinctrl-single,pins = <0x5a8 (PIN_OUTPUT | MUX_MODE4) /* clk */
- 0x5b6 (PIN_OUTPUT | MUX_MODE4) /* cs */
- 0x5b8 (PIN_OUTPUT | MUX_MODE4) /* tx */
- 0x5b4 (PIN_INPUT | MUX_MODE4) /* rx */
+ pinctrl-single,pins = <
+ OMAP3630_CORE2_IOPAD(0x25d8, PIN_OUTPUT | MUX_MODE4) /*
clk */
+ OMAP3630_CORE2_IOPAD(0x25e6, PIN_OUTPUT | MUX_MODE4) /*
cs */
+ OMAP3630_CORE2_IOPAD(0x25e8, PIN_OUTPUT | MUX_MODE4) /*
tx */
+ OMAP3630_CORE2_IOPAD(0x25e4, PIN_INPUT | MUX_MODE4) /*
rx */
>;
};
};
--
1.9.1
--
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/7] arm: dts: omap3-gta04: Add nand support
Add the needed sections to enable nand support on
gta04 board.
Add nand partitions information.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-gta04.dts | 54 +++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 021311f..7d7ddd7 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -309,3 +309,57 @@
};
};
};
+
+&gpmc {
+ ranges = <0 0 0x3000 0x04>; /* CS0: NAND */
+
+ nand@0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ nand-bus-width = <16>;
+ ti,nand-ecc-opt = "bch8";
+
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <44>;
+ gpmc,cs-wr-off-ns = <44>;
+ gpmc,adv-on-ns = <6>;
+ gpmc,adv-rd-off-ns = <34>;
+ gpmc,adv-wr-off-ns = <44>;
+ gpmc,we-off-ns = <40>;
+ gpmc,oe-off-ns = <54>;
+ gpmc,access-ns = <64>;
+ gpmc,rd-cycle-ns = <82>;
+ gpmc,wr-cycle-ns = <82>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ gpmc,device-width = <2>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ x-loader@0 {
+ label = "X-Loader";
+ reg = <0 0x8>;
+ };
+
+ bootloaders@8 {
+ label = "U-Boot";
+ reg = <0x8 0x1e>;
+ };
+
+ bootloaders_env@26 {
+ label = "U-Boot Env";
+ reg = <0x26 0x2>;
+ };
+
+ kernel@28 {
+ label = "Kernel";
+ reg = <0x28 0x40>;
+ };
+
+ filesystem@68 {
+ label = "File System";
+ reg = <0x68 0xf98>;
+ };
+ };
+};
--
1.9.1
--
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 6/7] arm: dts: omap3-gta04: Add display alias
Define alias for lcd display present on gta04 board.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-gta04.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 370c08b..05fd4d2 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -26,6 +26,10 @@
reg = <0x8000 0x2000>; /* 512 MB */
};
+ aliases {
+ display0 = &lcd;
+ };
+
gpio-keys {
compatible = "gpio-keys";
--
1.9.1
--
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 7/7] arm: dts: omap3-gta04: Add twl4030 regulators parameters
Define voltages and properties for various twl4030
regulators used on gta04 board.
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-gta04.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 05fd4d2..e39ede2 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -346,11 +346,37 @@
bb_uamp = <150>;
};
+/* spare */
+&vaux1 {
+ regulator-min-microvolt = <250>;
+ regulator-max-microvolt = <300>;
+};
+
+/* sensors */
+&vaux2 {
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ regulator-always-on;
+};
+
+/* camera */
+&vaux3 {
+ regulator-min-microvolt = <250>;
+ regulator-max-microvolt = <250>;
+};
+
+/* WLAN/BT */
&vaux4 {
regulator-min-microvolt = <280>;
regulator-max-microvolt = <315>;
};
+/* GPS LNA */
+&vsim {
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <315>;
+};
+
/* Needed to power the DPI pins */
&vpll2 {
regulator-always-on;
--
1.9.1
--
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 0/7] arm: dts: oma3-gta04: Various updates
Following patchset add various improvements to gta04 devicetree. Changes from v1: - added description to all patches Marek Belisko (7): arm: dts: omap3-gta04: Add nand support arm: dts: omap3-gta04: Fix magnetometer model arm: dts: omap3-gta04: Add wifi reset node arm: dts: omap3-gta04: Move spi gpio pins to pmx_core2 arm: dts: omap3-gta04: Add USB host support arm: dts: omap3-gta04: Add display alias arm: dts: omap3-gta04: Add twl4030 regulators parameters arch/arm/boot/dts/omap3-gta04.dts | 150 -- 1 file changed, 145 insertions(+), 5 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] ARM: DRA7: hwmod: Add data for RTC
On Tue, 22 Jul 2014, Lokesh Vutla wrote: > Hi Paul, > On Wednesday 09 July 2014 02:05 PM, Lokesh Vutla wrote: > > Add hwmod data for RTC > > > > Signed-off-by: Lokesh Vutla > > Signed-off-by: Sekhar Nori > > Reviewed-by: Rajendra Nayak > Can you take this patch. I have submitted logs also. Thanks, queued for 3.17. And thanks for running rtctest in your testlog - that's helpful and gives some extra confidence. - 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: [v3 PATCH 6/6] ARM: dts: omap5: Add prm_resets node
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Add the prm_resets node to the prm parent node.
>
> Add the omap54xx_resets file to define the
> omap5 reset lines that are handled by this reset
> framework.
>
> Signed-off-by: Dan Murphy
> ---
>
> v3 - No changes
>
> arch/arm/boot/dts/omap5.dtsi |7
> arch/arm/boot/dts/omap54xx-resets.dtsi | 66
>
> 2 files changed, 73 insertions(+)
> create mode 100644 arch/arm/boot/dts/omap54xx-resets.dtsi
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index a4ed549..97bfef5 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -139,6 +139,12 @@
>
> prm_clockdomains: clockdomains {
> };
> +
> + prm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
Should be corrected as per comment on DT bindings.
> + #reset-cells = <1>;
> + };
> };
>
> cm_core_aon: cm_core_aon@4a004000 {
> @@ -989,3 +995,4 @@
> };
>
> /include/ "omap54xx-clocks.dtsi"
> +/include/ "omap54xx-resets.dtsi"
> diff --git a/arch/arm/boot/dts/omap54xx-resets.dtsi
> b/arch/arm/boot/dts/omap54xx-resets.dtsi
> new file mode 100644
> index 000..cba6f52
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap54xx-resets.dtsi
> @@ -0,0 +1,66 @@
> +/*
> + * Device Tree Source for OMAP5 reset data
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +&prm_resets {
> + dsp_rstctrl {
> + reg = <0x1c00>,
> + <0x1c04>;
> +
> + dsp_reset: dsp_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + dsp_mmu_reset: dsp_mmu_reset {
> + control-bit = <0x02>;
> + status-bit = <0x02>;
> + };
> + };
> +
> + ipu_rstctrl {
> + reg = <0x910>,
> + <0x914>;
> +
> + ipu_cpu0_reset: ipu_cpu0_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + ipu_cpu1_reset: ipu_cpu1_reset {
> + control-bit = <0x02>;
> + status-bit = <0x02>;
> + };
> +
> + ipu_mmu_reset: ipu_mmu_reset {
> + control-bit = <0x04>;
> + status-bit = <0x04>;
> + };
> + };
Missing reset node for SGX/GFX?
> +
> + iva_rstctrl {
> + reg = <0x1210>,
> + <0x1214>;
> +
> + iva_reset: iva_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
IVA also has three resets, one for logic and two for the sequencers. You
are describing only one of them.
regards
Suman
> + };
> +
> + device_rstctrl {
> + reg = <0x1c00>,
> + <0x1c04>;
> +
> + device_reset: device_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +};
>
--
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: [v3 PATCH 5/6] ARM: dts: dra7: Add prm_resets node
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Add the prcm_resets node to the prm parent node.
>
> Add the draxx_resets file to define the
> dra7xx reset lines that are handled by this reset
> framework.
>
> Signed-off-by: Dan Murphy
> ---
>
> v3 - No changes
>
> arch/arm/boot/dts/dra7.dtsi |7 +++
> arch/arm/boot/dts/dra7xx-resets.dtsi | 82
> ++
> 2 files changed, 89 insertions(+)
> create mode 100644 arch/arm/boot/dts/dra7xx-resets.dtsi
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 8012763..f3a8819 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -93,6 +93,12 @@
>
> prm_clockdomains: clockdomains {
> };
> +
> + prm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
Should be corrected as per comment on DT bindings.
> + #reset-cells = <1>;
> + };
> };
>
> cm_core_aon: cm_core_aon@4a005000 {
> @@ -998,3 +1004,4 @@
> };
>
> /include/ "dra7xx-clocks.dtsi"
> +/include/ "dra7xx-resets.dtsi"
> diff --git a/arch/arm/boot/dts/dra7xx-resets.dtsi
> b/arch/arm/boot/dts/dra7xx-resets.dtsi
> new file mode 100644
> index 000..4c4966d
> --- /dev/null
> +++ b/arch/arm/boot/dts/dra7xx-resets.dtsi
> @@ -0,0 +1,82 @@
> +/*
> + * Device Tree Source for DRA7XX reset data
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +&prm_resets {
> + dsp_rstctrl {
> + reg = <0x410>,
> + <0x414>;
> +
> + dsp_reset: dsp_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + dsp_mmu_reset: dsp_mmu_reset {
> + control-bit = <0x02>;
> + status-bit = <0x02>;
> + };
> + };
> +
> + ipu_rstctrl {
> + reg = <0x510>,
> + <0x514>;
> +
> + ipu_cpu0_reset: ipu_cpu0_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + ipu_cpu1_reset: ipu_cpu1_reset {
> + control-bit = <0x02>;
> + status-bit = <0x02>;
> + };
> +
> + ipu_mmu_reset: ipu_mmu_reset {
> + control-bit = <0x04>;
> + status-bit = <0x04>;
> + };
> + };
There are two IPUs on DRA7. Which one is this node for? And please add
the other reset node for the other IPU as well.
> +
> + iva_rstctrl {
> + reg = <0xf10>,
> + <0xf14>;
> +
> + iva_reset: iva_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
IVA also has three resets, one for logic and two for the sequencers. You
are describing only one of them.
> + };
> +
> + pcie_rstctrl {
> + reg = <0x1310>,
> + <0x1314>;
> +
> + pcie1_reset: pcie1_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> +
> + pcie2_reset: pcie2_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
Copy-paste error? Both pcie resets cannot have the same control and
status bits.
regards
Suman
> + };
> +
> + device_rstctrl {
> + reg = <0x1D00>,
> + <0x1D04>;
> +
> + device_reset: device_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> +};
>
--
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: [v3 PATCH 4/6] ARM: dts: am4372: Add prcm_resets node
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Add the prcm_resets node to the prcm parent node.
>
> Add the am34xx_resets file to define the
> am34xx reset lines that are handled by this reset
> framework.
>
> Signed-off-by: Dan Murphy
> ---
>
> v3 - No changes
>
> arch/arm/boot/dts/am4372.dtsi|7 +
> arch/arm/boot/dts/am43xx-resets.dtsi | 52
> ++
> 2 files changed, 59 insertions(+)
> create mode 100644 arch/arm/boot/dts/am43xx-resets.dtsi
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index 49fa596..d0aa9c9 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -88,6 +88,12 @@
>
> prcm_clockdomains: clockdomains {
> };
> +
> + prcm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
Should be corrected as per comment on DT bindings.
> + #reset-cells = <1>;
> + };
> };
>
> scrm: scrm@44e1 {
> @@ -892,3 +898,4 @@
> };
>
> /include/ "am43xx-clocks.dtsi"
> +/include/ "am43xx-resets.dtsi"
> diff --git a/arch/arm/boot/dts/am43xx-resets.dtsi
> b/arch/arm/boot/dts/am43xx-resets.dtsi
> new file mode 100644
> index 000..ef338ba
> --- /dev/null
> +++ b/arch/arm/boot/dts/am43xx-resets.dtsi
> @@ -0,0 +1,52 @@
> +/*
> + * Device Tree Source for AM43XX reset data
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +&prcm_resets {
> + icss_rstctrl {
> + reg = <0x810>,
> + <0x814>;
> +
> + icss_reset: icss_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> + gfx_rstctrl {
> + reg = <0x410>,
> + <0x414>;
> +
> + gfx_reset: gfx_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> + per_rstctrl {
> + reg = <0x2010>,
> + <0x2014>;
> +
> + iva_reset: iva_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
There's no IVA on AM4372. Looking at the offset, it looks like you were
defining this for the WkupM3, in which case you got the initial node
name wrong. The PER rstctrl has the reset management for PRU-ICSS, so
you also need to correct the icss_rstctrl accordingly.
regards
Suman
> + };
> +
> + device_rstctrl {
> + reg = <0x4000>,
> + <0x4004>;
> +
> + device_reset: device_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> +};
>
--
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: [v3 PATCH 3/6] ARM: dts: am33xx: Add prcm_resets node
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Add the prcm_resets node to the prcm parent node.
>
> Add the am33xx_resets file to define the
> am33xx reset lines that are handled by this reset
> framework.
>
> Signed-off-by: Dan Murphy
> ---
>
> v3 - No changes
>
> arch/arm/boot/dts/am33xx-resets.dtsi | 42
> ++
> arch/arm/boot/dts/am33xx.dtsi|7 ++
> 2 files changed, 49 insertions(+)
> create mode 100644 arch/arm/boot/dts/am33xx-resets.dtsi
>
> diff --git a/arch/arm/boot/dts/am33xx-resets.dtsi
> b/arch/arm/boot/dts/am33xx-resets.dtsi
> new file mode 100644
> index 000..9260626
> --- /dev/null
> +++ b/arch/arm/boot/dts/am33xx-resets.dtsi
> @@ -0,0 +1,42 @@
> +/*
> + * Device Tree Source for AM33XX reset data
> + *
> + * Copyright (C) 2014 Texas Instruments, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +&prcm_resets {
> + gfx_rstctrl {
> + reg = <0x1104>,
> + <0x1114>;
> +
> + gfx_reset: gfx_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> + per_rstctrl {
> + reg = <0xD00>,
> + <0xD0C>;
> +
> + iva_reset: iva_reset {
There is no IVA on AM33xx, this should be corrected to reflect the PRU_ICSS.
> + control-bit = <0x04>;
> + status-bit = <0x10>;
> + };
> + };
Not defining the WkupM3 reset control?
> +
> + device_rstctrl {
> + reg = <0xf00>,
> + <0xf08>;
> +
> + device_reset: device_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4a4e02d..5cdc8f0 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -117,6 +117,12 @@
>
> prcm_clockdomains: clockdomains {
> };
> +
> + prcm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
Should be corrected as per comment on DT bindings.
regards
Suman
> + #reset-cells = <1>;
> + };
> };
>
> scrm: scrm@44e1 {
> @@ -834,3 +840,4 @@
> };
>
> /include/ "am33xx-clocks.dtsi"
> +/include/ "am33xx-resets.dtsi"
>
--
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: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
On Thu, 17 Jul 2014, Tony Lindgren wrote: > * Paul Walmsley [140716 11:59]: > > On Wed, 16 Jul 2014, Sebastian Andrzej Siewior wrote: > > > > > On 2014-07-15 20:21:21 [+], Paul Walmsley wrote: > > > > > > > > Acked-by: Sebastian Andrzej Siewior > > > > > > > > > > This is basically what Tony hasked me to do: No IRQ numbers & iomem. > > > > > > > > Sorry - I'm a bit confused - Sebastian, did you test this one? If so, > > > > is > > > > it okay to add a Tested-by from you? > > > > > > Tested-by: Sebastian Andrzej Siewior > > > > Thanks Sebastian. > > > > Mugunthan, next step would be for you to get a Reviewed-by: by someone who > > has access to the (non-public) DRA7xx TRM, and can review for SoC > > integration. Since Rajendra is no longer at TI, the right person is > > probably Tony. > > > > Then this patch should be mergeable. > > Yeah took a look at it and acked it. Thanks queued for 3.17. - 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: [v3 PATCH 2/6] dt: TI: Describe the ti reset DT entries
Hi Dan,
On 07/17/2014 11:45 AM, Murphy, Dan wrote:
> Describe the TI reset DT entries for TI SoC's.
The document definitely needs some cleanup. Here are comments from a
quick glance. In any case, I think this binding will change as you
address Tony's comments.
>
> Signed-off-by: Dan Murphy
> ---
>
> v3 - Changed Headline no other changes
>
> .../devicetree/bindings/reset/ti,reset.txt | 103
>
> 1 file changed, 103 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/ti,reset.txt
> b/Documentation/devicetree/bindings/reset/ti,reset.txt
> new file mode 100644
> index 000..9d5c29c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/ti,reset.txt
> @@ -0,0 +1,103 @@
> +Texas Instruments Reset Controller
> +==
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +Specifying the reset entries for the IP module
> +==
> +Parent module:
> +This is the module node that contains the reset registers and bits.
> +
> +example:
> + prcm_resets: resets {
> + compatible = "ti,dra7-resets";
> + #reset-cells = <1>;
> + };
> +
> +Required parent properties:
> +- compatible : Should be one of,
> + "ti,omap4-prm" for OMAP4 PRM instances
> + "ti,omap5-prm" for OMAP5 PRM instances
> + "ti,dra7-prm" for DRA7xx PRM instances
> + "ti,am4-prcm" for AM43xx PRCM instances
> + "ti,am3-prcm" for AM33xx PRCM instances
I am not sure if this belongs to the reset driver bindings, as the PRM
and CM nodes are defined at the SoC level. This document should only be
describing the reset nodes bindings.
Also, please list all the required node properties first, before you can
give an example.
> +
> +Required child reset property:
> +- compatible : Should be
> + "resets" for All TI SoCs
There is no "compatible" child property. This should have been the name
of the node, right? Also, please list all the properties required under
this node like #address-cells, #reset-cells etc.
> +
> +example:
> + prm: prm@4ae06000 {
> + compatible = "ti,omap5-prm";
> + reg = <0x4ae06000 0x3000>;
> +
> + prm_resets: resets {
> + #address-cells = <1>;
> + #size-cells = <1>;
This is wrong. You haven't corrected this from v2. The reg field is used
to give the offsets for control register and status register, and does
not use any size fields.
> + #reset-cells = <1>;
> + };
> + };
> +
> +
> +Reset node declaration
> +==
> +The reset node is declared in a parent child relationship. The main parent
> +is the PRCM module which contains the base address. The first child within
> +the reset parent declares the target modules reset name. This is followed by
> +the control and status offsets.
This is not clear. This is the case with each child node, which is
describing a particular reset domain, and then the individual resets
themselves are defined as child nodes of this reset domain child node.
> +
> +Within the first reset child node is a secondary child node which declares
> the
> +reset signal of interest. Under this node the control and status bits
> +are declared. These bits declare the bit mask for the target reset.
> +
> +
> +Required properties:
> +reg - This is the register offset from the PRCM parent.
> + This must be declared as:
> +
> + reg = ,
> + ;
> +
> +control-bit - This is the bit within the register which controls the reset
> + of the target module. This is declared as a bit mask for the register.
> +status-bit - This is the bit within the register which contains the status of
> + the reset of the target module.
> + This is declared as a bit mask for the register.
> +
> +example:
> +&prm_resets {
> + dsp_rstctrl {
> + reg = <0x1c00>,
> + <0x1c04>;
I guess both these entries can be defined in one line.
> +
> + dsp_reset: dsp_reset {
> + control-bit = <0x01>;
> + status-bit = <0x01>;
> + };
> + };
> +};
> +
> +
> +
> +Client Node Declaration
> +==
> +This is the consumer of the parent node to declare what resets this
> +particular module is interested in.
> +
> +example:
> + src: src@55082000 {
> + resets = <&reset_src phandle>;
> + reset-names = "";
> + };
> +
> +Required Properties:
> +reset_src - This is the parent DT entry for the reset controller
>
Re: [PATCH] pinctrl: dra: dt-bindings: Fix pull enable/disable
On 07/22/2014 11:47 AM, Felipe Balbi wrote:
> On Tue, Jul 22, 2014 at 10:39:54AM -0500, Nishanth Menon wrote:
>> The DRA74/72 control module pins have a weak pull up and pull down.
>> This is configured by bit offset 17. if BIT(17) is 1, a pull up is
>> selected, else a pull down is selected.
>>
>> However, this pull resisstor is applied based on BIT(16) -
>> PULLUDENABLE - if BIT(18) is *0*, then pull as defined in BIT(17) is
>> applied, else no weak pulls are applied. We defined this in reverse.
>>
>> Reference: Table 18-5 (Description of the pad configuration register
>> bits) in Technical Reference Manual Revision (DRA74x revision Q:
>> SPRUHI2Q Revised June 2014 and DRA72x revision F: SPRUHP2F - Revised
>> June 2014)
>>
>> Fixes: 6e58b8f1daaf1a ("ARM: dts: DRA7: Add the dts files for dra7 SoC and
>> dra7-evm board")
>> Signed-off-by: Nishanth Menon
>> ---
>
> Tested on an upcoming board.
>
> Tested-by: Felipe Balbi
> Acked-by: Felipe Balbi
>
>
Felipe,
Thanks.
Tony,
If you could consider this for the rc cycle it might be great(as well
as for stable). The pull direction error can cause all kinds of
Pull-down Vs Pull-Up contention with severe risk for certain IP
reliability.
--
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 2/2] ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
On 07/16/2014 03:36 AM, Lokesh Vutla wrote:
> From: Rajendra Nayak
>
> To deal with IPs which are specific to dra74x and dra72x, maintain seperate
> ocp interface lists, while keeping the common list for all common IPs.
>
> Move USB OTG SS4 to dra74x only list since its unavailable in
> dra72x and is giving an abort during boot. The dra72x only list
> is empty for now and a placeholder for future hwmod additions which
> are specific to dra72x.
>
> Fixes: d904b38 ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
please use a format as following:
Fixes: d904b38df0db13 ("ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss")
> Reported-by: Keerthy
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/mach-omap2/omap_hwmod.c |3 +++
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 --
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 6c074f3..14f8370 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -3345,6 +3345,9 @@ int __init omap_hwmod_register_links(struct
> omap_hwmod_ocp_if **ois)
> if (!ois)
> return 0;
>
> + if (ois[0] == NULL) /*empty list*/
/* Empty list */ ?
> + return 0;
> +
This change looks like a different patch?
> if (!linkspace) {
> if (_alloc_linkspace(ois)) {
> pr_err("omap_hwmod: could not allocate link space\n");
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 284324f..c95033c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -35,6 +35,7 @@
> #include "i2c.h"
> #include "mmc.h"
> #include "wd_timer.h"
> +#include "soc.h"
>
> /* Base offset for all DRA7XX interrupts external to MPUSS */
> #define DRA7XX_IRQ_GIC_START 32
> @@ -2705,7 +2706,6 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
> __initdata = {
> &dra7xx_l4_per3__usb_otg_ss1,
> &dra7xx_l4_per3__usb_otg_ss2,
> &dra7xx_l4_per3__usb_otg_ss3,
> - &dra7xx_l4_per3__usb_otg_ss4,
> &dra7xx_l3_main_1__vcp1,
> &dra7xx_l4_per2__vcp1,
> &dra7xx_l3_main_1__vcp2,
> @@ -2714,8 +2714,26 @@ static struct omap_hwmod_ocp_if
> *dra7xx_hwmod_ocp_ifs[] __initdata = {
> NULL,
> };
>
> +static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
> + &dra7xx_l4_per3__usb_otg_ss4,
> + NULL,
> +};
> +
> +static struct omap_hwmod_ocp_if *dra72x_hwmod_ocp_ifs[] __initdata = {
> + NULL,
> +};
> +
> int __init dra7xx_hwmod_init(void)
> {
> + int ret;
> +
> omap_hwmod_init();
> - return omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
> + ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
if (ret)
goto out;
> +
> + if (!ret && soc_is_dra74x())
no need of !ret
> + return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
> + else if (!ret && soc_is_dra72x())
no need of else and !ret
> + return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
> +
out:
> + return ret;
> }
>
--
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] pinctrl: dra: dt-bindings: Fix pull enable/disable
On Tue, Jul 22, 2014 at 10:39:54AM -0500, Nishanth Menon wrote:
> The DRA74/72 control module pins have a weak pull up and pull down.
> This is configured by bit offset 17. if BIT(17) is 1, a pull up is
> selected, else a pull down is selected.
>
> However, this pull resisstor is applied based on BIT(16) -
> PULLUDENABLE - if BIT(18) is *0*, then pull as defined in BIT(17) is
> applied, else no weak pulls are applied. We defined this in reverse.
>
> Reference: Table 18-5 (Description of the pad configuration register
> bits) in Technical Reference Manual Revision (DRA74x revision Q:
> SPRUHI2Q Revised June 2014 and DRA72x revision F: SPRUHP2F - Revised
> June 2014)
>
> Fixes: 6e58b8f1daaf1a ("ARM: dts: DRA7: Add the dts files for dra7 SoC and
> dra7-evm board")
> Signed-off-by: Nishanth Menon
> ---
Tested on an upcoming board.
Tested-by: Felipe Balbi
Acked-by: Felipe Balbi
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2] ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() varients
On 07/16/2014 03:36 AM, Lokesh Vutla wrote:
> From: Rajendra Nayak
>
> Use the corresponding compatibles to identify the devices.
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Lokesh Vutla
> ---
> arch/arm/mach-omap2/soc.h |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index 01ca808..5e1be94 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -245,6 +245,8 @@ IS_AM_SUBCLASS(437x, 0x437)
> #define soc_is_omap54xx()0
> #define soc_is_omap543x()0
> #define soc_is_dra7xx() 0
> +#define soc_is_dra74x() 0
> +#define soc_is_dra72x() 0
>
> #if defined(MULTI_OMAP2)
> # if defined(CONFIG_ARCH_OMAP2)
> @@ -393,7 +395,12 @@ IS_OMAP_TYPE(3430, 0x3430)
>
> #if defined(CONFIG_SOC_DRA7XX)
> #undef soc_is_dra7xx
> +#undef soc_is_dra74x
> +#undef soc_is_dra72x
> #define soc_is_dra7xx() (of_machine_is_compatible("ti,dra7"))
> +#define soc_is_dra74x() (of_machine_is_compatible("ti,dra74"))
> +#define soc_is_dra72x() (of_machine_is_compatible("ti,dra72"))
> +
> #endif
>
> /* Various silicon revisions for omap2 */
>
Acked-by: Nishanth Menon
--
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 0/2] ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists
On 07/16/2014 03:36 AM, Lokesh Vutla wrote: > This series add seperate ocp interface lists that are specific to dra74x > and dra72x, and moving USB OTG SS4 to dra74x only since its not present > in dra72x. Without this USB OTG SS4 hwmod gives an abort on dra72x. > > Adding support for soc_is_dra74x() and soc_is_dra72x() in order to > differentiate > between dra74x and dra72x and pass the respective ocp interface lists. > > Verified on dra74x evm and dra72x evm using 3.16-rc5 based mainline kernel. > > Before: > dra74x : http://paste.ubuntu.com/7802364/ > dra72x : http://paste.ubuntu.com/7802334/ (Kernel panic) > > After- > dra74x : http://paste.ubuntu.com/7802340/ > dra72x : http://paste.ubuntu.com/7802338/ (booted) > > Rajendra Nayak (2): > ARM: DRA7: Add support for soc_is_dra74x() and soc_is_dra72x() > varients > ARM: DRA7: hwmod: Add dra74x and dra72x specific ocp interface lists > > arch/arm/mach-omap2/omap_hwmod.c |3 +++ > arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 22 -- > arch/arm/mach-omap2/soc.h |7 +++ > 3 files changed, 30 insertions(+), 2 deletions(-) > Tested-by: Nishanth Menon BUT, I suggest a follow up series to do exactly the same (moving stuff that are not common from dra7.dtsi to dra72x.dtsi and 74x.dtsi) as well to ensure that dts indicates exactly the same information (only the applicable IPs are present in dts). -- 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 v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Tue, 22 Jul 2014, Felipe Balbi wrote:
> On Tue, Jul 22, 2014 at 04:45:03PM +0100, Lee Jones wrote:
> > > > > > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > > > > > +{
> > > > > > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > > > > +
> > > > > > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
> > > > > > + reg &= ~sw_pipew_reset_n(1);
> > > > >
> > > > > 1? Better to add defines for these magic numbers. What is 1 anyway?
> > > >
> > > > They are just bit setting macros, I've converted them over to use BIT
> > > > macro now,
> > > > so it no longer takes a parameter.
> > >
> > > the macros are better, but make them upper case as everybody else.
> >
> > When you say that the macros are better, what do you mean?
> >
> > Defines do the job in a manner which is a great deal cleaner:
> >
> > #define AUX_CLK_ENBIT(0)
> > #define SW_PIPEW_RESET_N BIT(4)
> > #define EXT_CFG_RESET_N BIT(8)
> > #define XHCI_REVISION BIT(12)
> >
> > reg = AUX_CLK_EN | SW_PIPEW_RESET_N | XHCI_REVISION;
> > reg &= ~SW_PIPEW_RESET_N
>
> this is what I meant ;-) I see what I wrote can be very ambiguous :-p
Okay great, thanks for clarifying. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
On Tue, Jul 22, 2014 at 04:45:03PM +0100, Lee Jones wrote:
> > > > > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > > > > +{
> > > > > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > > > +
> > > > > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
> > > > > + reg &= ~sw_pipew_reset_n(1);
> > > >
> > > > 1? Better to add defines for these magic numbers. What is 1 anyway?
> > >
> > > They are just bit setting macros, I've converted them over to use BIT
> > > macro now,
> > > so it no longer takes a parameter.
> >
> > the macros are better, but make them upper case as everybody else.
>
> When you say that the macros are better, what do you mean?
>
> Defines do the job in a manner which is a great deal cleaner:
>
> #define AUX_CLK_ENBIT(0)
> #define SW_PIPEW_RESET_N BIT(4)
> #define EXT_CFG_RESET_N BIT(8)
> #define XHCI_REVISION BIT(12)
>
> reg = AUX_CLK_EN | SW_PIPEW_RESET_N | XHCI_REVISION;
> reg &= ~SW_PIPEW_RESET_N
this is what I meant ;-) I see what I wrote can be very ambiguous :-p
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] pinctrl: dra: dt-bindings: Fix pull enable/disable
> 1: dra72x-evm: Boot ok: http://slexy.org/raw/s20I6QXQa (needs MMC filesystem > that current dts does not have. Oops - missed a character in the link: http://slexy.org/view/s20I6QXQal Sorry about the spam. -- 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 v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
> > > > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > > > +{
> > > > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > > +
> > > > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
> > > > + reg &= ~sw_pipew_reset_n(1);
> > >
> > > 1? Better to add defines for these magic numbers. What is 1 anyway?
> >
> > They are just bit setting macros, I've converted them over to use BIT macro
> > now,
> > so it no longer takes a parameter.
>
> the macros are better, but make them upper case as everybody else.
When you say that the macros are better, what do you mean?
Defines do the job in a manner which is a great deal cleaner:
#define AUX_CLK_ENBIT(0)
#define SW_PIPEW_RESET_N BIT(4)
#define EXT_CFG_RESET_N BIT(8)
#define XHCI_REVISION BIT(12)
reg = AUX_CLK_EN | SW_PIPEW_RESET_N | XHCI_REVISION;
reg &= ~SW_PIPEW_RESET_N
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] pinctrl: dra: dt-bindings: Fix pull enable/disable
The DRA74/72 control module pins have a weak pull up and pull down.
This is configured by bit offset 17. if BIT(17) is 1, a pull up is
selected, else a pull down is selected.
However, this pull resisstor is applied based on BIT(16) -
PULLUDENABLE - if BIT(18) is *0*, then pull as defined in BIT(17) is
applied, else no weak pulls are applied. We defined this in reverse.
Reference: Table 18-5 (Description of the pad configuration register
bits) in Technical Reference Manual Revision (DRA74x revision Q:
SPRUHI2Q Revised June 2014 and DRA72x revision F: SPRUHP2F - Revised
June 2014)
Fixes: 6e58b8f1daaf1a ("ARM: dts: DRA7: Add the dts files for dra7 SoC and
dra7-evm board")
Signed-off-by: Nishanth Menon
---
Patch based on v3.16-rc5 tag
1: dra72x-evm: Boot ok: http://slexy.org/raw/s20I6QXQa (needs MMC filesystem
that current dts does not have.
- Fails in plain Vanilla 3.16-rc5 kernel due to missing patch to handle
USB IP instance delta (between dra72x and dra74x) appropriately.
- Tested with fixes needed: https://patchwork.kernel.org/patch/4565431/
and https://patchwork.kernel.org/patch/4565461/
2: dra7xx-evm: Boot PASS: http://slexy.org/raw/s21c6X2wOd
Equivalent testing on 3.14 based product kernel:
dra72x-evm: Boot PASS: http://slexy.org/raw/s21yIgttJw
dra7xx-evm: Boot PASS: http://slexy.org/raw/s20w7OZaJJ
It is obvious that current users of padconf have'nt had trouble with
the wrong definitions. I think I might have been the first to discover
this as emmc on beagleboard-X15 (an upcoming platform) exposed this problem.
include/dt-bindings/pinctrl/dra.h |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/dt-bindings/pinctrl/dra.h
b/include/dt-bindings/pinctrl/dra.h
index 002a285..3d33794 100644
--- a/include/dt-bindings/pinctrl/dra.h
+++ b/include/dt-bindings/pinctrl/dra.h
@@ -30,7 +30,8 @@
#define MUX_MODE14 0xe
#define MUX_MODE15 0xf
-#define PULL_ENA (1 << 16)
+#define PULL_ENA (0 << 16)
+#define PULL_DIS (1 << 16)
#define PULL_UP(1 << 17)
#define INPUT_EN (1 << 18)
#define SLEWCONTROL(1 << 19)
@@ -38,10 +39,10 @@
#define WAKEUP_EVENT (1 << 25)
/* Active pin states */
-#define PIN_OUTPUT 0
+#define PIN_OUTPUT (0 | PULL_DIS)
#define PIN_OUTPUT_PULLUP (PIN_OUTPUT | PULL_ENA | PULL_UP)
#define PIN_OUTPUT_PULLDOWN(PIN_OUTPUT | PULL_ENA)
-#define PIN_INPUT INPUT_EN
+#define PIN_INPUT (INPUT_EN | PULL_DIS)
#define PIN_INPUT_SLEW (INPUT_EN | SLEWCONTROL)
#define PIN_INPUT_PULLUP (PULL_ENA | INPUT_EN | PULL_UP)
#define PIN_INPUT_PULLDOWN (PULL_ENA | INPUT_EN)
--
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 v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi,
On Tue, Jul 22, 2014 at 10:18:00AM +0100, Peter Griffin wrote:
> > > +static inline u32 st_dwc3_readl(void __iomem *base, u32 offset)
> > > +{
> > > + return readl_relaxed(base + offset);
> > > +}
> > > +
> > > +static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32
> > > value)
> > > +{
> > > + writel_relaxed(value, base + offset);
> > > +}
> >
> > Why are these being abstracted?
> >
> > Just use {read,write}l_relaxed() directly.
>
> Ok, unabstracted in v3
no, no... all other glues add their own local helpers for register
access. This is good for tracing, it's very easy to add a tracepoint to
this sort of function and get very low overhead tracing of every
register access.
> > > + if (dwc3_data->drd_device_conf)
> > > + val |= USB_SET_PORT_DEVICE;
> > > + else
> > > + val &= USB_HOST_DEFAULT_MASK;
> > > +
> > > + return regmap_write(dwc3_data->regmap, dwc3_data->syscfg_reg_off, val);
> > > +}
> > > +
> > > +/**
> > > + * st_dwc3_init: init the controller via glue logic
> > > + * @dwc3_data: driver private structure
> > > + */
> > > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > > +{
> > > + u32 reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > +
> > > + reg |= aux_clk_en(1) | ext_cfg_reset_n(1) | xhci_revision(1);
> > > + reg &= ~sw_pipew_reset_n(1);
> >
> > 1? Better to add defines for these magic numbers. What is 1 anyway?
>
> They are just bit setting macros, I've converted them over to use BIT macro
> now,
> so it no longer takes a parameter.
the macros are better, but make them upper case as everybody else.
> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
> > > +
> > > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1);
> > > + reg |= SEL_OVERRIDE_VBUSVALID(1) | SEL_OVERRIDE_POWERPRESENT(1) |
> > > + SEL_OVERRIDE_BVALID(1);
> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_VBUS_MNGMNT_SEL1, reg);
> > > + udelay(100);
> >
> > Why 100?
>
> I've asked ST how this value was derirved and why. It came from validation.
> The docs don't mention that it is necessary, and removing it
> seems to have no ill effects. So I've removed this udelay in v3.
make sure to test with many, many iterations just to make sure.
> > > + reg = st_dwc3_readl(dwc3_data->glue_base, USB2_CLKRST_CTRL);
> > > + reg |= sw_pipew_reset_n(1);
> > > + st_dwc3_writel(dwc3_data->glue_base, USB2_CLKRST_CTRL, reg);
> > > +}
> > > +
> > > +static void st_dwc3_dt_get_pdata(struct platform_device *pdev,
> > > + struct st_dwc3 *dwc3_data)
> > > +{
> > > + struct device_node *np = pdev->dev.of_node;
> > > +
> > > + dwc3_data->drd_device_conf =
> > > + of_property_read_bool(np, "st,dwc3-drd-device");
> >
> > This requires a DT Ack.
>
> Ok. Do the DT folks have any comment on this?
look at the child's dr-mode property instead of adding your own.
> > > + dwc3_data->glue_base = devm_request_and_ioremap(dev, res);
use devm_ioremap_resource()
> > > + regmap = syscon_regmap_lookup_by_phandle(node, "st,syscfg");
> > > + if (IS_ERR(regmap))
> > > + return PTR_ERR(regmap);
> > > +
> > > + dwc3 = platform_device_alloc("st-dwc3", PLATFORM_DEVID_AUTO);
> > > + if (!dwc3) {
> > > + dev_err(&pdev->dev, "couldn't allocate dwc3 device\n");
> > > + return -ENOMEM;
> > > + }
> >
> > I'm confused. What is this doing? Isn't this the DWC3 driver, which
> > already had a platform device structure associated to it? Perhaps a
> > small ASCII diagram describing the layers might be useful.
>
> Your right, this was wrong. It was some legacy code which is
> unnecessary and I've removed this in v3.
if you're going for DT, why don't you create the parent and the child
from DT as omap/exynos/qcom are doing ?
> > > + dma_set_coherent_mask(&dwc3->dev, dev->coherent_dma_mask);
> > > +
> > > + dwc3->dev.parent = &pdev->dev;
> > > + dwc3->dev.dma_mask = pdev->dev.dma_mask;
> > > + dwc3->dev.dma_parms = pdev->dev.dma_parms;
stick to DT device creation. Look into dwc3-omap.c
> > > +static int st_dwc3_remove(struct platform_device *pdev)
> > > +{
> > > + struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
> > > +
> > > + platform_device_unregister(dwc3_data->dwc3);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +#ifdef CONFIG_PM_SLEEP
> > > +static int st_dwc3_suspend(struct device *dev)
> > > +{
> > > + struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
> > > +
> > > + reset_control_assert(dwc3_data->rstc_pwrdn);
> > > +
> > > + pinctrl_pm_select_sleep_state(dev);
pinctrl will select sleep and default states automatically for you.
--
balbi
signature.asc
Description: Digital signature
[PATCH] drivers/misc/ti-st: Load firmware from ti-connectivity directory.
Looks like the default location for TI firmware is inside the ti-connectivity
directory, to be coherent with other firmware request used by TI drivers, load
the TIInit firmware from this directory instead of /lib/firmware directly.
Signed-off-by: Enric Balletbo i Serra
---
drivers/misc/ti-st/st_kim.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
index 9d3dbb2..fa6a900 100644
--- a/drivers/misc/ti-st/st_kim.c
+++ b/drivers/misc/ti-st/st_kim.c
@@ -244,7 +244,8 @@ static long read_local_version(struct kim_data_s
*kim_gdata, char *bts_scr_name)
if (version & 0x8000)
maj_ver |= 0x0008;
- sprintf(bts_scr_name, "TIInit_%d.%d.%d.bts", chip, maj_ver, min_ver);
+ sprintf(bts_scr_name, "ti-connectivity/TIInit_%d.%d.%d.bts",
+ chip, maj_ver, min_ver);
/* to be accessed later via sysfs entry */
kim_gdata->version.full = version;
@@ -287,7 +288,7 @@ static long download_firmware(struct kim_data_s *kim_gdata)
long len = 0;
unsigned char *ptr = NULL;
unsigned char *action_ptr = NULL;
- unsigned char bts_scr_name[30] = { 0 }; /* 30 char long bts scr name? */
+ unsigned char bts_scr_name[40] = { 0 }; /* 40 char long bts scr name? */
int wr_room_space;
int cmd_size;
unsigned long timeout;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] ARM: DRA7: hwmod: Add data for RTC
Hi Paul,
On Wednesday 09 July 2014 02:05 PM, Lokesh Vutla wrote:
> Add hwmod data for RTC
>
> Signed-off-by: Lokesh Vutla
> Signed-off-by: Sekhar Nori
> Reviewed-by: Rajendra Nayak
Can you take this patch. I have submitted logs also.
Thanks and regards,
Lokesh
> ---
> Changes since V1:
> Rebased on top of linux-next 20140708.
>
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41
> +
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 20b4398..d8032b9 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = {
> };
>
> /*
> + * 'rtcss' class
> + *
> + */
> +static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = {
> + .sysc_offs = 0x0078,
> + .sysc_flags = SYSC_HAS_SIDLEMODE,
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +SIDLE_SMART_WKUP),
> + .sysc_fields= &omap_hwmod_sysc_type3,
> +};
> +
> +static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
> + .name = "rtcss",
> + .sysc = &dra7xx_rtcss_sysc,
> +};
> +
> +/* rtcss */
> +static struct omap_hwmod dra7xx_rtcss_hwmod = {
> + .name = "rtcss",
> + .class = &dra7xx_rtcss_hwmod_class,
> + .clkdm_name = "rtc_clkdm",
> + .main_clk = "sys_32k_ck",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET,
> + .context_offs = DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
> +/*
> * 'sata' class
> *
> */
> @@ -2344,6 +2376,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi
> = {
> .user = OCP_USER_MPU | OCP_USER_SDMA,
> };
>
> +/* l4_per3 -> rtcss */
> +static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = {
> + .master = &dra7xx_l4_per3_hwmod,
> + .slave = &dra7xx_rtcss_hwmod,
> + .clk= "l4_root_clk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = {
> {
> .name = "sysc",
> @@ -2673,6 +2713,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
> __initdata = {
> &dra7xx_l4_cfg__mpu,
> &dra7xx_l4_cfg__ocp2scp1,
> &dra7xx_l3_main_1__qspi,
> + &dra7xx_l4_per3__rtcss,
> &dra7xx_l4_cfg__sata,
> &dra7xx_l4_cfg__smartreflex_core,
> &dra7xx_l4_cfg__smartreflex_mpu,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
> Thanks for reviewing, see my comments inline below: - In future, it's best to only reply to questions, or review comments that you disagree with. Anything that you will action or agree with can be snipped along with any irrelevant code from your reply and replaced with "" or "[...]". If you are planning on actioning everything and no not disagree with anything there's no need to reply at all. [...] -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
On Thursday 17 July 2014 01:19 PM, Tony Lindgren wrote: > We seem to have this layout WR_SOFT_RESET and WR_CONTROL in the TRM: > > WR_SOFT_RESET > [0] SOFT_RESET > > WR_CONTROL > [3:2] MMR_STDBYMODE 0 = force-idle, 1 = no-standby > [1:0] MMR_IDLEMODE0 = force-idle, 1 = no-idle > > And so it seems to match what am33xx also has for am33xx_cpgmac_sysc > and am33xx TRM for 14.5.9 CONTROL register. So as far as I'm concerned: > > Acked-by: Tony Lindgren Paul, Can you pull this patch as Tony acked the patch. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi Jingoo,
Sorry for the delay in replying. Thanks for reviewing,
see my comments inline below: -
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Would you re-order these headers alphabetically?
> It enhances the readability.
Ok fixed in V3
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg-glue");
> > + if (!res)
> > + return -ENXIO;
> > +
> > + dwc3_data->glue_base = devm_request_and_ioremap(dev, res);
>
> Please don't use devm_request_and_ioremap() any more. It was deprecated
> and will be removed from 3.17-rc1.
>
> Please, use devm_ioremap_resource() instead.
Ok changed over to use devm_ioremap_resource in V3.
>
> + dwc3_data->glue_base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(dwc3_data->glue_base))
> + return PTR_ERR(dwc3_data->glue_base);
>
> > + if (!dwc3_data->glue_base)
> > + return -EADDRNOTAVAIL;
> > +
> > +
> > +static const struct dev_pm_ops st_dwc3_dev_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(st_dwc3_suspend, st_dwc3_resume)
> > +};
> > +
> > +static struct of_device_id st_dwc3_match[] = {
>
> Please add 'const' as below. This is because all OF functions
> handle of_device_id as const.
>
> static const struct of_device_id st_dwc3_match[] = {
Ok, fixed in V3
>
> > + { .compatible = "st,stih407-dwc3" },
> > + { /* sentinel */ },
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, st_dwc3_match);
> > +
> > +static struct platform_driver st_dwc3_driver = {
> > + .probe = st_dwc3_probe,
> > + .remove = st_dwc3_remove,
> > + .driver = {
> > + .name = "usb-st-dwc3",
> > + .owner = THIS_MODULE,
> > + .of_match_table = of_match_ptr(st_dwc3_match),
>
> You already use OF dependency as below. So, of_match_ptr() is
> NOT necessary.
>
> +config USB_DWC3_ST
> + tristate "STMicroelectronics Platforms"
> + depends on ARCH_STI && OF
>
> Please remove of_match_ptr() as below.
>
> + .of_match_table = st_dwc3_match,
Ok fixed in V3
regards,
Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi Lee, Thanks for reviewing, see my comments inline below: - On Mon, 07 Jul 2014, Lee Jones wrote: > On Sat, 05 Jul 2014, Peter Griffin wrote: > > > This patch adds the ST glue logic to manage the DWC3 HC > > on STiH407 SoC family. It manages the powerdown signal, > > and configures the internal glue logic and syscfg registers. > > > > Signed-off-by: Giuseppe Cavallaro > > Signed-off-by: Peter Griffin > > --- > > drivers/usb/dwc3/Kconfig | 9 ++ > > drivers/usb/dwc3/Makefile | 1 + > > drivers/usb/dwc3/dwc3-st.c | 325 > > + > > 3 files changed, 335 insertions(+) > > create mode 100644 drivers/usb/dwc3/dwc3-st.c > > > > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig > > index 8eb996e..6c85c43 100644 > > --- a/drivers/usb/dwc3/Kconfig > > +++ b/drivers/usb/dwc3/Kconfig > > @@ -79,6 +79,15 @@ config USB_DWC3_KEYSTONE > > Support of USB2/3 functionality in TI Keystone2 platforms. > > Say 'Y' or 'M' here if you have one such device > > > > +config USB_DWC3_ST > > + tristate "STMicroelectronics Platforms" > > + depends on ARCH_STI && OF > > + default USB_DWC3_HOST > > + help > > + STMicroelectronics SoCs with one DesignWare Core USB3 IP > > + inside (i.e. STiH407). > > + Say 'Y' or 'M' if you have one such device. > > + > > comment "Debugging features" > > > > config USB_DWC3_DEBUG > > diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile > > index 10ac3e7..11c9f54 100644 > > --- a/drivers/usb/dwc3/Makefile > > +++ b/drivers/usb/dwc3/Makefile > > @@ -33,3 +33,4 @@ obj-$(CONFIG_USB_DWC3_OMAP) += dwc3-omap.o > > obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o > > obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o > > obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o > > +obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o > > diff --git a/drivers/usb/dwc3/dwc3-st.c b/drivers/usb/dwc3/dwc3-st.c > > new file mode 100644 > > index 000..2cae9d3 > > --- /dev/null > > +++ b/drivers/usb/dwc3/dwc3-st.c > > @@ -0,0 +1,325 @@ > > +/** > > + * dwc3-st.c Support for dwc3 platform devices on ST Microelectronics > > platforms > > + * > > + * This is a small platform driver for the dwc3 to provide the glue logic > > + * to configure the controller. Tested on STi platforms. > > Not sure about the use of the term 'platform driver' here and in the > title. We don't normally differentiate. I can find examples to the > contrary, but not many. Ok, removed 'platform' in V3 > > > + * Copyright (C) 2014 Stmicroelectronics > > + * > > + * Author: Giuseppe Cavallaro > > + * Contributors: Aymen Bouattay > > + * Peter Griffin > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License as published by > > + * the Free Software Foundation; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + * Inspired by dwc3-omap.c and dwc3-exynos.c. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "core.h" > > +#include "io.h" > > + > > +/* Reg glue registers */ > > +#define USB2_CLKRST_CTRL 0x00 > > +#define aux_clk_en(n) ((n)<<0) > > +#define sw_pipew_reset_n(n) ((n)<<4) > > +#define ext_cfg_reset_n(n) ((n)<<8) > > +#define xhci_revision(n) ((n)<<12) > > These all need reformatting, see CodingStyle - 3.1: Spaces Ok I have added a space either side of the shift operator and aligned using tabs. > > #define xhci_revision(n) ((n) << 12) > > Lining them up with TABs would make them easier to read. Ok fixed in v3 > > Also, I don't think there is a requirement to encapsulate the 'n'. Ok removed brackets around the 'n' > > > +#define USB2_VBUS_MNGMNT_SEL1 0x2C > > +/* > > + * 2'b00 : Override value from Reg 0x30 is selected > > + * 2'b01 : utmiotg_vbusvalid from usb3_top top is selected > > + * 2'b10 : pipew_powerpresent from PIPEW instance is selected > > + * 2'b11 : value is 1'b0 > > + */ > > What is this documenting? Isn't documentation meant to make things > clearer? Now I'm just really confused - by the documentation. It is documenting the bitfields in VBUS_MNGMNT_SEL1 register. I've hopefully made it a bit clearer by adding the following comment and slightly adjusting the descriptions a little. /* * For all fields in USB2_VBUS_MNGMNT_SEL1 * 2’b00 : Override value from Reg 0x30 is selected * 2’b01 : utmiotg_ from usb3_top is selected * 2’b10 : pipew_ from PIPEW instance is selected * 2’b11 : value is 1'b0 */ Apart from that it's a standard way to describe bitfields. You can find some examples in cx231xx-pcb-cfg.h, bnx2x_link.h and cx231xx-avcore.c > > > +#define SEL_OVERRIDE_VBUSVALID(n) ((n)<<0) > > +#define SEL_OVERRIDE_POWERPRESEN
Re: [PATCH 1/7] arm: dts: omap3-gta04: Add nand support
On Tue, Jul 22, 2014 at 8:24 AM, Tony Lindgren wrote: > * Marek Belisko [140721 14:08]: > > Can you please add the descriptions to all the patches? OK thanks for review. I'll send v2. > Other than that looks OK to me. > > Regards, > > Tony BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.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
