Re: Latest randconfig build errors
On Sun, Apr 14, 2013 at 12:29:46AM -0400, Rob Clark wrote: On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding [...] I had been thinking about this on and off for a while, but I haven't come up with anything concrete. Ideally we could just have some kind of event that userspace would listen for, so that new outputs can be dynamically added and userspace informed about them. Last time I checked most of the helpers assumed that the complete output configuration is known when the DRM device is registered, so some major rework will be required to efficiently make use of such dynamicity. I'm less worried about the kernel re-work.. more worried about the fact that we have no way to know whether userspace knows to listen for this new event. So anything down this path could, I think, be considered as breaking userspace. Yes, that's probably true. Although the typical use-case would be that the application would run on any of the detected outputs and if there is none to begin with it will just fail. If there already is one, it will try to use that instead and only fail to use a second one if it becomes available. I think in the end, we need some way to have sort of dummy connectors for output drivers which might or might not be probed, so that from userspace perspective, non-present panels appear as displays that are not plugged in. I can imagine that quite a few userspace programs will be broken by this as well. For instance if you have an LVDS panel, I'm pretty sure people will just assume that it can't be in a disconnected state and therefore won't deal with that case. From a driver's point of view this isn't all that different from the case you're trying to solve now. You still need to find out which outputs can eventually become available. But instead of waiting until they do before registering the DRM device you'd have to create dummy outputs and keep checking whether the device is actually there each time somebody interacts with the output. But maybe this case is different. For Tegra the problem is that some outputs (such as HDMI) require other drivers to be loaded first because they provide resources (regulators, GPIOs, ...) that the output drivers require. All of the drivers use deferred probing to resolve this dependency and we can be reasonably sure that eventually probing of the output will succeed (and therefore the output will become available). Postponing the DRM registration until that point doesn't hurt. From what I understand your use-case is similar. You need to load drivers for different panels based on a runtime decision. So the only thing you need is to be able to postpone the DRM registration until the panel driver has been loaded, right? Thierry pgp21kauR35ES.pgp Description: PGP signature
Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10
On Monday 15 April 2013 10:36 AM, Hiremath, Vaibhav wrote: -Original Message- From: Shilimkar, Santosh Sent: Wednesday, April 10, 2013 5:02 PM [..] From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00 2001 From: Sricharan R r.sricha...@ti.com Date: Fri, 5 Apr 2013 20:39:12 +0530 Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file - The IO resource information like dma request lines, irq number and ocp address space can be populated via dt blob. So such data can be stripped from SOC hwmod data file. - The devices like adc, mailbox, gpmc which are missing the device tree bindings, hwmod data is not added since AM33XX is DT only build. When such devices add the dt bindings, respective hwmod data can be added along with it. This seems unnecessary churn to me. DT bindings for most of the devices which you mentioned above are submitted and are at various stages of review process. ADC: GPMC: PWM: The modules are dropped as per what is going for 3.10 merge window. Above 3 modules can be retained if the DT conversion patches are under review and can go along with this patch most likely for 3.11. - The hwmod like firewall etc which are not useful are also dropped. This gets us around ~2000 loc of negative diff. Patch is boot tested on AM335X EVM. I would not recommend to get into unnecessary code churn in the future just to reduce temp Number of Lines of code. This will also kill our autogeneration concept as well. It doesn't break any concept. We just autogenrate what is *useful* rather. BTW, I didn't find any srcipt to auto-generate the AM33XX data so we have to manually do the updates. Can you send me a pointer if you have a sript for this. With script it is much simpler to clean-up the data. I would suggest you to just alone drop base-addr, irq and dma references from hwmod entries. That we are doing anyways. Apart from that we should also clean-up data which is not used and useful. Why do you need unused data like firewall and friends ? So as I understood, you would like to keep the data for ADC, PWM and GPMC which is fine by me. We just need those DT bindings in place so that they go together. Who is following the DT patches for these ? Thanks for looking into it Vaibhav. Are you planning to send updated version of this? I would rather prefer to review next version. Please let me know if you need any help here. Yes :-) It will be great if you take the patch forward and update it based on the discussion. Regards, Santosh -- 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
adding rpmsg.git to linux next
Hi Stephen, Could you please add: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next to linux-next to include new stuff coming from Rob? 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
[PATCH] ARM: dts: omap4-panda: Add USB Host support
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
The USB PHY needs AUXCLK3 to operate. Provide this information
as well.
Also provide pin multiplexer information for the USB host
pins.
This patch depends on OMAP clock binding introduced in
https://lkml.org/lkml/2013/4/12/407
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 58 +
arch/arm/boot/dts/omap4.dtsi |5 ++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..628f744 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -54,6 +54,38 @@
AFML, Line In,
AFMR, Line In;
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio2 30 0; /* gpio_62 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0;/* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ clocks = auxclk3;
+ clock-names = main_clk;
+ clock-frequency = 1920;
+ };
};
omap4_pmx_core {
@@ -64,6 +96,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -108,6 +141,23 @@
;
};
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 0x10C /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+ 0x84 0x4/*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x86 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x88 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x8a 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x8c 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x8e 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x90 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x92 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x94 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x96 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x98 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
+
i2c1_pins: pinmux_i2c1_pins {
pinctrl-single,pins =
0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
@@ -249,3 +299,11 @@
mode = 3;
power = 50;
};
+
+usbhshost {
+ port1-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..bd6036e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -660,5 +660,10 @@
ram-bits = 12;
ti,has-mailbox;
};
+
+ auxclk3: auxclk3 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
Hi Tony, On 2013-04-03 18:46, Tony Lindgren wrote: Tony, I've split these patches as follows: Platform data header file changes: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers Board file changes (based on header changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup DSS panel changes (based on header changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup Removing unused fields from header files (based on panel changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup The 2-late-panel-cleanup breaks compilation if the arch changes are not merged, so I'll leave that until they have been merged. Do you mind if I add the board-cleanup branch temporarily to omapdss's for-next, to simplify testing? When everything looks ok, I'll remove it and pass the branch to you to be handled through l-o. Sure please go ahead. There are still some board-*.c related patches that I have not merged, but we'll see those merge conflicts before next as I usually do a merge with next before sending out pull reqs. The code seems to work ok, so I think we can declare the branches stable. I've pushed new for-next branch that does not contain the arch files anymore. In fact, I removed all omapdss patches also, as omapdss should be merged through the drm tree, and I don't want to have conflicts with drm's for-next branch. So, to recap, the common header changes are located in: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers And the branch for linux-omap is: git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup After merging those, some displays won't start anymore until the omapdss changes are in, but things should still compile. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 02/13] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On Mon, Apr 01, 2013 at 11:21:12PM +0100, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com This converts arm and arm64 to use CLKSRC_OF DT based initialization for the arch timer. A new function arch_timer_arch_init is added to allow for arch specific setup. This has a side effect of enabling sched_clock on omap5 and exynos5. There should not be any reason not to use the arch timers for sched_clock. Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Russell King li...@arm.linux.org.uk Cc: Kukjin Kim kgene@samsung.com Cc: Tony Lindgren t...@atomide.com Cc: Simon Horman ho...@verge.net.au Cc: Magnus Damm magnus.d...@gmail.com Cc: Catalin Marinas catalin.mari...@arm.com Cc: Will Deacon will.dea...@arm.com Cc: John Stultz john.stu...@linaro.org Cc: Thomas Gleixner t...@linutronix.de Cc: linux-samsung-...@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux...@vger.kernel.org Unless you pushed the patches already (I've been away for two weeks), for arm64: Acked-by: Catalin Marinas catalin.mari...@arm.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Generic PHY Framework
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this infrastruction should be named something like usb-phy so that it isn't confused with other layers, and it really should live under drivers/usb. g. -- 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: [BUG] omap: mfd/regulator: twl/core: init order
On 04/13/2013 09:27 PM, Christoph Fritz wrote:
Hi
while testing an omap3 board with device tree support I stumbled upon a
bug which is due to wrong initialization order of twl-core and
twl-regulator (I suppose): In the boot process they get loaded way too
late so that a lot of drivers before where configured wrong or just
refuse to load.
For example the real time clock driver: The RTC kicks in way before
twl_probe() and due to that it configures its register map wrong
(at this time twl_priv-twl_id isn't configured yet).
Another example is the omap display subsystem. It (DSS) fails loading
while trying to register some not yet existent regulators and because it
lacks EPROBE_DEFER.
USB and MMC is also not working and I'm suspicious of the same cause.
Any ideas?
Hi Christoph,
It happens, because I2C probes execution have been deferred due to
pinctrl-single driver (, which is not ready at i2c bus initialization
time:
[0.525939] omap_i2c 4807.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c1_pins, deferring probe
[0.526000] platform 4807.i2c: Driver omap_i2c requests probe
deferral
[0.526062] omap_i2c 48072000.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c2_pins, deferring probe
[0.526092] platform 48072000.i2c: Driver omap_i2c requests probe
deferral
[0.526153] omap_i2c 4806.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c3_pins, deferring probe
[0.526184] platform 4806.i2c: Driver omap_i2c requests probe
deferral
[0.526245] omap_i2c 4835.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c4_pins, deferring probe
[0.526275] platform 4835.i2c: Driver omap_i2c requests probe
deferral
I think following change should fix it, could you try it, pls:
diff --git a/drivers/pinctrl/pinctrl-single.c
b/drivers/pinctrl/pinctrl-single.c
index 5c32e88..b2a9d4b 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1014,7 +1014,18 @@ static struct platform_driver pcs_driver = {
},
};
-module_platform_driver(pcs_driver);
+static int __init pcs_driver_drv_init(void)
+{
+ return platform_driver_register(pcs_driver);
+}
+postcore_initcall(pcs_driver_drv_init);
+
+static void __exit pcs_driver_drv_exit(void)
+{
+ platform_driver_unregister(pcs_driver);
+}
+module_exit(pcs_driver_drv_exit);
+
MODULE_AUTHOR(Tony Lindgren t...@atomide.com);
MODULE_DESCRIPTION(One-register-per-pin type device tree based
pinctrl driver);
Thanks
-- Christoph
--
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
--
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/5] capemgr: Beaglebone DT overlay based cape manager
On 21:35 Mon 07 Jan , Arnd Bergmann wrote: (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc) On Monday 07 January 2013, Tony Lindgren wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. I'm looking for this also as on at91 sama9x5ek and sam9cn12ek and the sama5d3xek, we have 1 wire eeproms to detect the boards (motherboards and daugther boards) where we have 1 1-wire per board and cpu boards so we can detect everything and have it's revision and more information we already have barebox that detect the 1-wire but we need the same handling in the kernel Best Regards, J. Arnd ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Generic PHY Framework
Hi, On Monday 15 April 2013 03:50 PM, Grant Likely wrote: On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this Not really. This can be used by USB, SATA and Sylwester was planning to use it for video PHY's. Thanks 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: [BUG] omap: mfd/regulator: twl/core: init order
On Mon, 2013-04-15 at 13:20 +0300, Grygorii Strashko wrote:
On 04/13/2013 09:27 PM, Christoph Fritz wrote:
Hi
while testing an omap3 board with device tree support I stumbled upon a
bug which is due to wrong initialization order of twl-core and
twl-regulator (I suppose): In the boot process they get loaded way too
late so that a lot of drivers before where configured wrong or just
refuse to load.
For example the real time clock driver: The RTC kicks in way before
twl_probe() and due to that it configures its register map wrong
(at this time twl_priv-twl_id isn't configured yet).
Another example is the omap display subsystem. It (DSS) fails loading
while trying to register some not yet existent regulators and because it
lacks EPROBE_DEFER.
USB and MMC is also not working and I'm suspicious of the same cause.
Any ideas?
Hi Christoph,
It happens, because I2C probes execution have been deferred due to
pinctrl-single driver (, which is not ready at i2c bus initialization
time:
[0.525939] omap_i2c 4807.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c1_pins, deferring probe
[0.526000] platform 4807.i2c: Driver omap_i2c requests probe
deferral
[0.526062] omap_i2c 48072000.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c2_pins, deferring probe
[0.526092] platform 48072000.i2c: Driver omap_i2c requests probe
deferral
[0.526153] omap_i2c 4806.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c3_pins, deferring probe
[0.526184] platform 4806.i2c: Driver omap_i2c requests probe
deferral
[0.526245] omap_i2c 4835.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c4_pins, deferring probe
[0.526275] platform 4835.i2c: Driver omap_i2c requests probe
deferral
I think following change should fix it, could you try it, pls:
diff --git a/drivers/pinctrl/pinctrl-single.c
b/drivers/pinctrl/pinctrl-single.c
index 5c32e88..b2a9d4b 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1014,7 +1014,18 @@ static struct platform_driver pcs_driver = {
},
};
-module_platform_driver(pcs_driver);
+static int __init pcs_driver_drv_init(void)
+{
+ return platform_driver_register(pcs_driver);
+}
+postcore_initcall(pcs_driver_drv_init);
+
+static void __exit pcs_driver_drv_exit(void)
+{
+ platform_driver_unregister(pcs_driver);
+}
+module_exit(pcs_driver_drv_exit);
+
Hi Grygorii,
thanks - indeed it does fix the problem. I checked at least the rtc
which is now configured right and working :-)
Do you consider the patch above as a hack or will it go mainline?
Thanks
-- Christoph
--
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] omap display changes for 3.10
Hi Dave, As agreed, here's the pull request for omap display. One thing to note is that the panel platform data cleanups require changes to the board files, which go through linux-omap tree. Merging only either the tag in this pull request, or the board file changes, will give a kernel that compiles and boots, but not all omap panels work properly. Tomi The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9: Linux 3.9-rc5 (2013-03-31 15:12:43 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.10 for you to fetch changes up to 3d62fe5b214fce69ae14abbdb88794a753418614: OMAPDSS: Merge omapdss topic branches (2013-04-15 12:01:02 +0300) Omapdss patches for 3.10 merge window The biggest changes are: * DSI video mode: automatic clock and timing calculation * Lots of platform data related panel driver cleanups, to prepare for DT Alexandru Gheorghiu (1): drivers: video: omap2: dss: Use PTR_RET function Archit Taneja (29): OMAPDSS: panels: keep platform data of all panels in a single header OMAPDSS: NEC-nl8048hl11: remove platform backlight support OMAPDSS: Generic DPI Panel: use devm_kzalloc for allocating driver data OMAPDSS: lb035q02: use devm_kzalloc for allocating driver data OMAPDSS: picodlp: use devm_kzalloc for allocating driver data OMAPDSS: panel acx565akm: remove omap_dss_device maximum backlight level usage OMAPDSS: lb035q02: handle gpios in panel driver OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacks OMAPDSS: generic dpi panel: remove uses of platform_enable/disable ops OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacks OMAPDSS: acx565akm panel: handle gpios in panel driver OMAPDSS: nec-nl8048 panel: handle gpios in panel driver OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacks OMAPDSS: tpo-td043 panel: handle gpios in panel driver OMAPDSS: tpo-td043: remove platform_enable/disable callbacks OMAPDSS: picodlp panel: handle gpio data in panel driver OMAPDSS: picodlp panel: remove platform_enable/disable callbacks OMAPDSS: n8x0 panel: handle gpio data in panel driver OMAPDSS: n8x0 panel: remove use of platform_enable/disable OMAPDSS: VENC: remove platform_enable/disable calls omapdss: DISPC: add max pixel clock limits for LCD and TV managers omapdss: Features: Fix some parameter ranges OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5 omapdss: use devm_clk_get() drm/omap: fix modeset_init if a panel doesn't satisfy omapdrm requirements drm/omap: Make fixed resolution panels work drm/omap: Take a fb reference in omap_plane_update() drm/omap: Fix and improve crtc and overlay manager correlation Lars-Peter Clausen (1): OMAPDSS: nec-nl8048 panel: Use dev_pm_ops Sachin Kamat (1): OMAPDSS: DSI: Use devm_clk_get() Tomi Valkeinen (38): OMAPDSS: add fields to panels' platform data OMAPDSS: DSI: remove DSI DISPC clk divisors from dssdev OMAPDSS: HDMI: remove HDMI clk divisors from dssdev OMAPDSS: DPI: remove omap_dss_device uses OMAPDSS: DSI: remove omap_dss_device uses OMAPDSS: Taal: remove multi-panel support OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync OMAPDSS: add missing export for omap_dss_get_output() OMAPDSS: HDMI: init output earlier OMAPDSS: add output-name OMAPDSS: add output-dispc_channel OMAPDSS: DSI: delay dispc initialization OMAPDSS: DSI: fix DSI channel source initialization OMAPDSS: Taal: remove rotate mirror support OMAPDSS: DPI: fix dpi_get_dsidev() for omap5 OMAPDSS: DISPC: store core clk rate OMAPDSS: DSI: fix wrong unsigned long long use OMAPDSS: DSI: simplify dsi configuration OMAPDSS: DSI: get line buffer size at probe OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode OMAPDSS: DSI remove unneeded clk source setup code OMAPDSS: DISPC: add new clock calculation code OMAPDSS: DSS: add new clock calculation code OMAPDSS: DSI: add new clock calculation code OMAPDSS: SDI: use new clock calculation code OMAPDSS: DPI: use new clock calculation code OMAPDSS: DSI: use new clock calculation code OMAPDSS: remove unused old clock calculation code OMAPDSS: remove dsi videomode from dssdev OMAPDSS: acx565akm: remove platform backlight calls OMAPDSS: ls037v7dw01: remove platform backlight calls OMAPDSS: n8x0: remove platform backlight calls OMAPDSS: generic dpi panel: handle gpios in panel driver OMAPDSS: LS037V7DW01: handle
Re: [BUG] omap: mfd/regulator: twl/core: init order
On 04/15/2013 01:56 PM, Christoph Fritz wrote:
On Mon, 2013-04-15 at 13:20 +0300, Grygorii Strashko wrote:
On 04/13/2013 09:27 PM, Christoph Fritz wrote:
Hi
while testing an omap3 board with device tree support I stumbled upon a
bug which is due to wrong initialization order of twl-core and
twl-regulator (I suppose): In the boot process they get loaded way too
late so that a lot of drivers before where configured wrong or just
refuse to load.
For example the real time clock driver: The RTC kicks in way before
twl_probe() and due to that it configures its register map wrong
(at this time twl_priv-twl_id isn't configured yet).
Another example is the omap display subsystem. It (DSS) fails loading
while trying to register some not yet existent regulators and because it
lacks EPROBE_DEFER.
USB and MMC is also not working and I'm suspicious of the same cause.
Any ideas?
Hi Christoph,
It happens, because I2C probes execution have been deferred due to
pinctrl-single driver (, which is not ready at i2c bus initialization
time:
[0.525939] omap_i2c 4807.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c1_pins, deferring probe
[0.526000] platform 4807.i2c: Driver omap_i2c requests probe
deferral
[0.526062] omap_i2c 48072000.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c2_pins, deferring probe
[0.526092] platform 48072000.i2c: Driver omap_i2c requests probe
deferral
[0.526153] omap_i2c 4806.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c3_pins, deferring probe
[0.526184] platform 4806.i2c: Driver omap_i2c requests probe
deferral
[0.526245] omap_i2c 4835.i2c: could not find pctldev for node
/ocp/pinmux@4a100040/pinmux_i2c4_pins, deferring probe
[0.526275] platform 4835.i2c: Driver omap_i2c requests probe
deferral
I think following change should fix it, could you try it, pls:
diff --git a/drivers/pinctrl/pinctrl-single.c
b/drivers/pinctrl/pinctrl-single.c
index 5c32e88..b2a9d4b 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1014,7 +1014,18 @@ static struct platform_driver pcs_driver = {
},
};
-module_platform_driver(pcs_driver);
+static int __init pcs_driver_drv_init(void)
+{
+ return platform_driver_register(pcs_driver);
+}
+postcore_initcall(pcs_driver_drv_init);
+
+static void __exit pcs_driver_drv_exit(void)
+{
+ platform_driver_unregister(pcs_driver);
+}
+module_exit(pcs_driver_drv_exit);
+
Hi Grygorii,
thanks - indeed it does fix the problem. I checked at least the rtc
which is now configured right and working :-)
Do you consider the patch above as a hack or will it go mainline?
I think, need more opinions on this from community )
I'm just trying to solve my problem and found similar issue.
Thanks
-- Christoph
--
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] ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
reversed when compared to other revisions i.e. it is
active high instead of active low.
Use the beagle_config.usb_pwr_level flag correctly so that
the power regulator can be configured at runtime.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5382215..21136b2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -112,13 +112,13 @@ static u8 omap3_beagle_version;
*/
static struct {
int mmc1_gpio_wp;
- int usb_pwr_level;
+ bool usb_pwr_level; /* 0 - Active Low, 1 - Active High */
int dvi_pd_gpio;
int usr_button_gpio;
int mmc_caps;
} beagle_config = {
.mmc1_gpio_wp = -EINVAL,
- .usb_pwr_level = GPIOF_OUT_INIT_LOW,
+ .usb_pwr_level = 0,
.dvi_pd_gpio = -EINVAL,
.usr_button_gpio = 4,
.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
@@ -178,7 +178,7 @@ static void __init omap3_beagle_init_rev(void)
case 0:
printk(KERN_INFO OMAP3 Beagle Rev: xM Ax/Bx\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
- beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ beagle_config.usb_pwr_level = 1;
beagle_config.mmc_caps = ~MMC_CAP_8_BIT_DATA;
break;
case 2:
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On Sun, Apr 14, 2013 at 10:53 PM, Linus Walleij
linus.wall...@linaro.org wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
Hi Linus, thanks a lot for your feedback.
This looks sort of OK, but I'm still struggling with the question of
what we could do to help other implementations facing the same issue.
Yes, I don't know how we can make it easier to other implementations
(besides adding the irq_request hook to irq_chip) since the logic is
GPIO controller specific.
For example I took a look to drivers/gpio/gpio-tegra.c and if I
understood correctly, the implementation for this driver should be
something like this:
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 414ad91..a2d5c3d 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -346,6 +346,11 @@ static int tegra_gpio_wake_enable(struct irq_data
*d, unsigned int enable)
}
#endif
+static int tegra_gpio_irq_request(struct irq_data *d)
+{
+ tegra_gpio_request(NULL, d-hwirq);
+}
+
static struct irq_chip tegra_gpio_irq_chip = {
.name = GPIO,
.irq_ack= tegra_gpio_irq_ack,
@@ -355,6 +360,7 @@ static struct irq_chip tegra_gpio_irq_chip = {
#ifdef CONFIG_PM_SLEEP
.irq_set_wake = tegra_gpio_wake_enable,
#endif
+ .irq_request= tegra_gpio_irq_request,
};
static const struct dev_pm_ops tegra_gpio_pm_ops = {
This is definitely quite similar to the omap-gpio.c change but not the same.
This is a pretty hard design pattern to properly replicate in every such
driver is it not?
H
Is indeed a hard design pattern but I couldn't figure out a more
generic way to handle this.
Maybe we could use [1] for now to solve the issue that we have with
OMAP GPIO and later when the same issue is found on other GPIO
controllers and a similar change is made on these drivers we will see
some form of pattern that emerge allowing us to make a later refactor
to reduce the code duplication.
Or do you have a better idea on how to solve this?
Yours,
Linus Walleij
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 v3 0/6] Generic PHY Framework
On 04/15/2013 12:36 PM, Kishon Vijay Abraham I wrote: On Monday 15 April 2013 03:50 PM, Grant Likely wrote: On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this Not really. This can be used by USB, SATA and Sylwester was planning to use it for video PHY's. Yes, I have already some RFC patches to handle the display and the camera interface DPHYs (MIPI DSI, MIPI CSI-2) with this API. I didn't post it, since this framework is not settled yet. Those DPHYs need very few operations, like disable/enable only and there was really not suitable API in the kernel until now to handle them. We had plans in the past to write something like this generic PHY framework for the Samsung SoCs. Some SoCs have plenty different PHYs: USB, SATA, MIPI CSI-2, MIPI DSI, HDMI... And some of them are simple enough to be covered by this generic PHY API. Thanks, Sylwester -- 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 1/6] drivers: phy: add generic PHY framework
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend,
resume,
poweron, shutdown.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Hi Kishon,
For review purposes, I'll skip most of the implementation and focus on
the data structures. I think you need to take another look at the
approach your using. The kernel already provides a lot of support for
implementing devices and binding them to drivers that you should be
able to use...
[...]
+/**
+ * struct phy - represent the phy device
+ * @dev: phy device
+ * @label: label given to phy
+ * @type: specifies the phy type
+ * @of_node: device node of the phy
+ * @ops: function pointers for performing phy operations
+ */
+struct phy {
+ struct device dev;
+ const char *label;
+ int type;
+ struct bus_type *bus;
+ struct device_node *of_node;
+ struct phy_ops *ops;
+};
Alright, so the core of the functionality is this 'struct phy' which
tracks all the instances of PHY devices. As I understand it each
physical phy will have a 'struct phy' instance tracking it. That makes
sense.
struct phy embeds a struct device. Also good. The linux driver model
knows all about devices and how to handle them. However, most of the
rest of this structure looks to be reinventing stuff the driver model
already does.
'label' seems unnecessary. struct device embeds a struct kobject, which
means it has a name and shows up in sysfs. Is there a reason that the
device name cannot be used directly?
'type' I just don't understand. I don't see any users of it in this
patch. I only see where it is set.
'bus' absolutely should not be here. The bus type should be set in the
struct device by this subsystem when the device gets registered. There
is no reason to have a pointer to it here.
'of_node' is already in struct device
Finally, it really doesn't look right for a device object to have an
'ops' structure. The whole point of the driver model is that a struct
device doesn't encapsulate any behaviour. A device gets registers to a
bus type, and then the driver core will associate a struct device_driver
to a device that it is able to drive, and the struct device_driver is
supposed to contain any ops structure used to control the device.
+
+/**
+ * struct phy_bind - represent the binding for the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @phy_dev_name: the device name of the phy
+ * @index: used if a single controller uses multiple phys
+ * @auto_bind: tells if the binding is done explicitly from board file or not
+ * @phy: reference to the phy
+ * @list: to maintain a linked list of the binding information
+ */
+struct phy_bind {
+ const char *dev_name;
+ const char *phy_dev_name;
+ int index;
+ int auto_bind:1;
+ struct phy *phy;
+ struct list_head list;
+};
How are PHYs attached to the system. Would the PHY be a direct child of
the host controller device, or would a PHY hang off another bus (like
i2c) for control? (this is how Ethernet phys work; they hang off the
MDIO bus, but may be attached to any Ethernet controller).
Since there is at most a 1:N relationship between host controllers and
PHYs, there shouldn't be any need for a separate structure to describe
binding. Put the inding data into the struct phy itself. Each host
controller can have a list of phys that it is bound to.
Tring to maintain a separate global list of PHY bindings isn't a good
idea. Keep it local to the host controller and the specific phys
instead.
g.
--
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] USB: ehci-omap: Don't select any PHY driver
Don't select NOP_USB_XCEIV. Instead, board config must select USB_PHY and the appropriate PHY driver. Also add a hint in Kconfig so that users enabling this driver manually enable the right PHY drivers as well. Gets rid of the below warnings when USB_EHCI_HCD_OMAP is enabled. warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT USB_PHY) warning: (USB_EHCI_HCD_OMAP) selects NOP_USB_XCEIV which has unmet direct dependencies (USB_SUPPORT USB_PHY) CC: Alan Stern st...@rowland.harvard.edu Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/host/Kconfig |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index c0be25c..c558472 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -150,11 +150,13 @@ config USB_EHCI_MXC config USB_EHCI_HCD_OMAP tristate EHCI support for OMAP3 and later chips depends on ARCH_OMAP - select NOP_USB_XCEIV default y ---help--- Enables support for the on-chip EHCI controller on OMAP3 and later chips. + If your system uses a PHY on the USB port, you will need to + enable USB_PHY and the appropriate PHY driver as well. Most + boards need the NOP_USB_XCEIV PHY driver. config USB_EHCI_HCD_ORION tristate Support for Marvell EBU on-chip EHCI USB controller -- 1.7.4.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 2/2] USB: ehci-omap: Improve PHY error handling
As the USB PHY layer never returns NULL we don't need
to check for that condition.
If we fail to get the PHY device it could be due
to missing USB PHY drivers. Give this hint to the user
in the error message.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/ehci-omap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 5de3e43..2e34ddd 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -175,13 +175,13 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
phy = devm_usb_get_phy_by_phandle(dev, phys, i);
else
phy = devm_usb_get_phy_dev(dev, i);
- if (IS_ERR(phy) || !phy) {
+ if (IS_ERR(phy)) {
/* Don't bail out if PHY is not absolutely necessary */
if (pdata-port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
continue;
- ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
- dev_err(dev, Can't get PHY device for port %d: %d\n,
+ ret = PTR_ERR(phy);
+ dev_err(dev, Can't get PHY device for port %d: %d. Is
USB_PHY driver enabled?\n,
i, ret);
goto err_phy;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3] driver: serial: prevent UART console idle on suspend while using no_console_suspend
Hi Kevin, On Thu, Apr 11, 2013 at 19:45:33, Kevin Hilman wrote: Kevin Hilman khil...@linaro.org writes: Bedia, Vaibhav vaibhav.be...@ti.com writes: Hi Sourav, On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote: [...] Yes, had a look at that and found your situation similar to UART. But how exactly this gets used, I mean I don't see any drivers/ in mainline making use of this compatible string ti,am3352-ocmcram. ? OCMC clock is enabled during bootup (not sure whether that's the h/w default or ROM does it) since the initial bootloader runs from there. By marking the corresponding hwmod with HWMOD_INIT_NO_IDLE we leave the clock running. Right now the sram code under arch/arm/plat-omap/ is what manages the OCMC. I guess this needs to move somewhere under drivers/ and start managing the clocks. Even then we'll need a mechanism to leave the clocks running as part of the kernel suspend process since the assembly code which runs at the fag end of the suspend process runs out of OCMC and hence we can't cut its clock. On AM335x, the OCMC clock is cut to have PER power domain transition but that's done in the WKUP-M3 firmware when going down. During the wakeup sequence, WKUP-M3 re-enables the OCMC clock so that when the kernel resumes the h/w state is same. OK, but *today*, in *mainline*, where in the linux kernel (not the M3 firmware) is the OCMRAM clock cut during suspend? From what I can see, there is no driver for this device, so there are no system PM calls being done for that device, and thus no omap_device calls being done for that device, so the no_idle_on_suspend has no effect. OK, I think I confused things here, sorry. I was thinking runtime PM here, but wrote system PM. The no_idle_on_suspend feature only affects system PM, and the omap_device calls will still be called during system PM, even without a driver. That being said, the commit below[1], added in v3.6 should prevent the any automaic clock gating for devices without drivers bound. Since there is no driver for the OCM RAM block, you shouldn't be affected by the automatic idle on suspend anyways. So, my proposal is that Sourav remove that flag from the AM33xx hwmod when he removes this feature. Apologies for the delayed response. I was out of office for a couple of days. I don't recall the exact kernel version in which I ended up adding this flag to keep the clock running but yes after the change mentioned below this flag is not required. I just did a sanity check by removing this flag on v3.8 kernel and things work fine across suspend. Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] driver: serial: prevent UART console idle on suspend while using no_console_suspend
Hi Kevin, On Thursday 11 April 2013 07:45 PM, Kevin Hilman wrote: Kevin Hilmankhil...@linaro.org writes: Bedia, Vaibhavvaibhav.be...@ti.com writes: Hi Sourav, On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote: [...] Yes, had a look at that and found your situation similar to UART. But how exactly this gets used, I mean I don't see any drivers/ in mainline making use of this compatible string ti,am3352-ocmcram. ? OCMC clock is enabled during bootup (not sure whether that's the h/w default or ROM does it) since the initial bootloader runs from there. By marking the corresponding hwmod with HWMOD_INIT_NO_IDLE we leave the clock running. Right now the sram code under arch/arm/plat-omap/ is what manages the OCMC. I guess this needs to move somewhere under drivers/ and start managing the clocks. Even then we'll need a mechanism to leave the clocks running as part of the kernel suspend process since the assembly code which runs at the fag end of the suspend process runs out of OCMC and hence we can't cut its clock. On AM335x, the OCMC clock is cut to have PER power domain transition but that's done in the WKUP-M3 firmware when going down. During the wakeup sequence, WKUP-M3 re-enables the OCMC clock so that when the kernel resumes the h/w state is same. OK, but *today*, in *mainline*, where in the linux kernel (not the M3 firmware) is the OCMRAM clock cut during suspend? From what I can see, there is no driver for this device, so there are no system PM calls being done for that device, and thus no omap_device calls being done for that device, so the no_idle_on_suspend has no effect. OK, I think I confused things here, sorry. I was thinking runtime PM here, but wrote system PM. The no_idle_on_suspend feature only affects system PM, and the omap_device calls will still be called during system PM, even without a driver. That being said, the commit below[1], added in v3.6 should prevent the any automaic clock gating for devices without drivers bound. Since there is no driver for the OCM RAM block, you shouldn't be affected by the automatic idle on suspend anyways. So, my proposal is that Sourav remove that flag from the AM33xx hwmod when he removes this feature. Kevin Thanks a lot for your inputs and helping in bringing this thread to a logical conclusion. I will post a v4 for this patch along with other fixes/cleanups required as recommended by you and russell. Thanks, Sourav [1] commit 72bb6f9b51c82c820ddef892455a85b115460904 Author: Kevin Hilmankhil...@ti.com Date: Tue Jul 10 15:29:04 2012 -0700 ARM: OMAP: omap_device: don't attempt late suspend if no driver bound Currently, the omap_device PM domain layer uses the late suspend and early resume callbacks to ensure devices are in their low power states. However, this is attempted even in cases where a driver probe has failed. If a driver's -probe() method fails, the driver is likely in a state where it is not expecting its runtime PM callbacks to be called, yet currently the omap_device PM domain code attempts to call the drivers callbacks. To fix, use the omap_device driver_status field to check whether a driver is bound to the omap_device before attempting to trigger driver callbacks. Reviewed-by: Paul Walmsleyp...@pwsan.com Signed-off-by: Kevin Hilmankhil...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Generic PHY Framework
On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Monday 15 April 2013 03:50 PM, Grant Likely wrote: On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this Not really. This can be used by USB, SATA and Sylwester was planning to use it for video PHY's. So what are the common bits that are shared between those phys? Merely matching phys to controllers? Besides that, each of those devices have very different behaviour. You wouldn't be able to attach any interface logic to the generic struct phy. I don't think it makes a whole lot of sense to lump them all into the same type of registration. g. -- 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 1/6] drivers: phy: add generic PHY framework
Hi,
On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
poweron, shutdown.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Hi Kishon,
For review purposes, I'll skip most of the implementation and focus on
the data structures. I think you need to take another look at the
approach your using. The kernel already provides a lot of support for
implementing devices and binding them to drivers that you should be
able to use...
[...]
+/**
+ * struct phy - represent the phy device
+ * @dev: phy device
+ * @label: label given to phy
+ * @type: specifies the phy type
+ * @of_node: device node of the phy
+ * @ops: function pointers for performing phy operations
+ */
+struct phy {
+ struct device dev;
+ const char *label;
+ int type;
+ struct bus_type *bus;
+ struct device_node *of_node;
+ struct phy_ops *ops;
+};
Alright, so the core of the functionality is this 'struct phy' which
tracks all the instances of PHY devices. As I understand it each
physical phy will have a 'struct phy' instance tracking it. That makes
sense.
struct phy embeds a struct device. Also good. The linux driver model
knows all about devices and how to handle them. However, most of the
rest of this structure looks to be reinventing stuff the driver model
already does.
'label' seems unnecessary. struct device embeds a struct kobject, which
means it has a name and shows up in sysfs. Is there a reason that the
device name cannot be used directly?
hmm.. the label name is supposed to be a simpler name than device name.
Say for instance omap-usb2.1.auto device name can simply be
omap-usb2-phy. Further the device name while using dt will have
register address in it. However it's used only for displaying the label
in sysfs entry (/sys/class/phy/phy/label).
'type' I just don't understand. I don't see any users of it in this
patch. I only see where it is set.
yeah. Was planning to remove this in my next version (btw the latest is
version 5).
'bus' absolutely should not be here. The bus type should be set in the
struct device by this subsystem when the device gets registered. There
is no reason to have a pointer to it here.
right. I had removed it in version 5 of this patch series.
'of_node' is already in struct device
I wasn't sure if we can manually assign the of_node of one device to
of_node of an another device. Here the of_node comes from _phy provider_.
Finally, it really doesn't look right for a device object to have an
'ops' structure. The whole point of the driver model is that a struct
device doesn't encapsulate any behaviour. A device gets registers to a
bus type, and then the driver core will associate a struct device_driver
We have decided not to implement the PHY layer as a separate bus layer.
The PHY provider can be part of any other bus. Making the PHY layer as a
bus will make the PHY provider to be part of multiple buses which will
lead to bad design. All we are trying to do here is keep the pool of PHY
devices under PHY class in this layer and help any controller that wants
to use the PHY to get it.
to a device that it is able to drive, and the struct device_driver is
supposed to contain any ops structure used to control the device.
+
+/**
+ * struct phy_bind - represent the binding for the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @phy_dev_name: the device name of the phy
+ * @index: used if a single controller uses multiple phys
+ * @auto_bind: tells if the binding is done explicitly from board file or not
+ * @phy: reference to the phy
+ * @list: to maintain a linked list of the binding information
+ */
+struct phy_bind {
+ const char *dev_name;
+ const char *phy_dev_name;
+ int index;
+ int auto_bind:1;
+ struct phy *phy;
+ struct list_head list;
+};
How are PHYs attached to the system. Would the PHY be a direct child of
the host controller device, or would a PHY
Re: Latest randconfig build errors
On Saturday 13 April 2013, Rob Clark wrote: On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren t...@atomide.com wrote: drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table' drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here Rob, I assume you'll do a patch for this one? oh, I apologize for the late reply, I didn't see this email... There is a patch that we can merge to make tilcdc bool instead of tristate[1], which I suppose is ok for a temporary fix. Although I'm all-ears if someone has a better idea about how to fix this. The problem is that we have multiple sub-devices for different possible panel drivers, so that depending on DT tables, the correct ones get loaded for the hw. But they are all built into a single module. If the master device is always present, that's enough for autoloading the module anyway, you can just drop the other two MODULE_DEVICE_TABLE lines. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Generic PHY Framework
Hi, On Monday 15 April 2013 05:56 PM, Grant Likely wrote: On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Monday 15 April 2013 03:50 PM, Grant Likely wrote: On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this Not really. This can be used by USB, SATA and Sylwester was planning to use it for video PHY's. So what are the common bits that are shared between those phys? Merely matching phys to controllers? Besides that, each of those devices have The same PIPE3 PHY IP is used for USB (usb3) and SATA in OMAP5. Even for just matching PHYs to controllers you need a simple framework (like this) or else we'll end up in creating such frameworks for lot of these subsystems. Thanks 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
[PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
This will not work for Rev Cx boards because of reversed logic
for USB_POWER_Enable.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 62 +
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..d394c51 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,60 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio5 19 0; /* gpio_147 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ enable-active-high; /* FIXME: active-low for Rev. C */
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ vcc-supply = hsusb2_power;
+ };
+
+};
+
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+ 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x1aa 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x1ac 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
};
i2c1 {
@@ -125,3 +179,11 @@
mode = 3;
power = 50;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx
On 04/15/2013 03:35 PM, Roger Quadros wrote:
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
This will not work for Rev Cx boards because of reversed logic
for USB_POWER_Enable.
CC: Benoît Cousson b-cous...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..d394c51 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,60 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio5 19 0; /* gpio_147 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ enable-active-high; /* FIXME: active-low for Rev. C */
Benoit Tony,
Any ideas how to tackle the reversed logic for Rev. C boards?
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ vcc-supply = hsusb2_power;
+ };
+
+};
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
[RFC v1 0/1] introduce regulator chain locking scheme
Hi Mark, Liam, All Our target is to reuse common DVFS framework proposed by Mike Turquette in http://lwn.net/Articles/540422/ and cpufreq-cpu0.c for all TI SoC and minimize creation of any TI specific APIs or modules. The common DVFS framework solution is based on assumption that Regulator, connected to DVFS FW or CPU0 CPUFreq, is able to change requested voltage for the corresponding Voltage domain (like CPU/MPU) by itself. But most of TI SoCs, which support DVFS, have more complex voltage supply schema as shown below: || || --| RegulatorY |--| CPU DVFS | || || \ \ \ \_ \\ |---| |---| |-| --| RegulatorX (PMIC) |--| Regulator AVS |--| ABB LDO |-- |---| |---| |-| /|\ | |__| Voltage adjustment and they need to configure, at least, internal ABB LDO befor/after reconfiguring external voltage supplier in PMIC. (as maximum - Regulator AVS (Adaptive voltage scaling) is needed to be reconfigured after ABB LDO, and Regulator AVS may, finally, reconfigure external voltage supplier with voltage value which is different from initially requested by DVFS). for example (VcurVreq): - DVFS requests voltage change - AVS converts Vreq to Vreq1 (say calibrated) - AVS reconfigure RegulatorX (PMIC) to voltage Vreq1 - ABB LDO change type to FBB This Regulator chaining scema can fit to Regulator framework very well (from our point of view): - DVFS: abb-set_voltage(Vreq) - ABB: if (VcurVreq) AVS-set_voltage(Vreq) - AVS: PMIC-set_voltage(Vreq1) - ABB: if (VcurVreq) change type to FBB But there are some limitations: - the whole Regulator chain need to be locked in case if any part of it has been accessed from outside; - child regulator should have access to set/get voltage methods of its parent (supplier). The proposed patches allow to remove these restrictions and they are inspired by http://lwn.net/Articles/540422/. Related dicussions: - regulator: query on regulator re-entrance http://marc.info/?l=linux-omapm=136513861315970w=2 - clk: notifier handler for dynamic voltage scaling https://lkml.org/lkml/2013/2/27/414 Tested on K3.8 OMAP4 SDP/T2 (ABB+vcvp regulator) and OMAP5 sevm (ABB+smps123(i2c) regulator): - cpu freq voltages was scaled. Could you please review and advise? Does anyone else interested in or have similar problems? Grygorii Strashko (1): regulator: core: introduce regulator chain locking scheme drivers/regulator/core.c | 134 -- include/linux/regulator/driver.h |2 + 2 files changed, 88 insertions(+), 48 deletions(-) Regards Grygorii Strashko Cc: linux-ker...@vger.kernel.org (open list) Cc: Mike Turquette mturque...@linaro.org Cc: Tero Kristo t-kri...@ti.com Cc: Nishanth Menon n...@ti.com Cc: linux-omap linux-omap@vger.kernel.org Cc: linux-arm linux-arm-ker...@lists.infradead.org -- 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
[RFC v1] regulator: core: introduce regulator chain locking scheme
In some cases the regulators may be organized in a chain like:
-regA-regB-regC
where regA is supplier for regB and regB is supplier for regC.
Currently it would be possible to reconfigure regA and regC at same time
form different contexts, because each regulator has it own mutex.
But in some cases, the only the whole chain is allowed be reconfigured
because of dependencies between regulators - to change regB
configuration the regA need to be updated first.
Hence, introduce regulator chain locking scheme to lock whole Regulator
chain in case if any part of it has been accessed from outside.
To achieve this goal:
- abstract regulator locking out into helper functions;
- use the root Regulator (which has no supply defined, like regA) in chain to
protect the whole chain;
- implement regulator chain locking scheme as proposed by Thomas Gleixner for
CCF
re-entrance in https://lkml.org/lkml/2013/3/27/171 and in the similar way as
it is done for CCF by Mike Turquette in https://lkml.org/lkml/2013/3/28/512
In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.
Cc: linux-ker...@vger.kernel.org
Cc: Mike Turquette mturque...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: linux-omap linux-omap@vger.kernel.org
Cc: linux-arm linux-arm-ker...@lists.infradead.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/regulator/core.c | 134 --
include/linux/regulator/driver.h |2 +
2 files changed, 88 insertions(+), 48 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index e3661c2..089cc63 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -110,6 +110,44 @@ static const char *rdev_get_name(struct regulator_dev
*rdev)
return ;
}
+static void regulator_lock(struct regulator_dev *rdev)
+{
+ struct regulator_dev *locking_rdev = rdev;
+
+ while (locking_rdev-supply)
+ locking_rdev = locking_rdev-supply-rdev;
+
+ if (!mutex_trylock(locking_rdev-mutex)) {
+ if (locking_rdev-lock_owner == current) {
+ locking_rdev-lock_count++;
+ return;
+ }
+ mutex_lock(locking_rdev-mutex);
+ }
+
+ WARN_ON_ONCE(locking_rdev-lock_owner != NULL);
+ WARN_ON_ONCE(locking_rdev-lock_count != 0);
+
+ locking_rdev-lock_count = 1;
+ locking_rdev-lock_owner = current;
+ dev_dbg(locking_rdev-dev, Is locked. locking %s\n,
+ rdev_get_name(rdev));
+}
+
+static void regulator_unlock(struct regulator_dev *rdev)
+{
+ struct regulator_dev *locking_rdev = rdev;
+
+ while (locking_rdev-supply)
+ locking_rdev = locking_rdev-supply-rdev;
+
+ if (--locking_rdev-lock_count)
+ return;
+
+ locking_rdev-lock_owner = NULL;
+ mutex_unlock(locking_rdev-mutex);
+}
+
/**
* of_get_regulator - get a regulator device node based on supply name
* @dev: Device pointer for the consumer (of regulator) device
@@ -292,9 +330,9 @@ static ssize_t regulator_uV_show(struct device *dev,
struct regulator_dev *rdev = dev_get_drvdata(dev);
ssize_t ret;
- mutex_lock(rdev-mutex);
+ regulator_lock(rdev);
ret = sprintf(buf, %d\n, _regulator_get_voltage(rdev));
- mutex_unlock(rdev-mutex);
+ regulator_unlock(rdev);
return ret;
}
@@ -357,9 +395,9 @@ static ssize_t regulator_state_show(struct device *dev,
struct regulator_dev *rdev = dev_get_drvdata(dev);
ssize_t ret;
- mutex_lock(rdev-mutex);
+ regulator_lock(rdev);
ret = regulator_print_state(buf, _regulator_is_enabled(rdev));
- mutex_unlock(rdev-mutex);
+ regulator_unlock(rdev);
return ret;
}
@@ -467,10 +505,10 @@ static ssize_t regulator_total_uA_show(struct device *dev,
struct regulator *regulator;
int uA = 0;
- mutex_lock(rdev-mutex);
+ regulator_lock(rdev);
list_for_each_entry(regulator, rdev-consumer_list, list)
uA += regulator-uA_load;
- mutex_unlock(rdev-mutex);
+ regulator_unlock(rdev);
return sprintf(buf, %d\n, uA);
}
static DEVICE_ATTR(requested_microamps, 0444, regulator_total_uA_show, NULL);
@@ -1104,7 +1142,7 @@ static struct regulator *create_regulator(struct
regulator_dev *rdev,
if (regulator == NULL)
return NULL;
- mutex_lock(rdev-mutex);
+ regulator_lock(rdev);
regulator-rdev = rdev;
list_add(regulator-list, rdev-consumer_list);
@@ -1156,12 +1194,12 @@ static struct regulator *create_regulator(struct
regulator_dev *rdev,
_regulator_is_enabled(rdev))
regulator-always_on = true;
- mutex_unlock(rdev-mutex);
+ regulator_unlock(rdev);
return regulator;
Re: [PATCH V4 10/18] ARM: OMAP2+: Add function to read GPMC settings from device-tree
On Tue, 19 Mar 2013 11:35:48 -0500, Jon Hunter jon-hun...@ti.com wrote: Adds a function to read the various GPMC chip-select settings from device-tree and store them in the gpmc_settings structure. Update the GPMC device-tree binding documentation to describe these options. Signed-off-by: Jon Hunter jon-hun...@ti.com Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Documentation/devicetree/bindings/bus/ti-gpmc.txt | 23 arch/arm/mach-omap2/gpmc.c| 40 + arch/arm/mach-omap2/gpmc.h|2 ++ 3 files changed, 65 insertions(+) diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt index 5ddb2e9..6fde1cf 100644 --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x: - gpmc,wr-access - gpmc,wr-data-mux-bus +GPMC chip-select settings properties for child nodes. All are optional. + +- gpmc,burst-length Page/burst length. Must be 4, 8 or 16. +- gpmc,burst-wrapEnables wrap bursting +- gpmc,burst-readEnables read page/burst mode +- gpmc,burst-write Enables write page/burst mode +- gpmc,device-nand Device is NAND +- gpmc,device-width Total width of device(s) connected to a GPMC + chip-select in bytes. The GPMC supports 8-bit + and 16-bit devices and so this property must be + 1 or 2. I would suggest specifying the actual number of bits. ie. 8 or 16. There is some precidence for that already in DT bindings. +- gpmc,mux-add-data Address and data multiplexing configuration. + Valid values are 1 for address-address-data + multiplexing mode and 2 for address-data + multiplexing mode. +- gpmc,sync-read Enables synchronous read. Defaults to asynchronous + is this is not set. 'if'? +- gpmc,sync-writeEnables synchronous writes. Defaults to asynchronous + is this is not set. +- gpmc,wait-pin Wait-pin used by client. Must be less than + gpmc,num-waitpins. +- gpmc,wait-on-read Enables wait monitoring on reads. +- gpmc,wait-on-write Enables wait monitoring on writes. Otherwise looks okay to me. g. -- 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
[RFC PATCH v2 0/6] ARM: OMAP3+: Introduce ABB driver
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Following patch series introduces the Adaptive Body-Bias LDO driver, which handles LDOs voltage during OPP change routine. Current implementation is based on patch series from Mike Turquette: http://marc.info/?l=linux-omapm=134931341818379w=2 ABB transition is a part of OPP changing sequence. ABB can operate in the following modes: - Bypass mode: Activated when ABB is not required - FBB mode: Fast Body Bias mode, used on fast OPPs - RBB mode: Reverse Body Bias mode, used on slow OPPs In current implementation ABB is converted to regulator. Standalone OPP table is used to store ABB mode, it is defined in device tree for each ABB regulator. It has the following format: operating-points = /* uV ABB (0 - Bypass, 1 - FBB, 2 - RBB) */ 88 0 106 1 125 1 126 1 ; ABB regulator is linked to regulator chain. Related discussions: regulator: query on regulator re-entrance http://marc.info/?l=linux-omapm=136513861315970w=2 regulator: core: introduce regulator chain locking scheme https://patchwork.kernel.org/patch/2445091/ clk: notifier handler for dynamic voltage scaling https://lkml.org/lkml/2013/2/27/414 Andrii.Tseglytskyi (6): ARM: dts: OMAP36xx: add device tree for ABB ARM: dts: OMAP4: add device tree for ABB ARM: dts: OMAP5: add device tree for ABB ARM: OMAP3+: ABB: add aliases for sysclk used in ABB driver ARM: OMAP3+: ABB: introduce ABB driver ARM: OMAP3+: ABB: introduce debugfs entry Documentation/devicetree/bindings/power/abb.txt | 38 ++ arch/arm/boot/dts/omap36xx.dtsi | 20 + arch/arm/boot/dts/omap4.dtsi| 22 + arch/arm/boot/dts/omap443x.dtsi | 23 + arch/arm/boot/dts/omap446x.dtsi | 39 ++ arch/arm/boot/dts/omap5.dtsi| 39 ++ arch/arm/mach-omap2/cclock3xxx_data.c |1 + arch/arm/mach-omap2/cclock44xx_data.c |2 + drivers/regulator/Kconfig |6 + drivers/regulator/Makefile |1 + drivers/regulator/abb-regulator.c | 710 +++ 11 files changed, 901 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/abb.txt create mode 100644 arch/arm/boot/dts/omap446x.dtsi create mode 100644 drivers/regulator/abb-regulator.c -- 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
[RFC PATCH v2 1/6] ARM: dts: OMAP36xx: add device tree for ABB
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add DT ABB data for OMAP36xx family of devices.
Data is based on OMAP36XX TRM document.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
Documentation/devicetree/bindings/power/abb.txt | 38 +++
arch/arm/boot/dts/omap36xx.dtsi | 20
2 files changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/abb.txt
diff --git a/Documentation/devicetree/bindings/power/abb.txt
b/Documentation/devicetree/bindings/power/abb.txt
new file mode 100644
index 000..3f6c17c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/abb.txt
@@ -0,0 +1,38 @@
+ABB regulator for OMAP platforms
+
+Required properties :
+- compatible:
+ - ti,omap36xx-abb for OMAP36XX
+ - ti,omap4-abb for OMAP4
+ - ti,omap5-abb for OMAP5
+
+- regulator-min-microvolt: lowest OPP voltage
+- regulator-max-microvolt: highest OPP voltage
+- regulator-always-on: ABB should be always on
+- reg: addres range defined in TRM
+- ti,tranxdone_status_mask: ABB transition state mask
+- operating-points: An array of 2-tuples items, and each item consists
+ of voltage and ABB opp_sel, like volt-uV opp_sel.
+ volt: voltage in uV
+ opp_sel: 0-bypass, 1-FBB, 2-RBB
+
+Examples :
+abb_mpu_iva: regulator-abb1 {
+ compatible = ti,omap36xx-abb;
+ regulator-name = abb_mpu_iva;
+ regulator-min-microvolt = 1012500;
+ regulator-max-microvolt = 1375000;
+ regulator-always-on;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x483072f0 0x8,
+ 0x48306818 0x4;
+ ti,tranxdone_status_mask = 0x400;
+ operating-points =
+ /* uV ABB */
+ 1012500 0
+ 120 0
+ 1325000 0
+ 1375000 1
+ ;
+};
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index b89233e..5e917ca 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -28,6 +28,26 @@
};
};
+ abb_mpu_iva: regulator-abb1 {
+ compatible = ti,omap36xx-abb;
+ regulator-name = abb_mpu_iva;
+ regulator-min-microvolt = 1012500;
+ regulator-max-microvolt = 1375000;
+ regulator-always-on;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x483072f0 0x8,
+ 0x48306818 0x4;
+ ti,tranxdone_status_mask = 0x400;
+ operating-points =
+ /* uV ABB */
+ 1012500 0
+ 120 0
+ 1325000 0
+ 1375000 1
+ ;
+ };
+
ocp {
uart4: serial@49042000 {
compatible = ti,omap3-uart;
--
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
[RFC PATCH v2 2/6] ARM: dts: OMAP4: add device tree for ABB
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add DT ABB data for OMAP44xx family of devices.
Data is based on OMAP44xx TRM document.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/boot/dts/omap4.dtsi| 22 ++
arch/arm/boot/dts/omap443x.dtsi | 23 +++
arch/arm/boot/dts/omap446x.dtsi | 39 +++
3 files changed, 84 insertions(+)
create mode 100644 arch/arm/boot/dts/omap446x.dtsi
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..8a98002 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -81,6 +81,28 @@
};
};
+ abb_mpu: regulator-abb1 {
+ compatible = ti,omap4-abb;
+ regulator-name = abb_mpu;
+ regulator-always-on;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x4a307bd0 0x8,
+ 0x4a306014 0x4;
+ ti,tranxdone_status_mask = 0x80;
+ };
+
+ abb_iva: regulator-abb2 {
+ compatible = ti,omap4-abb;
+ regulator-name = abb_iva;
+ regulator-always-on;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x4a307bd8 0x8,
+ 0x4a306010 0x4;
+ ti,tranxdone_status_mask = 0x8000;
+ };
+
/*
* XXX: Use a flat representation of the OMAP4 interconnect.
* The real OMAP interconnect network is quite complex.
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..044b54c 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -24,4 +24,27 @@
clock-latency = 30; /* From legacy driver */
};
};
+
+ abb_mpu: regulator-abb1 {
+ regulator-min-microvolt = 1025000;
+ regulator-max-microvolt = 1375000;
+ operating-points =
+ /* uV ABB */
+ 1025000 0
+ 120 0
+ 1313000 0
+ 1375000 1
+ ;
+ };
+
+ abb_iva: regulator-abb2 {
+ regulator-min-microvolt = 95;
+ regulator-max-microvolt = 1291000;
+ operating-points =
+ /* uV ABB */
+ 95 0
+ 1114000 0
+ 1291000 0
+ ;
+ };
};
diff --git a/arch/arm/boot/dts/omap446x.dtsi b/arch/arm/boot/dts/omap446x.dtsi
new file mode 100644
index 000..3c81d3b
--- /dev/null
+++ b/arch/arm/boot/dts/omap446x.dtsi
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Source for OMAP446x SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.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/ omap4.dtsi
+
+/ {
+ abb_mpu: regulator-abb1 {
+ regulator-min-microvolt = 1025000;
+ regulator-max-microvolt = 139;
+ operating-points =
+ /* uV ABB */
+ 1025000 0
+ 1203000 0
+ 1317000 0
+ 138 1
+ 139 1
+ ;
+ };
+
+ abb_iva: regulator-abb2 {
+ regulator-min-microvolt = 95;
+ regulator-max-microvolt = 1376000;
+ operating-points =
+ /* uV ABB */
+ 95 0
+ 114 0
+ 1291000 0
+ 1375000 1
+ 1376000 1
+ ;
+ };
+};
--
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
[RFC PATCH v2 3/6] ARM: dts: OMAP5: add device tree for ABB
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add DT ABB data for OMAP543x family of devices.
Data is based on OMAP543x TRM document.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 39 +++
1 file changed, 39 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..e1b2c92 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -74,6 +74,45 @@
};
};
+ abb_mpu: regulator-abb1 {
+ compatible = ti,omap5-abb;
+ regulator-name = abb_mpu;
+ regulator-min-microvolt = 88;
+ regulator-max-microvolt = 126;
+ regulator-always-on;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x4ae07cdc 0x8,
+ 0x4ae06014 0x4;
+ ti,tranxdone_status_mask = 0x80;
+ operating-points =
+ /* uV ABB */
+ 88 0
+ 106 1
+ 125 1
+ 126 1
+ ;
+ };
+
+ abb_iva: regulator-abb2 {
+ compatible = ti,omap5-abb;
+ regulator-name = abb_iva;
+ regulator-min-microvolt = 88;
+ regulator-max-microvolt = 112;
+ regulator-always-on;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x4ae07ce4 0x8,
+ 0x4ae06010 0x4;
+ ti,tranxdone_status_mask = 0x8000;
+ operating-points =
+ /* uV ABB */
+ 88 0
+ 1025000 0
+ 112 0
+ ;
+ };
+
/*
* XXX: Use a flat representation of the OMAP3 interconnect.
* The real OMAP interconnect network is quite complex.
--
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
[RFC PATCH v2 4/6] ARM: OMAP3+: ABB: add aliases for sysclk used in ABB driver
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
This patch introduces aliases for SYS clock nedded for ABB
driver, which will be introduced in the following patch.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |1 +
arch/arm/mach-omap2/cclock44xx_data.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 45cd264..9784332 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3540,6 +3540,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, timer_32k_ck, omap_32k_fck),
CLK(NULL, timer_sys_ck, sys_ck),
CLK(NULL, cpufreq_ck, dpll1_ck),
+ CLK(483072f0.regulator-abb1, abb_sys_ck, sys_ck),
};
static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 88e37a4..0b7914d 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1684,6 +1684,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK(4013c000.timer, timer_sys_ck, syc_clk_div_ck),
CLK(4013e000.timer, timer_sys_ck, syc_clk_div_ck),
CLK(NULL, cpufreq_ck, dpll_mpu_ck),
+ CLK(4a307bd0.regulator-abb1, abb_sys_ck, sys_clkin_ck),
+ CLK(4a307bd8.regulator-abb2, abb_sys_ck, sys_clkin_ck),
};
int __init omap4xxx_clk_init(void)
--
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
[RFC PATCH v2 5/6] ARM: OMAP3+: ABB: introduce ABB driver
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Patch introduces the Adaptive Body-Bias LDO driver, which handles LDOs voltage during OPP change routine. Current implementation is based on patch series from Mike Turquette: http://marc.info/?l=linux-omapm=134931341818379w=2 ABB can operate in the following modes: - Bypass mode: Activated when ABB is not required - FBB mode: Fast Body Bias mode, used on fast OPPs - RBB mode: Reverse Body Bias mode, used on slow OPPs ABB transition is a part of OPP changing sequence: Case 1. Transition From Lower OPP to Higher OPP: - Set the new OPP voltage value - Select the next OPP for the ABB LDO - Change MPU/IVA/CORE frequency to the new OPP frequency ABB mode must be changed AFTER voltage scaling and BEFORE clock rate scaling, if OPP scales UP. Case 2. Transition From Higher OPP to Lower OPP: - Change MPU/IVA/CORE frequency to new OPP frequency - Select the next OPP for the ABB LDO - Set the new OPP voltage value ABB mode must be changed AFTER clock rate scaling and BEFORE voltage scaling, if OPP scales DOWN. In current implementation ABB is handled using generic regulator framework. Standalone OPP table is used to store ABB mode, it has the following format in device tree: operating-points = /* uV ABB (0 - Bypass, 1 - FBB, 2 - RBB) */ 88 0 106 1 125 1 126 1 ; Cc: Mike Turquette mturque...@linaro.org Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Signed-off-by: Mike Turquette mturque...@linaro.org --- drivers/regulator/Kconfig |6 + drivers/regulator/Makefile|1 + drivers/regulator/abb-regulator.c | 638 + 3 files changed, 645 insertions(+) create mode 100644 drivers/regulator/abb-regulator.c diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index a5d97ea..60c0bab 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -514,5 +514,11 @@ config REGULATOR_AS3711 This driver provides support for the voltage regulators on the AS3711 PMIC +config REGULATOR_ABB + bool TI Adaptive Body Bias + depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5) + help + This driver supports the ABB voltage regulators + endif diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index 6e82503..ea39b22 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -70,6 +70,7 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o +obj-$(CONFIG_REGULATOR_ABB) += abb-regulator.o ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG diff --git a/drivers/regulator/abb-regulator.c b/drivers/regulator/abb-regulator.c new file mode 100644 index 000..5a828e2 --- /dev/null +++ b/drivers/regulator/abb-regulator.c @@ -0,0 +1,638 @@ +/* + * OMAP Adaptive Body-Bias core + * + * Copyright (C) 2011 Texas Instruments, Inc. + * Mike Turquette mturque...@ti.com + * + * Copyright (C) 2013 Texas Instruments, Inc. + * Andrii Tseglytskyi andrii.tseglyts...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/delay.h +#include linux/module.h +#include linux/platform_device.h +#include linux/of_device.h +#include linux/io.h +#include linux/clk.h +#include linux/opp.h +#include linux/regulator/driver.h +#include linux/regulator/machine.h +#include linux/regulator/of_regulator.h + +/* NOMINAL_OPP bypasses the ABB ldo, FAST_OPP sets it to Forward Body-Bias */ +#define OMAP_ABB_NOMINAL_OPP 0 +#define OMAP_ABB_FAST_OPP 1 +#define OMAP_ABB_SLOW_OPP 3 +#define OMAP_ABB_NO_LDO(~0) + +/* Time for the ABB ldo to settle after transition (in micro-seconds) */ +#define ABB_TRANXDONE_TIMEOUT 50 + +#define ABB_OPP_SEL_MASK (0x3 0) +#define ABB_OPP_CHANGE_MASK(0x1 2) +#define ABB_SR2EN_MASK (0x1 0) +#define ABB_ACTIVE_FBB_SEL_MASK(0x1 2) +#define ABB_ACTIVE_RBB_SEL_MASK(0x1 1) +#define ABB_SR2_WTCNT_VALUE_MASK (0xff 8) + +/* + * struct omap_abb_data - common data for each instance of ABB ldo + * + * @opp_sel_mask: selects Fast/Nominal/Slow OPP for ABB + * @opp_change_mask: selects OPP_CHANGE bit value + * @sr2_wtcnt_value_mask: LDO settling time for active-mode OPP change + * @sr2en_mask:enables/disables ABB + * @fbb_sel_mask: selects FBB mode + * @rbb_sel_mask: selects RBB mode + * @settling_time: IRQ handle used to resolve IRQSTATUS offset masks + * @clock_cycles: value needed for LDO setting time
[RFC PATCH v2 6/6] ARM: OMAP3+: ABB: introduce debugfs entry
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Patch adds debugfs entry for each ABB:
/sys/kernel/debug/ABB device name
This entry is read-only. It prints current state of ABB.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
drivers/regulator/abb-regulator.c | 74 -
1 file changed, 73 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/abb-regulator.c
b/drivers/regulator/abb-regulator.c
index 5a828e2..dad517d 100644
--- a/drivers/regulator/abb-regulator.c
+++ b/drivers/regulator/abb-regulator.c
@@ -19,6 +19,7 @@
#include linux/io.h
#include linux/clk.h
#include linux/opp.h
+#include linux/debugfs.h
#include linux/regulator/driver.h
#include linux/regulator/machine.h
#include linux/regulator/of_regulator.h
@@ -440,6 +441,74 @@ static struct regulator_ops omap_abb_reg_ops = {
};
/*
+ * omap_abb_info_dump() - ABB debug dump
+ *
+ * Returns 0
+ */
+static int omap_abb_info_dump(struct seq_file *sf, void *unused)
+{
+ const struct omap_abb *abb = (struct omap_abb *)sf-private;
+ struct opp *opp;
+ u32 abb_ctrl, abb_setup;
+ unsigned long freq = 0;
+
+ if (!abb) {
+ seq_printf(sf, No ABB defined\n);
+ goto err;
+ }
+
+ abb_ctrl = omap_abb_readl(abb, abb-data.control_offs);
+ abb_setup = omap_abb_readl(abb, abb-data.setup_offs);
+ seq_printf(sf, Enabled\t-\t%d\n
+ opp_sel\t-\t%u\n
+ FBB mode\t-\t%u\n
+ RBB mode\t-\t%u\n
+ PRM_LDO_ABB_XXX_SETUP\t-\t0x%08x\n
+ PRM_LDO_ABB_XXX_CTRL\t-\t0x%08x\n,
+ !!(abb_setup abb-data.sr2en_mask),
+ abb-opp_sel,
+ !!(abb_setup abb-data.fbb_sel_mask),
+ !!(abb_setup abb-data.rbb_sel_mask),
+ abb_setup,
+ abb_ctrl);
+
+ seq_printf(sf, OPP table\n);
+ rcu_read_lock();
+ do {
+ opp = opp_find_freq_ceil(abb-dev, freq);
+ if (IS_ERR(opp))
+ break;
+
+ seq_printf(sf, Voltage (%lu) ABB (%lu)\n,
+ opp_get_freq(opp) / 1000,
+ opp_get_voltage(opp));
+
+ freq++;
+ } while (1);
+ rcu_read_unlock();
+
+err:
+ return 0;
+}
+
+/*
+ * omap_abb_fops_open() - debugfs open callback
+ *
+ * Returns 0 on success or error code otherwise
+ */
+static int omap_abb_fops_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, omap_abb_info_dump, inode-i_private);
+}
+
+static const struct file_operations omap_abb_debug_fops = {
+ .open = omap_abb_fops_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+/*
* omap_abb_init_timings() - Initialize ABB timings
* @abb: pointer to the ABB instance
*
@@ -507,7 +576,6 @@ static int __init omap_abb_init_timings(struct omap_abb
*abb)
clk_put(sys_clk);
return 0;
}
-
/*
* omap_abb_probe() - Initialize an ABB ldo instance
* @pdev: ABB platform device
@@ -615,6 +683,10 @@ static int __init omap_abb_probe(struct platform_device
*pdev)
if (IS_ERR(abb-supply_reg))
abb-supply_reg = NULL;
+ /* create debugfs entry */
+ debugfs_create_file(dev_name(pdev-dev), S_IRUGO, NULL,
+ abb, omap_abb_debug_fops);
+
return 0;
err:
--
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 v1] regulator: core: introduce regulator chain locking scheme
On Mon, Apr 15, 2013 at 04:03:35PM +0300, Grygorii Strashko wrote: To achieve this goal: - abstract regulator locking out into helper functions; - use the root Regulator (which has no supply defined, like regA) in chain to protect the whole chain; - implement regulator chain locking scheme as proposed by Thomas Gleixner for CCF re-entrance in https://lkml.org/lkml/2013/3/27/171 and in the similar way as it is done for CCF by Mike Turquette in https://lkml.org/lkml/2013/3/28/512 Split this into separate refactoring and other change commits - one change per commit. In addition, such locking scheme allows to have access to the supplier regulator API from inside child's (consumer) regulator API. I've still not seen any use case articulated for doing this... signature.asc Description: Digital signature
Re: [PATCH] spi: omap2-mcspi: Fix transfers if DMADEVICES is not set
On Fri, Apr 12, 2013 at 05:25:07PM -0700, Tony Lindgren wrote: Selecting CONFIG_DMADEVICES is optional, and we must be able to continue even without DMA. Otherwise things like omap4430sdp nfsroot will fail if DMA is not selected. Applied, thanks. signature.asc Description: Digital signature
Re: [RFC v1] regulator: core: introduce regulator chain locking scheme
Hi Mark, On 04/15/2013 06:50 PM, Mark Brown wrote: In addition, such locking scheme allows to have access to the supplier regulator API from inside child's (consumer) regulator API. I've still not seen any use case articulated for doing this... Use case is introduced in ABB series: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg88293.html During voltage scaling we would like to have the following sequence: cpufreq_cpu0 | |--- set_voltage(ABB) | |-set_voltage(AVS) | |--set_voltage(smps123) Where smps123 is a regulator, connected ot i2c bus. In this particular case regulator chain guarantees proper order of calls of voltage scaling sequence. Regards, Andrii -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
On 04/12/2013 04:54 PM, Nishanth Menon wrote: OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c. However, this presents an obstacle for using these clock nodes in Device Tree definitions. This is especially true for board specific clocks initially. The fixed clocks are currently found via clock aliases table. There are many possible approaches to this problem as discussed in the following thread: http://marc.info/?t=13637032569r=1w=2. Highlights of the options: a) device specific clk_add_alias: cons: driver handling required b) using an generic clk node and indexing to reach the clock required. This is similar in approach taken by tegra and few other platforms. Example usage: clock = clk 5; cons: potential to have mismatches in indexed table and associated dtb data. In addition, managing continued documentation in bindings as clock indexing increases. Even though readability angle could be improved by using preprocessing of DT using macros, indexed approach is inherently risky from cases like the following: clk indexes in kernel: 1 - mpu_dpll 2 - aux_clk1 3 - core_clk DT entry for peripheral X uses clk 2 to reach aux_clk1. Now, let's say kernel updates indices to: 1 - mpu_dpll 2 - per_dpll 3 - aux_clk1 4 - core_clk using the old dtb(or dts missing an update), on new kernel which has updated indices will result in per_dpll now controlled for peripheral X without warning or any potential error detection. Even though we could claim this is user error, such errors are hard to track down and fix. The error in case (b) is that you shouldn't be changing the DT bindings after they've first been created. That would avoid the problem situation. The person using the old DTB with the new kernel didn't commit user error. An alternate approach introduced here is to introduce device tree bindings corresponding to the clock nodes required in DT definition for SoC which automatically maps back to the definitions in cclockXYZ_data.c. Well, I haven't read the patches, but isn't that exactly what the 2 is in clk 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: [BUG] omap: mfd/regulator: twl/core: init order
* Grygorii Strashko grygorii.stras...@ti.com [130415 04:05]:
On 04/15/2013 01:56 PM, Christoph Fritz wrote:
On Mon, 2013-04-15 at 13:20 +0300, Grygorii Strashko wrote:
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1014,7 +1014,18 @@ static struct platform_driver pcs_driver = {
},
};
-module_platform_driver(pcs_driver);
+static int __init pcs_driver_drv_init(void)
+{
+ return platform_driver_register(pcs_driver);
+}
+postcore_initcall(pcs_driver_drv_init);
+
+static void __exit pcs_driver_drv_exit(void)
+{
+ platform_driver_unregister(pcs_driver);
+}
+module_exit(pcs_driver_drv_exit);
+
Hi Grygorii,
thanks - indeed it does fix the problem. I checked at least the rtc
which is now configured right and working :-)
Do you consider the patch above as a hack or will it go mainline?
I think, need more opinions on this from community )
I'm just trying to solve my problem and found similar issue.
This fix should not be needed. It just means the real
problem is somewhere else. Pinctrl is already before the i2c
in drivers/Makefile. Maybe one of the MFD drivers has
a wrong initcall level?
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 v2 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Quoting Andrii Tseglytskyi (2013-04-15 06:28:10) Cc: Mike Turquette mturque...@linaro.org Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Signed-off-by: Mike Turquette mturque...@linaro.org It is very strange to Cc me and include my Signed-off-by. Go ahead and drop my SoB. I'll review these patches this week but I don't think implicitly including my SoB is appropriate. Also why is this limited to LOML? Cc LKML and Mark Brown (regulator maintainer) on the next version. More eyeballs on the code is better. Finally I also suggest that you rename this patch to: regulator: introduce omap abb driver As we move stuff out of arch/arm it's important to loop in wider mailing lists, Cc the appropriate maintainers and title patches more appropriately. Regards, Mike -- 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/5] gpio/omap: Add DT support to GPIO driver
On 04/13/2013 07:35 PM, Javier Martinez Canillas wrote:
...
Is the following inlined patch [1] what you were thinking that would
be the right approach?
...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
...
+static int omap_gpio_irq_request(struct irq_data *d)
+{
+ struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+ return omap_gpio_request(bank-chip, d-hwirq);
If you want the GPIO usage to be known to the GPIO subsystem, then
wouldn't you call gpio_request() here rather than omap_gpio_request()?
The above code will certainly do enough so that the OMAP GPIO HW is
fully enabled as you need, but I thought the idea was to also prevent
some other code successfully running gpio_request() on that same GPIO?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 10/18] ARM: OMAP2+: Add function to read GPMC settings from device-tree
On 04/15/2013 08:27 AM, Grant Likely wrote: On Tue, 19 Mar 2013 11:35:48 -0500, Jon Hunter jon-hun...@ti.com wrote: Adds a function to read the various GPMC chip-select settings from device-tree and store them in the gpmc_settings structure. Update the GPMC device-tree binding documentation to describe these options. Signed-off-by: Jon Hunter jon-hun...@ti.com Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- Documentation/devicetree/bindings/bus/ti-gpmc.txt | 23 arch/arm/mach-omap2/gpmc.c| 40 + arch/arm/mach-omap2/gpmc.h|2 ++ 3 files changed, 65 insertions(+) diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt index 5ddb2e9..6fde1cf 100644 --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x: - gpmc,wr-access - gpmc,wr-data-mux-bus +GPMC chip-select settings properties for child nodes. All are optional. + +- gpmc,burst-length Page/burst length. Must be 4, 8 or 16. +- gpmc,burst-wrap Enables wrap bursting +- gpmc,burst-read Enables read page/burst mode +- gpmc,burst-write Enables write page/burst mode +- gpmc,device-nand Device is NAND +- gpmc,device-width Total width of device(s) connected to a GPMC +chip-select in bytes. The GPMC supports 8-bit +and 16-bit devices and so this property must be +1 or 2. I would suggest specifying the actual number of bits. ie. 8 or 16. There is some precidence for that already in DT bindings. I used bytes and not bits here as it was more convenient for programming a register bit field. However, it would be equally easy to shift the value and program the register if we use bits. So this can be changed. By the way, I have seen some of the flash bindings (eg. mtd-physmap.txt) use bytes and not bits, however, I do see others use bits (nand.txt). However, if the preference is for bits then we can conform to that. Tony has this queued for v3.10 now. However, we can fix this up if you feel strongly about this. +- gpmc,mux-add-data Address and data multiplexing configuration. +Valid values are 1 for address-address-data +multiplexing mode and 2 for address-data +multiplexing mode. +- gpmc,sync-readEnables synchronous read. Defaults to asynchronous +is this is not set. 'if'? +- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous +is this is not set. +- gpmc,wait-pin Wait-pin used by client. Must be less than +gpmc,num-waitpins. +- gpmc,wait-on-read Enables wait monitoring on reads. +- gpmc,wait-on-writeEnables wait monitoring on writes. Otherwise looks okay to me. Thanks Jon -- 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: 4430sdp nfsroot broken with ff5c9059
On 04/13/2013 11:50 AM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130412 19:22]: On 04/12/2013 07:06 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130410 15:32]: * Jon Hunter jon-hun...@ti.com [130410 15:30]: Are you saying that you want to use the version with that is using the pre-processor definitions? I was thinking that may be we could do that as a clean-up for v3.11 and just use the original version I posted earlier. Seems cleaner to me. No let's do that the preprocessor conversion for v3.11. Hmm looks like there are few more 3430sdp dt nfsroot exposed issues in today's linux next. I don't even see any ethernet devices defined in the omap3430-sdp.dts file. Is this something that you have added on top? Oops sorry I meant the ks8851 on SPI on 4430sdp, not 3430. Ok makes sense. To get nfsroot to behave, I had to have your earlier fix from this thread and also revert a2797bea (gpio/omap: force restore if context loss is not detectable). Otherwise nfsroot fails, but not necessarily every time? Well this patch is going to force a gpio restore everytime we call pm_runtime_get() when the use-count is 0. Yes this is not efficient, however, without this patch you run the risk of context being lost and you would never know. Per the changelog, long term a better solution is needed. It seems that this patch kills the ks8851 GPIO interrupt somehow, at least most of the time. Hmmm, let me go back and re-test this. I could not git bisect it down to the commit above, had to manually figure it out.. There may also be DMA related issues, but I don't know for sure any longer. I made a patch to fix SPI PIO mode and then hacked SPI to always use PIO to leave out the DMA related parts. Anyways, will post that separately, let's hope the DMA related issues I saw earlier are also related to dt + a2797bea. Ok, I don't follow that. I am not sure how gpio is related to DMA in this case. I think the DMA issues might be related to the GPIO interrupt not working properly. What is the use-case? DMA + SPI? Talking to what on what board? Cheers Jon -- 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/5] gpio/omap: Add DT support to GPIO driver
On 04/14/2013 02:53 PM, Linus Walleij wrote: On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Is the following inlined patch [1] what you were thinking that would be the right approach? This looks sort of OK, but I'm still struggling with the question of what we could do to help other implementations facing the same issue. This is a pretty hard design pattern to properly replicate in every such driver is it not? Well, instead of adding .request_irq() to the irqchip, and then making each driver call gpio_request() from the implementation, perhaps you could add a .irq_to_gpio() to the irqchip, have the IRQ core call that, and if it gets back a non-error response, the IRQ core could call gpio_request(). That means that the change to each GPIO+IRQ driver is simply to implement a standalone data transformation function .irq_to_gpio(). Now, this does re-introduce irq_to_gpio() in some way, but with the following advantages: 1) The implementation is per-controller, not a single global function, so isn't introducing any kind of centralized mapping scheme again. 2) This irq-chip-specific .irq_to_gpio() would only be implemented for IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs. Its potential existence doesn't imply that all IRQ chips need implement this; it would be very specifically be for this one particular case. So, I think it's reasonable to introduce this. -- 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 v1] regulator: core: introduce regulator chain locking scheme
On Mon, Apr 15, 2013 at 07:21:25PM +0300, Andrii Tseglytskyi wrote: On 04/15/2013 06:50 PM, Mark Brown wrote: In addition, such locking scheme allows to have access to the supplier regulator API from inside child's (consumer) regulator API. I've still not seen any use case articulated for doing this... Use case is introduced in ABB series: Sorry, I meant any sensible use case. -- 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/3] driver: net: ethernet: cpsw: dual emac interface implementation
On 4/15/2013 12:50 AM, Mark Jackson wrote:
On 11/02/13 19:52, Mugunthan V N wrote:
The CPSW switch can act as Dual EMAC by segregating the switch ports
using VLAN and port VLAN as per the TRM description in
14.3.2.10.2 Dual Mac Mode
Following CPSW components will be common for both the interfaces.
* Interrupt source is common for both eth interfaces
* Interrupt pacing is common for both interfaces
* Hardware statistics is common for all the ports
* CPDMA is common for both eth interface
* CPTS is common for both the interface and it should not be enabled on
both the interface as timestamping information doesn't contain port
information.
Constrains
* Reserved VID of One port should not be used in other interface
which will
enable switching functionality
* Same VID must not be used in both the interface which will enable
switching
functionality
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
@@ -1237,6 +1372,18 @@ static int cpsw_probe_dt(struct
cpsw_platform_data *data,
if (mac_addr)
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
+if (data-dual_emac) {
+if (of_property_read_u32(node, dual_emac_res_vlan,
+ prop)) {
Shouldn't this be:-
if (of_property_read_u32(slave_node, dual_emac_res_vlan,
^^
... so we pick each VLAN id from the individual slaves ?
Good catch, will send a fixup patch for this.
Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW
On 4/15/2013 12:46 AM, Mark Jackson wrote:
On 11/02/13 19:52, Mugunthan V N wrote:
This patch series implements Dual EMAC mode implementation of CPSW
which acts as two standalone EMAC by segregating the switch using VIDs
and port VLAN
Mugunthan V N (3):
driver: net: ethernet: davinci_cpdma: add support for directed packet
and source port detection
driver: net: ethernet: cpsw: make cpts as pointer
driver: net: ethernet: cpsw: dual emac interface implementation
Documentation/devicetree/bindings/net/cpsw.txt |2 +
drivers/net/ethernet/ti/cpsw.c | 387
+++-
drivers/net/ethernet/ti/davinci_cpdma.c| 17 +-
drivers/net/ethernet/ti/davinci_cpdma.h|4 +-
drivers/net/ethernet/ti/davinci_emac.c |6 +-
include/linux/platform_data/cpsw.h |3 +
6 files changed, 338 insertions(+), 81 deletions(-)
I'm trying to get dual emac mode working, but I'm only having partial
success. We have a custom AM335x board with dual LAN8710 PYHs, but
the basic design is based on the BeagleBone board.
I have the following in my .dts file:-
mac: ethernet@4a10 {
dual_emac = 1;
cpsw_emac0: slave@4a100200 {
dual_emac_res_vlan = 1;
};
cpsw_emac1: slave@4a100300 {
dual_emac_res_vlan = 2;
};
};
When I boot my board (across nfs via eth1):-
(a) the kernel is loaded (via tftp under U-Boot)
(b) the kernel mounts the nfsroot
(c) my init scripts are run (e.g. dropbear)
(d) the shell prompt appears
So far so good, but when I then try any shell command (e.g. ps) the
nfs link just hangs.
Below is an extract from the boot messages:-
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.9.0-rc6-00186-g5b55d70-dirty
(mpfj@mpfj-nanobone) (gcc version 4.7.2 (Buildroot
2013.02-00154-g851ceaa) ) #19 Sun Apr 14 19:50:21 BST 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model:
Newflow AM335x NanoBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 64768
[0.00] Kernel command line: root=/dev/nfs
nfsroot=10.1.0.111:/tftpboot/nanobone/rootfs rw
ip=10.1.0.199:10.1.0.111:10.1.0.1:255.255.0.0::eth1:off
console=ttyO0,115200
...
[1.424977] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[1.431443] davinci_mdio 4a101000.mdio: detected phy mask fffc
[1.440939] libphy: 4a101000.mdio: probed
[1.445266] davinci_mdio 4a101000.mdio: phy[0]: device
4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[1.454962] davinci_mdio 4a101000.mdio: phy[1]: device
4a101000.mdio:01, driver SMSC LAN8710/LAN8720
[1.465059] Random MACID = a2:3f:fb:2c:47:d9
[1.472276] cpsw: Random MACID = ae:d5:c0:c0:27:03
[1.480588] rtc-ds1307 0-0068: setting system clock to 2013-04-14
19:59:52 UTC (1365969592)
[1.491543] net eth1: initializing cpsw version 1.12 (0)
[1.516965] net eth1: phy found : id is : 0x7c0f1
[4.595479] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
[4.625872] IP-Config: Complete:
[4.629307] device=eth1, hwaddr=ae:d5:c0:c0:27:03,
ipaddr=10.1.0.199, mask=255.255.0.0, gw=10.1.0.1
[4.639365] host=10.1.0.199, domain=, nis-domain=(none)
[4.645359] bootserver=10.1.0.111, rootserver=10.1.0.111,
rootpath=
[4.674219] VFS: Mounted root (nfs filesystem) on device 0:12.
[4.682438] devtmpfs: mounted
[4.686042] Freeing init memory: 196K
Starting logging: OK
Initializing random number generator... done.
Starting network...
ip: RTNETLINK answers: File exists
[5.340677] net eth0: initializing cpsw version 1.12 (0)
[5.366463] net eth0: phy found : id is : 0x7c0f1
ip: RTNETLINK answers: File exists
ip: RTNETLINK answers: File exists
ip: RTNETLINK answers: File exists
Starting dropbear sshd: OK
Welcome to Buildroot
nanobone login: root
Password:
# ps
[ 18.845266] nfs: server 10.1.0.111 not responding, still trying
At this point, I can disconnect my network cable from eth1 and connect
to eth0, and back again which shows the PYHs appear to be detecting
the link up/down status of each port.
[ 562.675229] libphy: 4a101000.mdio:01 - Link is Down
[ 567.885586] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 571.965156] libphy: 4a101000.mdio:00 - Link is Down
[ 575.014943] nfs: server 10.1.0.111 not responding, still trying
[ 576.635412] libphy: 4a101000.mdio:01 - Link is Up - 100/Full
[ 579.426051] nfs: server 10.1.0.111 OK
Notice that at the end, the nfs link appears to come back ok, but
the ps command never completes.
Any ideas of what's going on ?
I have tried ping on both the interface fine. Will
Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW
On 15/04/13 18:07, Mugunthan V N wrote: On 4/15/2013 12:46 AM, Mark Jackson wrote: snip Notice that at the end, the nfs link appears to come back ok, but the ps command never completes. Any ideas of what's going on ? I have tried ping on both the interface fine. Will verify with ps again later in this week. Can you provide below details details - Are you using EVMsk or custom build EVM? This is a custom board (based on the BeagleBone design) with dual Ethernet, NAND, NOR and FRAM. The dual emac thing is (one of) the last things to get signed off, so I'm willing to assist in tracking this down. Regards Mark J. -- 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
[net PATCH 1/1] drivers: net: ethernet: cpsw: get slave VLAN id from slave node instead of cpsw node
Dual EMAC slave VLAN id must be got from slave node instead of cpsw node as
VLAN id for each slave will be different.
Reported-by: Mark Jackson mpfj-l...@mimc.co.uk
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 80cad06..4781d3d 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1380,7 +1380,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
if (data-dual_emac) {
- if (of_property_read_u32(node, dual_emac_res_vlan,
+ if (of_property_read_u32(slave_node,
dual_emac_res_vlan,
prop)) {
pr_err(Missing dual_emac_res_vlan in DT.\n);
slave_data-dual_emac_res_vlan = i+1;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW
On 4/15/2013 10:58 PM, Mark Jackson wrote: On 15/04/13 18:07, Mugunthan V N wrote: On 4/15/2013 12:46 AM, Mark Jackson wrote: snip Notice that at the end, the nfs link appears to come back ok, but the ps command never completes. Any ideas of what's going on ? I have tried ping on both the interface fine. Will verify with ps again later in this week. Can you provide below details details - Are you using EVMsk or custom build EVM? This is a custom board (based on the BeagleBone design) with dual Ethernet, NAND, NOR and FRAM. The dual emac thing is (one of) the last things to get signed off, so I'm willing to assist in tracking this down. After testing the scenario i may be able to send you an update later in this week. Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW
On 15/04/13 18:34, Mugunthan V N wrote: On 4/15/2013 10:58 PM, Mark Jackson wrote: On 15/04/13 18:07, Mugunthan V N wrote: On 4/15/2013 12:46 AM, Mark Jackson wrote: snip Notice that at the end, the nfs link appears to come back ok, but the ps command never completes. Any ideas of what's going on ? I have tried ping on both the interface fine. Will verify with ps again later in this week. Can you provide below details details - Are you using EVMsk or custom build EVM? This is a custom board (based on the BeagleBone design) with dual Ethernet, NAND, NOR and FRAM. The dual emac thing is (one of) the last things to get signed off, so I'm willing to assist in tracking this down. After testing the scenario i may be able to send you an update later in this week. Excellent ... if you've anything I can test now, I'd be happy to try. Cheers Mark J. -- 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: 4430sdp nfsroot broken with ff5c9059
On 04/15/2013 11:57 AM, Jon Hunter wrote:
On 04/13/2013 11:50 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130412 19:22]:
On 04/12/2013 07:06 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130410 15:32]:
* Jon Hunter jon-hun...@ti.com [130410 15:30]:
Are you saying that you want to use the version with that is using the
pre-processor definitions? I was thinking that may be we could do that
as a clean-up for v3.11 and just use the original version I posted
earlier. Seems cleaner to me.
No let's do that the preprocessor conversion for v3.11.
Hmm looks like there are few more 3430sdp dt nfsroot exposed
issues in today's linux next.
I don't even see any ethernet devices defined in the omap3430-sdp.dts
file. Is this something that you have added on top?
Oops sorry I meant the ks8851 on SPI on 4430sdp, not 3430.
Ok makes sense.
To get nfsroot to behave, I had to have your earlier fix
from this thread and also revert a2797bea (gpio/omap: force
restore if context loss is not detectable).
Otherwise nfsroot fails, but not necessarily every time?
Well this patch is going to force a gpio restore everytime we call
pm_runtime_get() when the use-count is 0. Yes this is not efficient,
however, without this patch you run the risk of context being lost and
you would never know. Per the changelog, long term a better solution is
needed.
It seems that this patch kills the ks8851 GPIO interrupt somehow,
at least most of the time.
Hmmm, let me go back and re-test this.
Ok I am seeing the problem. Looks like this patch exposed another
bug in the gpio driver. Seems that we never initialise the gpio
context during the probe and so on the first pm_runtime_get_sync()
during the probe we are restoring crap. Can you try this? If this
works, I will add a changelog and post as a fix.
Jon
From 56598ba51a75481b050433bb38b7ae31a5ed4ae8 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Mon, 15 Apr 2013 13:06:54 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
---
drivers/gpio/gpio-omap.c | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..53bb8d5 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+ bool context_setup;
int stride;
u32 width;
int context_loss_count;
@@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
}
static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_setup_context(struct gpio_bank *p);
static int omap_gpio_probe(struct platform_device *pdev)
{
@@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device *pdev)
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
- if (bank-loses_context)
+ if (bank-loses_context) {
bank-get_context_loss_count = pdata-get_context_loss_count;
+ omap_gpio_setup_context(bank);
+ }
pm_runtime_put(bank-dev);
@@ -1385,8 +1389,43 @@ void omap2_gpio_resume_after_idle(void)
}
#if defined(CONFIG_PM_RUNTIME)
+static void omap_gpio_setup_context(struct gpio_bank *p)
+{
+ struct omap_gpio_reg_offs *regs = p-regs;
+ void __iomem *base = p-base;
+
+ p-context.wake_en = __raw_readl(base + regs-wkup_en);
+ p-context.ctrl = __raw_readl(base + regs-ctrl);
+ p-context.ctrl = __raw_readl(base + regs-ctrl);
+ p-context.leveldetect0 = __raw_readl(base + regs-leveldetect0);
+ p-context.leveldetect1 = __raw_readl(base + regs-leveldetect1);
+ p-context.risingdetect = __raw_readl(base + regs-risingdetect);
+ p-context.fallingdetect = __raw_readl(base + regs-fallingdetect);
+
+ if (regs-set_dataout p-regs-clr_dataout)
+ p-context.dataout = __raw_readl(base + regs-set_dataout);
+ else
+ p-context.dataout = __raw_readl(base + regs-dataout);
+
+ p-context.oe = __raw_readl(base + regs-direction);
+
+ if (p-dbck_enable_mask) {
+ p-context.debounce = __raw_readl(base + regs-debounce);
+ p-context.debounce_en = __raw_readl(base + regs-debounce_en);
+ }
+
+ p-context.irqenable1 = __raw_readl(base + regs-irqenable);
+ p-context.irqenable2 = __raw_readl(base + regs-irqenable2);
+
+ p-context_setup = true;
+}
+
static void omap_gpio_restore_context(struct gpio_bank *bank)
{
+ /* If context has not been initialised yet, return */
+ if (!bank-context_setup)
+ return;
+
__raw_writel(bank-context.wake_en,
bank-base + bank-regs-wkup_en);
__raw_writel(bank-context.ctrl, bank-base + bank-regs-ctrl);
@@ -1422,6 +1461,7 @@ static void omap_gpio_restore_context(struct
Re: [net PATCH 1/1] drivers: net: ethernet: cpsw: get slave VLAN id from slave node instead of cpsw node
From: Mugunthan V N mugunthan...@ti.com Date: Mon, 15 Apr 2013 23:01:28 +0530 Dual EMAC slave VLAN id must be got from slave node instead of cpsw node as VLAN id for each slave will be different. Reported-by: Mark Jackson mpfj-l...@mimc.co.uk Signed-off-by: Mugunthan V N mugunthan...@ti.com Applied. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
On Mon, Apr 15, 2013 at 11:22 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 04/12/2013 04:54 PM, Nishanth Menon wrote: OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c. However, this presents an obstacle for using these clock nodes in Device Tree definitions. This is especially true for board specific clocks initially. The fixed clocks are currently found via clock aliases table. There are many possible approaches to this problem as discussed in the following thread: http://marc.info/?t=13637032569r=1w=2. Highlights of the options: a) device specific clk_add_alias: cons: driver handling required b) using an generic clk node and indexing to reach the clock required. This is similar in approach taken by tegra and few other platforms. Example usage: clock = clk 5; cons: potential to have mismatches in indexed table and associated dtb data. In addition, managing continued documentation in bindings as clock indexing increases. Even though readability angle could be improved by using preprocessing of DT using macros, indexed approach is inherently risky from cases like the following: clk indexes in kernel: 1 - mpu_dpll 2 - aux_clk1 3 - core_clk DT entry for peripheral X uses clk 2 to reach aux_clk1. Now, let's say kernel updates indices to: 1 - mpu_dpll 2 - per_dpll 3 - aux_clk1 4 - core_clk using the old dtb(or dts missing an update), on new kernel which has updated indices will result in per_dpll now controlled for peripheral X without warning or any potential error detection. Even though we could claim this is user error, such errors are hard to track down and fix. The error in case (b) is that you shouldn't be changing the DT bindings after they've first been created. That would avoid the problem situation. The person using the old DTB with the new kernel didn't commit user error. That is what we'd like folks to follow, but when code is in development, or productization, there is no saying the type of mistakes people end up doing. An alternate approach introduced here is to introduce device tree bindings corresponding to the clock nodes required in DT definition for SoC which automatically maps back to the definitions in cclockXYZ_data.c. Well, I haven't read the patches, but isn't that exactly what the 2 is in clk 2? partly so. yes: it indexes back to the right clock node - at that point the comparison stops. we just point back on naming as needed and introduce nodes purely for the ones that we need. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/6] drivers: phy: add generic PHY framework
On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to
the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board
file)
should have already called phy_bind with the binding information. The
binding
information consists of phy's device name, phy user device name and an
index.
The index is used when the same phy user binds to mulitple phys.
PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend,
resume,
poweron, shutdown.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Hi Kishon,
For review purposes, I'll skip most of the implementation and focus on
the data structures. I think you need to take another look at the
approach your using. The kernel already provides a lot of support for
implementing devices and binding them to drivers that you should be
able to use...
[...]
+/**
+ * struct phy - represent the phy device
+ * @dev: phy device
+ * @label: label given to phy
+ * @type: specifies the phy type
+ * @of_node: device node of the phy
+ * @ops: function pointers for performing phy operations
+ */
+struct phy {
+ struct device dev;
+ const char *label;
+ int type;
+ struct bus_type *bus;
+ struct device_node *of_node;
+ struct phy_ops *ops;
+};
Alright, so the core of the functionality is this 'struct phy' which
tracks all the instances of PHY devices. As I understand it each
physical phy will have a 'struct phy' instance tracking it. That makes
sense.
struct phy embeds a struct device. Also good. The linux driver model
knows all about devices and how to handle them. However, most of the
rest of this structure looks to be reinventing stuff the driver model
already does.
'label' seems unnecessary. struct device embeds a struct kobject, which
means it has a name and shows up in sysfs. Is there a reason that the
device name cannot be used directly?
hmm.. the label name is supposed to be a simpler name than device name.
Say for instance omap-usb2.1.auto device name can simply be
omap-usb2-phy. Further the device name while using dt will have
register address in it. However it's used only for displaying the label
in sysfs entry (/sys/class/phy/phy/label).
I wouldn't go mucking with names in that way. Stick with one name and
drop the separate label. Otherwise you introduce addtional sources of
confusion.
'type' I just don't understand. I don't see any users of it in this
patch. I only see where it is set.
yeah. Was planning to remove this in my next version (btw the latest is
version 5).
'bus' absolutely should not be here. The bus type should be set in the
struct device by this subsystem when the device gets registered. There
is no reason to have a pointer to it here.
right. I had removed it in version 5 of this patch series.
'of_node' is already in struct device
I wasn't sure if we can manually assign the of_node of one device to
of_node of an another device. Here the of_node comes from _phy provider_.
There is no problem with multiple devices referencing the same node. The
only time it may cause problems is when two devices of the same bus type
are referencing the same of_node. In that situation the device will get
probed more than once. You're not in that situation.
Finally, it really doesn't look right for a device object to have an
'ops' structure. The whole point of the driver model is that a struct
device doesn't encapsulate any behaviour. A device gets registers to a
bus type, and then the driver core will associate a struct device_driver
We have decided not to implement the PHY layer as a separate bus layer.
The PHY provider can be part of any other bus. Making the PHY layer as a
bus will make the PHY provider to be part of multiple buses which will
lead to bad design. All we are trying to do here is keep the pool of PHY
devices under PHY class in this layer and help any controller that wants
to use the PHY to get it.
If you're using a class, then you already have your list of registered
phy devices! :-) No need to create another global list that you need to
manage.
You really need to be careful here though. By lumping all the phy types
into a single pot your glossing over the
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On 04/15/2013 11:53 AM, Stephen Warren wrote:
On 04/13/2013 07:35 PM, Javier Martinez Canillas wrote:
...
Is the following inlined patch [1] what you were thinking that would
be the right approach?
...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
...
+static int omap_gpio_irq_request(struct irq_data *d)
+{
+struct gpio_bank *bank = irq_data_get_irq_chip_data(d);
+
+return omap_gpio_request(bank-chip, d-hwirq);
If you want the GPIO usage to be known to the GPIO subsystem, then
wouldn't you call gpio_request() here rather than omap_gpio_request()?
The above code will certainly do enough so that the OMAP GPIO HW is
fully enabled as you need, but I thought the idea was to also prevent
some other code successfully running gpio_request() on that same GPIO?
Also, although omap gpios default to being inputs, we should not assume
that. So may be you should call gpio_request_one() here passing as flags
GPIOF_IN to configure as an input.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
* Tomi Valkeinen tomi.valkei...@ti.com [130415 02:34]: Hi Tony, On 2013-04-03 18:46, Tony Lindgren wrote: Tony, I've split these patches as follows: Platform data header file changes: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers Board file changes (based on header changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup DSS panel changes (based on header changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10/1-panel-cleanup Removing unused fields from header files (based on panel changes): git://gitorious.org/linux-omap-dss2/linux.git 3.10/2-late-panel-cleanup The 2-late-panel-cleanup breaks compilation if the arch changes are not merged, so I'll leave that until they have been merged. Do you mind if I add the board-cleanup branch temporarily to omapdss's for-next, to simplify testing? When everything looks ok, I'll remove it and pass the branch to you to be handled through l-o. Sure please go ahead. There are still some board-*.c related patches that I have not merged, but we'll see those merge conflicts before next as I usually do a merge with next before sending out pull reqs. The code seems to work ok, so I think we can declare the branches stable. I've pushed new for-next branch that does not contain the arch files anymore. In fact, I removed all omapdss patches also, as omapdss should be merged through the drm tree, and I don't want to have conflicts with drm's for-next branch. So, to recap, the common header changes are located in: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers And the branch for linux-omap is: git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup After merging those, some displays won't start anymore until the omapdss changes are in, but things should still compile. Sounds like it's best that you merge those branches via your tree as the conflicts have been already resolved in linux next. 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: 4430sdp nfsroot broken with ff5c9059
* Jon Hunter jon-hun...@ti.com [130415 11:15]:
On 04/15/2013 11:57 AM, Jon Hunter wrote:
On 04/13/2013 11:50 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130412 19:22]:
On 04/12/2013 07:06 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130410 15:32]:
* Jon Hunter jon-hun...@ti.com [130410 15:30]:
Are you saying that you want to use the version with that is using the
pre-processor definitions? I was thinking that may be we could do that
as a clean-up for v3.11 and just use the original version I posted
earlier. Seems cleaner to me.
No let's do that the preprocessor conversion for v3.11.
Hmm looks like there are few more 3430sdp dt nfsroot exposed
issues in today's linux next.
I don't even see any ethernet devices defined in the omap3430-sdp.dts
file. Is this something that you have added on top?
Oops sorry I meant the ks8851 on SPI on 4430sdp, not 3430.
Ok makes sense.
To get nfsroot to behave, I had to have your earlier fix
from this thread and also revert a2797bea (gpio/omap: force
restore if context loss is not detectable).
Otherwise nfsroot fails, but not necessarily every time?
Well this patch is going to force a gpio restore everytime we call
pm_runtime_get() when the use-count is 0. Yes this is not efficient,
however, without this patch you run the risk of context being lost and
you would never know. Per the changelog, long term a better solution is
needed.
It seems that this patch kills the ks8851 GPIO interrupt somehow,
at least most of the time.
Hmmm, let me go back and re-test this.
Ok I am seeing the problem. Looks like this patch exposed another
bug in the gpio driver. Seems that we never initialise the gpio
context during the probe and so on the first pm_runtime_get_sync()
during the probe we are restoring crap. Can you try this? If this
works, I will add a changelog and post as a fix.
Jon
From 56598ba51a75481b050433bb38b7ae31a5ed4ae8 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Mon, 15 Apr 2013 13:06:54 -0500
Subject: [PATCH] gpio/omap: ensure gpio context is initialised
Seems to work thanks:
Tested-by: Tony Lindgren t...@atomide.com
drivers/gpio/gpio-omap.c | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0557529..53bb8d5 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -70,6 +70,7 @@ struct gpio_bank {
bool is_mpuio;
bool dbck_flag;
bool loses_context;
+ bool context_setup;
int stride;
u32 width;
int context_loss_count;
@@ -1085,6 +1086,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
}
static const struct of_device_id omap_gpio_match[];
+static void omap_gpio_setup_context(struct gpio_bank *p);
static int omap_gpio_probe(struct platform_device *pdev)
{
@@ -1179,8 +1181,10 @@ static int omap_gpio_probe(struct platform_device
*pdev)
omap_gpio_chip_init(bank);
omap_gpio_show_rev(bank);
- if (bank-loses_context)
+ if (bank-loses_context) {
bank-get_context_loss_count = pdata-get_context_loss_count;
+ omap_gpio_setup_context(bank);
+ }
pm_runtime_put(bank-dev);
@@ -1385,8 +1389,43 @@ void omap2_gpio_resume_after_idle(void)
}
#if defined(CONFIG_PM_RUNTIME)
+static void omap_gpio_setup_context(struct gpio_bank *p)
+{
+ struct omap_gpio_reg_offs *regs = p-regs;
+ void __iomem *base = p-base;
+
+ p-context.wake_en = __raw_readl(base + regs-wkup_en);
+ p-context.ctrl = __raw_readl(base + regs-ctrl);
+ p-context.ctrl = __raw_readl(base + regs-ctrl);
+ p-context.leveldetect0 = __raw_readl(base + regs-leveldetect0);
+ p-context.leveldetect1 = __raw_readl(base + regs-leveldetect1);
+ p-context.risingdetect = __raw_readl(base + regs-risingdetect);
+ p-context.fallingdetect = __raw_readl(base + regs-fallingdetect);
+
+ if (regs-set_dataout p-regs-clr_dataout)
+ p-context.dataout = __raw_readl(base + regs-set_dataout);
+ else
+ p-context.dataout = __raw_readl(base + regs-dataout);
+
+ p-context.oe = __raw_readl(base + regs-direction);
+
+ if (p-dbck_enable_mask) {
+ p-context.debounce = __raw_readl(base + regs-debounce);
+ p-context.debounce_en = __raw_readl(base + regs-debounce_en);
+ }
+
+ p-context.irqenable1 = __raw_readl(base + regs-irqenable);
+ p-context.irqenable2 = __raw_readl(base + regs-irqenable2);
+
+ p-context_setup = true;
+}
+
static void omap_gpio_restore_context(struct gpio_bank *bank)
{
+ /* If context has not been initialised yet, return */
+ if (!bank-context_setup)
+ return;
+
__raw_writel(bank-context.wake_en,
Re: [PATCHv3] driver: serial: prevent UART console idle on suspend while using no_console_suspend
Hi Vaibhav, Bedia, Vaibhav vaibhav.be...@ti.com writes: [...] So, my proposal is that Sourav remove that flag from the AM33xx hwmod when he removes this feature. Apologies for the delayed response. I was out of office for a couple of days. I don't recall the exact kernel version in which I ended up adding this flag to keep the clock running but yes after the change mentioned below this flag is not required. I just did a sanity check by removing this flag on v3.8 kernel and things work fine across suspend. Great, thanks for checking. That leaves only the UART driver, so after Sourav's changes, we will drop the flag completely. Kevin -- 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/5] gpio/omap: Add DT support to GPIO driver
On 04/15/2013 11:58 AM, Stephen Warren wrote:
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
This looks sort of OK, but I'm still struggling with the question of
what we could do to help other implementations facing the same issue.
This is a pretty hard design pattern to properly replicate in every such
driver is it not?
Well, instead of adding .request_irq() to the irqchip, and then making
each driver call gpio_request() from the implementation, perhaps you
could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
and if it gets back a non-error response, the IRQ core could call
gpio_request(). That means that the change to each GPIO+IRQ driver is
simply to implement a standalone data transformation function
.irq_to_gpio().
I am still concerned about the case where a driver may have already
called gpio_request() and then calls request_irq(). I think that the
solution needs to handle cases where the driver may or may not call
gpio_request() to allocate the gpio.
Although it could be argued that this is problem is not DT specific,
it does become a bigger problem to handle in the case of DT. Therefore,
I am wondering if we should just focus on the DT case for now.
Now, this does re-introduce irq_to_gpio() in some way, but with the
following advantages:
1) The implementation is per-controller, not a single global function,
so isn't introducing any kind of centralized mapping scheme again.
2) This irq-chip-specific .irq_to_gpio() would only be implemented for
IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
Its potential existence doesn't imply that all IRQ chips need implement
this; it would be very specifically be for this one particular case.
So, I think it's reasonable to introduce this.
How about using the gpio irq domain xlate function?
Typically, in DT land a device using a gpio as an interrupt source
will have something like the following ...
eth@0 {
compatible = ks8851;
...
interrupt-parent = gpio2;
interrupts = 2 8; /* gpio line 34, low triggered */
};
... or ...
mmc {
label = pandaboard::status2;
gpios = gpio1 8 0;
...
};
Both these devices are using a gpio as an interrupt source, but the mmc
driver is requesting the gpio directly. In the first case the xlate
function for the gpio irq domain will be called where as it is not used
in the 2nd case. Therefore, we could add a custom xlate function. For
example ...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 53bb8d5..caaeab2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1085,6 +1085,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
irq_set_handler_data(bank-irq, bank);
}
+
+int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq, unsigned int *out_type)
+{
+ struct gpio_bank *bank;
+ int irq;
+
+ if (WARN_ON(intsize 1))
+ return -EINVAL;
+
+ irq = irq_find_mapping(d, intspec[0]);
+ bank = irq_get_chip_data(irq);
+ if (!bank)
+ return -ENODEV;
+
+ gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN, ctrlr-name);
+
+ *out_hwirq = intspec[0];
+ *out_type = (intsize 1) ? intspec[1] : IRQ_TYPE_NONE;
+ return 0;
+}
+
+static const struct irq_domain_ops omap_irq_domain_ops = {
+ .xlate = omap_irq_domain_xlate,
+};
+
static const struct of_device_id omap_gpio_match[];
static void omap_gpio_setup_context(struct gpio_bank *p);
@@ -1135,7 +1162,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
bank-domain = irq_domain_add_linear(node, bank-width,
-irq_domain_simple_ops, NULL);
+omap_irq_domain_ops, NULL);
if (!bank-domain)
return -ENODEV;
Cheers
Jon
--
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/5] gpio/omap: Add DT support to GPIO driver
On 04/15/2013 04:40 PM, Jon Hunter wrote:
On 04/15/2013 11:58 AM, Stephen Warren wrote:
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
This looks sort of OK, but I'm still struggling with the question of
what we could do to help other implementations facing the same issue.
This is a pretty hard design pattern to properly replicate in every such
driver is it not?
Well, instead of adding .request_irq() to the irqchip, and then making
each driver call gpio_request() from the implementation, perhaps you
could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
and if it gets back a non-error response, the IRQ core could call
gpio_request(). That means that the change to each GPIO+IRQ driver is
simply to implement a standalone data transformation function
.irq_to_gpio().
I am still concerned about the case where a driver may have already
called gpio_request() and then calls request_irq(). I think that the
solution needs to handle cases where the driver may or may not call
gpio_request() to allocate the gpio.
Although it could be argued that this is problem is not DT specific,
it does become a bigger problem to handle in the case of DT. Therefore,
I am wondering if we should just focus on the DT case for now.
Now, this does re-introduce irq_to_gpio() in some way, but with the
following advantages:
1) The implementation is per-controller, not a single global function,
so isn't introducing any kind of centralized mapping scheme again.
2) This irq-chip-specific .irq_to_gpio() would only be implemented for
IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
Its potential existence doesn't imply that all IRQ chips need implement
this; it would be very specifically be for this one particular case.
So, I think it's reasonable to introduce this.
How about using the gpio irq domain xlate function?
Typically, in DT land a device using a gpio as an interrupt source
will have something like the following ...
eth@0 {
compatible = ks8851;
...
interrupt-parent = gpio2;
interrupts = 2 8; /* gpio line 34, low triggered */
};
... or ...
mmc {
label = pandaboard::status2;
gpios = gpio1 8 0;
...
};
Both these devices are using a gpio as an interrupt source, but the mmc
driver is requesting the gpio directly. In the first case the xlate
function for the gpio irq domain will be called where as it is not used
in the 2nd case. Therefore, we could add a custom xlate function. For
example ...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 53bb8d5..caaeab2 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1085,6 +1085,33 @@ static void omap_gpio_chip_init(struct gpio_bank *bank)
irq_set_handler_data(bank-irq, bank);
}
+
+int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq, unsigned int *out_type)
+{
+ struct gpio_bank *bank;
+ int irq;
+
+ if (WARN_ON(intsize 1))
+ return -EINVAL;
+
+ irq = irq_find_mapping(d, intspec[0]);
+ bank = irq_get_chip_data(irq);
+ if (!bank)
+ return -ENODEV;
+
+ gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN,
ctrlr-name);
By the way, I know that I should check the return code here, but this
was just an example. Also I don't think using ctrlr-name here works
either as this is just gpio.
Jon
--
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 v2 0/6] ARM: OMAP3+: Introduce ABB driver
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes: From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Following patch series introduces the Adaptive Body-Bias LDO driver, which handles LDOs voltage during OPP change routine. Current implementation is based on patch series from Mike Turquette: http://marc.info/?l=linux-omapm=134931341818379w=2 ABB transition is a part of OPP changing sequence. ABB can operate in the following modes: - Bypass mode: Activated when ABB is not required - FBB mode: Fast Body Bias mode, used on fast OPPs Fast? I thought the 'F' was for Forward? - RBB mode: Reverse Body Bias mode, used on slow OPPs In current implementation ABB is converted to regulator. Standalone OPP table is used to store ABB mode, it is defined in device tree for each ABB regulator. It has the following format: operating-points = /* uV ABB (0 - Bypass, 1 - FBB, 2 - RBB) */ 88 0 106 1 125 1 126 1 ; ABB regulator is linked to regulator chain In addition to Mike's comments (which I completely agree with), it would be very helfpul to see how this is actually used. e.g, how the regulators are chained together, how the proper ordering is managed, etc. etc. IOW, This series gives a bunch of low-level details without demonstrating the actual use case and showing the regulator API usage that would make this work. Kevin -- 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/5] gpio/omap: free irq domain in probe() failure paths
Jon Hunter jon-hun...@ti.com writes: On 04/10/2013 02:33 PM, Linus Walleij wrote: On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter jon-hun...@ti.com wrote: Currently the IRQ domain is not freed once allocated, in the case where omap_gpio_probe() fails. Therefore, ensure we free the domain if the probe does fail. Furthermore, the local variable ret is not needed and so remove this. Signed-off-by: Jon Hunter jon-hun...@ti.com Hm Kevin is still listed as maintainer on this driver but on a mail address that bounces, can you send a patch replacing him in MAINTAINERS with yourself if you're willing to pick it up? Anyway, patch applied. Thanks. There is a patch to fix this queued for v3.10 [1]. Yeah, but you've already been doing the heavly lifting here and should be the maintainer going forward, IMO. Patch below. Linus, do you want to queue this up? Kevin From 00d19c10c02c3a3aa99ca7ae75bc88a932437abd Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@linaro.org Date: Mon, 15 Apr 2013 15:02:26 -0700 Subject: [PATCH] MAINTAINERS: update OMAP GPIO driver: Jon Hunter taking over Jon has already been doing most of maintenance of this driver, so make it official. Cc: Linus Walleij linus.wall...@linaro.org Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Kevin Hilman khil...@linaro.org --- Applies on v3.9-rc7 MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8bdd7a7..a18cacb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5789,7 +5789,7 @@ F:arch/arm/*omap*/usb* OMAP GPIO DRIVER M: Santosh Shilimkar santosh.shilim...@ti.com -M: Kevin Hilman khil...@deeprootsystems.com +M: Jon Hunter jon-hun...@ti.com L: linux-omap@vger.kernel.org S: Maintained F: drivers/gpio/gpio-omap.c -- 1.8.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver
On 04/15/2013 03:40 PM, Jon Hunter wrote:
On 04/15/2013 11:58 AM, Stephen Warren wrote:
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
This looks sort of OK, but I'm still struggling with the question of
what we could do to help other implementations facing the same issue.
This is a pretty hard design pattern to properly replicate in every such
driver is it not?
Well, instead of adding .request_irq() to the irqchip, and then making
each driver call gpio_request() from the implementation, perhaps you
could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
and if it gets back a non-error response, the IRQ core could call
gpio_request(). That means that the change to each GPIO+IRQ driver is
simply to implement a standalone data transformation function
.irq_to_gpio().
I am still concerned about the case where a driver may have already
called gpio_request() and then calls request_irq(). I think that the
solution needs to handle cases where the driver may or may not call
gpio_request() to allocate the gpio.
Are there actually drivers that do this? Perhaps they could just be
fixed not to.
Although it could be argued that this is problem is not DT specific,
it does become a bigger problem to handle in the case of DT. Therefore,
I am wondering if we should just focus on the DT case for now.
That doesn't sound like a good idea; this issue is entirely orthogonal
to DT.
Now, this does re-introduce irq_to_gpio() in some way, but with the
following advantages:
1) The implementation is per-controller, not a single global function,
so isn't introducing any kind of centralized mapping scheme again.
2) This irq-chip-specific .irq_to_gpio() would only be implemented for
IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
Its potential existence doesn't imply that all IRQ chips need implement
this; it would be very specifically be for this one particular case.
So, I think it's reasonable to introduce this.
How about using the gpio irq domain xlate function?
That translates DT IRQ-specifiers to Linux IRQ numbers. There's no
reason to believe that, as an absolute rule, it would work for anything
GPIO-related. The fact that in practice most GPIO+IRQ controllers happen
to use the same numbering for GPIOs and IRQs is just co-incidence.
Typically, in DT land a device using a gpio as an interrupt source
will have something like the following ...
eth@0 {
compatible = ks8851;
...
interrupt-parent = gpio2;
interrupts = 2 8; /* gpio line 34, low triggered */
};
OK, that really is an interrupt...
... or ...
mmc {
label = pandaboard::status2;
gpios = gpio1 8 0;
...
};
But that's a gpio-leds instance, not an MMC controller... I really
really hope there's no DT node using gpios to mean interrupts... And
it wouldn't make any sense for an on-SoC device anyway.
Both these devices are using a gpio as an interrupt source, but the mmc
driver is requesting the gpio directly. In the first case the xlate
function for the gpio irq domain will be called where as it is not used
in the 2nd case. Therefore, we could add a custom xlate function. For
example ...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
+int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
...
+ gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN,
ctrlr-name);
I guess that could work, but:
a) It still means doing the gpio_request() in each driver instead of
centrally.
b) This approach doesn't solve the issue where some client driver has
already requested the GPIO. This code would simply prevent that call
from succeeding, which would probably make the driver probe() error out,
which isn't any different to the equivalent proposed centralized
gpio_request() inside some request_irq() failing, and causing the
device's probe() to error out.
--
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/5] gpio/omap: Add DT support to GPIO driver
On 04/15/2013 05:16 PM, Stephen Warren wrote:
On 04/15/2013 03:40 PM, Jon Hunter wrote:
On 04/15/2013 11:58 AM, Stephen Warren wrote:
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
This looks sort of OK, but I'm still struggling with the question of
what we could do to help other implementations facing the same issue.
This is a pretty hard design pattern to properly replicate in every such
driver is it not?
Well, instead of adding .request_irq() to the irqchip, and then making
each driver call gpio_request() from the implementation, perhaps you
could add a .irq_to_gpio() to the irqchip, have the IRQ core call that,
and if it gets back a non-error response, the IRQ core could call
gpio_request(). That means that the change to each GPIO+IRQ driver is
simply to implement a standalone data transformation function
.irq_to_gpio().
I am still concerned about the case where a driver may have already
called gpio_request() and then calls request_irq(). I think that the
solution needs to handle cases where the driver may or may not call
gpio_request() to allocate the gpio.
Are there actually drivers that do this? Perhaps they could just be
fixed not to.
Yes ideally, but my fear is that there are several. I know both omap
display and mmc drivers do this. There are many drivers calling
gpio_direction_input() but I have not looked to see which of those are
just reading state versus configuring an interrupt.
Although it could be argued that this is problem is not DT specific,
it does become a bigger problem to handle in the case of DT. Therefore,
I am wondering if we should just focus on the DT case for now.
That doesn't sound like a good idea; this issue is entirely orthogonal
to DT.
True, but it is proving to be difficult to find a solution that everyone
can agree on.
Now, this does re-introduce irq_to_gpio() in some way, but with the
following advantages:
1) The implementation is per-controller, not a single global function,
so isn't introducing any kind of centralized mapping scheme again.
2) This irq-chip-specific .irq_to_gpio() would only be implemented for
IRQ+GPIO chips that actually have a 1:1 mapping between GPIOs and IRQs.
Its potential existence doesn't imply that all IRQ chips need implement
this; it would be very specifically be for this one particular case.
So, I think it's reasonable to introduce this.
How about using the gpio irq domain xlate function?
That translates DT IRQ-specifiers to Linux IRQ numbers. There's no
reason to believe that, as an absolute rule, it would work for anything
GPIO-related. The fact that in practice most GPIO+IRQ controllers happen
to use the same numbering for GPIOs and IRQs is just co-incidence.
Yes but provides a hook where we could call gpio_request(). However, I
am not sure if this would be considered abuse :-p
Typically, in DT land a device using a gpio as an interrupt source
will have something like the following ...
eth@0 {
compatible = ks8851;
...
interrupt-parent = gpio2;
interrupts = 2 8; /* gpio line 34, low triggered */
};
OK, that really is an interrupt...
... or ...
mmc {
label = pandaboard::status2;
gpios = gpio1 8 0;
...
};
But that's a gpio-leds instance, not an MMC controller... I really
really hope there's no DT node using gpios to mean interrupts... And
it wouldn't make any sense for an on-SoC device anyway.
Oops yes, I overlooked that. However, the omap mmc driver
(drivers/mmc/host/omap_hsmmc.c) does call gpio_request() and
request_threaded_irq() for the mmc card-detect interrupt. I believe
tegra is doing the same ...
sdhci@7800 {
...
cd-gpios = gpio 69 0; /* gpio PI5 */
...
};
Both these devices are using a gpio as an interrupt source, but the mmc
driver is requesting the gpio directly. In the first case the xlate
function for the gpio irq domain will be called where as it is not used
in the 2nd case. Therefore, we could add a custom xlate function. For
example ...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
+int omap_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
...
+ gpio_request_one(irq_to_gpio(bank, intspec[0]), GPIOF_IN,
ctrlr-name);
I guess that could work, but:
a) It still means doing the gpio_request() in each driver instead of
centrally.
Right this is device specific, but it avoids exposing irq_to_gpio for a
device. However, we could make this generic if we did expose irq_to_gpio
for each device.
b) This approach doesn't solve the issue where some client driver has
already requested the GPIO. This code would simply prevent that call
from succeeding, which would probably make the driver probe() error out,
which isn't any different to
Re: adding rpmsg.git to linux next
Hi Ohad, On Mon, 15 Apr 2013 09:28:17 +0300 Ohad Ben-Cohen o...@wizery.com wrote: Could you please add: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next to linux-next to include new stuff coming from Rob? Well, you could tell me something about it. Like what is in it and how it will be merged up to Linus. Does this have anything to do with the remoteproc tree I already include? Who is the official maintainer (there is no mention of drivers/rpmsg in the MAINTAINERS file). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpQTN94Wa_fK.pgp Description: PGP signature
Re: [PATCH 00/33] OMAPDSS: platform_enable/disable callback removal from panel drivers
On 2013-04-16 00:20, Tony Lindgren wrote: So, to recap, the common header changes are located in: git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers And the branch for linux-omap is: git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup After merging those, some displays won't start anymore until the omapdss changes are in, but things should still compile. Sounds like it's best that you merge those branches via your tree as the conflicts have been already resolved in linux next. The dss changes are going through drm tree this time, as there are some drm dependencies also, and I've already sent the pull request for those. And when I asked Dave Airlie if he can merge the dss changes, I didn't talk about a big chunk of arch file changes getting included. Also, the whole division to two independent branches was done only to make it possible for the arch changes to go through l-o tree. There will probably be more these kind of changes in the future, so I think we should agree how to handle those and stick to the plan. Dividing the arch file changes to a separate branch is often quite laborious, and I'd rather not do that for nothing. Tomi signature.asc Description: OpenPGP digital signature
