Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Sunday 01 February 2015 02:36:06 Matthijs van Duin wrote: On 31 January 2015 at 20:06, Pali Rohár pali.ro...@gmail.com wrote: I have configured two testing N900 devices. One with signed bootloader which enable omap aes support and one device with signed bootloader which does not enable omap aes support. I'm probably missing some context here, but why not just use the one with aes support? Alternatively, one may argue that it's the bootloader's job to provide the kernel with an accurate device tree. (Though one may equally well argue that it would be nice to avoid having to customize the device tree for every feature-flavor of a processor, especially if this depends on how it's initialized.) Nokia X-Loader is closed source and signed. So we cannot modify it. And it is responsible for configuring L3/L4 firewall. Year ago it was possible to find on internet signed X-Loader for N900 which enable omap aes support (for testing purpose together with open source linux kernel modules), but it is unofficial and I think there only too few people who flashed it into N900 nand. If somebody needs binaries I have backup all of them. More info about that aes enabled X-Loader: http://maemo.org/community/maemo-developers/n900_aes_and_sha1-md5_hw_acceleration_drivers/ Majority of users use only official X-Loader which does not enable aes support so we cannot enable kernel modules (cause crashes). And also we cannot force users to flash some unofficial binary into their device... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Sat, Jan 31, 2015 at 7:41 AM, Ohad Ben-Cohen o...@wizery.com wrote: On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson bj...@kryo.se wrote: In a system where you have two hwlock blocks lckA and lckB, each consisting of 8 locks and you have dspB that can only access lckB This is a good example - thanks. To be able to cope with such cases we will have to pass a hwlock block reference and its relative lock id. Additionally, to support such a scenario, we can no longer retain the simple dynamic allocation API we have today, because it might end up allocating dspB an hwlock from IckA. We will have to make sure hwlocks are allocated only from pools visible to the user, something that will change not only the hwspinlock API but also the way it maintains the hwlocks. I suspect we want to wait for such hardware to show up first, and only then add framework support for it. Regardless, we obviously do want to make sure our DT binding is prepared for the worse, so we'll drop the base-id field. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bq2415x_charger.c: battery is discharged (fast, 224mA) when it should be charged
Hello, On Sunday 01 February 2015 10:47:02 Pavel Machek wrote: Hi! I connected N900 with full battery using USB. For some reason, charge limit was set to 100mA, battery was full and was discharging: Make sure you have loaded some usb gadget. Without it battery charging via dedicated wallcharger (and probably also usb host charger) does not working. g_nokia should be OK. Try also compiling kernel with CONFIG_USB_GADGET_VBUS_DRAW=500 Also for charger autodetection you need to have loaded isp1704_charer.ko module (or compiled into kernel). And make sure that isp1704_charger is loaded before module bq2415x_charger (there is some probe defer, no idea if it works as excepted). root@n900:/my/tui/ofone# ./tefone Ready. Battery 4.017 V 4.039 V 81 % 0 % 0 / 0 / 2056 mAh Full -242.224 / 550 / 100 mA I adjusted the current limit, but got no change, battery is still discharging, fast: root@n900:/my/tui/ofone# echo 500 /sys/class/power_supply/bq24150a-0/current_limit You can try to write host to sysfs entry mode. Another value is dedicated for wallchargers. root@n900:/my/tui/ofone# ./tefone Ready. Battery 3.994 V 4.034 V 78 % 0 % 0 / 0 / 2056 mAh Full -251.506 / 550 / 500 mA Battery 4.0 V 4.037 V 79 % 0 % 0 / 0 / 2056 mAh Full -223.125 / 550 / 500 mA Battery 4.005 V 4.037 V 79 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 3.994 V 4.037 V 78 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 4.023 V 4.037 V 81 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 4.011 V 4.037 V 80 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 3.994 V 4.031 V 78 % 0 % 0 / 0 / 2056 mAh Full -256.504 / 550 / 500 mA Battery 3.994 V 4.029 V 78 % 0 % 0 / 0 / 2056 mAh Full -224.017 / 550 / 500 mA Battery 3.988 V 4.029 V 77 % 0 % 0 / 0 / 2056 mAh Full -224.731 / 550 / 500 mA Battery 4.005 V 4.023 V 79 % 0 % 0 / 0 / 2056 mAh Full -223.66 / 550 / 500 mA I'm getting a lot of [ 208.037719] bq27x00-battery 2-0055: battery is not calibrated! ignoring capacity values [ 238.038024] bq27x00-battery 2-0055: battery is not calibrated! ignoring capacity values Message is print every time when somebody try to read those properties. I think that printing it only one time should be enough. Change to WARN_ONCE? Also design capacity from bq27x00_battery is incorrect (2056) on all N900 devices. It comes from some EEPROM memory stored in N900 and without HW hacking it is not possible to rewrite. I would suggest to add support for bq27x00_battery module to do not report design capacity. Maybe in N900 DT file can be property which tell driver to ignore it. messages, that's why all the 0s in battery information dump. Any ideas? Thanks, Pavel -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
bq2415x_charger.c: battery is discharged (fast, 224mA) when it should be charged
Hi! I connected N900 with full battery using USB. For some reason, charge limit was set to 100mA, battery was full and was discharging: root@n900:/my/tui/ofone# ./tefone Ready. Battery 4.017 V 4.039 V 81 % 0 % 0 / 0 / 2056 mAh Full -242.224 / 550 / 100 mA I adjusted the current limit, but got no change, battery is still discharging, fast: root@n900:/my/tui/ofone# echo 500 /sys/class/power_supply/bq24150a-0/current_limit root@n900:/my/tui/ofone# ./tefone Ready. Battery 3.994 V 4.034 V 78 % 0 % 0 / 0 / 2056 mAh Full -251.506 / 550 / 500 mA Battery 4.0 V 4.037 V 79 % 0 % 0 / 0 / 2056 mAh Full -223.125 / 550 / 500 mA Battery 4.005 V 4.037 V 79 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 3.994 V 4.037 V 78 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 4.023 V 4.037 V 81 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 4.011 V 4.037 V 80 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 3.994 V 4.031 V 78 % 0 % 0 / 0 / 2056 mAh Full -256.504 / 550 / 500 mA Battery 3.994 V 4.029 V 78 % 0 % 0 / 0 / 2056 mAh Full -224.017 / 550 / 500 mA Battery 3.988 V 4.029 V 77 % 0 % 0 / 0 / 2056 mAh Full -224.731 / 550 / 500 mA Battery 4.005 V 4.023 V 79 % 0 % 0 / 0 / 2056 mAh Full -223.66 / 550 / 500 mA I'm getting a lot of [ 208.037719] bq27x00-battery 2-0055: battery is not calibrated! ignoring capacity values [ 238.038024] bq27x00-battery 2-0055: battery is not calibrated! ignoring capacity values messages, that's why all the 0s in battery information dump. Any ideas? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: bq2415x_charger.c: battery is discharged (fast, 224mA) when it should be charged
Hi! On Sun 2015-02-01 11:08:16, Pali Rohár wrote: On Sunday 01 February 2015 10:47:02 Pavel Machek wrote: Hi! I connected N900 with full battery using USB. For some reason, charge limit was set to 100mA, battery was full and was discharging: Make sure you have loaded some usb gadget. Without it battery charging via dedicated wallcharger (and probably also usb host charger) does not working. g_nokia should be OK. I had that loaded (was running from root over USB at the moment.) Try also compiling kernel with CONFIG_USB_GADGET_VBUS_DRAW=500 Also for charger autodetection you need to have loaded isp1704_charer.ko module (or compiled into kernel). And make sure that isp1704_charger is loaded before module bq2415x_charger (there is some probe defer, no idea if it works as excepted). It seems bq2415x_charger is the problem: it all started working when I did echo reset mode... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: bq2415x_charger.c: battery is discharged (fast, 224mA) when it should be charged
On Sun 2015-02-01 12:38:13, Pavel Machek wrote: Hi! On Sun 2015-02-01 11:08:16, Pali Rohár wrote: On Sunday 01 February 2015 10:47:02 Pavel Machek wrote: Hi! I connected N900 with full battery using USB. For some reason, charge limit was set to 100mA, battery was full and was discharging: Make sure you have loaded some usb gadget. Without it battery charging via dedicated wallcharger (and probably also usb host charger) does not working. g_nokia should be OK. I had that loaded (was running from root over USB at the moment.) Try also compiling kernel with CONFIG_USB_GADGET_VBUS_DRAW=500 Also for charger autodetection you need to have loaded isp1704_charer.ko module (or compiled into kernel). And make sure that isp1704_charger is loaded before module bq2415x_charger (there is some probe defer, no idea if it works as excepted). It seems bq2415x_charger is the problem: it all started working when I did echo reset mode... It does not switch from Full to Charging, and it does not seem to switch from Charging to Full, either...: root@n900:/my/tui/ofone# ./tefone Ready. Battery 4.152 V 4.161 V 95 % 0 % 0 / 0 / 2056 mAh Charging 40.876 / 650 / 500 mA Battery 4.152 V 4.161 V 95 % 0 % 0 / 0 / 2056 mAh Charging 48.195 / 650 / 500 mA Battery 4.152 V 4.164 V 95 % 0 % 0 / 0 / 2056 mAh Charging 43.554 / 650 / 500 mA Battery 4.14 V 4.164 V 94 % 0 % 0 / 0 / 2056 mAh Charging 40.162 / 650 / 500 mA Battery 4.158 V 4.172 V 95 % 0 % 0 / 0 / 2056 mAh Charging 54.621 / 650 / 500 mA Battery 4.158 V 4.175 V 95 % 0 % 0 / 0 / 2056 mAh Charging 33.736 / 650 / 500 mA aHello, world Battery 4.164 V 4.175 V 96 % 0 % 0 / 0 / 2056 mAh Charging 2.142 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 19.992 / 650 / 500 mA Battery 4.158 V 4.177 V 95 % 0 % 0 / 0 / 2056 mAh Charging 18.207 / 650 / 500 mA Battery 4.158 V 4.177 V 95 % 0 % 0 / 0 / 2056 mAh Charging 17.493 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 16.243 / 650 / 500 mA Battery 4.158 V 4.177 V 95 % 0 % 0 / 0 / 2056 mAh Charging 16.243 / 650 / 500 mA -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Fri, Jan 30, 2015 at 9:41 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson bj...@kryo.se wrote: In a system where you have two hwlock blocks lckA and lckB, each consisting of 8 locks and you have dspB that can only access lckB This is a good example - thanks. To be able to cope with such cases we will have to pass a hwlock block reference and its relative lock id. Correct, so the #hwlock-cells and hwlock part from the proposal are the important one. Having an optional hwlock-names will make things easier to read as well, but is not necessary. The DT binding should definitely be prepared for such cases (just kill the base-id field?), but let's see what it means about the Linux implementation. From the dt binding PoV, we should be able to skip num-locks as well. It seems most hwlock blocks have a fixed amount of locks provided and the drivers are reporting this to the core when registering. So I think we can reduce the binding to: Providers: #hwlock-cells Consumers: hwlocks hwlock-names For the hardware where number of locks is actually variable (e.g. different variants of same block) there can be driver specific entries for this. Since the existence of several hwblocks is still fictional (Bjorn, please confirm too?), we may prefer to introduce changes to support it only when it shows up; it all depends on the amount of changes needed. Suman, care to take a look please? I haven't seen any such systems yet. We could introduce the logic found in other subsystems of allowing -1 as base_id and having the core find a available range. This will work for all cases where the global ids doesn't have to be static; either due to the fact that we use block:local-id or that the indices are hard coded. (Referencing locks via dt is equivalent of the block:local-id case) - Sometimes a remote processor, which may not be running Linux, will have to dynamically allocate a hwlock, and send the ID of the allocated lock to us (another processor running Linux) I'm sorry but you cannot have a system on both sides that is allowed to do dynamic allocation from a limited set of resources. Of course not. On such systems, Linux is not the one responsible for allocating the hwlocks, at least not during part of the time or from part of the hwlocks. There were a few different use cases, with different semantics, that required communicating to Linux an hwlock id, but since none of them have reached mainline, we should only remember they may show up one day, but not put too much effort to support them right now. That makes more sense, although I still believe that you end up with a system wide setup where locks are statically allocated in some document beforehand. Either that or you will have to feed that other system with the list of constraints. Non the less, that's unrelated. If we get an incoming message saying lckX:Y (or the global lckZ), we probably wouldn't define that in DT. We would need a way to resolve the hwlock-block lckX so we can request lock Y from that block. We would basically build the DT reference on the fly. I think this is a future problem to be solved and more importantly I don't think it's limited to hwlocks. If a system architect designs a system where a remote entity will do allocation of resources for us, they will most likely do so not only for hwlocks but also for gpios, irqs and other resources that we today reference with arguments in DT. Hopefully that will not happen anytime soon, so let's just ignore that problem for now and go for a simple binding that will cover todays use cases (with some thought into multi-block support). Regards, Bjorn -- 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: bq2415x_charger.c: battery is discharged (fast, 224mA) when it should be charged
On Sun 2015-02-01 10:47:02, Pavel Machek wrote: Hi! I connected N900 with full battery using USB. For some reason, charge limit was set to 100mA, battery was full and was discharging: root@n900:/my/tui/ofone# ./tefone Ready. Battery 4.017 V 4.039 V 81 % 0 % 0 / 0 / 2056 mAh Full -242.224 / 550 / 100 mA I adjusted the current limit, but got no change, battery is still discharging, fast: root@n900:/my/tui/ofone# echo 500 /sys/class/power_supply/bq24150a-0/current_limit root@n900:/my/tui/ofone# ./tefone Ready. Battery 3.994 V 4.034 V 78 % 0 % 0 / 0 / 2056 mAh Full -251.506 / 550 / 500 mA Battery 4.0 V 4.037 V 79 % 0 % 0 / 0 / 2056 mAh Full -223.125 / 550 / 500 mA Battery 4.005 V 4.037 V 79 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 3.994 V 4.037 V 78 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 4.023 V 4.037 V 81 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 4.011 V 4.037 V 80 % 0 % 0 / 0 / 2056 mAh Full -224.91 / 550 / 500 mA Battery 3.994 V 4.031 V 78 % 0 % 0 / 0 / 2056 mAh Full -256.504 / 550 / 500 mA Battery 3.994 V 4.029 V 78 % 0 % 0 / 0 / 2056 mAh Full -224.017 / 550 / 500 mA Battery 3.988 V 4.029 V 77 % 0 % 0 / 0 / 2056 mAh Full -224.731 / 550 / 500 mA Battery 4.005 V 4.023 V 79 % 0 % 0 / 0 / 2056 mAh Full -223.66 / 550 / 500 mA I'm getting a lot of [ 208.037719] bq27x00-battery 2-0055: battery is not calibrated! ignoring capacity values [ 238.038024] bq27x00-battery 2-0055: battery is not calibrated! ignoring capacity values messages, that's why all the 0s in battery information dump. Any ideas? Reset kicked the charger back into the charging mode: root@n900:/sys/class/power_supply/bq24150a-0# echo reset mode root@n900:/sys/class/power_supply/bq24150a-0# cat mode auto (host) root@n900:/sys/class/power_supply/bq24150a-0# Battery 4.017 V 4.037 V 81 % 0 % 0 / 0 / 2056 mAh Charging -109.42 / 650 / 500 mA Battery 4.017 V 4.039 V 81 % 0 % 0 / 0 / 2056 mAh Charging -103.173 / 650 / 500 mA ...and discharge current reduced. I tried adjusting current limit, but it still discharges at 100mA (with screen on). USB extension cable was probably part of a problem. It works better with n900 plugged in directly into the PC. (But it still will not terminate the charge: Battery 4.158 V 4.177 V 95 % 0 % 0 / 0 / 2056 mAh Charging 13.03 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 13.03 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 10.888 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 1.249 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 10.353 / 650 / 500 mA Battery 4.158 V 4.177 V 95 % 0 % 0 / 0 / 2056 mAh Charging 9.639 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 10.71 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 7.497 / 650 / 500 mA Battery 4.158 V 4.177 V 95 % 0 % 0 / 0 / 2056 mAh Charging 9.639 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 6.247 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 5.533 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 4.284 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 4.284 / 650 / 500 mA Battery 4.164 V 4.177 V 96 % 0 % 0 / 0 / 2056 mAh Charging 3.927 / 650 / 500 mA ) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: Clock Regression in next-20150130 caused by cb75a8fcd14e
Quoting Tony Lindgren (2015-01-30 17:04:44) Hi all, Looks like commit cb75a8fcd14e (clk: Add rate constraints to clocks) causes a regression on at least omaps where the serial console either does not show anything, or just prints garbage. Reverting cb75a8fcd14e makes things work again on next-20150130. Any ideas? Stephen posted a patch[0] to fix this. I've squashed that into Tomeu's commit that you reference above and my Panda board is booting fine once again. [0] http://lkml.kernel.org/r/20150131013158.ga4...@codeaurora.org Please let me know if any other issues pop up. There are new WARNs for OMAP3+ boards introduced by a different patch from Tomeu, but this is really because the OMAP DPLL and FAPLL code are dereferencing struct clk pointers when they should not be and is a separate issue from the constraints patch (with a separate email thread). Regards, Mike Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 4/6] clk: Add rate constraints to clocks
Quoting Tomeu Vizoso (2015-01-31 10:36:22)
On 31 January 2015 at 02:31, Stephen Boyd sb...@codeaurora.org wrote:
On 01/29, Stephen Boyd wrote:
On 01/29/15 05:31, Geert Uytterhoeven wrote:
Hi Tomeu, Mike,
On Fri, Jan 23, 2015 at 12:03 PM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2391,25 +2543,24 @@ int __clk_get(struct clk *clk)
return 1;
}
-static void clk_core_put(struct clk_core *core)
+void __clk_put(struct clk *clk)
{
struct module *owner;
- owner = core-owner;
+ if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
+ return;
clk_prepare_lock();
- kref_put(core-ref, __clk_release);
+
+ hlist_del(clk-child_node);
+ clk_core_set_rate_nolock(clk-core, clk-core-req_rate);
At this point, clk-core-req_rate is still zero, causing
cpg_div6_clock_round_rate() to be called with a zero rate parameter,
e.g. on r8a7791:
Hmm.. I wonder if we should assign core-req_rate to be the same as
core-rate during __clk_init()? That would make this call to
clk_core_set_rate_nolock() a nop in this case.
Here's a patch to do this
---8
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] clk: Assign a requested rate by default
We need to assign a requested rate here so that we avoid
requesting a rate of 0 on clocks when we remove clock consumers.
Hi, this looks good to me.
Reviewed-by: Tomeu Vizoso tomeu.viz...@collabora.com
It seems to fix the total boot failure on OMAPs, and hopefully does the
same for SH Mobile and others. I've squashed this into Tomeu's rate
constraints patch to maintain bisect.
Regards,
Mike
Thanks,
Tomeu
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/clk/clk.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a29daf9edea4..8416ed1c40be 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2142,6 +2142,7 @@ int __clk_init(struct device *dev, struct clk
*clk_user)
struct clk_core *orphan;
struct hlist_node *tmp2;
struct clk_core *clk;
+ unsigned long rate;
if (!clk_user)
return -EINVAL;
@@ -2266,12 +2267,13 @@ int __clk_init(struct device *dev, struct clk
*clk_user)
* then rate is set to zero.
*/
if (clk-ops-recalc_rate)
- clk-rate = clk-ops-recalc_rate(clk-hw,
+ rate = clk-ops-recalc_rate(clk-hw,
clk_core_get_rate_nolock(clk-parent));
else if (clk-parent)
- clk-rate = clk-parent-rate;
+ rate = clk-parent-rate;
else
- clk-rate = 0;
+ rate = 0;
+ clk-rate = clk-req_rate = rate;
/*
* walk the list of orphan clocks and reparent any that are
children of
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v13 3/6] clk: Make clk API return per-user struct clk instances
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little API
as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller, but by
the clock implementation, so the former shouldn't call clk_put() on it.
Because some boards in mach-omap2 still register clocks statically, their
clock
registration had to be updated to take into account that the clock information
is stored in struct clk_core now.
Tero, Paul Tony,
Tomeu's patch unveils a problem with omap3_noncore_dpll_enable and
struct dpll_data, namely this snippet from
arch/arm/mach-omap2/dpll3xxx.c:
parent = __clk_get_parent(hw-clk);
if (__clk_get_rate(hw-clk) == __clk_get_rate(dd-clk_bypass)) {
WARN(parent != dd-clk_bypass,
here0, parent name is %s, bypass name is %s\n,
__clk_get_name(parent),
__clk_get_name(dd-clk_bypass));
r = _omap3_noncore_dpll_bypass(clk);
} else {
WARN(parent != dd-clk_ref,
here1, parent name is %s, ref name is %s\n,
__clk_get_name(parent),
__clk_get_name(dd-clk_ref));
r = _omap3_noncore_dpll_lock(clk);
}
struct dpll_data has members clk_ref and clk_bypass which are struct clk
pointers. This was always a bit of a violation of the clk.h contract
since drivers are not supposed to deref struct clk pointers. Now that we
generate unique pointers for each call to clk_get (clk_ref clk_bypass
are populated by of_clk_get in ti_clk_register_dpll) then the pointer
comparisons above will never be equal (even if they resolve down to the
same struct clk_core). I added the verbose traces to the WARNs above to
illustrate the point: the names are always the same but the pointers
differ.
AFAICT this doesn't break anything, but booting on OMAP3+ results in
noisy WARNs.
I think the correct fix is to replace clk_bypass and clk_ref pointers
with a simple integer parent_index. In fact we already have this index.
See how the pointers are populated in ti_clk_register_dpll:
dd-clk_ref = of_clk_get(node, 0);
dd-clk_bypass = of_clk_get(node, 1);
Tony, the same problem affects the FAPLL code which copy/pastes some of
the DPLL code.
Thoughts?
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] ASoC: tlv320aic3x: Add support for tlv320aic3104
On 01/30/2015 06:02 PM, Jyri Sarha wrote:
Disables GPIO support and LINE2 input and renames Mic3 input to Mic2,
if tlv320aic3104 mode is seleced. Devicetree binding document is
updated accordingly.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/sound/tlv320aic3x.txt | 10 +-
sound/soc/codecs/tlv320aic3x.c | 344
++--
2 files changed, 252 insertions(+), 102 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index 5e6040c..47a213c 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -9,6 +9,7 @@ Required properties:
ti,tlv320aic33 - TLV320AIC33
ti,tlv320aic3007 - TLV320AIC3007
ti,tlv320aic3106 - TLV320AIC3106
+ti,tlv320aic3104 - TLV320AIC3104
I think you should update the driver's tlv320aic3x_of_match[] table to include
the ti,tlv320aic3104 as well?
other than that it looks good.
--
Péter
- reg - int - I2C slave address
@@ -18,6 +19,7 @@ Optional properties:
- gpio-reset - gpio pin number used for codec reset
- ai3x-gpio-func - array of 2 int - AIC3X_GPIO1 AIC3X_GPIO2 Functionality
+ - Not supported on tlv320aic3104
- ai3x-micbias-vg - MicBias Voltage required.
1 - MICBIAS output is powered to 2.0V,
2 - MICBIAS output is powered to 2.5V,
@@ -36,7 +38,13 @@ CODEC output pins:
* HPLCOM
* HPRCOM
-CODEC input pins:
+CODEC input pins for TLV320AIC3104:
+ * MIC2L
+ * MIC2R
+ * LINE1L
+ * LINE1R
+
+CODEC input pins for other compatible codecs:
* MIC3L
* MIC3R
* LINE1L
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index b7ebce0..49ba3c7 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -87,6 +87,7 @@ struct aic3x_priv {
#define AIC3X_MODEL_3X 0
#define AIC3X_MODEL_33 1
#define AIC3X_MODEL_3007 2
+#define AIC3X_MODEL_3104 3
u16 model;
/* Selects the micbias voltage */
@@ -316,52 +317,37 @@ static const struct snd_kcontrol_new
aic3x_snd_controls[] = {
* only for swapped L-to-R and R-to-L routes. See below stereo controls
* for direct L-to-L and R-to-R routes.
*/
- SOC_SINGLE_TLV(Left Line Mixer Line2R Bypass Volume,
-LINE2R_2_LLOPM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left Line Mixer PGAR Bypass Volume,
PGAR_2_LLOPM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left Line Mixer DACR1 Playback Volume,
DACR1_2_LLOPM_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Right Line Mixer Line2L Bypass Volume,
-LINE2L_2_RLOPM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right Line Mixer PGAL Bypass Volume,
PGAL_2_RLOPM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right Line Mixer DACL1 Playback Volume,
DACL1_2_RLOPM_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Left HP Mixer Line2R Bypass Volume,
-LINE2R_2_HPLOUT_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left HP Mixer PGAR Bypass Volume,
PGAR_2_HPLOUT_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left HP Mixer DACR1 Playback Volume,
DACR1_2_HPLOUT_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Right HP Mixer Line2L Bypass Volume,
-LINE2L_2_HPROUT_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right HP Mixer PGAL Bypass Volume,
PGAL_2_HPROUT_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right HP Mixer DACL1 Playback Volume,
DACL1_2_HPROUT_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Left HPCOM Mixer Line2R Bypass Volume,
-LINE2R_2_HPLCOM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left HPCOM Mixer PGAR Bypass Volume,
PGAR_2_HPLCOM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left HPCOM Mixer DACR1 Playback Volume,
DACR1_2_HPLCOM_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Right HPCOM Mixer Line2L Bypass Volume,
-LINE2L_2_HPRCOM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right HPCOM Mixer PGAL Bypass Volume,
PGAL_2_HPRCOM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right HPCOM Mixer DACL1 Playback Volume,
DACL1_2_HPRCOM_VOL, 0, 118, 1, output_stage_tlv),
/* Stereo output controls for direct L-to-L and R-to-R routes */
- SOC_DOUBLE_R_TLV(Line Line2 Bypass Volume,
- LINE2L_2_LLOPM_VOL, LINE2R_2_RLOPM_VOL,
- 0, 118, 1,
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
Hi Roger, On 01/30/2015 11:05 PM, Roger Quadros wrote: Hi, On 30/01/15 13:04, Roger Quadros wrote: Felipe Chanwoo, On 26/01/15 14:15, Roger Quadros wrote: The recommended name for USB-Host cable state is USB-Host and not USB-HOST as per drivers/extcon/extcon-class.c extcon_cable_name. Change all instances of USB-HOST to USB-Host. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com This patch has no dependency to the rest so can be picked up as soon as possible. Do you think it is better to go via the USB tree? If yes then Chanwoo, can you please Ack this one? Thanks. This would mean that only the first patch needs to go through extcon tree as Tony will pick the rest. Hold on. Let's first decide what we really want to go ahead with USB-Host or USB-HOST. Currently, extcon driver have used the specific cable name(USB-Host or USB-HOST) without any standard way. So, I have plan to define common cable name in extcon header file by using capital letter. Thanks, Chanwoo Choi -- 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/7] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi Roger,
On 01/30/2015 11:03 PM, Roger Quadros wrote:
On 30/01/15 02:11, Chanwoo Choi wrote:
Hi Roger,
On 01/28/2015 09:15 PM, Roger Quadros wrote:
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros rog...@ti.com
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 233
+
4 files changed, 259 insertions(+)
create mode 100644
Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID
pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be linux,extcon-usb-gpio
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+ extcon_usb1 {
+ compatible = linux,extcon-usb-gpio;
+ id-gpio = gpio6 1 GPIO_ACTIVE_HIGH;
+ }
+
+ omap_dwc3_1 {
+ extcon = extcon_usb1;
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..fd11536 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+ tristate USB GPIO extcon support
+ select GPIOLIB
+ help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c
b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/extcon.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/workqueue.h
+
+#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
+
+struct usb_extcon_info {
+ struct device *dev;
+ struct extcon_dev *edev;
+
+ struct gpio_desc *id_gpiod;
+ int id_irq;
+ bool id_irqwake;/* ID wakeup enabled flag */
+
+ unsigned long debounce_jiffies;
+ struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = USB,
+ [EXTCON_CABLE_USB_HOST] = USB-Host,
I'll use the defined name for extcon cable name as soon because
it has potential isseu about the conflict of extcon cable name between
subsystems.
So, I recommend to
