Re: [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
* Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 11:17]: Hi Tony and Joerg, On Monday 21 July 2014 02:33:36 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140721 02:16]: Hi Suman, Joerg and Tony, 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 s-a...@ti.com 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 t...@atomide.com 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 :) 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: AM3517 fails to boot 3.16-rc5 device tree kernel
* Michael Welling mwell...@emacinc.com [140721 17:17]: On Mon, Jul 21, 2014 at 11:38 AM, Michael Welling mwell...@emacinc.com wrote: On Mon, Jul 21, 2014 at 12:09:13AM -0700, Tony Lindgren wrote: * Michael Welling mwell...@emacinc.com [140718 07:42]: On Fri, Jul 18, 2014 at 1:38 AM, Tony Lindgren t...@atomide.com wrote: Hmm maybe double check your're booting device tree based kernel instead of legacy machine ID based kernel? The legacy booting should still work just fine and no changes has been made to it, but it will get removed shortly. I downloaded the version from the test results and it did boot. OK that's good to hear. These are combining the uImage and dtb. How do you accomplish this? You need to make sure you have the appended DTB support enabled like we do in omap2plus_defconfig: CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y Then just cat zImage board.dtb /tmp/zImage-dtba and run mkimage to convert it to a uImage: $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/zImage-dtba /tmp/uImage I actually discovered this and got LCD video working. Now USB host is not working. The only thing that registers is the OHCI/EHCI hosts. root@som3517:~# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Not sure what the problem is. The USB devices that are plugged in are powered but never detected. Any hints? So I got the USB host to work on boot with additional entries in the devicetree. Documentation/devicetree/bindings/omap-usb-host.txt Though the devices work if plugged in at boot, any time a device is hotplugged then the device is not detected. It is powered very briefly and then off without any kernel messages. So hints from this point would be good. Sorry no idea on that, maybe send a separate email about that with the USB and PHY people in Cc. 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 1/7] arm: dts: omap3-gta04: Add nand support
* Marek Belisko ma...@goldelico.com [140721 14:08]: Can you please add the descriptions to all the patches? Other than that looks OK to me. 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 V2 1/2] ARM: OMAP2+: DMA: remove requirement of irq for platform-dma driver
* Sricharan R r.sricha...@ti.com [140612 04:48]: From: Nishanth Menon n...@ti.com we have currently 2 DMA drivers that try to co-exist. drivers/dma/omap-dma.c which registers it's own IRQ and is device tree aware and uses arch/arm/plat-omap/dma.c instance created by arch/arm/mach-omap2/dma.c to maintain channel usage (omap_request_dma). Currently both try to register interrupts and mach-omap2/plat-omap dma.c attempts to use the IRQ number registered by hwmod to register it's own interrupt handler. Now, there is no reasonable way of static allocating DMA irq in GIC SPI when we use crossbar. However, since the dma_chan structure is freed as a result of IRQ not being present due to devm allocation, maintaining information of channel by platform code fails at a later point in time when that region of memory is reused. So, if hwmod does not indicate an IRQ number, then, assume that dma-engine will take care of the interrupt handling. Looks OK to me, applying both into omap-for-v3.17/soc thanks. 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 1/7] arm: dts: omap3-gta04: Add nand support
On Tue, Jul 22, 2014 at 8:24 AM, Tony Lindgren t...@atomide.com wrote: * Marek Belisko ma...@goldelico.com [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
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 peppe.cavall...@st.com Signed-off-by: Peter Griffin peter.grif...@linaro.org --- 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 peppe.cavall...@st.com + * Contributors: Aymen Bouattay aymen.bouat...@st.com + * Peter Griffin peter.grif...@linaro.org + * + * 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 linux/module.h +#include linux/kernel.h +#include linux/slab.h +#include linux/interrupt.h +#include linux/platform_device.h +#include linux/ioport.h +#include linux/io.h +#include linux/of.h +#include linux/of_platform.h +#include linux/mfd/syscon.h +#include linux/delay.h +#include linux/regmap.h +#include linux/reset.h + +#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_signal_name from usb3_top is selected * 2’b10 : pipew_signal_name 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
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: -
snip
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/ioport.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/mfd/syscon.h
+#include linux/delay.h
+#include linux/regmap.h
+#include linux/reset.h
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;
+
snip
+
+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: [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 t...@atomide.com 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
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 snip 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: [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 lokeshvu...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
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
[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 eballe...@iseebcn.com
---
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/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] 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 n...@ti.com --- 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
+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
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
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 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 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 n...@ti.com 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 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 rna...@ti.com Use the corresponding compatibles to identify the devices. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- 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 n...@ti.com -- 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 n...@ti.com --- Tested on an upcoming board. Tested-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
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 rna...@ti.com
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 j-keer...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
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 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 n...@ti.com --- Tested on an upcoming board. Tested-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com 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: [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 dmur...@ti.com
---
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 register offset,
+ status register offset;
+
+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 = reset_name;
+ };
+
+Required Properties:
+reset_src - This is the parent DT entry for the reset controller
+phandle - This is the phandle of the specific reset to be used by the clien
+
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 p...@pwsan.com [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 sebast...@breakpoint.cc 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 sebast...@breakpoint.cc 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 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 dmur...@ti.com
---
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: [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 dmur...@ti.com
---
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 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 dmur...@ti.com
---
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 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 dmur...@ti.com
---
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: [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 lokeshvu...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com 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
[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
[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 ma...@goldelico.com
---
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 6/7] arm: dts: omap3-gta04: Add display alias
Define alias for lcd display present on gta04 board.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
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 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 ma...@goldelico.com
---
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 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 ma...@goldelico.com
---
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 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 ma...@goldelico.com
---
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 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 ma...@goldelico.com
---
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 ma...@goldelico.com
---
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
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 ma...@goldelico.com
---
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
Re: [PATCH v2 2/7] arm: dts: omap3-gta04: Fix magnetometer model
On Tue, Jul 22, 2014 at 9:46 PM, Peter Meerwald pme...@pmeerw.net 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 ma...@goldelico.com
---
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
[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 ma...@goldelico.com
---
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: [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 dmur...@ti.com
---
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 dmur...@ti.com
+ *
+ * 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 linux/delay.h
+#include linux/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_address.h
This header is no longer needed, now that you are not using of_iomap.
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/reset.h
+#include linux/reset-controller.h
+#include linux/slab.h
+#include linux/spinlock.h
+
+#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
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: [PATCH v2] ARM: AM43xx: hwmod: add DSS hwmod data
On Tue, 17 Jun 2014, Tomi Valkeinen wrote:
From: Sathya Prakash M R sath...@ti.com
Add DSS hwmod data for AM43xx.
Signed-off-by: Sathya Prakash M R sath...@ti.com
[tomi.valkei...@ti.com: added missing dispc flags]
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Rajendra Nayak rna...@ti.com
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 sath...@ti.com
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 sath...@ti.com
[tomi.valkei...@ti.com: added missing dispc flags]
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Rajendra Nayak rna...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Tested-by: Felipe Balbi ba...@ti.com # on linux-next 5f295cdf5c5d
[p...@pwsan.com: fixed build break on AM43xx-only config]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
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 = {
+
[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
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
Re: Nokia N900 FB regression?
On Tue, Jul 22, 2014 at 5:23 PM, Aaro Koskinen aaro.koski...@iki.fi 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
Re: Nokia N900 FB regression?
On Tue, Jul 22, 2014 at 6:02 PM, Nick Krause xerofo...@gmail.com wrote:
On Tue, Jul 22, 2014 at 5:23 PM, Aaro Koskinen aaro.koski...@iki.fi 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: [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 eballe...@iseebcn.com --- 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: [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 laurent.pinch...@ideasonboard.com [140721 11:17]: On Monday 21 July 2014 02:33:36 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [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 s-a...@ti.com 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 t...@atomide.com 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 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 rna...@ti.com
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 j-keer...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
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 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 n...@ti.com 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
