Re: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
On Wednesday 02 July 2014 05:24 PM, Nick Dyer wrote: On 02/07/14 11:49, Sekhar Nori wrote: On Tuesday 01 July 2014 09:44 PM, Stephen Warren wrote: On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at least a valid) choice. That's probably because the Atmel IRQ signal is routed to our GPIO controller, which is also an IRQ controller, and then forwarded up the chain to the GIC, with the polarity the GIC expects. If IRQ_TRIGGER_FALLING doesn't work everywhere, then we'll need to add some kind of DT property to configure the polarity of the IRQ output. Yeah, I think so too. Nick, If you are going to rebase your branch, will you be able to fold in the patch in my previous e-mail? Else, I can send a more formal patch to you. Either IRQF_TRIGGER_FALLING or IRQF_TRIGGER_LOW will work with these chips (it isn't a question of polarity but whether it's edge- or level- triggered). There isn't a sensible default. Atmel prefer IRQF_TRIGGER_LOW, however I've seen some IRQ controllers will revert to a polled mode for IRQF_TRIGGER_LOW, which kills performance. So, the sensible course of action seems to be to remove the default IRQF_TRIGGER_FALLING in the device tree parsing, and provide a device tree parameter for the flags. If you agree, I will sort this out at my end, you don't need to send a patch. Sounds good. I have to leave it in in the case where there is neither static platform data, or device tree node, because that is used for some systems, but that shouldn't affect either of you. BTW, I do have a set of patches ready to send, once this change is made. It will be great if you could CC me on that posting so I could test and ack. Regards, Sekhar -- 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: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Suman, On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna s-a...@ti.com wrote: I'm not sure we need this patch. This patch is needed if we use the controller-phandle + args specifier for requesting hwlocks by a client, as we need to translate controller-phandle to the corresponding hwspinlock_device. Looks like we still don't have a closure on the semantics of how clients have to request a lock in DT. You are suggesting something like hwlocks = global_lock1 global_lock2 ...; whereas this patch is built to support based on comments from DT-maintainers, hwlocks = controller-phandle lock-specifier1, controller-phandle lock-specifier2...; I'm actually ok with this suggestion and haven't suggested otherwise. All I propose is that we add the base_id property to the controller node (as you have done in the subsequent patches), and then drivers will be able to infer the global lock id from the DT data by adding the controller's base_id to the lock specifier. Controllers with non standard lock indexing may use an xlate() method if needed but frankly this is fictional right now. We can start without this, and add it later when needed, as this doesn't affect the DT data. With the global lock id in hand, drivers could simply use the existing hwspin_lock_request_specific API to obtain a specific lock, and then we don't need this patch. Thanks, Ohad. -- 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: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Suman, On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna s-a...@ti.com wrote: Do we have a use case today that require the xlate() method? If not, let's remove it as we could always add it back if some new hardware shows up that needs it. The xlate() method is to support the phandle + args specifier way of requesting hwlocks, platform implementations are free to implement their own xlate functions, but the above supports the simplest case of controller + relative lock index within controller. Do we have a use case for a different implementation other than the simplest case? If not, it seems to me this will just become redundant boilerplate code (every platform will use the simple xlate method). This function again is to support the phandle + args specifier way of requesting hwlocks, the hwspin_lock_request_specific() is invoked internally within this function, so we are still reusing the actual request code other than handling the DT parsing portion. If we go back to using global locks in client hwlocks property, we don't need a of_hwspin_lock_get_id(), the same can be achieved using the existing DT function, of_property_read_u32_index(). I think you may have misunderstood me, sorry. I'm ok with the phandle + args specifier. I just think we can use it, together with the base_id property, to infer the global lock id from the DT data. This is not only a must to support heterogenous multi-processing systems, it will also substantially simplify the code. Thanks, Ohad. -- 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: [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
On Wed, Jul 2, 2014 at 10:42 PM, Suman Anna s-a...@ti.com wrote: Yeah, I did this since we only had 1 instance, and used the same value as used in the non-DT legacy code. Once I fold back Patch 8 that adds the hwlock-base-id property, this will be assigned by reading that property. Sounds good, thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
* Robert Nelson robertcnel...@gmail.com [140702 12:27]: On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote: It has been only tested as console UART. The tty name is ttyS based instead of ttyO. How big is the pain here, what could be the easiest way to provide compatibility? have been considering that myself for months. You could pass an optional argument to serial8250_register_8250_port() but that only solves part of the problem :-( Some kind of compability layer sure would be nice. When ttyS - ttyO change was done on OMAP, compatibility was not an issue. Why should we care about it now? It would be a good opportunity to force everyone to update their bootloader. ;) Besides the BeagleBoard forum is quiet now, no one is complaining about that old (ttyS - ttyO) transition anymore.. How about a Kconfig option to provide ttyO by default? The not even do that if kernel has cmdline option nottyomap. I'll just end up carrying a patch like, to support bb.org users over the transition.. https://github.com/RobertCNelson/stable-kernel/blob/v3.7.x/patches/omap_beagle/0004-zeroMAP-Open-your-eyes.patch Heh. Just to summarize the reason ttyO needs to be a separate name and device entry from ttyS is because we also have external 8250 devices on GPMC and hotplug busses. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
On 07/01/2014 10:48 PM, Felipe Balbi wrote:
Hi,
On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous default, and causes problems on AM43x when
using display and ethernet. There are multiple ways to select the clock
muxes on AM43x, and some of those clock paths have the same source
clocks for display and ethernet. When changing the clock rate for the
display subsystem, the clock framework decides to change the display mux
from the dedicated display PLL to a shared PLL which is used by the
ethernet, and then changes the rate of the shared PLL, breaking the
ethernet.
As I don't think there ever is a case where we want the clock framework
to automatically change the parent clock of a clock mux, this patch sets
the CLK_SET_RATE_NO_REPARENT for all ti,mux-clocks.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index 0197a478720c..e9d650e51287 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -160,7 +160,7 @@ static void of_mux_clk_setup(struct device_node *node)
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
- u32 flags = 0;
+ u32 flags = CLK_SET_RATE_NO_REPARENT;
num_parents = of_clk_get_parent_count(node);
if (num_parents 2) {
Thanks, queued for 3.16-rc fixes.
did you skip a few -rcs by any chance? Looks like this could've been
merged on v3.16-rc3... Just checking.
This goes through Mike's clk tree, so there is extra latency there. Not
sure when he plans to send next pull-req for clk-fixes to linux-master.
-Tero
--
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: am335x: system doesn't reboot after flashing NAND
+ Nishant. On 07/02/2014 06:45 PM, Yegor Yefremov wrote: On Fri, Jun 6, 2014 at 11:33 AM, Roger Quadros rog...@ti.com wrote: On 06/05/2014 01:07 PM, Yegor Yefremov wrote: On Thu, Jun 5, 2014 at 12:02 PM, Roger Quadros rog...@ti.com wrote: On 06/04/2014 10:45 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 12:52 PM, Sekhar Nori nsek...@ti.com wrote: On Wednesday 04 June 2014 04:00 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 12:20 PM, Sekhar Nori nsek...@ti.com wrote: On Wednesday 04 June 2014 03:11 PM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 10:48 AM, Roger Quadros rog...@ti.com wrote: Hi, On 06/04/2014 11:25 AM, Yegor Yefremov wrote: On Wed, Jun 4, 2014 at 8:40 AM, Sekhar Nori nsek...@ti.com wrote: On Tuesday 03 June 2014 04:18 PM, Yegor Yefremov wrote: On Tue, Jun 3, 2014 at 9:57 AM, Yegor Yefremov yegorsli...@googlemail.com wrote: Kernel: 3.14, 3.15 (I haven't tried another kernels) As soon as I write something to my NAND flash (via cat image /dev/mtdblockx or ubiupdatevol) and make reboot or press a reset button, I see only C and nothing happens before I make a power cycle. Any idea? Just forgot to mention, that I was actually booting from MMC (mmc1). The boot sequence is UART0...XIP...MMC0...NAND. Can you try to get XIP out of the boot sequence and see if it works? Maybe try to boot from mmc directly? This would prove that NAND/GPMC driver is leaving some state that doesn't go well with the bootROM XIP. This configuration is soldered. It won't be easy to change. Most likely XIP is the issue if sysboot has not changed. The way ROM works for XIP boot is: 1) Set chip select 0 base address to 0x0800' 2) Read memory at 0x0800' 3) If something else other than 0x0 or ~0x0 is found, jump to 0x0800' and start executing. Can you check to see the contents of 0x0800' before and after nand write using mtdblock? Before writing: # devmem 0x0800 32 0x After writing: # devmem 0x0800 32 0xE0E0E0E0 Okay, so this is the cause of failure to boot. I am not sure what operation by NAND driver causes this value to change. Perhaps you could bisect a bit by dumping this address at various points during the write operation? If you have a debugger it will become easy to do this. The 0x8000 address seems to be the beginning of NAND region: ranges = 0 0 0x0800 0x1000; /* CS0: NAND */ I've taken this example from am335x_evm.dts. I have tried to change the mapping to 0x9000, but kernel still uses 0x8000, Where in the kernel will ranges be evaluated? I'm digging thorugh arch/arm/mach-omap2/gpmc.c and gpmc-nand.c, but didn't really found the place. Well it doesn't. It just uses whatever was setup by the bootloader or randomly allocated by gpmc_cs_request(). I'm working on fixing this up. I should be posting v2 of the GPMC refactor series by this week and you should be able to map the CS region as specified in the DT. Till then, maybe you can pre-configure CS0 in the bootloader to wherever you want or alternatively call gpmc_cs_remap() after the gpmc_cs_request() in gpmc_nand_init(); I've found the stuff in bootloader and mapped NAND to 0x0900, but it didn't help. Not sure why it didn't work. Was the CSVALID bit in GPMC_CONFIG7_0 register set? If you are daring enough ;), you could try out the cleaned up GPMC code where remapping should work. I still need to do some final touches before I can post it to mailing list. g...@github.com:rogerq/linux.git gpmc-3.16-temp There are some subtle changes you need to do to the GPMC/Nand node. e.g. adding compatible_id, 2nd register space and interrupts. For a working example, please see omap3-beagle.dts. And finally you need to enable CONFIG_TI_GPMC, which is a new kernel config option. Have attached my BDI2000 to the am335x and found out, that ROM boot stops at 0x00020084. AFAIK it can be wrong address exception. Need to debug further. Unfortunately I cannot use OpenOCD and my Jtagkey debugger :-( Have also tried 3.16-rc3 without using flash and it freezes during reboot from time time, but I can reboot via reset button. With 3.15 and NAND reset button doesn't help. OK, so it is not NAND related but more soft reboot related. Have you checked that all power supplies are stable when you soft reboot? cheers, -roger -- 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 3/6] phy: core: Support regulator supply for PHY power
On 07/02/2014 03:32 PM, Sergei Shtylyov wrote:
Hello.
On 07/02/2014 04:03 PM, Roger Quadros wrote:
Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-core.c | 32
include/linux/phy/phy.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 49c4465..d817107 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
[...]
@@ -664,6 +689,10 @@ EXPORT_SYMBOL_GPL(devm_phy_create);
void phy_destroy(struct phy *phy)
{
pm_runtime_disable(phy-dev);
+
+if (phy-pwr)
+regulator_put(phy-pwr);
regulator_put() already handles NULL pointer.
Good to know that. I'll remove the 'if' then.
cheers,
-roger
+
device_unregister(phy-dev);
}
EXPORT_SYMBOL_GPL(phy_destroy);
@@ -800,6 +829,9 @@ static void phy_release(struct device *dev)
phy = to_phy(dev);
dev_vdbg(dev, releasing '%s'\n, dev_name(dev));
+if (phy-pwr)
+regulator_put(phy-pwr);
Same comment here.
+
ida_simple_remove(phy_ida, phy-id);
kfree(phy);
}
WBR, Sergei
--
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: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
On Wednesday 25 June 2014 11:32 PM, Kishon Vijay Abraham I wrote:
Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC.
Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro
for pcie1 phy and pcie2 phy.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Tested-by: Kishon Vijay Abraham I kis...@ti.com
Looks good to me, feel free to add
Reviewed-by: Rajendra Nayak rna...@ti.com
---
Please find the bootlog with these hwmod patches
http://paste.ubuntu.com/7701601/
arch/arm/mach-omap2/cm2_7xx.h |4 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 57
+
arch/arm/mach-omap2/prm7xx.h |4 ++
3 files changed, 65 insertions(+)
diff --git a/arch/arm/mach-omap2/cm2_7xx.h b/arch/arm/mach-omap2/cm2_7xx.h
index 9ad7594..e966e3a 100644
--- a/arch/arm/mach-omap2/cm2_7xx.h
+++ b/arch/arm/mach-omap2/cm2_7xx.h
@@ -357,6 +357,10 @@
#define DRA7XX_CM_L3INIT_SATA_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0088)
#define DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET 0x00a0
#define DRA7XX_CM_PCIE_STATICDEP_OFFSET 0x00a4
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET 0x00b0
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b0)
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET 0x00b8
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b8)
#define DRA7XX_CM_GMAC_CLKSTCTRL_OFFSET 0x00c0
#define DRA7XX_CM_GMAC_STATICDEP_OFFSET 0x00c4
#define DRA7XX_CM_GMAC_DYNAMICDEP_OFFSET 0x00c8
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 3deb76e..6ff40a6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1290,6 +1290,45 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE PHY' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_phy_hwmod_class = {
+ .name = pcie-phy,
+};
+
+/* pcie1 phy */
+static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
+ .name = pcie1-phy,
+ .class = dra7xx_pcie_phy_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 phy */
+static struct omap_hwmod dra7xx_pcie2_phy_hwmod = {
+ .name = pcie2-phy,
+ .class = dra7xx_pcie_phy_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L3INIT_PCIESS2_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'qspi' class
*
*/
@@ -2409,6 +2448,22 @@ static struct omap_hwmod_ocp_if
dra7xx_l4_cfg__ocp2scp1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - pcie1 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie1_phy_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg - pcie2 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2_phy = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie2_phy_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
{
.pa_start = 0x4b30,
@@ -2758,6 +2813,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l4_cfg__ocp2scp3,
+ dra7xx_l4_cfg__pcie1_phy,
+ dra7xx_l4_cfg__pcie2_phy,
dra7xx_l3_main_1__qspi,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
diff --git a/arch/arm/mach-omap2/prm7xx.h b/arch/arm/mach-omap2/prm7xx.h
index d92a840..4bb50fbf 100644
--- a/arch/arm/mach-omap2/prm7xx.h
+++ b/arch/arm/mach-omap2/prm7xx.h
@@ -374,6 +374,10 @@
#define DRA7XX_RM_L3INIT_IEEE1500_2_OCP_CONTEXT_OFFSET
Re: [PATCH 2/2] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
On Wednesday 25 June 2014 11:32 PM, Kishon Vijay Abraham I wrote:
Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Tested-by: Kishon Vijay Abraham I kis...@ti.com
---
Please find the bootlog with these hwmod patches
http://paste.ubuntu.com/7701601/
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 55
+
1 file changed, 55 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 6ff40a6..934aa9d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1290,6 +1290,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
};
/*
+ * 'PCIE' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+ .name = pcie,
+};
+
+/* pcie1 */
+static struct omap_hwmod dra7xx_pcie1_hwmod = {
+ .name = pcie1,
+ .class = dra7xx_pcie_hwmod_class,
+ .clkdm_name = l3init_clkdm,
The TRM tells me it belongs to 'pcie_clkdm' instead. Can you please recheck?
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* pcie2 */
+static struct omap_hwmod dra7xx_pcie2_hwmod = {
+ .name = pcie2,
+ .class = dra7xx_pcie_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'PCIE PHY' class
*
*/
@@ -2448,6 +2485,22 @@ static struct omap_hwmod_ocp_if
dra7xx_l4_cfg__ocp2scp1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - pcie1 */
There seems to be a slave port on l3_init as well which seems to be missing?
Refer to 'Figure 24-157. PCIe Controllers Integration' of TRM version P.
regards,
Rajendra
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie1_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg - pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_pcie2_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_cfg - pcie1 phy */
static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
.master = dra7xx_l4_cfg_hwmod,
@@ -2813,6 +2866,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l4_cfg__ocp2scp3,
+ dra7xx_l4_cfg__pcie1,
+ dra7xx_l4_cfg__pcie2,
dra7xx_l4_cfg__pcie1_phy,
dra7xx_l4_cfg__pcie2_phy,
dra7xx_l3_main_1__qspi,
--
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 OCP2SCP3 module
On Thursday 19 June 2014 01:20 AM, Roger Quadros wrote:
This module is needed for the SATA and PCIe PHYs.
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Roger Quadros rog...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
v2:
- added .main_clk to hwmod.
- moved interface structure to the right place.
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 24
1 file changed, 24 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..c9daee4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1215,6 +1215,21 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
},
};
+/* ocp2scp3 */
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = dra7xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'qspi' class
*
@@ -2326,6 +2341,14 @@ static struct omap_hwmod_ocp_if
dra7xx_l4_cfg__ocp2scp1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
{
.pa_start = 0x4b30,
@@ -2672,6 +2695,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_per1__mmc4,
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
+ dra7xx_l4_cfg__ocp2scp3,
dra7xx_l3_main_1__qspi,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
--
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: Fixup SATA hwmod
On Wednesday 18 June 2014 05:46 PM, Roger Quadros wrote:
Get rid of optional clock as that is now managed by the
AHCI platform driver.
The optional clock info in hwmod is actually unused for a lot of
other modules too.
http://www.spinics.net/lists/arm-kernel/msg333025.html
Correct .mpu_rt_idx to 1 as the module register space (SYSCONFIG..)
is passed as the second memory resource in the device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Tested-by: Roger Quadros rog...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index cedef6b..bc42eab 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1292,9 +1292,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class
= {
};
/* sata */
-static struct omap_hwmod_opt_clk sata_opt_clks[] = {
- { .role = ref_clk, .clk = sata_ref_clk },
-};
static struct omap_hwmod dra7xx_sata_hwmod = {
.name = sata,
@@ -1302,6 +1299,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.clkdm_name = l3init_clkdm,
.flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
@@ -1309,8 +1307,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
- .opt_clks = sata_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
};
/*
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: dts: dra7xx-clocks: Fix the l3 and l4 clock rates
On Tuesday 27 May 2014 02:25 PM, Rajendra Nayak wrote:
Without the patch:
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck # cat clk_rate
53200
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck/l3_iclk_div # cat clk_rate
53200
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck/l3_iclk_div/l4_root_clk_div #
cat clk_rate
53200
With the patch:
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck # cat clk_rate
53200
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck/l3_iclk_div # cat clk_rate
26600
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck/l3_iclk_div/l4_root_clk_div #
cat clk_rate
13300
The l3 clock derived from core DPLL is actually a divider clock,
with the default divider set to 2. l4 then derived from l3 is a fixed factor
clock, but the fixed divider is 2 and not 1. Which means the l3 clock is
half of core DPLLs h12x2 and l4 is half of l3 (as seen with this patch)
Tero, this seems like is yet to be picked up. You see any issues with this that
needs to be
addressed?
regards,
Rajendra
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc7..a14c99b 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -673,10 +673,12 @@
l3_iclk_div: l3_iclk_div {
#clock-cells = 0;
- compatible = fixed-factor-clock;
+ compatible = ti,divider-clock;
+ ti,max-div = 2;
+ ti,bit-shift = 4;
+ reg = 0x0100;
clocks = dpll_core_h12x2_ck;
- clock-mult = 1;
- clock-div = 1;
+ ti,index-power-of-two;
};
l4_root_clk_div: l4_root_clk_div {
@@ -684,7 +686,7 @@
compatible = fixed-factor-clock;
clocks = l3_iclk_div;
clock-mult = 1;
- clock-div = 1;
+ clock-div = 2;
};
video1_clk2_div: video1_clk2_div {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: dts: dra7xx-clocks: Fix the l3 and l4 clock rates
On 07/03/2014 11:34 AM, Rajendra Nayak wrote:
On Tuesday 27 May 2014 02:25 PM, Rajendra Nayak wrote:
Without the patch:
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck # cat clk_rate
53200
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck/l3_iclk_div # cat clk_rate
53200
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck/l3_iclk_div/l4_root_clk_div # cat
clk_rate
53200
With the patch:
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck # cat clk_rate
53200
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck/l3_iclk_div # cat clk_rate
26600
/debug/.../dpll_core_x2_ck/dpll_core_h12x2_ck/l3_iclk_div/l4_root_clk_div # cat
clk_rate
13300
The l3 clock derived from core DPLL is actually a divider clock,
with the default divider set to 2. l4 then derived from l3 is a fixed factor
clock, but the fixed divider is 2 and not 1. Which means the l3 clock is
half of core DPLLs h12x2 and l4 is half of l3 (as seen with this patch)
Tero, this seems like is yet to be picked up. You see any issues with this that
needs to be
addressed?
Yea this actually looks good to me. Queued for 3.16-rc dt-clk fixes.
-Tero
regards,
Rajendra
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index cfb8fc7..a14c99b 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -673,10 +673,12 @@
l3_iclk_div: l3_iclk_div {
#clock-cells = 0;
- compatible = fixed-factor-clock;
+ compatible = ti,divider-clock;
+ ti,max-div = 2;
+ ti,bit-shift = 4;
+ reg = 0x0100;
clocks = dpll_core_h12x2_ck;
- clock-mult = 1;
- clock-div = 1;
+ ti,index-power-of-two;
};
l4_root_clk_div: l4_root_clk_div {
@@ -684,7 +686,7 @@
compatible = fixed-factor-clock;
clocks = l3_iclk_div;
clock-mult = 1;
- clock-div = 1;
+ clock-div = 2;
};
video1_clk2_div: video1_clk2_div {
--
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 v7 0/5] Input: pixcir_i2c_ts: Add Type-B Multi-touch and DT support
Hi Dmitry, Gentle reminder to pick this series for -next. Thanks :). cheers, -roger On 06/17/2014 12:31 PM, Roger Quadros wrote: Hi Dmitry, These are the pending patches that didn't go through in the 3.16 merge window. Please queue them for -next. Thanks. The series does the following - convert to Type-B multi touch protocol - support upto 5 fingers with hardware supplied tracking IDs - device tree support Tony, The last 2 patches fix the touch screen size property in the device tree since we now use the unified touch screen properties. cheers, -roger Changelog: v7: - Rebased on 3.16-rc1. v6: - Use unified touchscreen bindings. - Update pointer math i.e. bufptr += 4 instead of bufptr[4]; v5: - Changed ts-exiting flag to ts-running in patch 2. - Don't call pixcir_stop() from .suspend() if wakeup is required. v4: - Imporved pixcir_stop() as per Dmitry's suggestion. - Removed unnecessary input_unregister_device() from .remove(). v3: - Rebased to 3.15-rc3 - Fixed suspend while touchscreen in use - Fixed module removal while touchscreen in use v2: - Addressed review comments and re-arranged patch order v1: - http://article.gmane.org/gmane.linux.kernel/1616417 -- Roger Quadros (5): Input: pixcir_i2c_ts: Use Type-B Multi-Touch protocol Input: pixcir_i2c_ts: support upto 5 fingers and hardware provided tracking IDs Input: pixcir_i2c_ts: Add device tree support ARM: dts: am43x-epos-evm: Update binding for touchscreen size ARM: dts: am437x-gp-evm: Update binding for touchscreen size .../bindings/input/touchscreen/pixcir_i2c_ts.txt | 26 +++ .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/am437x-gp-evm.dts| 4 +- arch/arm/boot/dts/am43x-epos-evm.dts | 4 +- drivers/input/touchscreen/pixcir_i2c_ts.c | 251 ++--- include/linux/input/pixcir_ts.h| 12 + 6 files changed, 259 insertions(+), 39 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt -- 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/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
From: Roger Quadros rog...@ti.com After clarification from the hardware team it was found that this 1.8V PHY supply can't be switched OFF when SoC is Active. Since the PHY IPs don't contain isolation logic built in the design to allow the power rail to be switched off, there is a very high risk of IP reliability and additional leakage paths which can result in additional power consumption. The only scenario where this rail can be switched off is part of Power on reset sequencing, but it needs to be kept always-on during operation. This patch is required for proper functionality of USB, SATA and PCIe on DRA7-evm. CC: Rajendra Nayak rna...@ti.com CC: Tero Kristo t-kri...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/dra7-evm.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 4adc280..8308954 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -240,6 +240,7 @@ regulator-name = ldo3; regulator-min-microvolt = 180; regulator-max-microvolt = 180; + regulator-always-on; regulator-boot-on; }; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/6] phy: core: Support regulator supply for PHY power
From: Roger Quadros rog...@ti.com
Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-core.c | 27 +++
include/linux/phy/phy.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 49c4465..2add59c 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -21,6 +21,7 @@
#include linux/phy/phy.h
#include linux/idr.h
#include linux/pm_runtime.h
+#include linux/regulator/consumer.h
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
@@ -226,6 +227,12 @@ int phy_power_on(struct phy *phy)
if (!phy)
return 0;
+ if (phy-pwr) {
+ ret = regulator_enable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
ret = phy_pm_runtime_get_sync(phy);
if (ret 0 ret != -ENOTSUPP)
return ret;
@@ -247,6 +254,8 @@ int phy_power_on(struct phy *phy)
out:
mutex_unlock(phy-mutex);
phy_pm_runtime_put_sync(phy);
+ if (phy-pwr)
+ regulator_disable(phy-pwr);
return ret;
}
@@ -272,6 +281,9 @@ int phy_power_off(struct phy *phy)
mutex_unlock(phy-mutex);
phy_pm_runtime_put(phy);
+ if (phy-pwr)
+ regulator_disable(phy-pwr);
+
return 0;
}
EXPORT_SYMBOL_GPL(phy_power_off);
@@ -588,6 +600,16 @@ struct phy *phy_create(struct device *dev, const struct
phy_ops *ops,
goto free_phy;
}
+ /* phy-supply */
+ phy-pwr = regulator_get_optional(dev, phy);
+ if (IS_ERR(phy-pwr)) {
+ if (PTR_ERR(phy-pwr) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto free_ida;
+ }
+ phy-pwr = NULL;
+ }
+
device_initialize(phy-dev);
mutex_init(phy-mutex);
@@ -617,6 +639,9 @@ put_dev:
put_device(phy-dev); /* calls phy_release() which frees resources */
return ERR_PTR(ret);
+free_ida:
+ ida_simple_remove(phy_ida, phy-id);
+
free_phy:
kfree(phy);
return ERR_PTR(ret);
@@ -664,6 +689,7 @@ EXPORT_SYMBOL_GPL(devm_phy_create);
void phy_destroy(struct phy *phy)
{
pm_runtime_disable(phy-dev);
+ regulator_put(phy-pwr);
device_unregister(phy-dev);
}
EXPORT_SYMBOL_GPL(phy_destroy);
@@ -800,6 +826,7 @@ static void phy_release(struct device *dev)
phy = to_phy(dev);
dev_vdbg(dev, releasing '%s'\n, dev_name(dev));
+ regulator_put(phy-pwr);
ida_simple_remove(phy_ida, phy-id);
kfree(phy);
}
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 2760744..9a86945 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -18,6 +18,7 @@
#include linux/of.h
#include linux/device.h
#include linux/pm_runtime.h
+#include linux/regulator/consumer.h
struct phy;
@@ -65,6 +66,7 @@ struct phy {
int init_count;
int power_count;
struct phy_attrsattrs;
+ struct regulator*pwr;
};
/**
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: DTS: am335x-evmsk: Enable the McASP FIFO for audio
The use of FIFO in McASP can reduce the risk of audio under/overrun and
lowers the load on the memories since the DMA will operate in bursts.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ab9a34ce524c..80a3b215e7d6 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -560,8 +560,8 @@
serial-dir = /* 0: INACTIVE, 1: TX, 2: RX */
0 0 1 2
;
- tx-num-evt = 1;
- rx-num-evt = 1;
+ tx-num-evt = 32;
+ rx-num-evt = 32;
};
tscadc {
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: DTS: am335x-evm: Enable the McASP FIFO for audio
The use of FIFO in McASP can reduce the risk of audio under/overrun and
lowers the load on the memories since the DMA will operate in bursts.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index ecb267767cf5..e2156a583de7 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -529,8 +529,8 @@
serial-dir = /* 0: INACTIVE, 1: TX, 2: RX */
0 0 1 2
;
- tx-num-evt = 1;
- rx-num-evt = 1;
+ tx-num-evt = 32;
+ rx-num-evt = 32;
};
tps {
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: system doesn't reboot after flashing NAND
On Thursday 03 July 2014 02:45 AM, Yegor Yefremov wrote: Btw how can I debug the kernel via JTAG? I've read, that one must activate JTAG clock or something like this. What is the proper way to do this in 3.15 - 3.16? Please try with Lokesh's patch here: http://www.spinics.net/lists/arm-kernel/msg320801.html Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DRA7: hwmod: add entry for RTCSS
On Friday 09 May 2014 06:07 PM, Sekhar Nori wrote:
From: Lokesh Vutla lokeshvu...@ti.com
RTCSS on DRA7 provides a precise real-time clock.
Add hwmod entry for this IP.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
---
Applies to linux-next of 5th May.
Might need a repost with rebase on the latest mainline.
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 810c205..402ffc7 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
*
*/
@@ -2354,6 +2386,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,
@@ -2683,6 +2723,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l3_main_1__qspi,
+ dra7xx_l4_per3__rtcss,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
dra7xx_l4_cfg__smartreflex_mpu,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
On Wednesday 02 July 2014 04:56 PM, Roger Quadros wrote: Sekhar, On 06/18/2014 02:19 PM, Rajendra Nayak wrote: On Wednesday 18 June 2014 04:40 PM, Roger Quadros wrote: + Nishant and Rajendra for review. On 05/05/2014 12:54 PM, Roger Quadros wrote: Add the sysconfig class bits for the Super Speed USB controllers CC: Paul Walmsley p...@pwsan.com Signed-off-by: Roger Quadros rog...@ti.com verified against TRM version vP, looks good to me. Reviewed-by: Rajendra Nayak rna...@ti.com Could you please give your Tested-by tag for this? Then we can take this into 3.16-rc. Boot tested on my DRA7x EVM. Boot log here: http://paste.ubuntu.com/7741337/ Tested-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar -- 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/3] OMAP: dra7: hwmod: Fixes for 3.16
Hi, For your convenience I have collected the 3 hwmod patches that were floating around and added the Reviewed-by and Tested-by tags. Please queue them for 3.16-rc. Thanks. Patches are also available in my git tree g...@github.com:rogerq/linux.githwmod-v3.16-v2 cheers, -roger Roger Quadros (3): ARM: DRA7: hwmod: Add OCP2SCP3 module ARM: DRA7: hwmod: Fixup SATA hwmod ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 42 +++ 1 file changed, 37 insertions(+), 5 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
Add the sysconfig class bits for the Super Speed USB
controllers
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Tested-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 5ea094a..c87d10e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1742,8 +1742,20 @@ static struct omap_hwmod dra7xx_uart6_hwmod = {
*
*/
+static struct omap_hwmod_class_sysconfig dra7xx_usb_otg_ss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_DMADISABLE | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
static struct omap_hwmod_class dra7xx_usb_otg_ss_hwmod_class = {
.name = usb_otg_ss,
+ .sysc = dra7xx_usb_otg_ss_sysc,
};
/* usb_otg_ss1 */
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] ARM: DRA7: hwmod: Fixup SATA hwmod
Get rid of optional clock as that is now managed by the
AHCI platform driver.
Correct .mpu_rt_idx to 1 as the module register space (SYSCONFIG..)
is passed as the second memory resource in the device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Tested-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index c9daee4..5ea094a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1283,9 +1283,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class = {
};
/* sata */
-static struct omap_hwmod_opt_clk sata_opt_clks[] = {
- { .role = ref_clk, .clk = sata_ref_clk },
-};
static struct omap_hwmod dra7xx_sata_hwmod = {
.name = sata,
@@ -1293,6 +1290,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.clkdm_name = l3init_clkdm,
.flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = func_48m_fclk,
+ .mpu_rt_idx = 1,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
@@ -1300,8 +1298,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
- .opt_clks = sata_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
};
/*
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] ARM: DRA7: hwmod: Add OCP2SCP3 module
This module is needed for the SATA and PCIe PHYs.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Rajendra Nayak rna...@ti.com
Tested-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 24
1 file changed, 24 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..c9daee4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1215,6 +1215,21 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
},
};
+/* ocp2scp3 */
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
+ .name = ocp2scp3,
+ .class = dra7xx_ocp2scp_hwmod_class,
+ .clkdm_name = l3init_clkdm,
+ .main_clk = l4_root_clk_div,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'qspi' class
*
@@ -2326,6 +2341,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
+ .master = dra7xx_l4_cfg_hwmod,
+ .slave = dra7xx_ocp2scp3_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
{
.pa_start = 0x4b30,
@@ -2672,6 +2695,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_per1__mmc4,
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
+ dra7xx_l4_cfg__ocp2scp3,
dra7xx_l3_main_1__qspi,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
On Thu, Jul 03, 2014 at 12:34:11AM -0700, Tony Lindgren wrote: * Robert Nelson robertcnel...@gmail.com [140702 12:27]: On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote: It has been only tested as console UART. The tty name is ttyS based instead of ttyO. How big is the pain here, what could be the easiest way to provide compatibility? have been considering that myself for months. You could pass an optional argument to serial8250_register_8250_port() but that only solves part of the problem :-( Some kind of compability layer sure would be nice. When ttyS - ttyO change was done on OMAP, compatibility was not an issue. Why should we care about it now? It would be a good opportunity to force everyone to update their bootloader. ;) Besides the BeagleBoard forum is quiet now, no one is complaining about that old (ttyS - ttyO) transition anymore.. How about a Kconfig option to provide ttyO by default? The not even do that if kernel has cmdline option nottyomap. what about single zImage ? I don't want to use ttyO on my Allwinner/Exynos/Snapdragon/whatever SoC just because OMAP is in the same image ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 5/6] phy: omap-usb2: Balance pm_runtime_enable() on probe failure
Hi Roger,
On Wednesday 02 July 2014 05:33 PM, Roger Quadros wrote:
If probe fails then we need to call pm_runtime_disable() to balance
out the previous pm_runtime_enable() call. Else it will cause
unbalanced pm_runtime_enable() call in the succeding probe call.
This anomaly was observed when the call to devm_phy_create() failed
with -EPROBE_DEFER.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-usb2.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..c6f9809 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -265,15 +265,19 @@ static int omap_usb2_probe(struct platform_device *pdev)
pm_runtime_enable(phy-dev);
generic_phy = devm_phy_create(phy-dev, ops, NULL);
- if (IS_ERR(generic_phy))
+ if (IS_ERR(generic_phy)) {
+ pm_runtime_disable(phy-dev);
return PTR_ERR(generic_phy);
+ }
Maybe we can move pm_runtime_enable to just before phy_provider_register?
phy_set_drvdata(generic_phy, phy);
phy_provider = devm_of_phy_provider_register(phy-dev,
of_phy_simple_xlate);
- if (IS_ERR(phy_provider))
+ if (IS_ERR(phy_provider)) {
+ pm_runtime_disable(phy-dev);
return PTR_ERR(phy_provider);
+ }
Noticed pm_runtime_disable was missing in omap_usb2_remove too. Would be good
to fix it here.
Cheers
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
On Thu, Jul 3, 2014 at 8:25 AM, Felipe Balbi ba...@ti.com wrote: On Thu, Jul 03, 2014 at 12:34:11AM -0700, Tony Lindgren wrote: * Robert Nelson robertcnel...@gmail.com [140702 12:27]: On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote: It has been only tested as console UART. The tty name is ttyS based instead of ttyO. How big is the pain here, what could be the easiest way to provide compatibility? have been considering that myself for months. You could pass an optional argument to serial8250_register_8250_port() but that only solves part of the problem :-( Some kind of compability layer sure would be nice. When ttyS - ttyO change was done on OMAP, compatibility was not an issue. Why should we care about it now? It would be a good opportunity to force everyone to update their bootloader. ;) Besides the BeagleBoard forum is quiet now, no one is complaining about that old (ttyS - ttyO) transition anymore.. How about a Kconfig option to provide ttyO by default? The not even do that if kernel has cmdline option nottyomap. what about single zImage ? I don't want to use ttyO on my Allwinner/Exynos/Snapdragon/whatever SoC just because OMAP is in the same image ;-) What if we just kept it simple, leave the ttyO driver enabled and add a warning (pr_info) that it's deprecated. It's not like it's broken, it just won't get later features or devices support added. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] Doc/DT: Add SiI9022 binding documentation
Add DT binding documentation for Silicon Image SiI9022 HDMI encoder.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/video/sil,sii9022.txt | 53 ++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/sil,sii9022.txt
diff --git a/Documentation/devicetree/bindings/video/sil,sii9022.txt
b/Documentation/devicetree/bindings/video/sil,sii9022.txt
new file mode 100644
index ..0cd926636998
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sil,sii9022.txt
@@ -0,0 +1,53 @@
+Silicon Image SiI9022 HDMI Encoder
+==
+
+Silicon Image SiI9022 is an HDMI encoder that encodes parallel RGB
+signal to HDMI signal. The SiI9022 is controlled with i2c command, and
+it has a single reset pin and single interrupt pin.
+
+Required properties:
+- compatible: sil,sii9022
+
+Optional properties:
+- reset-gpio: reset gpio
+- interrupts: interrupt line
+
+Required nodes:
+- Video port 0 for parallel video input
+- Video port 1 for HDMI output
+
+Example
+---
+
+i2c2 {
+ sii9022: sii9022@3b {
+ compatible = sil,sii9022;
+ reg = 0x3b;
+
+ reset-gpio = gpio2 1 GPIO_ACTIVE_LOW;
+
+ interrupt-parent = gpio1;
+ interrupts = 18 IRQ_TYPE_LEVEL_LOW;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ sii9022_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ sii9022_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+};
--
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 4/4] arm/dts: am437x GP HDMI support
AM437x GP board has both LCD and HDMI outputs. The active display is
selected with a GPIO, which affects video and audio signal routing, and
LCD backlight.
Managing the gpio dynamically has proven rather difficult, so the
approach taken here is just to have two separate .dts files for LCD/HDMI
use cases. The HDMI dts file includes the base file, which has LCD
support, and overrides and adds the necessary items.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am437x-gp-evm-hdmi.dts | 70
2 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am437x-gp-evm-hdmi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5a1fba6d10b5..3065fb2d113b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -302,7 +302,8 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-var-stk-om44.dtb
dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
am437x-gp-evm.dtb \
- am43x-epos-evm-hdmi.dtb
+ am43x-epos-evm-hdmi.dtb \
+ am437x-gp-evm-hdmi.dtb
dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
omap5-sbc-t54.dtb \
omap5-uevm.dtb
diff --git a/arch/arm/boot/dts/am437x-gp-evm-hdmi.dts
b/arch/arm/boot/dts/am437x-gp-evm-hdmi.dts
new file mode 100644
index ..9380a47b
--- /dev/null
+++ b/arch/arm/boot/dts/am437x-gp-evm-hdmi.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.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.
+ */
+
+/* AM437x GP EVM with HDMI output */
+
+#include am437x-gp-evm.dts
+
+/ {
+ aliases {
+ display0 = hdmi;
+ };
+
+ hdmi: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = b;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = sii9022_out;
+ };
+ };
+ };
+};
+
+i2c1 {
+ sii9022@3b {
+ compatible = sil,sii9022;
+ reg = 0x3b;
+
+ /* XXX 'SelLCDorHDMI' Gpio, LOW to select HDMI */
+ reset-gpios = gpio5 8 GPIO_ACTIVE_HIGH;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ sii9022_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ sii9022_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+};
+
+dss {
+ port {
+ dpi_out: endpoint@0 {
+ remote-endpoint = sii9022_in;
+ data-lines = 24;
+ };
+ };
+};
--
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 1/4] OMAPDSS: add SiI9022 encoder driver
Add an OMAPDSS encoder driver for Silicon Image SiI9022 HDMI encoder.
The driver supports only video at the moment, audio support will be
added separately.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/displays-new/Kconfig | 8 +
drivers/video/fbdev/omap2/displays-new/Makefile| 1 +
.../fbdev/omap2/displays-new/encoder-sii9022.c | 966 +
.../fbdev/omap2/displays-new/encoder-sii9022.h | 58 ++
4 files changed, 1033 insertions(+)
create mode 100644 drivers/video/fbdev/omap2/displays-new/encoder-sii9022.c
create mode 100644 drivers/video/fbdev/omap2/displays-new/encoder-sii9022.h
diff --git a/drivers/video/fbdev/omap2/displays-new/Kconfig
b/drivers/video/fbdev/omap2/displays-new/Kconfig
index e6cfc38160d3..f0ca306edd25 100644
--- a/drivers/video/fbdev/omap2/displays-new/Kconfig
+++ b/drivers/video/fbdev/omap2/displays-new/Kconfig
@@ -12,6 +12,14 @@ config DISPLAY_ENCODER_TPD12S015
Driver for TPD12S015, which offers HDMI ESD protection and level
shifting.
+config DISPLAY_ENCODER_SII9022
+ tristate SiI9022 HDMI Encoder
+ depends on I2C
+ help
+ Driver for Silicon Image SiI9022 HDMI encoder.
+ A brief about SiI9022 can be found here:
+
http://www.semiconductorstore.com/pdf/newsite/siliconimage/SiI9022a_pb.pdf
+
config DISPLAY_CONNECTOR_DVI
tristate DVI Connector
depends on I2C
diff --git a/drivers/video/fbdev/omap2/displays-new/Makefile
b/drivers/video/fbdev/omap2/displays-new/Makefile
index 0323a8a1c682..f7f034b1c2b7 100644
--- a/drivers/video/fbdev/omap2/displays-new/Makefile
+++ b/drivers/video/fbdev/omap2/displays-new/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_DISPLAY_ENCODER_TFP410) += encoder-tfp410.o
obj-$(CONFIG_DISPLAY_ENCODER_TPD12S015) += encoder-tpd12s015.o
+obj-$(CONFIG_DISPLAY_ENCODER_SII9022) += encoder-sii9022.o
obj-$(CONFIG_DISPLAY_CONNECTOR_DVI) += connector-dvi.o
obj-$(CONFIG_DISPLAY_CONNECTOR_HDMI) += connector-hdmi.o
obj-$(CONFIG_DISPLAY_CONNECTOR_ANALOG_TV) += connector-analog-tv.o
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-sii9022.c
b/drivers/video/fbdev/omap2/displays-new/encoder-sii9022.c
new file mode 100644
index ..955beae57e71
--- /dev/null
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-sii9022.c
@@ -0,0 +1,966 @@
+/*
+ * Silicon Image SiI9022 Encoder Driver
+ *
+ * Copyright (C) 2014 Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@ti.com
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/i2c.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/of_gpio.h
+#include linux/workqueue.h
+#include linux/of_irq.h
+#include linux/hdmi.h
+
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+#include drm/drm_edid.h
+
+#include encoder-sii9022.h
+
+static const struct regmap_config sii9022_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+ struct i2c_client *i2c_client;
+ struct gpio_desc *reset_gpio;
+ struct regmap *regmap;
+ struct omap_video_timings timings;
+ struct delayed_work work;
+ struct mutex lock;
+
+ int irq;
+ bool use_polling;
+
+ bool htplg_state;
+ bool rxsense_state;
+
+ bool hdmi_mode;
+ struct hdmi_avi_infoframe frame;
+};
+
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int sii9022_set_power_state(struct panel_drv_data *ddata,
+ enum sii9022_power_state state)
+{
+ unsigned pwr;
+ unsigned cold;
+ int r;
+
+ switch (state) {
+ case SII9022_POWER_STATE_D0:
+ pwr = 0;
+ cold = 0;
+ break;
+ case SII9022_POWER_STATE_D2:
+ pwr = 2;
+ cold = 0;
+ break;
+ case SII9022_POWER_STATE_D3_HOT:
+ pwr = 3;
+ cold = 0;
+ break;
+ case SII9022_POWER_STATE_D3_COLD:
+ pwr = 3;
+ cold = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ r = regmap_update_bits(ddata-regmap, SII9022_POWER_STATE_CTRL_REG,
+ 1 2, cold 2);
+ if (r) {
+ dev_err(ddata-i2c_client-dev, failed to set hot/cold
bit\n);
+ return r;
+ }
+
+ r = regmap_update_bits(ddata-regmap,
[PATCH 3/4] arm/dts: am43x EPOS HDMI support
AM43x EPOS board has both LCD and HDMI outputs. The active display is
selected with a GPIO, which affects video and audio signal routing, and
LCD backlight.
Managing the gpio dynamically has proven rather difficult, so the
approach taken here is just to have two separate .dts files for LCD/HDMI
use cases. The HDMI dts file includes the base file, which has LCD
support, and overrides and adds the necessary items.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/Makefile| 3 +-
arch/arm/boot/dts/am43x-epos-evm-hdmi.dts | 83 +++
2 files changed, 85 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am43x-epos-evm-hdmi.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5986ff63b901..5a1fba6d10b5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -301,7 +301,8 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-var-dvk-om44.dtb \
omap4-var-stk-om44.dtb
dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
- am437x-gp-evm.dtb
+ am437x-gp-evm.dtb \
+ am43x-epos-evm-hdmi.dtb
dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
omap5-sbc-t54.dtb \
omap5-uevm.dtb
diff --git a/arch/arm/boot/dts/am43x-epos-evm-hdmi.dts
b/arch/arm/boot/dts/am43x-epos-evm-hdmi.dts
new file mode 100644
index ..9e52b220084d
--- /dev/null
+++ b/arch/arm/boot/dts/am43x-epos-evm-hdmi.dts
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.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.
+ */
+
+/* AM43x EPOS EVM with HDMI output */
+
+#include am43x-epos-evm.dts
+
+/ {
+ aliases {
+ display0 = hdmi;
+ };
+
+ hdmi: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = b;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = sii9022_out;
+ };
+ };
+ };
+};
+
+am43xx_pinmux {
+ sii9022_pins: sii9022_pins {
+ pinctrl-single,pins =
+ 0x48 (PIN_INPUT | MUX_MODE7)/* gpmc_a2.gpio1_18 */
+ ;
+ };
+};
+
+i2c2 {
+ sii9022@3b {
+ compatible = sil,sii9022;
+ reg = 0x3b;
+
+ pinctrl-names = default;
+ pinctrl-0 = sii9022_pins;
+
+ reset-gpio = gpio2 1 GPIO_ACTIVE_LOW;/* 65'SelLCDorHDMI'
Gpio, LOW to select HDMI */
+
+ interrupt-parent = gpio1;
+ interrupts = 18 IRQ_TYPE_LEVEL_LOW;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ sii9022_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ sii9022_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+};
+
+dss {
+ port {
+ dpi_out: endpoint@0 {
+ remote-endpoint = sii9022_in;
+ data-lines = 24;
+ };
+ };
+};
--
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 0/4] SiI9022 HDMI encoder for AM4xxx boards
Hi, This series adds a driver for SiI9022 HDMI encoder, which is used on AM437x GP and AM43x EPOS boards. The series is based on the OMAPDSS HDMI infoframe series sent earlier, as the SiI9022 driver uses the new infoframe support. Tomi Tomi Valkeinen (4): OMAPDSS: add SiI9022 encoder driver Doc/DT: Add SiI9022 binding documentation arm/dts: am43x EPOS HDMI support arm/dts: am437x GP HDMI support .../devicetree/bindings/video/sil,sii9022.txt | 53 ++ arch/arm/boot/dts/Makefile | 4 +- arch/arm/boot/dts/am437x-gp-evm-hdmi.dts | 70 ++ arch/arm/boot/dts/am43x-epos-evm-hdmi.dts | 83 ++ drivers/video/fbdev/omap2/displays-new/Kconfig | 8 + drivers/video/fbdev/omap2/displays-new/Makefile| 1 + .../fbdev/omap2/displays-new/encoder-sii9022.c | 966 + .../fbdev/omap2/displays-new/encoder-sii9022.h | 58 ++ 8 files changed, 1242 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/video/sil,sii9022.txt create mode 100644 arch/arm/boot/dts/am437x-gp-evm-hdmi.dts create mode 100644 arch/arm/boot/dts/am43x-epos-evm-hdmi.dts create mode 100644 drivers/video/fbdev/omap2/displays-new/encoder-sii9022.c create mode 100644 drivers/video/fbdev/omap2/displays-new/encoder-sii9022.h -- 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 3/5] ARM: dts: AM43x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 19f1f7e..749098b 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -323,6 +323,44 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of
OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of
OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
at24@50 {
compatible = at24,24c256;
--
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
[PATCH 5/5] ARM: configs: omap2plus_defconfig: enable TPS65218 configs
Enable TPS65218 config options. Signed-off-by: Keerthy j-keer...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 536a137..f650f00 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -180,6 +180,7 @@ CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_SYSCON=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65218=y CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y CONFIG_REGULATOR_FIXED_VOLTAGE=y @@ -188,6 +189,7 @@ CONFIG_REGULATOR_TI_ABB=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y +CONFIG_REGULATOR_TPS65218=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_PBIAS=y -- 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
[PATCH 1/5] mfd: Add DT bindings for tps65218 PMIC
Add DT bindings for tps65218 PMIC
Signed-off-by: Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/tps65218.txt | 57
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..38f48ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,57 @@
+Texas Instruments TPS65218 family
+
+The TPS65218 are Integrated Power Management Chips.
+
+Required properties:
+- compatible : Must be ti,tps65218;
+ For Integrated power-management used in AM437x based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the tps65218 supports several interrupts
+ internally, it is considered as an interrupt controller cascaded to the
+ SoC one.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller which is gic.
+
+Optional node:
+- TPS65218 PMIC has a number of child nodes. Mainly the regularors and SMPSs.
+
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
--
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
[PATCH 4/5] ARM: dts: AM437x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 38 +++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 003766c..fc35d24 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -260,6 +260,44 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of
OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of
OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
};
i2c1 {
--
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
[PATCH 2/5] regulator: Add DT bindings for tps65218 PMIC regulators.
Add DT bindings for tps65218 PMIC regulators.
Signed-off-by: Keerthy j-keer...@ti.com
---
.../devicetree/bindings/regulator/tps65218.txt | 21
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..6272a73
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,21 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
+ - ti,tps65218-ldo1 for LDO1
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator@0 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
--
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
[PATCH 0/5] ARM: dts: AM43x: Add devcice tree nodes
The patch series adds the device tree nodes and the corresponding documentation. The series also enabled tps65218 config options in the omap2plus_defconfig. The series is boot tested on both AM43x-epos-evm and AM437x-gp-evm. Keerthy (5): mfd: Add DT bindings for tps65218 PMIC regulator: Add DT bindings for tps65218 PMIC regulators. ARM: dts: AM43x: Add TPS65218 device tree nodes ARM: dts: AM437x: Add TPS65218 device tree nodes ARM: configs: omap2plus_defconfig: enable TPS65218 configs Documentation/devicetree/bindings/mfd/tps65218.txt | 57 .../devicetree/bindings/regulator/tps65218.txt | 21 arch/arm/boot/dts/am437x-gp-evm.dts| 38 + arch/arm/boot/dts/am43x-epos-evm.dts | 38 + arch/arm/configs/omap2plus_defconfig |2 + 5 files changed, 156 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt -- 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: [RFC PATCH] tty: serial: Add 8250-core based omap driver
On Thu, Jul 03, 2014 at 08:34:44AM -0500, Robert Nelson wrote: On Thu, Jul 3, 2014 at 8:25 AM, Felipe Balbi ba...@ti.com wrote: On Thu, Jul 03, 2014 at 12:34:11AM -0700, Tony Lindgren wrote: * Robert Nelson robertcnel...@gmail.com [140702 12:27]: On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote: It has been only tested as console UART. The tty name is ttyS based instead of ttyO. How big is the pain here, what could be the easiest way to provide compatibility? have been considering that myself for months. You could pass an optional argument to serial8250_register_8250_port() but that only solves part of the problem :-( Some kind of compability layer sure would be nice. When ttyS - ttyO change was done on OMAP, compatibility was not an issue. Why should we care about it now? It would be a good opportunity to force everyone to update their bootloader. ;) Besides the BeagleBoard forum is quiet now, no one is complaining about that old (ttyS - ttyO) transition anymore.. How about a Kconfig option to provide ttyO by default? The not even do that if kernel has cmdline option nottyomap. what about single zImage ? I don't want to use ttyO on my Allwinner/Exynos/Snapdragon/whatever SoC just because OMAP is in the same image ;-) What if we just kept it simple, leave the ttyO driver enabled and add a warning (pr_info) that it's deprecated. It's not like it's broken, it just won't get later features or devices support added. Fine by me, I'd switch to 8250 as soon as it's merged though :-) would be nice to get an example DTS change just so I can start testing on the boards I have around. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] mfd: Add DT bindings for tps65218 PMIC
Hi,
On Thu, Jul 03, 2014 at 07:14:58PM +0530, Keerthy wrote:
Add DT bindings for tps65218 PMIC
Signed-off-by: Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/tps65218.txt | 57
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..38f48ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,57 @@
+Texas Instruments TPS65218 family
+
+The TPS65218 are Integrated Power Management Chips.
+
+Required properties:
+- compatible : Must be ti,tps65218;
+ For Integrated power-management used in AM437x based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the tps65218 supports several interrupts
+ internally, it is considered as an interrupt controller cascaded to the
+ SoC one.
+- #interrupt-cells = 2;
+- interrupt-parent : The parent interrupt controller which is gic.
+
+Optional node:
+- TPS65218 PMIC has a number of child nodes. Mainly the regularors and SMPSs.
+
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of OPP100 */
wonder if this comment really makes sense here as boards might have
another regulator assignment. Likewise fro the other two regulators.
Also, this device provides 7 regulated outputs according to [1], why
only provide three here ?
[1] http://www.ti.com/product/tps65218
--
balbi
signature.asc
Description: Digital signature
Re: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
On 02/07/14 18:25, Dmitry Torokhov wrote:
In this case board code should take care of setting up the interrupt
properly and the driver should simply use 0 as flags in request_irq().
By the way, doesn't generic DT infrastructure already allow specifying
interrupt triggers and sets them up properly?
Yes. I've checked and tested this behaviour today. If you don't specify a
trigger type, then when you request the irq it trusts that the platform has
already set it up correctly:
http://lxr.free-electrons.com/source/kernel/irq/manage.c#L1208
Stephen: you should be able to set up the interrupt config in the device
tree. I believe this should be done by putting IRQ_TYPE_LEVEL_LOW or
IRQ_TYPE_EDGE_FALLING in the third field in the interrupts definition,
although I haven't a tegra DTS device to test on at the moment.
I've applied the patch below, which is basically what Sekhar had
originally, with a minor extra fix.
I've merged it into the appropriate parts of my for upstream series at
https://github.com/ndyer/linux/commits/for-next
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscree
index dc46100..15efb3b 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1453,7 +1453,7 @@ static int mxt_check_retrigen(struct mxt_data *data)
int error;
int val;
- if (data-pdata-irqflags IRQF_TRIGGER_LOW)
+ if (irq_get_trigger_type(data-irq) IRQF_TRIGGER_LOW)
return 0;
if (data-T18_address) {
@@ -3155,9 +3155,6 @@ static struct mxt_platform_data *mxt_parse_dt(struct
i2c_c
pdata-gpio_reset = of_get_named_gpio_flags(dev-of_node,
atmel,reset-gpio, 0, NULL);
- /* Default to this. Properties can be added to configure it later */
- pdata-irqflags = IRQF_TRIGGER_FALLING;
-
of_property_read_string(dev-of_node, atmel,cfg_name,
pdata-cfg_name);
--
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/5] regulator: Add DT bindings for tps65218 PMIC regulators
On Thu, Jul 03, 2014 at 07:14:59PM +0530, Keerthy wrote:
Add DT bindings for tps65218 PMIC regulators.
Signed-off-by: Keerthy j-keer...@ti.com
---
.../devicetree/bindings/regulator/tps65218.txt | 21
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..6272a73
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,21 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - ti,tps65218-dcdc1 for DCDC1
+ - ti,tps65218-dcdc2 for DCDC2
+ - ti,tps65218-dcdc3 for DCDC3
+ - ti,tps65218-dcdc4 for DCDC4
ti,tps65218-dcdc5 for DCDC5
ti,tps65218-dcdc6 for DCDC6
+ - ti,tps65218-ldo1 for LDO1
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator@0 {
+ compatible = ti,tps65218-dcdc1;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 300;
+ };
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/5] ARM: dts: AM43x: Add TPS65218 device tree nodes
On Thu, Jul 03, 2014 at 07:15:00PM +0530, Keerthy wrote:
Add TPS65218 device tree nodes.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 38
++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 19f1f7e..749098b 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -323,6 +323,44 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
looks unrelated but small enough that it should suffice to mention on
commit log.
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of
OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of
OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
missing vdcdc3, vdcdc4, vdcdc5 and vdcdc6.
+
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
at24@50 {
compatible = at24,24c256;
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 5/5] ARM: configs: omap2plus_defconfig: enable TPS65218 configs
On Thu, Jul 03, 2014 at 07:15:02PM +0530, Keerthy wrote: Enable TPS65218 config options. Signed-off-by: Keerthy j-keer...@ti.com Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 536a137..f650f00 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -180,6 +180,7 @@ CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_SYSCON=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65218=y CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y CONFIG_REGULATOR_FIXED_VOLTAGE=y @@ -188,6 +189,7 @@ CONFIG_REGULATOR_TI_ABB=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y +CONFIG_REGULATOR_TPS65218=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_PBIAS=y -- 1.7.9.5 -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/5] ARM: dts: AM437x: Add TPS65218 device tree nodes
On Thu, Jul 03, 2014 at 07:15:01PM +0530, Keerthy wrote:
Add TPS65218 device tree nodes.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 38
+++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 003766c..fc35d24 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -260,6 +260,44 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = i2c0_pins;
+ clock-frequency = 40;
same as before, also indentation is wrong, but I see indentation was
already wrong on this file, perhaps add a patch before this one fixing
that so this file is indented with tabs only ?
+
+ tps65218: tps65218@24 {
+ reg = 0x24;
+ compatible = ti,tps65218;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* NMIn */
+ interrupt-parent = gic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = ti,tps65218-dcdc1;
+ /* VDD_CORE voltage limits min of OPP50 and max of
OPP100 */
+ regulator-name = vdd_core;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1144000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = ti,tps65218-dcdc2;
+ /* VDD_MPU voltage limits min of OPP50 and max of
OPP_NITRO */
+ regulator-name = vdd_mpu;
+ regulator-min-microvolt = 912000;
+ regulator-max-microvolt = 1378000;
+ regulator-boot-on;
+ regulator-always-on;
+ };
also missing dcdc3/4/5. (6 has a non-populated 0 ohm resistor, so it
should be turned off).
+ ldo1: regulator-ldo1 {
+ compatible = ti,tps65218-ldo1;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
};
i2c1 {
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V2 0/6] regulator: palmas: cleanup and fixes
On Mon, Jun 30, 2014 at 10:57:33AM -0500, Nishanth Menon wrote: Hi, Original thread (v1): http://marc.info/?t=14038076654r=1w=2 This series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git branch: topic/palmas (4c0c9ca Merge remote-tracking branch 'regulator/fix/palmas' into regulator-palmas) This series does a few cleanups to help ensure we dont make typo mistakes and finally provides a fix as attempted by (v1). Applied all, thanks. Please fix your mailer to word wrap within paragraphs. signature.asc Description: Digital signature
Re: [PATCH 0/4] SiI9022 HDMI encoder for AM4xxx boards
Tomi Valkeinen tomi.valkei...@ti.com writes: Hi, Hi, This series adds a driver for SiI9022 HDMI encoder, which is used on AM437x GP and AM43x EPOS boards. The series is based on the OMAPDSS HDMI infoframe series sent earlier, as the SiI9022 driver uses the new infoframe support. Is there any small possibility to not make it an omap specific driver? There are other boards with sii9022 out there. imx5x dev boards could receive a daughter board with this chip (both sold by Freescale) and efikamx platform has it too. I think that some old msm platforms has it too. I've not compared the code of the drivers and don't know how the sii9022 works but would be annoying to have 2 or more drivers for the same piece of HW. imho, it would be nice if it could be avoided. Thanks, Arnaud -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
Hi, On Thu, Jul 03, 2014 at 09:07:36AM -0500, Felipe Balbi wrote: On Thu, Jul 03, 2014 at 08:34:44AM -0500, Robert Nelson wrote: On Thu, Jul 3, 2014 at 8:25 AM, Felipe Balbi ba...@ti.com wrote: On Thu, Jul 03, 2014 at 12:34:11AM -0700, Tony Lindgren wrote: * Robert Nelson robertcnel...@gmail.com [140702 12:27]: On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote: It has been only tested as console UART. The tty name is ttyS based instead of ttyO. How big is the pain here, what could be the easiest way to provide compatibility? have been considering that myself for months. You could pass an optional argument to serial8250_register_8250_port() but that only solves part of the problem :-( Some kind of compability layer sure would be nice. When ttyS - ttyO change was done on OMAP, compatibility was not an issue. Why should we care about it now? It would be a good opportunity to force everyone to update their bootloader. ;) Besides the BeagleBoard forum is quiet now, no one is complaining about that old (ttyS - ttyO) transition anymore.. How about a Kconfig option to provide ttyO by default? The not even do that if kernel has cmdline option nottyomap. what about single zImage ? I don't want to use ttyO on my Allwinner/Exynos/Snapdragon/whatever SoC just because OMAP is in the same image ;-) What if we just kept it simple, leave the ttyO driver enabled and add a warning (pr_info) that it's deprecated. It's not like it's broken, it just won't get later features or devices support added. Fine by me, I'd switch to 8250 as soon as it's merged though :-) would be nice to get an example DTS change just so I can start testing on the boards I have around. DT is supposed to contain information about the hardware, so it should stay the same? I think there is no non-hackish way to decide at runtime which driver should be loaded. One possible solution is: * Keep both drivers for a couple of kernel releases * Add the deprecation warning to the older one * Add a conflict between both drivers in Kconfig Thus its decided at build-time, which driver should be used. This would keep existing .config files working for a couple of releases. -- Sebastian signature.asc Description: Digital signature
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
On Thu, Jul 03, 2014 at 05:44:26PM +0200, Sebastian Reichel wrote: Hi, On Thu, Jul 03, 2014 at 09:07:36AM -0500, Felipe Balbi wrote: On Thu, Jul 03, 2014 at 08:34:44AM -0500, Robert Nelson wrote: On Thu, Jul 3, 2014 at 8:25 AM, Felipe Balbi ba...@ti.com wrote: On Thu, Jul 03, 2014 at 12:34:11AM -0700, Tony Lindgren wrote: * Robert Nelson robertcnel...@gmail.com [140702 12:27]: On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote: It has been only tested as console UART. The tty name is ttyS based instead of ttyO. How big is the pain here, what could be the easiest way to provide compatibility? have been considering that myself for months. You could pass an optional argument to serial8250_register_8250_port() but that only solves part of the problem :-( Some kind of compability layer sure would be nice. When ttyS - ttyO change was done on OMAP, compatibility was not an issue. Why should we care about it now? It would be a good opportunity to force everyone to update their bootloader. ;) Besides the BeagleBoard forum is quiet now, no one is complaining about that old (ttyS - ttyO) transition anymore.. How about a Kconfig option to provide ttyO by default? The not even do that if kernel has cmdline option nottyomap. what about single zImage ? I don't want to use ttyO on my Allwinner/Exynos/Snapdragon/whatever SoC just because OMAP is in the same image ;-) What if we just kept it simple, leave the ttyO driver enabled and add a warning (pr_info) that it's deprecated. It's not like it's broken, it just won't get later features or devices support added. Fine by me, I'd switch to 8250 as soon as it's merged though :-) would be nice to get an example DTS change just so I can start testing on the boards I have around. DT is supposed to contain information about the hardware, so it should stay the same? I think there is no non-hackish way to decide compatible would change, at a minimum. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
Hi, On Thu, Jul 03, 2014 at 10:52:40AM -0500, Felipe Balbi wrote: DT is supposed to contain information about the hardware, so it should stay the same? I think there is no non-hackish way to decide compatible would change, at a minimum. why? I would expect it to stay the same (and the current patch uses the same compatible strings). -- Sebastian signature.asc Description: Digital signature
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
On Thu, Jul 3, 2014 at 6:06 PM, Sebastian Reichel s...@kernel.org wrote: Hi, On Thu, Jul 03, 2014 at 10:52:40AM -0500, Felipe Balbi wrote: DT is supposed to contain information about the hardware, so it should stay the same? I think there is no non-hackish way to decide compatible would change, at a minimum. why? I would expect it to stay the same (and the current patch uses the same compatible strings). Exactly, the new driver must support all the compatible strings defined in Documentation/devicetree/bindings/serial/omap_serial.tx (which already does as you pointed out). Otherwise the current drivers/tty/serial/omap-serial.c could never be removed since that would mean breaking DT backward compatibility. -- Sebastian Best regards, Javier -- 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 5/6] phy: omap-usb2: Balance pm_runtime_enable() on probe failure
On 07/03/2014 04:31 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Wednesday 02 July 2014 05:33 PM, Roger Quadros wrote:
If probe fails then we need to call pm_runtime_disable() to balance
out the previous pm_runtime_enable() call. Else it will cause
unbalanced pm_runtime_enable() call in the succeding probe call.
This anomaly was observed when the call to devm_phy_create() failed
with -EPROBE_DEFER.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-usb2.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..c6f9809 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -265,15 +265,19 @@ static int omap_usb2_probe(struct platform_device
*pdev)
pm_runtime_enable(phy-dev);
generic_phy = devm_phy_create(phy-dev, ops, NULL);
-if (IS_ERR(generic_phy))
+if (IS_ERR(generic_phy)) {
+pm_runtime_disable(phy-dev);
return PTR_ERR(generic_phy);
+}
Maybe we can move pm_runtime_enable to just before phy_provider_register?
OK. will try that.
phy_set_drvdata(generic_phy, phy);
phy_provider = devm_of_phy_provider_register(phy-dev,
of_phy_simple_xlate);
-if (IS_ERR(phy_provider))
+if (IS_ERR(phy_provider)) {
+pm_runtime_disable(phy-dev);
return PTR_ERR(phy_provider);
+}
Noticed pm_runtime_disable was missing in omap_usb2_remove too. Would be good
to fix it here.
Fine, I'll add it there.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver
On Thu, Jul 03, 2014 at 06:19:47PM +0200, Javier Martinez Canillas wrote: On Thu, Jul 3, 2014 at 6:06 PM, Sebastian Reichel s...@kernel.org wrote: Hi, On Thu, Jul 03, 2014 at 10:52:40AM -0500, Felipe Balbi wrote: DT is supposed to contain information about the hardware, so it should stay the same? I think there is no non-hackish way to decide compatible would change, at a minimum. why? I would expect it to stay the same (and the current patch uses the same compatible strings). Exactly, the new driver must support all the compatible strings defined in Documentation/devicetree/bindings/serial/omap_serial.tx (which already does as you pointed out). Otherwise the current drivers/tty/serial/omap-serial.c could never be removed since that would mean breaking DT backward compatibility. that settles it then... good. I'll start testing this next week. -- balbi signature.asc Description: Digital signature
Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Ohad, On 07/03/2014 02:00 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna s-a...@ti.com wrote: I'm not sure we need this patch. This patch is needed if we use the controller-phandle + args specifier for requesting hwlocks by a client, as we need to translate controller-phandle to the corresponding hwspinlock_device. Looks like we still don't have a closure on the semantics of how clients have to request a lock in DT. You are suggesting something like hwlocks = global_lock1 global_lock2 ...; whereas this patch is built to support based on comments from DT-maintainers, hwlocks = controller-phandle lock-specifier1, controller-phandle lock-specifier2...; I'm actually ok with this suggestion and haven't suggested otherwise. OK, thanks for confirming and sorry for the misinterpretation. All I propose is that we add the base_id property to the controller node (as you have done in the subsequent patches), and then drivers will be able to infer the global lock id from the DT data by adding the controller's base_id to the lock specifier. OK, but we would still require this function to lookup the registered device from the controller-phandle to retrieve the base_id. Do note that the hwspinlock core currently only maintains the registered locks in an integrated radix tree, but not the registered hwspinlock banks themselves. regards Suman Controllers with non standard lock indexing may use an xlate() method if needed but frankly this is fictional right now. We can start without this, and add it later when needed, as this doesn't affect the DT data. With the global lock id in hand, drivers could simply use the existing hwspin_lock_request_specific API to obtain a specific lock, and then we don't need this patch. Thanks, Ohad. -- 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: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Ohad, On 07/03/2014 02:15 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna s-a...@ti.com wrote: Do we have a use case today that require the xlate() method? If not, let's remove it as we could always add it back if some new hardware shows up that needs it. The xlate() method is to support the phandle + args specifier way of requesting hwlocks, platform implementations are free to implement their own xlate functions, but the above supports the simplest case of controller + relative lock index within controller. Do we have a use case for a different implementation other than the simplest case? If not, it seems to me this will just become redundant boilerplate code (every platform will use the simple xlate method). Not at the moment, with the existing platform implementations. So, if I understand you correctly, you are asking to leave out the xlate ops and make the of_hwspin_lock_simple_xlate() internal until a need for an xlate method arises. This also means, we only support a value of 1 for #hwlock-cells. This function again is to support the phandle + args specifier way of requesting hwlocks, the hwspin_lock_request_specific() is invoked internally within this function, so we are still reusing the actual request code other than handling the DT parsing portion. If we go back to using global locks in client hwlocks property, we don't need a of_hwspin_lock_get_id(), the same can be achieved using the existing DT function, of_property_read_u32_index(). I think you may have misunderstood me, sorry. I'm ok with the phandle + args specifier. I just think we can use it, together with the base_id property, to infer the global lock id from the DT data. Aah ok, its minor code rearrangement for what you are asking - I just need to leave out invoking the request_specific invocation in the OF request specific existing function, just return the global id and let the client users call the normal request_specific API themselves. But, that would mean DT-based client users would have to invoke two function calls to request a hwspinlock. We already have an API to get the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF API for requesting a lock directly rather than giving an OF API for getting the lock id. This is in keeping in convention with what other drivers do normally - a regular get and an OF get. I can modify it if you still prefer the OF API for getting a global lock id, but I feel its a burden for client users. Also, do you prefer an open property-name in client users (like I am doing at the moment) or imposing a standard property name hwlocks? regards Suman This is not only a must to support heterogenous multi-processing systems, it will also substantially simplify the code. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: DRA7: dts: clock data fixes
Hi Tony, The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.16-rc/clk-dt-fixes for you to fetch changes up to dd94324b983afe114ba9e7ee3649313b451f63ce: ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates (2014-07-03 20:59:36 +0300) One fix for 3.16-rc. Fixes wrong dividers for l3/l4 clock nodes on DRA7. Rajendra Nayak (1): ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: clock cleanup for v3.17 merge window
Hi Tony, Posting this early, as I will be going for vacation from next week and might miss the merge window myself. Small cleanup set for the clock drivers residing under mach-omap2 folder to prepare their move under drivers/clk. I'll leave it for your judgement whether you pull this or not based on the potential feedback. The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.17/omap2-clk-cleanup for you to fetch changes up to 4eccc64a2bc25514754c30cdfc985207aee8b2fd: ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file (2014-07-01 17:46:27 +0300) Tero Kristo (13): ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow ARM: OMAP4+: clock: remove DEFINE_CLK_OMAP_HSDIVIDER macro ARM: OMAP4+: dpll: remove cpu_is_omap44xx checks ARM: OMAP4+: dpll44xx: remove cm-regbits-44xx.h and clock44xx.h includes ARM: OMAP2+: clock: introduce ti_clk_features flags ARM: OMAP2+: clock: add fint values to the ti_clk_features struct ARM: OMAP2+: clock/dpll: add private API for checking if DPLL is in bypass ARM: OMAP2+: clock/dpll: convert bypass check to use clk_features ARM: OMAP2+: clock/dpll: add jitter correction behind clk_features ARM: OMAP2+: clock/interface: add a clk_features definition for idlest value ARM: OMAP2+: clock/dpll: remove unused header includes from clkt_dpll.c ARM: OMAP2+: clock/dpll: remove unused header includes from dpll3xxx.c ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file arch/arm/mach-omap2/clkt_dpll.c | 100 ++- arch/arm/mach-omap2/clkt_iclk.c |8 ++-- arch/arm/mach-omap2/clock.c | 76 ++--- arch/arm/mach-omap2/clock.h | 44 - arch/arm/mach-omap2/dpll3xxx.c |7 +-- arch/arm/mach-omap2/dpll44xx.c | 19 +--- arch/arm/mach-omap2/io.c|2 + 7 files changed, 155 insertions(+), 101 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2: clock data migration to DT for 3.17 merge window
Hi Tony, Posting this pull-request also early due to my holidays. Anyway, these patches were supposed to go in already during 3.16 merge window, but they missed it due to pending dependencies. Finalizes the move of OMAP24xx clock data to the DT, and also removes the legacy clock data. Might be good to try this branch out with n800 / 2420 hardware also as I don't have access to those. --- The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.17/omap2-use-dt-clks for you to fetch changes up to 6a194a6e2a8fa55e133936a124ed500aea434116: ARM: OMAP24xx: clock: remove legacy clock data (2014-07-02 15:59:03 +0300) Tero Kristo (5): ARM: OMAP2: convert sys_ck and osc_ck to standard clock types ARM: OMAP2420: clock: get rid of fixed-div property use ARM: OMAP2: PRM: add support for OMAP2 specific clock providers ARM: OMAP2: clock: use DT clock boot if available ARM: OMAP24xx: clock: remove legacy clock data .../devicetree/bindings/arm/omap/prcm.txt | 65 + arch/arm/boot/dts/omap2420.dtsi|3 + arch/arm/boot/dts/omap2430.dtsi|3 + arch/arm/mach-omap2/Makefile |6 +- arch/arm/mach-omap2/cclock2420_data.c | 1931 -- arch/arm/mach-omap2/cclock2430_data.c | 2048 arch/arm/mach-omap2/clkt2xxx_osc.c | 69 - arch/arm/mach-omap2/clkt2xxx_sys.c | 47 - arch/arm/mach-omap2/clock.c| 21 - arch/arm/mach-omap2/clock.h|3 - arch/arm/mach-omap2/clock2xxx.h|2 - arch/arm/mach-omap2/cm-regbits-24xx.h |1 + arch/arm/mach-omap2/io.c |7 +- arch/arm/mach-omap2/pm24xx.c |4 + arch/arm/mach-omap2/prm_common.c |2 + 15 files changed, 85 insertions(+), 4127 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/prcm.txt delete mode 100644 arch/arm/mach-omap2/cclock2420_data.c delete mode 100644 arch/arm/mach-omap2/cclock2430_data.c delete mode 100644 arch/arm/mach-omap2/clkt2xxx_osc.c delete mode 100644 arch/arm/mach-omap2/clkt2xxx_sys.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] CLK: TI: changes for v3.17 merge window
Hi Mike, Posting this pull-request early due to my holidays, I might miss the merge window myself. Just a minor update for DRA7 and an update to the MAINTAINERS file. --- The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.17/ti-clk-driver for you to fetch changes up to 94e72ae5dbb1aff59791e6f96e2f0416b8a82257: CLK: ti: dra7: Initialize USB_DPLL (2014-07-02 17:08:26 +0300) Roger Quadros (1): CLK: ti: dra7: Initialize USB_DPLL Tero Kristo (1): MAINTAINERS: add TI Clock driver MAINTAINERS |7 +++ drivers/clk/ti/clk-7xx.c | 11 +++ 2 files changed, 18 insertions(+) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: DRA7: dts: clock data fixes
On Thu, Jul 03, 2014 at 09:04:18PM +0300, Tero Kristo wrote: Hi Tony, The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f: Linux 3.16-rc1 (2014-06-15 17:45:28 -1000) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.16-rc/clk-dt-fixes you might want to set separate url and pushurl on your .gitconfig. Tony might not have permission to access your trees through ssh. for you to fetch changes up to dd94324b983afe114ba9e7ee3649313b451f63ce: ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates (2014-07-03 20:59:36 +0300) One fix for 3.16-rc. Fixes wrong dividers for l3/l4 clock nodes on DRA7. Rajendra Nayak (1): ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- balbi signature.asc Description: Digital signature
Re: [PATCH] spi: omap2-mcspi: Configure hardware when slave driver changes mode
On Tue, Jul 01, 2014 at 08:28:32PM -0700, Mark A. Greer wrote: Commit id 2bd16e3e23d9df41592c6b257c59b6860a9cc3ea (spi: omap2-mcspi: Do not configure the controller on each transfer unless needed) does its job too Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v2 2/3] ARM: DRA7: hwmod: Fixup SATA hwmod
On Thu, 3 Jul 2014, Roger Quadros wrote: Get rid of optional clock as that is now managed by the AHCI platform driver. Correct .mpu_rt_idx to 1 as the module register space (SYSCONFIG..) is passed as the second memory resource in the device tree. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com Tested-by: Sekhar Nori nsek...@ti.com Thanks, this looks like a fix, so, queueing for v3.16-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
On Thu, 3 Jul 2014, Roger Quadros wrote: Add the sysconfig class bits for the Super Speed USB controllers Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com Tested-by: Sekhar Nori nsek...@ti.com Thanks, this looks like a fix, so, queueing for v3.16-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: DRA7: hwmod: Add OCP2SCP3 module
On Thu, 3 Jul 2014, Roger Quadros wrote: This module is needed for the SATA and PCIe PHYs. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Rajendra Nayak rna...@ti.com Tested-by: Sekhar Nori nsek...@ti.com This looks like adding support for a new device, so, after discussing with Tony, queuing for v3.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
[PATCH 1/2] mmc: hsmmc: Add reset gpio configuration option.
From: NeilBrown ne...@suse.de
If a 'gpio_reset' is specified, then hold it low while
turning the power regulator on.
This is needed for some wi2wi wireless modules, particularly
when the regulator is held active by some other client.
The wi2wi needs to be reset if power isn't actually removed, and
the gpio can be used to do this.
Signed-off-by: NeilBrown ne...@suse.de
---
arch/arm/mach-omap2/hsmmc.c| 7 ++-
arch/arm/mach-omap2/hsmmc.h| 3 +++
drivers/mmc/host/omap_hsmmc.c | 26 +++---
include/linux/platform_data/mmc-omap.h | 1 +
4 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 07d4c7b..046bfdd 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -172,6 +172,10 @@ static inline void omap_hsmmc_mux(struct
omap_mmc_platform_data *mmc_controller,
(mmc_controller-slots[0].gpio_wp OMAP_MAX_GPIO_LINES))
omap_mux_init_gpio(mmc_controller-slots[0].gpio_wp,
OMAP_PIN_INPUT_PULLUP);
+ if (gpio_is_valid(mmc_controller-slots[0].gpio_reset)
+ (mmc_controller-slots[0].gpio_reset OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-slots[0].gpio_reset,
+ OMAP_PIN_OUTPUT);
if (cpu_is_omap34xx()) {
if (controller_nr == 0) {
omap_mux_init_signal(sdmmc1_clk,
@@ -270,6 +274,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-slots[0].switch_pin = c-gpio_cd;
mmc-slots[0].gpio_wp = c-gpio_wp;
+ mmc-slots[0].gpio_reset = c-gpio_reset;
mmc-slots[0].remux = c-remux;
mmc-slots[0].init_card = c-init_card;
@@ -389,7 +394,7 @@ void omap_hsmmc_late_init(struct omap2_hsmmc_info *c)
continue;
mmc_pdata-slots[0].switch_pin = c-gpio_cd;
- mmc_pdata-slots[0].gpio_wp = c-gpio_wp;
+ mmc_pdata-slots[0].gpio_reset = c-gpio_reset;
res = omap_device_register(pdev);
if (res)
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 7f2e790..16b2ac5 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -24,6 +24,9 @@ struct omap2_hsmmc_info {
booldeferred; /* mmc needs a deferred probe */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
+ int gpio_reset; /* or -EINVAL - reset is held low during
+* power-on
+*/
char*name; /* or NULL for default */
struct platform_device *pdev; /* mmc controller instance */
int ocr_mask; /* temporary HACK */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9656726..4a264fc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -300,6 +300,8 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (!host-vcc)
return 0;
+ if (gpio_is_valid(mmc_slot(host).gpio_reset))
+ gpio_set_value_cansleep(mmc_slot(host).gpio_reset, 0);
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
@@ -365,6 +367,8 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (mmc_slot(host).after_set_reg)
mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);
+ if (gpio_is_valid(mmc_slot(host).gpio_reset))
+ gpio_set_value_cansleep(mmc_slot(host).gpio_reset, 1);
error_set_power:
return ret;
@@ -481,10 +485,22 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
- return 0;
+ if (gpio_is_valid(pdata-slots[0].gpio_reset)) {
+ ret = gpio_request(pdata-slots[0].gpio_reset, mmc_reset);
+ if (ret)
+ goto err_free_wp;
+ ret = gpio_direction_output(pdata-slots[0].gpio_reset, 1);
+ if (ret)
+ goto err_free_reset;
+ } else
+ pdata-slots[0].gpio_reset = -EINVAL;
+ return 0;
+err_free_reset:
+ gpio_free(pdata-slots[0].gpio_reset);
err_free_wp:
- gpio_free(pdata-slots[0].gpio_wp);
+ if (gpio_is_valid(pdata-slots[0].gpio_wp))
+ gpio_free(pdata-slots[0].gpio_wp);
err_free_cd:
if (gpio_is_valid(pdata-slots[0].switch_pin))
err_free_sp:
@@ -494,6 +510,8 @@ err_free_sp:
static void omap_hsmmc_gpio_free(struct omap_mmc_platform_data *pdata)
{
+ if (gpio_is_valid(pdata-slots[0].gpio_reset))
+ gpio_free(pdata-slots[0].gpio_reset);
if
[PATCH 2/2] Documentation: devicetree: mmc: Document reset-gpio property
Signed-off-by: Marek Belisko ma...@goldelico.com
---
Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 431716e..b094bd2 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -21,6 +21,7 @@ Optional properties:
below for the case, when a GPIO is used for the CD line
- wp-inverted: when present, polarity on the WP line is inverted. See the note
below for the case, when a GPIO is used for the WP line
+- reset-gpios: Specify GPIOs which will be hold down when turning power
regulator
- max-frequency: maximum operating clock frequency
- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
this system, even if the controller claims it is.
@@ -72,6 +73,7 @@ sdhci@ab00 {
cd-gpios = gpio 69 0;
cd-inverted;
wp-gpios = gpio 70 0;
+ reset-gpios = gpio 71 0;
max-frequency = 5000;
keep-power-in-suspend;
enable-sdio-wakeup;
--
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] rpmsg: compute number of buffers to allocate from vrings
The buffers to be used for communication are allocated during
the rpmsg virtio driver's probe, and the number of buffers is
currently hard-coded to 512. Remove this hard-coded value, as
this can vary from one platform to another or between different
remote processors. Instead, rely on the number of buffers the
virtqueue vring is setup with in the first place.
This fixes the WARN_ON during the setup of the receive buffers
for vrings with buffers less than 512.
NOTE: The number of buffers is already assumed to be symmetrical
in each direction, and that logic is not unchanged.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/rpmsg/virtio_rpmsg_bus.c | 41 +---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index b6135d4..e9866a6 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -41,6 +41,7 @@
* @svq: tx virtqueue
* @rbufs: kernel address of rx buffers
* @sbufs: kernel address of tx buffers
+ * @num_bufs: total number of buffers for rx and tx
* @last_sbuf: index of last tx buffer used
* @bufs_dma: dma base addr of the buffers
* @tx_lock: protects svq, sbufs and sleepers, to allow concurrent senders.
@@ -60,6 +61,7 @@ struct virtproc_info {
struct virtio_device *vdev;
struct virtqueue *rvq, *svq;
void *rbufs, *sbufs;
+ unsigned int num_bufs;
int last_sbuf;
dma_addr_t bufs_dma;
struct mutex tx_lock;
@@ -86,14 +88,14 @@ struct rpmsg_channel_info {
#define to_rpmsg_driver(d) container_of(d, struct rpmsg_driver, drv)
/*
- * We're allocating 512 buffers of 512 bytes for communications, and then
- * using the first 256 buffers for RX, and the last 256 buffers for TX.
+ * We're allocating buffers of 512 bytes each for communications. The
+ * number of buffers are computed from the number of buffers supported
+ * by the virtqueue vring and then use the first half of those buffers
+ * for RX, and the last half buffers for TX.
*
* Each buffer will have 16 bytes for the msg header and 496 bytes for
* the payload.
*
- * This will require a total space of 256KB for the buffers.
- *
* We might also want to add support for user-provided buffers in time.
* This will allow bigger buffer size flexibility, and can also be used
* to achieve zero-copy messaging.
@@ -102,9 +104,7 @@ struct rpmsg_channel_info {
* can change this without changing anything in the firmware of the remote
* processor.
*/
-#define RPMSG_NUM_BUFS (512)
#define RPMSG_BUF_SIZE (512)
-#define RPMSG_TOTAL_BUF_SPACE (RPMSG_NUM_BUFS * RPMSG_BUF_SIZE)
/*
* Local addresses are dynamically allocated on-demand.
@@ -579,7 +579,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp)
* either pick the next unused tx buffer
* (half of our buffers are used for sending messages)
*/
- if (vrp-last_sbuf RPMSG_NUM_BUFS / 2)
+ if (vrp-last_sbuf vrp-num_bufs / 2)
ret = vrp-sbufs + RPMSG_BUF_SIZE * vrp-last_sbuf++;
/* or recycle a used one */
else
@@ -948,6 +948,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
struct virtproc_info *vrp;
void *bufs_va;
int err = 0, i;
+ size_t total_buf_space;
vrp = kzalloc(sizeof(*vrp), GFP_KERNEL);
if (!vrp)
@@ -968,10 +969,19 @@ static int rpmsg_probe(struct virtio_device *vdev)
vrp-rvq = vqs[0];
vrp-svq = vqs[1];
+ /*
+* We expect equal number of buffers for each direction as per current
+* code, so throw a warning if the configuration doesn't match. This can
+* easily be adjusted if needed.
+*/
+ vrp-num_bufs = virtqueue_get_vring_size(vrp-rvq) * 2;
+ WARN_ON(virtqueue_get_vring_size(vrp-svq) != (vrp-num_bufs / 2));
+ total_buf_space = vrp-num_bufs * RPMSG_BUF_SIZE;
+
/* allocate coherent memory for the buffers */
bufs_va = dma_alloc_coherent(vdev-dev.parent-parent,
- RPMSG_TOTAL_BUF_SPACE,
- vrp-bufs_dma, GFP_KERNEL);
+total_buf_space, vrp-bufs_dma,
+GFP_KERNEL);
if (!bufs_va) {
err = -ENOMEM;
goto vqs_del;
@@ -984,10 +994,10 @@ static int rpmsg_probe(struct virtio_device *vdev)
vrp-rbufs = bufs_va;
/* and half is dedicated for TX */
- vrp-sbufs = bufs_va + RPMSG_TOTAL_BUF_SPACE / 2;
+ vrp-sbufs = bufs_va + total_buf_space / 2;
/* set up the receive buffers */
- for (i = 0; i RPMSG_NUM_BUFS / 2; i++) {
+ for (i = 0; i vrp-num_bufs / 2; i++) {
struct scatterlist sg;
void *cpu_addr = vrp-rbufs + i * RPMSG_BUF_SIZE;
@@ -1023,8 +1033,8 @@ static int rpmsg_probe(struct virtio_device
Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
Quoting Tero Kristo (2014-07-03 00:41:22)
On 07/01/2014 10:48 PM, Felipe Balbi wrote:
Hi,
On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous default, and causes problems on AM43x when
using display and ethernet. There are multiple ways to select the clock
muxes on AM43x, and some of those clock paths have the same source
clocks for display and ethernet. When changing the clock rate for the
display subsystem, the clock framework decides to change the display mux
from the dedicated display PLL to a shared PLL which is used by the
ethernet, and then changes the rate of the shared PLL, breaking the
ethernet.
As I don't think there ever is a case where we want the clock framework
to automatically change the parent clock of a clock mux, this patch sets
the CLK_SET_RATE_NO_REPARENT for all ti,mux-clocks.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index 0197a478720c..e9d650e51287 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -160,7 +160,7 @@ static void of_mux_clk_setup(struct device_node *node)
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
- u32 flags = 0;
+ u32 flags = CLK_SET_RATE_NO_REPARENT;
num_parents = of_clk_get_parent_count(node);
if (num_parents 2) {
Thanks, queued for 3.16-rc fixes.
did you skip a few -rcs by any chance? Looks like this could've been
merged on v3.16-rc3... Just checking.
This goes through Mike's clk tree, so there is extra latency there. Not
sure when he plans to send next pull-req for clk-fixes to linux-master.
Expect it late next week as several new fixes pull requests have come
in. I merge those into clk-fixes, which then gets merged into clk-next
and all of that gets pulled into linux-next. After some cycles there and
testing on my end I send the fixes PR to Linus. So expect it to go
between -rc4 and -rc5.
Regards,
Mike
-Tero
--
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] mmc: hsmmc: Add reset gpio configuration option.
Hi,
On Thu, Jul 03, 2014 at 10:49:23PM +0200, Marek Belisko wrote:
From: NeilBrown ne...@suse.de
If a 'gpio_reset' is specified, then hold it low while
turning the power regulator on.
This is needed for some wi2wi wireless modules, particularly
when the regulator is held active by some other client.
The wi2wi needs to be reset if power isn't actually removed, and
the gpio can be used to do this.
Signed-off-by: NeilBrown ne...@suse.de
---
arch/arm/mach-omap2/hsmmc.c| 7 ++-
arch/arm/mach-omap2/hsmmc.h| 3 +++
drivers/mmc/host/omap_hsmmc.c | 26 +++---
include/linux/platform_data/mmc-omap.h | 1 +
4 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 07d4c7b..046bfdd 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -172,6 +172,10 @@ static inline void omap_hsmmc_mux(struct
omap_mmc_platform_data *mmc_controller,
(mmc_controller-slots[0].gpio_wp OMAP_MAX_GPIO_LINES))
omap_mux_init_gpio(mmc_controller-slots[0].gpio_wp,
OMAP_PIN_INPUT_PULLUP);
+ if (gpio_is_valid(mmc_controller-slots[0].gpio_reset)
+ (mmc_controller-slots[0].gpio_reset OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-slots[0].gpio_reset,
+ OMAP_PIN_OUTPUT);
if (cpu_is_omap34xx()) {
if (controller_nr == 0) {
omap_mux_init_signal(sdmmc1_clk,
@@ -270,6 +274,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-slots[0].switch_pin = c-gpio_cd;
mmc-slots[0].gpio_wp = c-gpio_wp;
+ mmc-slots[0].gpio_reset = c-gpio_reset;
mmc-slots[0].remux = c-remux;
mmc-slots[0].init_card = c-init_card;
@@ -389,7 +394,7 @@ void omap_hsmmc_late_init(struct omap2_hsmmc_info *c)
continue;
mmc_pdata-slots[0].switch_pin = c-gpio_cd;
- mmc_pdata-slots[0].gpio_wp = c-gpio_wp;
+ mmc_pdata-slots[0].gpio_reset = c-gpio_reset;
res = omap_device_register(pdev);
if (res)
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 7f2e790..16b2ac5 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -24,6 +24,9 @@ struct omap2_hsmmc_info {
booldeferred; /* mmc needs a deferred probe */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
+ int gpio_reset; /* or -EINVAL - reset is held low during
+ * power-on
+ */
char*name; /* or NULL for default */
struct platform_device *pdev; /* mmc controller instance */
int ocr_mask; /* temporary HACK */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9656726..4a264fc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -300,6 +300,8 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (!host-vcc)
return 0;
+ if (gpio_is_valid(mmc_slot(host).gpio_reset))
+ gpio_set_value_cansleep(mmc_slot(host).gpio_reset, 0);
if (mmc_slot(host).before_set_reg)
mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
@@ -365,6 +367,8 @@ static int omap_hsmmc_set_power(struct device *dev, int
slot, int power_on,
if (mmc_slot(host).after_set_reg)
mmc_slot(host).after_set_reg(dev, slot, power_on, vdd);
+ if (gpio_is_valid(mmc_slot(host).gpio_reset))
+ gpio_set_value_cansleep(mmc_slot(host).gpio_reset, 1);
error_set_power:
return ret;
@@ -481,10 +485,22 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
} else
pdata-slots[0].gpio_wp = -EINVAL;
- return 0;
+ if (gpio_is_valid(pdata-slots[0].gpio_reset)) {
+ ret = gpio_request(pdata-slots[0].gpio_reset, mmc_reset);
+ if (ret)
+ goto err_free_wp;
+ ret = gpio_direction_output(pdata-slots[0].gpio_reset, 1);
+ if (ret)
+ goto err_free_reset;
+ } else
+ pdata-slots[0].gpio_reset = -EINVAL;
looks like this should be implemented as a reset-gpio.c driver. This
piece of code would, then
reset_assert(slot-reset);
do_the_magic_dance();
reset_deassert(slot-reset);
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2] mmc: hsmmc: Add reset gpio configuration option.
On Thu, Jul 03, 2014 at 10:49:23PM +0200, Marek Belisko wrote: From: NeilBrown ne...@suse.de If a 'gpio_reset' is specified, then hold it low while turning the power regulator on. This is needed for some wi2wi wireless modules, particularly when the regulator is held active by some other client. The wi2wi needs to be reset if power isn't actually removed, and the gpio can be used to do this. Signed-off-by: NeilBrown ne...@suse.de Obvious statement knowing what's been going on elsewhere... A while back, Olof produced a couple of patches to add /generic/ support to deal with power and reset controls for SDIO WIFI cards. Patches were posted to linux-arm-kernel and other places around January time this year. No real conclusion came out of it, and it kind of died. The point here is that this is not an OMAP problem. We have this very same problem on different platforms and different SoCs. Why should we have N different solutions to the same problem. Why can't we have one solution to fix this issue, rather than having every host driver implement some different solution to what's a common problem. If everyone is going to run away from generic problems and continue inventing their own private solutions to generic problems, the kernel is just going to become severely bloated and unmaintainable... Please, sort out generic problems with generic solutions. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data
On Tue, Jul 01, 2014 at 10:22:49PM -0500, Felipe Balbi wrote: Hi, On Fri, Jun 13, 2014 at 07:11:58PM +, Paul Walmsley wrote: Hi Felipe, Tomi, On Fri, 13 Jun 2014, Felipe Balbi wrote: On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote: From: Sathya Prakash M R sath...@ti.com Add DSS hwmod data for AM43xx. Cc: Andrew Morton a...@linux-foundation.org Acked-by: Rajendra Nayak rna...@ti.com Signed-off-by: Sathya Prakash M R sath...@ti.com Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- Note that this patch was originally send on May 9th [1], changes were requested and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged maintainer again and go no response. Without this patch, we cannot get display working on any AM437x devices. [1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2 [2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2 [3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++ arch/arm/mach-omap2/prcm43xx.h | 1 + 2 files changed, 99 insertions(+) Sorry for the delay on this. Have been corresponding with TI management to figure out what to do about patches for AM43xx. I don't have boards or public documentation for these devices, so it's impossible for me to documentation is now available publicly http://www.ti.com/product/AM4379 at [1] you can find most (all?) board-related documentation. [2] will give you AM437x GP EVM schematics. [1] http://processors.wiki.ti.com/index.php/AM437X_EVM_Boards [2] http://processors.wiki.ti.com/images/9/95/Am437x_gp_evm_3k0006_schematic_rev1_4a.pdf -- balbi signature.asc Description: Digital signature
Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Suman, On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna s-a...@ti.com wrote: Not at the moment, with the existing platform implementations. So, if I understand you correctly, you are asking to leave out the xlate ops and make the of_hwspin_lock_simple_xlate() internal until a need for an xlate method arises. Yes, please. It seems to me this way we're reducing complexity without compromising anything. This also means, we only support a value of 1 for #hwlock-cells. When a different #hwlock-cells value shows up, someone would have to write a new xlate implementation anyway. At the same time, the xlate ops could be brought back quite easily. Since we're not imposing anything on the DT data, this doesn't affect our ability to support these scenarios in the future, but unless I'm missing a current use case, these scenarios right now seems somewhat fictional. But, that would mean DT-based client users would have to invoke two function calls to request a hwspinlock. We already have an API to get the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF API for requesting a lock directly rather than giving an OF API for getting the lock id. This is in keeping in convention with what other drivers do normally - a regular get and an OF get. I can modify it if you still prefer the OF API for getting a global lock id, but I feel its a burden for client users. Let's discuss this. I was actually thinking of the more general use case of an heterogenous system: - driver gets the global lock id from a remote processor - driver then requests the specific lock Looking at these cases, the OF scenario only differs in the small part of fetching the lock id, and if we keep the regular request_specific API we'll have more common code between drivers. What do you think? Also, do you prefer an open property-name in client users (like I am doing at the moment) or imposing a standard property name hwlocks? Good point - I think we can start with an imposed hwlocks name, and evolve in the future as needed (again, only because we're not really imposing anything on the DT data - this is just kernel code that we could always extend as needed). Thanks, Ohad. -- 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: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Suman, On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna s-a...@ti.com wrote: OK, but we would still require this function to lookup the registered device from the controller-phandle to retrieve the base_id. Can we retrieve the base_id from the parent DT node itself? Thanks, Ohad. -- 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
