Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi, Am 17.03.2015 um 09:47 schrieb Pavel Machek pa...@ucw.cz: Hi! diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt new file mode 100644 index 000..bb3580c --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt @@ -0,0 +1,43 @@ +twl4030_madc_battery + +Required properties: + - compatible : ti,twl4030-madc-battery + - capacity-uah : battery capacity in uAh Could we make it capacity-uAh ? This name was suggested by Mark Rutland [1] and naming convention should be all lowercase. There exists already bindings without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. Messing up SI units due to convention is _stupid_. Don't do it. to introduce coefficients for temperature and discharge rate? What do you mean? Nothing like that is used in current driver why do we need to add it? Well, conversion between Li-ion's voltage and state of charge at 0 current is well known: We can’t measure at 0 current since the OMAP is driven from battery and charger and may also draw some mA… def percent(m, v): u = 0.0387-(1.4523*(3.7835-v)) if u 0: return 0 return (0.1966+math.sqrt(u))*100 And there's not much to calibrate there, and it should become library helper function; there's no need to write it to every single dts. The charge/discharge difference is due to internal battery resistance, and Ohm's law. (Then, you should not need different values for charging/discharging case.) Yes, and that also depends on the board and battery type. So you always need to specify some battery specific coefficient for that in the DT. We simply did choose a table, because calculating the right coefficients is more complex and getting the table values can easily be done from running one full charge-discharge-charge cycle. With your aproach, you'll get lower percentage when phone is under load vs. idle. Taking internal resistance into account would give you more precise readings. (Attached, old patch for zaurus shows the needed computation). This is why we have a charging and a discharging table to compensate for this effect. And if you wanted even more precise readings... internal resistance depends on temperature. We don’t necessarily know the real battery temperature. I guess this should go into library somewhere, because many machines need similar code. Is a library easier to maintain and handle than just a set of table values? Anyways it ends up in a representation of a mapping function with two input parameters (voltage and charge/discharge indication). My proposal: keep it simple for everybody. And I can’t imagine something easier than a mapping table. BR, Nikolaus -- 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 v6 5/6] ARM: dts: add wl12xx/wl18xx bindings
that would be great. thanks. i'll try posting the updated patchset (v7, some minor changes) tomorrow. Eliad. On Mon, Mar 16, 2015 at 3:08 PM, Pau Pajuel paup...@gmail.com wrote: Hi, 2015-03-13 9:17 GMT+01:00 Enric Balletbo Serra eballe...@gmail.com: Hello, 2015-03-13 9:01 GMT+01:00 Javier Martinez Canillas jav...@dowhile0.org: Hello Eliad, On Thu, Mar 12, 2015 at 1:09 PM, Eliad Peller el...@wizery.com wrote: Replace all the pdata-quirks for setting wl12xx/wl18xx platform data with proper DT definitions. The patch was compile-tested only. Signed-off-by: Eliad Peller el...@wizery.com --- I wanted to test your series but I realized that the IGEPv2 I've access is the old revision that has another SDIO wlan module instead of a Wilink8. Maybe Enric have the new revision? I also added to Pau Pajuel as cc who still works in the company manufacturing these boards so he should be able to test it. Sorry, now I only have an old revision too, so I can't test, cc'ing Agustí that has access to the hardware, maybe he can test it or he can provide to us a board ;) But in any case, your patch looks good to me so for the arch/arm/boot/dts/omap3-igep00* changes: Acked-by: Javier Martinez Canillas jav...@dowhile0.org For my part also looks good. Acked-by: Enric Balletbo i Serra eballe...@gmail.com Best regards, Enric Best regards, Javier I'm gonna test it this week. I added Eduard Gavin as cc too. Cheers! -- 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Am 17.03.2015 um 09:48 schrieb Pavel Machek pa...@ucw.cz: Temperature calibration should have already been done in the underlaying twl4030 iio driver. Discharge rate is the real current flow reported in uA. Also reported by iio. Ack, but there's rather severe temperature dependency of the lithium battery, which you should take into account if you want to compute “percentage charged. We just want to estimate it as good as possible. 5-10% is sufficient and better than no value at all (which is what you get without this driver). And, we just convert the (existing) driver from non-DT to DT and to use iio, so we do not want to change the inner logic what it does and how it works. BR, Nikolaus -- 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 v6 6/6] wlcore: remove wl12xx_platform_data
On Mon, Mar 16, 2015 at 8:24 PM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@ring0.de [150316 11:26]: Hi, On Mon, Mar 16, 2015 at 08:29:39AM -0700, Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [150315 05:10]: On Sunday 15 March 2015 10:50:42 Eliad Peller wrote: yeah, i missed it :/ looks like there's no platform that defines platform data for it. i'll replace the dev_get_platdata() with a function that only parses the clock-frequency properties (the irq is taken in this case from the spi_device). (or maybe i should just drop it, as no one actually uses it?) I don't think we should drop the driver, but dropping the platform_data support sounds reasonable. New users of this driver should all be using DT, and if there is a good reason to use platform_data, it's easily put back. Well we have n8x0 and n900 using the spi driver. For those, n8x0 boot all in dts mode, but n900 still also boots in legacy mode. It seems the board-rx51-peripherals.c only passes the power_gpio though, so that should be easy to keep around. We should keep things still working for n900 in legacy mode until the pending regressions with device tree based booting have been cleared for at least one merge cycle. I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali. mh by migrating to newer gpiod interface platform data is no longer needed (instead the boardfile would need a gpiod_lookup_table). That way all of the dirty code is in the board file and will be removed once the time comes. See for example rx51_fmtx_gpios_table. Note: This is independent of wl12xx changes, since N900 uses wl1251. Oh sorry yes sounds like that's different platform data then. In that case I see no reasons to drop the platform data for wl12xx. great. so i'll drop the relevant wlcore_spi platform data code, and rebase the patches on top of v4.0-rc4 (probably tomorrow). Eliad. -- 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi!
diff --git
a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 000..bb3580c
--- /dev/null
+++
b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,43 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : ti,twl4030-madc-battery
+ - capacity-uah : battery capacity in uAh
Could we make it capacity-uAh ?
This name was suggested by Mark Rutland [1] and naming convention
should be all lowercase. There exists already bindings
without uppercase (e.g. ti,bb-uamp) so I would keep it consistent.
Messing up SI units due to convention is _stupid_. Don't do it.
to introduce coefficients for temperature and discharge rate?
What do you mean? Nothing like that is used in current driver why do
we need to add it?
Well, conversion between Li-ion's voltage and state of charge at 0
current is well known:
def percent(m, v):
u = 0.0387-(1.4523*(3.7835-v))
if u 0:
return 0
return (0.1966+math.sqrt(u))*100
And there's not much to calibrate there, and it should become library
helper function; there's no need to write it to every single dts.
The charge/discharge difference is due to internal battery resistance,
and Ohm's law. (Then, you should not need different values for
charging/discharging case.)
With your aproach, you'll get lower percentage when phone is under
load vs. idle. Taking internal resistance into account would give you
more precise readings. (Attached, old patch for zaurus shows the
needed computation).
And if you wanted even more precise readings... internal resistance
depends on temperature.
I guess this should go into library somewhere, because many machines
need similar code.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
./drivers/power - ./drivers/power.ofic
diff -X /usr/src/linux/.gitignore -ur ./drivers/power.ofic/Makefile ./drivers/power/Makefile
--- ./drivers/power.ofic/Makefile 2011-03-16 10:11:34.0 +0100
+++ ./drivers/power/Makefile 2011-04-29 15:12:14.0 +0200
@@ -19,7 +19,9 @@
obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
obj-$(CONFIG_BATTERY_TOSA) += tosa_battery.o
+obj-m += spitz_battery.o
obj-$(CONFIG_BATTERY_COLLIE) += collie_battery.o
+obj-m += spitz_battery.o
obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o
obj-$(CONFIG_BATTERY_BQ20Z75) += bq20z75.o
obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
diff -X /usr/src/linux/.gitignore -ur ./drivers/power.ofic/power_supply_sysfs.c ./drivers/power/power_supply_sysfs.c
--- ./drivers/power.ofic/power_supply_sysfs.c 2011-02-02 10:54:32.0 +0100
+++ ./drivers/power/power_supply_sysfs.c 2011-04-29 15:02:07.0 +0200
@@ -40,7 +40,8 @@
static ssize_t power_supply_show_property(struct device *dev,
struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
static char *type_text[] = {
Battery, UPS, Mains, USB,
USB_DCP, USB_CDP, USB_ACA
@@ -102,7 +103,8 @@
static ssize_t power_supply_store_property(struct device *dev,
struct device_attribute *attr,
- const char *buf, size_t count) {
+ const char *buf, size_t count)
+{
ssize_t ret;
struct power_supply *psy = dev_get_drvdata(dev);
const ptrdiff_t off = attr - power_supply_attrs;
Only in ./drivers/power: spitz_battery.c
./drivers/video - ./drivers/video.ofic
diff -X /usr/src/linux/.gitignore -ur ./drivers/video.ofic/pxafb.c ./drivers/video/pxafb.c
--- ./drivers/video.ofic/pxafb.c 2011-02-02 09:44:53.0 +0100
+++ ./drivers/video/pxafb.c 2011-04-29 14:50:27.0 +0200
@@ -1648,6 +1648,9 @@
#endif
#ifdef CONFIG_PM
+
+static struct pxafb_info *my_fbi;
+
/*
* Power management hooks. Note that we won't be called from IRQ context,
* unlike the blank functions above, so we may sleep.
@@ -1656,6 +1659,8 @@
{
struct pxafb_info *fbi = dev_get_drvdata(dev);
+ my_fbi = fbi;
+
set_ctrlr_state(fbi, C_DISABLE_PM);
return 0;
}
./arch/arm - ./arch/arm.ofic
Binary files ./arch/arm.ofic/boot/Image and ./arch/arm/boot/Image differ
Binary files ./arch/arm.ofic/boot/compressed/piggy.gzip and ./arch/arm/boot/compressed/piggy.gzip differ
Binary files ./arch/arm.ofic/boot/compressed/vmlinux and ./arch/arm/boot/compressed/vmlinux differ
Binary files ./arch/arm.ofic/boot/zImage and ./arch/arm/boot/zImage differ
diff -X /usr/src/linux/.gitignore -ur ./arch/arm.ofic/mach-pxa/corgi_pm.c ./arch/arm/mach-pxa/corgi_pm.c
--- ./arch/arm.ofic/mach-pxa/corgi_pm.c 2011-02-02 10:30:38.0 +0100
+++ ./arch/arm/mach-pxa/corgi_pm.c 2011-04-29 15:12:15.0 +0200
@@ -43,6 +43,92 @@
{ CORGI_GPIO_KEY_INT, GPIOF_IN, Key Interrupt },
};
+static
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Temperature calibration should have already been done in the underlaying twl4030 iio driver. Discharge rate is the real current flow reported in uA. Also reported by iio. Ack, but there's rather severe temperature dependency of the lithium battery, which you should take into account if you want to compute percentage charged. 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: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Hi,
On Tue, 2015-03-17 at 11:01 +0900, Chanwoo Choi wrote:
Hi Ivan,
On 03/16/2015 11:23 PM, Ivan T. Ivanov wrote:
Hi Roger,
On Mon, 2015-03-16 at 15:11 +0200, Roger Quadros wrote:
Hi Ivan,
On 16/03/15 14:32, Ivan T. Ivanov wrote:
Hi,
On Mon, 2015-02-02 at 12:21 +0200, 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
---
v4:
- got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
- changed host cable name to USB-HOST
I am sorry that I am getting a bit little late into this.
Isn't supposed that we have to use strings defined in
const char extcon_cable_name[][]?
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
Same here: duplicated with enum extcon_cable_name
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = USB,
+ [EXTCON_CABLE_USB_HOST] = USB-HOST,
+ NULL,
+};
I'm not exactly sure how else it is supposed to work if we
support only a subset of cables from the global extcon_cable_name[][].
I don't see issue that we use just 2 events. I think that we can
reuse enum extcon_cable_name
Now I see that extcon_dev_register() expect NULL terminated array of
pointers, so it will not be possible to use enum extcon_cable_name
as index in the above array, sorry.
and strings already defined in
extcon_cable_name[][] global variable. It is defined extern in
extcon.h file exactly for this purpose, no?
'extcon_cable_name' global variable is not used on extcon driver directly.
It is just recommended cable name.
Hm, this is what bothers me. How client drivers will know cable name if
every provider start using its own naming scheme?
If I write client driver I will use:
extcon_register_interest(obj, name, extcon_cable_name[EXTCON_USB_HOST], nb);
and this will now work with this driver because it define string differently.
... Well, I see that string is changed because your recommendation :-),
then lets fix extcon_cable_name strings and not let drivers define its own
names.
I have plan to use standard cable name for extcon driver instead of that
each extcon driver define the cable name.
Sound like a good plan :-)
Regards,
Ivan
--
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/1] extcon: usb-gpio: Introduce gpio usb extcon driver
Fixed spelling error.
On Tue, 2015-03-17 at 09:52 +0200, Ivan T. Ivanov wrote:
Hi,
On Tue, 2015-03-17 at 11:01 +0900, Chanwoo Choi wrote:
Hi Ivan,
On 03/16/2015 11:23 PM, Ivan T. Ivanov wrote:
Hi Roger,
On Mon, 2015-03-16 at 15:11 +0200, Roger Quadros wrote:
Hi Ivan,
On 16/03/15 14:32, Ivan T. Ivanov wrote:
Hi,
On Mon, 2015-02-02 at 12:21 +0200, 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
---
v4:
- got rid of id_irqwake flag. Fail if enable/disable_irq_wake()
fails
- changed host cable name to USB-HOST
I am sorry that I am getting a bit little late into this.
Isn't supposed that we have to use strings defined in
const char extcon_cable_name[][]?
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
Same here: duplicated with enum extcon_cable_name
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = USB,
+ [EXTCON_CABLE_USB_HOST] = USB-HOST,
+ NULL,
+};
I'm not exactly sure how else it is supposed to work if we
support only a subset of cables from the global extcon_cable_name[][].
I don't see issue that we use just 2 events. I think that we can
reuse enum extcon_cable_name
Now I see that extcon_dev_register() expect NULL terminated array of
pointers, so it will not be possible to use enum extcon_cable_name
as index in the above array, sorry.
and strings already defined in
extcon_cable_name[][] global variable. It is defined extern in
extcon.h file exactly for this purpose, no?
'extcon_cable_name' global variable is not used on extcon driver directly.
It is just recommended cable name.
Hm, this is what bothers me. How client drivers will know cable name if
every provider start using its own naming scheme?
If I write client driver I will use:
extcon_register_interest(obj, name, extcon_cable_name[EXTCON_USB_HOST], nb);
and this will now work with this driver because it define string differently.
^^^
s/now/not/
... Well, I see that string is changed because your recommendation :-),
then lets fix extcon_cable_name strings and not let drivers define its own
names.
I have plan to use standard cable name for extcon driver instead of that
each extcon driver define the cable name.
Sound like a good plan :-)
Regards,
Ivan
--
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: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
On 03/17/2015 11:26 AM, santosh shilimkar wrote: On 3/16/2015 4:30 PM, Tony Lindgren wrote: * Stefan Hengelein stefan.hengel...@fau.de [150225 10:48]: The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a contradiction in it's dependencies. The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be enabled. These options inherit a dependency from an enclosing menu, that requires ARCH_MULTIPLATFORM to be 'enabled'. This is a contradiction and made this option also unavailable for non-multiplatform configurations. Since there are no selects on OMAP4_ERRATA_I688, which would ignore dependencies, the code related to that option is dead and can be removed. This (logical) defect has been found with the undertaker tool. (https://undertaker.cs.fau.de) Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de --- Tony Lindgren suggested to remove the code since nobody complained for a few years and Santosh Shilimkar agreed. https://lkml.org/lkml/2015/2/25/449 --- As far as I see, this should remove all the code related to OMAP4_ERRATA_I688, I hope I didn't remove too much. Seems to boot fine, so applying into omap-for-v4.1/fixes-not-urgent. Acked-by: Santosh Shilimkar ssant...@kernel.org We no longer need i688? I do understand the need to cleanup the macros for multi-arch etc.. but loosing a bug workaround for a real silicon bug is really an invitation for hard to debug issues IMHO. -- 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] ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
On Tue, Mar 17, 2015 at 12:10 PM, Tony Lindgren t...@atomide.com wrote: Yes that's a good point and adding a printk is a good idea. Care to crank out a separate patch for that? had hoped to have it part of this patch - does'nt that make more sense? -- --- 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 02/35 linux-next] regulator: constify of_device_id array
On 17 March 2015 at 18:19 Mark Brown broo...@kernel.org wrote: On Tue, Mar 17, 2015 at 06:10:12PM +0100, Fabian Frederick wrote: Thanks Mark, I used a --cc-cmd script by Joe Perches with git send-email which uses --nom for cover-letter. This limits recipients to mailing lists: 37 instead of 123 in this case. I guess it's better to reduce the noise :) Well, another thing to do if there's no dependencies is to just send each patch separately - there's no real relationship between the patches. This also avoids the issue. Such trivial updates are generally applied by David or Greg after receiving some ack. That's the reason for the patchset :) -- 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] regulator: palmas: Correct TPS659038 register definition for REGEN2
The register offset for REGEN2_CTRL in different for TPS659038 chip as when
compared with other Palmas family PMICs. In the case of TPS659038 the wrong
offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same.
Signed-off-by: Keerthy j-keer...@ti.com
---
Tested for the regulator enumerations on DRA7 and BEAGLE-X15 boards.
No Hang observed.
drivers/regulator/palmas-regulator.c | 4
include/linux/mfd/palmas.h | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 9205f43..1819831 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1572,6 +1572,10 @@ static int palmas_regulators_probe(struct
platform_device *pdev)
if (!pmic)
return -ENOMEM;
+ if (of_device_is_compatible(node, ti,tps659038-pmic))
+ palmas_generic_regs_info[PALMAS_REG_REGEN2].ctrl_addr =
+ TPS659038_REGEN2_CTRL;
+
pmic-dev = pdev-dev;
pmic-palmas = palmas;
palmas-pmic = pmic;
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index fb0390a..ee7b1ce 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -2999,6 +2999,9 @@ enum usb_irq_events {
#define PALMAS_GPADC_TRIM150x0E
#define PALMAS_GPADC_TRIM160x0F
+/* TPS659038 regen2_ctrl offset iss different from palmas */
+#define TPS659038_REGEN2_CTRL 0x12
+
/* TPS65917 Interrupt registers */
/* Registers for function INTERRUPT */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] regulator: TPS659038: Fixes for REGEN2 and REGEN3
The series fixes couple of issues in the driver w.r.t TPS659038 PMICs. 1) Correcting the REGEN2_CTRL address. 2) REGEN3 is not present hence adding a check not to register for TPS659038. Tested for the regulator enumerations on DRA7 and BEAGLE-X15 boards. Keerthy (2): regulator: palmas: Correct TPS659038 register definition for REGEN2 regulator: Palmas: Add has_regen3 check for TPS659038 drivers/regulator/palmas-regulator.c | 11 +++ include/linux/mfd/palmas.h | 4 2 files changed, 15 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! to introduce coefficients for temperature and discharge rate? What do you mean? Nothing like that is used in current driver why do we need to add it? Well, conversion between Li-ion's voltage and state of charge at 0 current is well known: We can’t measure at 0 current since the OMAP is driven from battery and charger and may also draw some mA… Yes, but you know how many mA you are taking just now. So if you knew the internal resistance, you could compute the voltage at 0 current. (And it should also work during charging, as long as you know how much current is going in.) def percent(m, v): u = 0.0387-(1.4523*(3.7835-v)) if u 0: return 0 return (0.1966+math.sqrt(u))*100 And there's not much to calibrate there, and it should become library helper function; there's no need to write it to every single dts. The charge/discharge difference is due to internal battery resistance, and Ohm's law. (Then, you should not need different values for charging/discharging case.) Yes, and that also depends on the board and battery type. So you always need to specify some battery specific coefficient for that in the DT. Yes, and that coefficient should be internal battery resistance ;-). We simply did choose a table, because calculating the right coefficients is more complex and getting the table values can easily be done from running one full charge-discharge-charge cycle. Well.. One set of coefficients would be kind of ok. But you are doing two, because it really depends on current, not charge/discharge. So why not do it right, for all currents...? With your aproach, you'll get lower percentage when phone is under load vs. idle. Taking internal resistance into account would give you more precise readings. (Attached, old patch for zaurus shows the needed computation). This is why we have a charging and a discharging table to compensate for this effect. Yes, but there's very different current during idle phone and during call (for example). So yes, you are compensating for different current during charge and discharge, but it is possible to do better. I guess this should go into library somewhere, because many machines need similar code. Is a library easier to maintain and handle than just a set of table values? I think so, yes, because otherwise you need a set of tables for each machine. 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
[PATCH] ARM: dts: dra7x-evm: beagle-x14: Fix USB Peripheral
Now that we have EXTCON_USB_GPIO queued for v4.1, revert
commit addfcde7c485 (ARM: dts: dra7x-evm: beagle-x15: Fix USB Host)
On these EVMs, the USB cable state has to be determined via the
ID pin tied to a GPIO line. We use the gpio-usb-extcon driver
to read the ID pin and the extcon framework to forward
the USB cable state information to the USB driver so the
controller can be configured in the right mode (host/peripheral).
Gets USB peripheral mode to work on this EVM.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 8
arch/arm/boot/dts/dra7-evm.dts | 8
arch/arm/boot/dts/dra72-evm.dts | 8
3 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index bd48dba..170fbf9 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -548,6 +548,14 @@
pinctrl-0 = usb1_pins;
};
+omap_dwc3_1 {
+ extcon = extcon_usb1;
+};
+
+omap_dwc3_2 {
+ extcon = extcon_usb2;
+};
+
usb2 {
dr_mode = peripheral;
};
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index b1bd06c..aa46590 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -541,6 +541,14 @@
};
};
+omap_dwc3_1 {
+ extcon = extcon_usb1;
+};
+
+omap_dwc3_2 {
+ extcon = extcon_usb2;
+};
+
usb1 {
dr_mode = peripheral;
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index daf2811..ce0390f 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -377,6 +377,14 @@
phy-supply = ldo4_reg;
};
+omap_dwc3_1 {
+ extcon = extcon_usb1;
+};
+
+omap_dwc3_2 {
+ extcon = extcon_usb2;
+};
+
usb1 {
dr_mode = peripheral;
pinctrl-names = default;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] regulator: Palmas: Add has_regen3 check for TPS659038
Palmas driver is used to cater to even TPS659038 but TPS659038 does not have
REGEN3 resource. Adding another field in the driver data to check on that.
Signed-off-by: Keerthy j-keer...@ti.com
---
Tested for the regulator enumerations on DRA7 and BEAGLE-X15 boards.
REGEN3 is rightly not registered on TPS659038.
drivers/regulator/palmas-regulator.c | 9 -
include/linux/mfd/palmas.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1819831..a3c56b6 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -916,6 +916,9 @@ static int palmas_ldo_registration(struct palmas_pmic *pmic,
(id == PALMAS_REG_LDO6))
desc-enable_time = 2000;
} else {
+ if (!ddata-has_regen3 id == PALMAS_REG_REGEN3)
+ continue;
+
desc-n_voltages = 1;
if (reg_init reg_init-roof_floor)
desc-ops = palmas_ops_ext_control_extreg;
@@ -1398,6 +1401,7 @@ static struct palmas_pmic_driver_data palmas_ddata = {
.ldo_begin = PALMAS_REG_LDO1,
.ldo_end = PALMAS_REG_LDOUSB,
.max_reg = PALMAS_NUM_REGS,
+ .has_regen3 = true,
.palmas_regs_info = palmas_generic_regs_info,
.palmas_matches = palmas_matches,
.sleep_req_info = palma_sleep_req_info,
@@ -1411,6 +1415,7 @@ static struct palmas_pmic_driver_data tps65917_ddata = {
.ldo_begin = TPS65917_REG_LDO1,
.ldo_end = TPS65917_REG_LDO5,
.max_reg = TPS65917_NUM_REGS,
+ .has_regen3 = true,
.palmas_regs_info = tps65917_regs_info,
.palmas_matches = tps65917_matches,
.sleep_req_info = tps65917_sleep_req_info,
@@ -1572,9 +1577,11 @@ static int palmas_regulators_probe(struct
platform_device *pdev)
if (!pmic)
return -ENOMEM;
- if (of_device_is_compatible(node, ti,tps659038-pmic))
+ if (of_device_is_compatible(node, ti,tps659038-pmic)) {
palmas_generic_regs_info[PALMAS_REG_REGEN2].ctrl_addr =
TPS659038_REGEN2_CTRL;
+ palmas_ddata.has_regen3 = false;
+ }
pmic-dev = pdev-dev;
pmic-palmas = palmas;
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index ee7b1ce..bb270bd 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -117,6 +117,7 @@ struct palmas_pmic_driver_data {
int ldo_begin;
int ldo_end;
int max_reg;
+ bool has_regen3;
struct palmas_regs_info *palmas_regs_info;
struct of_regulator_match *palmas_matches;
struct palmas_sleep_requestor_info *sleep_req_info;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Am 17.03.2015 um 09:47 schrieb Pavel Machek pa...@ucw.cz: Hi! diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt new file mode 100644 index 000..bb3580c --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt @@ -0,0 +1,43 @@ +twl4030_madc_battery + +Required properties: + - compatible : ti,twl4030-madc-battery + - capacity-uah : battery capacity in uAh Could we make it capacity-uAh ? This name was suggested by Mark Rutland [1] and naming convention should be all lowercase. There exists already bindings without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. Messing up SI units due to convention is _stupid_. Don't do it. to introduce coefficients for temperature and discharge rate? What do you mean? Nothing like that is used in current driver why do we need to add it? Well, conversion between Li-ion's voltage and state of charge at 0 current is well known: def percent(m, v): u = 0.0387-(1.4523*(3.7835-v)) if u 0: return 0 return (0.1966+math.sqrt(u))*100 I forgot to ask: does the kernel have a sqrt() function? And there's not much to calibrate there, and it should become library helper function; there's no need to write it to every single dts. The charge/discharge difference is due to internal battery resistance, and Ohm's law. (Then, you should not need different values for charging/discharging case.) With your aproach, you'll get lower percentage when phone is under load vs. idle. Taking internal resistance into account would give you more precise readings. (Attached, old patch for zaurus shows the needed computation). And if you wanted even more precise readings... internal resistance depends on temperature. I guess this should go into library somewhere, because many machines need similar code. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html zbattery.10.diff -- 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings
On Tue 2015-03-17 10:07:12, Dr. H. Nikolaus Schaller wrote: Am 17.03.2015 um 09:47 schrieb Pavel Machek pa...@ucw.cz: Hi! diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt new file mode 100644 index 000..bb3580c --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt @@ -0,0 +1,43 @@ +twl4030_madc_battery + +Required properties: + - compatible : ti,twl4030-madc-battery + - capacity-uah : battery capacity in uAh Could we make it capacity-uAh ? This name was suggested by Mark Rutland [1] and naming convention should be all lowercase. There exists already bindings without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. Messing up SI units due to convention is _stupid_. Don't do it. to introduce coefficients for temperature and discharge rate? What do you mean? Nothing like that is used in current driver why do we need to add it? Well, conversion between Li-ion's voltage and state of charge at 0 current is well known: def percent(m, v): u = 0.0387-(1.4523*(3.7835-v)) if u 0: return 0 return (0.1966+math.sqrt(u))*100 I forgot to ask: does the kernel have a sqrt() function? This could be good enough. https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/2.6.0-mm1/broken-out/fix-sqrt.patch 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: [PATCH v2 7/7] ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB
On 16/03/15 19:53, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [150126 04:19]: This driver is needed for USB cable type detection on dra7-evm, dra72-evm and am57xx-beagle-x15. Signed-off-by: Roger Quadros rog...@ti.com Applying this into omap-for-v4.1/defconfig. I think it's all queued up after this, please check and repost patches if it's still missing something as I've marked all the extcon related threads as read here now. Thanks Tony. We just need to revert the following commit. addfcde7c485 (ARM: dts: dra7x-evm: beagle-x15: Fix USB Host) I'll send a patch on l-o for that. cheers, -roger Regards, Tony --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 667d9d5..7e10e58 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -326,6 +326,7 @@ CONFIG_DMADEVICES=y CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y CONFIG_EXTCON=y +CONFIG_EXTCON_USB_GPIO=m CONFIG_EXTCON_PALMAS=y CONFIG_PWM=y CONFIG_PWM_TIECAP=y -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: omap2plus_defconfig: Enable n900 modem as loadable modules
Hi Tony, On Mon, Mar 16, 2015 at 01:00:03PM -0700, Tony Lindgren wrote: Enable n900 modem as loadable modules. Acked-By: Sebastian Reichel s...@kernel.org [...] +CONFIG_HSI_CHAR=m [...] I think this one should be disabled by default. It's only needed by very few people (it exposes the hsi bus to userspace, like i2c-dev driver does for i2c). -- Sebastian signature.asc Description: Digital signature
Re: [PATCHv3 08/35] clk: ti: fix ti_clk_get_reg_addr error handling
* Mike Turquette mturque...@linaro.org [150306 11:18]: Quoting Tero Kristo (2015-02-25 11:04:18) There is a case where NULL can be a valid return value for ti_clk_get_reg_addr, specifically the case where both the provider index and register offsets are zero. In this case, the current error checking against a NULL pointer will fail. Thus, change the API to return a ERR_PTR value in an error case, and change all the users of this API to check against IS_ERR instead. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Michael Turquette mturque...@linaro.org Looks good to me. ... --- drivers/clk/ti/apll.c |5 +++-- drivers/clk/ti/autoidle.c |2 +- drivers/clk/ti/clk.c |7 --- drivers/clk/ti/divider.c |4 ++-- drivers/clk/ti/dpll.c |6 +++--- drivers/clk/ti/gate.c |4 ++-- drivers/clk/ti/interface.c |2 +- drivers/clk/ti/mux.c |4 ++-- 8 files changed, 18 insertions(+), 16 deletions(-) Can this patch be queued separately by Mike or is there some dependency to this series? Other than wondering about the above and the dts related comments, this series works for me with PM tests. 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 3/3] ARM: omap2plus_defconfig: Enable n900 modem as loadable modules
* Sebastian Reichel s...@kernel.org [150317 04:00]: Hi Tony, On Mon, Mar 16, 2015 at 01:00:03PM -0700, Tony Lindgren wrote: Enable n900 modem as loadable modules. Acked-By: Sebastian Reichel s...@kernel.org [...] +CONFIG_HSI_CHAR=m [...] I think this one should be disabled by default. It's only needed by very few people (it exposes the hsi bus to userspace, like i2c-dev driver does for i2c). OK will disable thanks. 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] ARM: dts: dra7x-evm: beagle-x14: Fix USB Peripheral
* Felipe Balbi ba...@ti.com [150317 07:55]: Hi, On Tue, Mar 17, 2015 at 11:43:51AM +0200, Roger Quadros wrote: Now that we have EXTCON_USB_GPIO queued for v4.1, revert commit addfcde7c485 (ARM: dts: dra7x-evm: beagle-x15: Fix USB Host) On these EVMs, the USB cable state has to be determined via the ID pin tied to a GPIO line. We use the gpio-usb-extcon driver to read the ID pin and the extcon framework to forward the USB cable state information to the USB driver so the controller can be configured in the right mode (host/peripheral). Gets USB peripheral mode to work on this EVM. Signed-off-by: Roger Quadros rog...@ti.com on subject: x14 ? other than that Reviewed-by: Felipe Balbi ba...@ti.com Applying into omap-for-v4.1/dt-v2 with the subject line fixed. 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: Serious memory leak in TI EDMA driver (drivers/dma/edma.c)
Hi Peter, thanks a lot for the details. I believe it's not an Ethernet issue, it's really related to the SD card. If we use the USB storage instead of the SD card on our device we don't see the leaks. I enabled the dynamic debug and added a debug message for the kzalloc() in edma_prep_slave_sg() and for the kfree() in the edma_desc_free() both to print the pointer address. And it gives an interesting result, see below. You can see that after every alloc (i.e.edma_prep_slave_sg()) edma_execute() is called (file transfer starting...), however not all of them end with Transfer complete. And exactly those are also not freed. Unfortunately I do not know how exactly the edma mechanism works with all the callbacks, states, etc. But does it make any sense for you? Can you help me to debug more? Thanks Petr ALLOC edesc c65d5c80 first transfer starting on channel 65565 ALLOC edesc c5b69640 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c5b69640 ALLOC edesc c58ec580 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c58ec580 ALLOC edesc c5103d80 first transfer starting on channel 65565 ALLOC edesc c61e78c0 first transfer starting on channel 65565 ALLOC edesc c65d6f80 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c65d6f80 ALLOC edesc c5b698c0 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c5b698c0 ALLOC edesc c52244c0 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c52244c0 ALLOC edesc c52244c0 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c52244c0 ALLOC edesc c52244c0 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c52244c0 ALLOC edesc c52244c0 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c52244c0 ALLOC edesc c58ec580 first transfer starting on channel 65565 ALLOC edesc c5b698c0 first transfer starting on channel 65565 ALLOC edesc c5103480 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c5103480 ALLOC edesc c5b69640 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c5b69640 ALLOC edesc c61e62c0 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c61e62c0 ALLOC edesc c5227440 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c5227440 ALLOC edesc c5b69640 first transfer starting on channel 65565 ALLOC edesc c5b69b40 first transfer starting on channel 65565 ALLOC edesc c5233000 first transfer starting on channel 65565 ALLOC edesc c5233dc0 first transfer starting on channel 65565 ALLOC edesc c5233140 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c5233140 ALLOC edesc c5233140 first transfer starting on channel 65565 ALLOC edesc c5233280 first transfer starting on channel 65565 Transfer complete, stopping channel 29 FREE edesc c5233280 On 17.03.2015 13:38, Peter Ujfalusi wrote: Hi, On 03/16/2015 09:26 PM, Petr Kulhavy wrote: Hi, I have found a memory leak in the TI EDMA driver, which happens every time a DMA transfer is performed. The leak is in kernel 3.17, however the same problem seems to exist also in 3.19. I have issues booting the 3.17, 3.18 and 3.19 on my am335x-evmsk so I could only test this with 4.0-rc4 and linux-next. In particular this was found on our custom TI AM1808 based hardware while accessing the MMC/SD card interface. When extensively using the SD card (e.g. downloading files to it) you can virtually see the SUnreclaim memory in /proc/meminfo growing few kB every few seconds. I've done the test dd-ing to/from the mmc, running a recursive grep on the filesystem on the mmc. This should have generated enough edma requests. After few days of operation a device with 128MB of RAM renders unusable (lack of memory, system slow, processes being killed, etc.), the unreclaimed SLAB memory is over 50MB. The kernel memory leak debug mechanism revealed the leak to happen in edma_prep_slave_sg(), however the same pattern repeats all over the edma.c file (see below). unreferenced object 0xc5abe3c0 (size 128): comm mmcqd/0, pid 1099, jiffies 4294948151 (age 5865.330s) hex dump (first 32 bytes): b7 02 00 00 03 00 00 00 00 00 00 00 80 bb 81 c7 18 b4 23 c0 00 00 00 00 00 00 00 00 00 00 00 00 ..#. backtrace: [c023c8d0] edma_prep_slave_sg+0x98/0x344 [c030b350] mmc_davinci_request+0x3d4/0x53c [c02f86c8] mmc_start_request+0xc4/0xe8 [c02f9654] mmc_start_req+0x18c/0x354 [c0307c84] mmc_blk_issue_rw_rq+0xc0/0xc94 [c0308a0c] mmc_blk_issue_rq+0x1b4/0x4f4 [c0309648] mmc_queue_thread+0xb8/0x168 [c0034930] kthread+0xb4/0xd0 [c0009730] ret_from_fork+0x14/0x24
Re: [PATCH] ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
On Tue, Mar 17, 2015 at 11:34 AM, Tony Lindgren t...@atomide.com wrote: On 03/17/2015 11:26 AM, santosh shilimkar wrote: On 3/16/2015 4:30 PM, Tony Lindgren wrote: * Stefan Hengelein stefan.hengel...@fau.de [150225 10:48]: The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a contradiction in it's dependencies. The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be enabled. These options inherit a dependency from an enclosing menu, that requires ARCH_MULTIPLATFORM to be 'enabled'. This is a contradiction and made this option also unavailable for non-multiplatform configurations. Since there are no selects on OMAP4_ERRATA_I688, which would ignore dependencies, the code related to that option is dead and can be removed. This (logical) defect has been found with the undertaker tool. (https://undertaker.cs.fau.de) Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de --- Tony Lindgren suggested to remove the code since nobody complained for a few years and Santosh Shilimkar agreed. https://lkml.org/lkml/2015/2/25/449 --- As far as I see, this should remove all the code related to OMAP4_ERRATA_I688, I hope I didn't remove too much. Seems to boot fine, so applying into omap-for-v4.1/fixes-not-urgent. Acked-by: Santosh Shilimkar ssant...@kernel.org We no longer need i688? I do understand the need to cleanup the macros for multi-arch etc.. but loosing a bug workaround for a real silicon bug is really an invitation for hard to debug issues IMHO. Well that code has not been selectable for a few years now. Naturally we can add it back when it actually does something with multiarch. I suppose we are sure that downstream kernels that actually try stuff out never went ahead and enabled this.. we do have non multi-platform builds as well... I am just saying... having been around during the discovery of i688, I kinda know how much pain it takes to find the damn thing in the first place. a simple boot was not ever an easy enough test for it. I do suggest at least adding a print for omap4 saying that i688 is disabled.. -- --- 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 02/35 linux-next] regulator: constify of_device_id array
On 17 March 2015 at 13:11 Mark Brown broo...@kernel.org wrote: On Mon, Mar 16, 2015 at 08:17:08PM +0100, Fabian Frederick wrote: of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Applied, thanks. Please remember to always include people in the cover letter for patch serieses so they know what's going on with regard to dependencies and so on. Thanks Mark, I used a --cc-cmd script by Joe Perches with git send-email which uses --nom for cover-letter. This limits recipients to mailing lists: 37 instead of 123 in this case. I guess it's better to reduce the noise :) Regards, Fabian -- 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: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
* Nishanth Menon n...@ti.com [150317 09:57]: On Tue, Mar 17, 2015 at 11:34 AM, Tony Lindgren t...@atomide.com wrote: On 03/17/2015 11:26 AM, santosh shilimkar wrote: On 3/16/2015 4:30 PM, Tony Lindgren wrote: * Stefan Hengelein stefan.hengel...@fau.de [150225 10:48]: The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a contradiction in it's dependencies. The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be enabled. These options inherit a dependency from an enclosing menu, that requires ARCH_MULTIPLATFORM to be 'enabled'. This is a contradiction and made this option also unavailable for non-multiplatform configurations. Since there are no selects on OMAP4_ERRATA_I688, which would ignore dependencies, the code related to that option is dead and can be removed. This (logical) defect has been found with the undertaker tool. (https://undertaker.cs.fau.de) Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de --- Tony Lindgren suggested to remove the code since nobody complained for a few years and Santosh Shilimkar agreed. https://lkml.org/lkml/2015/2/25/449 --- As far as I see, this should remove all the code related to OMAP4_ERRATA_I688, I hope I didn't remove too much. Seems to boot fine, so applying into omap-for-v4.1/fixes-not-urgent. Acked-by: Santosh Shilimkar ssant...@kernel.org We no longer need i688? I do understand the need to cleanup the macros for multi-arch etc.. but loosing a bug workaround for a real silicon bug is really an invitation for hard to debug issues IMHO. Well that code has not been selectable for a few years now. Naturally we can add it back when it actually does something with multiarch. I suppose we are sure that downstream kernels that actually try stuff out never went ahead and enabled this.. we do have non multi-platform builds as well... I am just saying... having been around during the discovery of i688, I kinda know how much pain it takes to find the damn thing in the first place. a simple boot was not ever an easy enough test for it. I do suggest at least adding a print for omap4 saying that i688 is disabled.. Yes that's a good point and adding a printk is a good idea. Care to crank out a separate patch for that? 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 02/35 linux-next] regulator: constify of_device_id array
On Tue, Mar 17, 2015 at 06:10:12PM +0100, Fabian Frederick wrote: Thanks Mark, I used a --cc-cmd script by Joe Perches with git send-email which uses --nom for cover-letter. This limits recipients to mailing lists: 37 instead of 123 in this case. I guess it's better to reduce the noise :) Well, another thing to do if there's no dependencies is to just send each patch separately - there's no real relationship between the patches. This also avoids the issue. signature.asc Description: Digital signature
Re: [PATCH 0/2] Couple of dmtimer fixes
* Suman Anna s-a...@ti.com [150316 18:14]: Hi Tony, Please find couple of non-urgent fixes to the OMAP dmtimer driver. The patches are based on 4.0-rc1. The first patch is a fix for the issue I reported earlier on the DRA7 dmtimer hwmod patches [1]. DRA7 has timers 13 through 16 disabled in DT currently, and enabling any of them would cause a kernel hang. This fix properly checks the pm_runtime_get_sync() calls in the OMAP dmtimer driver irrespective of whether the hwmods are added or not. In the case that they are not added, the runtime_pm calls should return the value as returned from _od_fail_runtime_resume(), and the probe should bail out properly fixing the boot hang. Second patch is a minor fix that balances the pm_runtime_enable() call in probe with pm_runtime_disable() call in remove, so that the devices can be bound again properly after doing an unbind through sysfs. OK thanks applying both into omap-for-v4.0/fixes. Tony [1] http://marc.info/?l=linux-omapm=142653933112526w=2 Suman Anna (2): ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure ARM: OMAP: dmtimer: disable pm runtime on remove arch/arm/plat-omap/dmtimer.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) -- 2.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
* Nishanth Menon n...@ti.com [150317 10:18]: On Tue, Mar 17, 2015 at 12:10 PM, Tony Lindgren t...@atomide.com wrote: Yes that's a good point and adding a printk is a good idea. Care to crank out a separate patch for that? had hoped to have it part of this patch - does'nt that make more sense? Hmm well this patch removes code that's been dead for a few years.. I'd rather keep this as clean up, then merge what you're suggesting as a separate non-critical patch as that we could already do without removing this code. 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 3/4] ARM: dts: Add cppi41 support for dm816x MUSB
* Felipe Balbi ba...@ti.com [150317 17:32]: Hi, On Tue, Mar 17, 2015 at 05:19:20PM -0700, Tony Lindgren wrote: Looks like we have cppi41 on dm816x just like on am335x. Cc: Bin Liu binml...@gmail.com Cc: Brian Hutchinson b.hutch...@gmail.com Cc: Felipe Balbi ba...@ti.com Cc: Matthijs van Duin matthijsvand...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com Any logs available ? Any throughput improvements with DMA ? So far I only logged with the debug option on. I can do some test runs with your for-next branch to a USB mass storage device if you prefer that, or got some other test in mind? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
* Linus Walleij linus.wall...@linaro.org [150317 18:31]:
On Tue, Mar 10, 2015 at 7:33 PM, Nishanth Menon n...@ti.com wrote:
On 03/10/2015 12:31 PM, Tony Lindgren wrote:
Yes except I'd make use of some kind of #pinctrl-cells here just like
interrupt controller has #interrupt-cells. Then you can have the values
seprate and the controller knows what to do with them based on the
compatible flag and #pinctrl-cells.
Something like the following I suppose, where pinctrl-cells is optional?
dra7_pmx_core: pinmux@4a003400 {
compatible = ti,dra7-padconf, pinctrl-single;
reg = 0x4a003400 0x0464;
#address-cells = 1;
#size-cells = 0;
#interrupt-cells = 1;
interrupt-controller;
pinctrl-single,register-width = 32;
pinctrl-single,function-mask = 0x3fff;
};
dra7_iodelay_core: padconf@4844a000 {
compatible = ti,dra7-iodelay;
reg = 0x4844a000 0x0d1c;
#address-cells = 1;
#size-cells = 0;
#pinctrl-cells = 2;
};
Linus,
I hope you are ok with the above?
Hm depends on where the documentation hits I guess?
Such a generic cell count property has to be to the generic
pinctrl-bindings.txt document if I read it right.
Yeah agreed. I suggest discussing the binding and the generic
parsing code for it first :)
Overall I guess this will be acceptable but you really need to
reuse some more code between this driver and pinctrl-single.c
if I read it right.
It seems with the generic binding the actual driver should be
just the hardware specific code hopefully.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
On Tue, Mar 10, 2015 at 7:33 PM, Nishanth Menon n...@ti.com wrote:
On 03/10/2015 12:31 PM, Tony Lindgren wrote:
Yes except I'd make use of some kind of #pinctrl-cells here just like
interrupt controller has #interrupt-cells. Then you can have the values
seprate and the controller knows what to do with them based on the
compatible flag and #pinctrl-cells.
Something like the following I suppose, where pinctrl-cells is optional?
dra7_pmx_core: pinmux@4a003400 {
compatible = ti,dra7-padconf, pinctrl-single;
reg = 0x4a003400 0x0464;
#address-cells = 1;
#size-cells = 0;
#interrupt-cells = 1;
interrupt-controller;
pinctrl-single,register-width = 32;
pinctrl-single,function-mask = 0x3fff;
};
dra7_iodelay_core: padconf@4844a000 {
compatible = ti,dra7-iodelay;
reg = 0x4844a000 0x0d1c;
#address-cells = 1;
#size-cells = 0;
#pinctrl-cells = 2;
};
Linus,
I hope you are ok with the above?
Hm depends on where the documentation hits I guess?
Such a generic cell count property has to be to the generic
pinctrl-bindings.txt document if I read it right.
Overall I guess this will be acceptable but you really need to
reuse some more code between this driver and pinctrl-single.c
if I read it right.
Yours,
Linus Walleij
--
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/4] ARM: dts: Add cppi41 support for dm816x MUSB
Hi, On Tue, Mar 17, 2015 at 05:19:20PM -0700, Tony Lindgren wrote: Looks like we have cppi41 on dm816x just like on am335x. Cc: Bin Liu binml...@gmail.com Cc: Brian Hutchinson b.hutch...@gmail.com Cc: Felipe Balbi ba...@ti.com Cc: Matthijs van Duin matthijsvand...@gmail.com Signed-off-by: Tony Lindgren t...@atomide.com Any logs available ? Any throughput improvements with DMA ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/4] ARM: dts: Add minimal support for dm8168-evm
* Tony Lindgren t...@atomide.com [150202 08:15]:
* Matthijs van Duin matthijsvand...@gmail.com [150131 17:54]:
I just noticed the dm816x.dtsi says:
ocp {
compatible = ti,omap3-l3-smx, simple-bus;
This is incorrect: the DM81xx (and siblings like the AM335x) use
Arteris FlexNOC for the L3 interconnect, same as omap4/5 and vayu, not
SonicsMX. (In general everything on the DM81xx seems to be
omap4-generation)
Good catch, yes it seems it's mostly omap4. Looks like we
should also add it for am33xx.dtsi while at it.
I'll also check the devices one more time if I have some as
compatible with omap3 instead of omap4.
Hmm this is also broken on am33xx, and the following patch is needed.
And we also need to populate the tables along the lines of 27b7d5f3cc49
(bus: omap_l3_noc: Add AM4372 interconnect error data).
Do the below ranges match your JTAG results? I scanned them in u-boot
using md for the ranges where I found some related data.
That got me wondering if we can actually scan that data based
on the ranges below as target is 00130001 and flagmux 00370001.
We would be missing the names, but that would be still less data
to pile up in the kernel :) If some module is disabled, then it
should never produce errors so it seems safe to scan the data..
Can we dig even more info based on the RX port address at offset
0x10? That's the L3_TARG_STDHOSTHDR_NTTPADDR_0.
Or got any good ideas for populating the names?
Regards,
Tony
8 --
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -105,7 +105,10 @@
* the whole bus hierarchy.
*/
ocp {
- compatible = simple-bus;
+ compatible = ti,am335-l3-noc, simple-bus;
+ reg = 0x4400 0x1200
+ 0x4480 0x1000;
+ interrupts = 9 10;
#address-cells = 1;
#size-cells = 1;
ranges;
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -58,8 +58,10 @@
* the whole bus hierarchy.
*/
ocp {
- compatible = ti,omap4-l3-noc, simple-bus;
- reg = 0x4400 0x1;
+ compatible = ti,dm816-l3-noc, simple-bus;
+ reg = 0x4400 0x1200
+ 0x4440 0x1200
+ 0x4480 0x1000;
interrupts = 9 10;
#address-cells = 1;
#size-cells = 1;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] phy: Add a driver for dm816x USB PHY
Add a minimal driver for dm816x USB. This makes USB work on dm816x
without any other changes needed as it can use the existing musb_dsps
glue layer for the USB controller.
Note that this phy is different from dm814x and am335x.
Cc: Bin Liu binml...@gmail.com
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Cc: Matthijs van Duin matthijsvand...@gmail.com
Cc: Paul Bolle pebo...@tiscali.nl
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/phy/dm816x-phy.txt | 24 ++
drivers/phy/Kconfig| 7 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-dm816x-usb.c | 304 +
4 files changed, 336 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/dm816x-phy.txt
create mode 100644 drivers/phy/phy-dm816x-usb.c
diff --git a/Documentation/devicetree/bindings/phy/dm816x-phy.txt
b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
new file mode 100644
index 000..2fe3d11
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/dm816x-phy.txt
@@ -0,0 +1,24 @@
+Device tree binding documentation for am816x USB PHY
+=
+
+Required properties:
+- compatible : should be ti,dm816x-usb-phy
+- reg : offset and length of the PHY register set.
+- reg-names : name for the phy registers
+- clocks : phandle to the clock
+- clock-names : name of the clock
+- syscon: phandle for the syscon node to access misc registers
+- #phy-cells : from the generic PHY bindings, must be 1
+- syscon: phandle for the syscon node to access misc registers
+
+Example:
+
+usb_phy0: usb-phy@20 {
+ compatible = ti,dm8168-usb-phy;
+ reg = 0x20 0x8;
+ reg-names = phy;
+ clocks = main_fapll 6;
+ clock-names = refclk;
+ #phy-cells = 0;
+ syscon = scm_conf;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2962de2..c858c2b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -35,6 +35,13 @@ config ARMADA375_USBCLUSTER_PHY
depends on OF
select GENERIC_PHY
+config PHY_DM816X_USB
+ tristate TI dm816x USB PHY driver
+ depends on ARCH_OMAP2PLUS
+ select GENERIC_PHY
+ help
+ Enable this for dm81xx USB to work.
+
config PHY_EXYNOS_MIPI_VIDEO
tristate S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver
depends on HAS_IOMEM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f080e1b..dab6665 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
+obj-$(CONFIG_PHY_DM816X_USB) += phy-dm816x-usb.o
obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-dm816x-usb.c b/drivers/phy/phy-dm816x-usb.c
new file mode 100644
index 000..2fc276d
--- /dev/null
+++ b/drivers/phy/phy-dm816x-usb.c
@@ -0,0 +1,304 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/regmap.h
+
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+#include linux/phy/phy.h
+#include linux/of_platform.h
+
+#include linux/mfd/syscon.h
+
+/*
+ * TRM has two sets of USB_CTRL registers.. The correct register bits
+ * are in TRM section 24.9.8.2 USB_CTRL Register. The TRM documents the
+ * phy as being SR70LX Synopsys USB 2.0 OTG nanoPHY. It also seems at
+ * least dm816x rev c ignores writes to USB_CTRL register, but the TI
+ * kernel is writing to those so it's possible that later revisions
+ * have worknig USB_CTRL register.
+ *
+ * Also note that At least USB_CTRL register seems to be dm816x specific
+ * according to the TRM. It's possible that USBPHY_CTRL is more generic,
+ * but that would have to be checked against the SR70LX documentation
+ * which does not seem to be publicly available.
+ *
+ * Finally, the phy on dm814x and am335x is different from dm816x.
+ */
+#define DM816X_USB_CTRL_PHYCLKSRC BIT(8) /* 1 = PLL ref clock */
+#define DM816X_USB_CTRL_PHYSLEEP1 BIT(1) /* Enable the first phy */
+#define
[PATCH 2/4] ARM: dts: Fix typo for dm816x usb0_pins
Commit a54879a00859 (ARM: dts: Fix USB dts configuration for dm816x)
attempted to fix the USB features introduced by commit 7800064ba507
(ARM: dts: Add basic dm816x device tree configuration) but obviously
I did not read the dmesg as more USB issues still keep trickling in.
It should be usb1_pins instead not usb0_pins for the second interface
to avoid warnings from pinctrl framework.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Cc: Matthijs van Duin matthijsvand...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/dm8168-evm.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
index afe678f..b520a8b 100644
--- a/arch/arm/boot/dts/dm8168-evm.dts
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -52,13 +52,13 @@
usb0_pins: pinmux_usb0_pins {
pinctrl-single,pins =
- DM816X_IOPAD(0x0d00, MUX_MODE0) /*
USB0_DRVVBUS */
+ DM816X_IOPAD(0x0d04, MUX_MODE0) /*
USB0_DRVVBUS */
;
};
- usb1_pins: pinmux_usb0_pins {
+ usb1_pins: pinmux_usb1_pins {
pinctrl-single,pins =
- DM816X_IOPAD(0x0d04, MUX_MODE0) /*
USB1_DRVVBUS */
+ DM816X_IOPAD(0x0d08, MUX_MODE0) /*
USB1_DRVVBUS */
;
};
};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: Remove PIN_INPUT for dm816x McSPI
On dm816x we have no PIN_INPUT vs PIN_OUTPUT configuration, there
are just pulls. Let's remove the bogus flags.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Matthijs van Duin matthijsvand...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/dm8168-evm.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
index b520a8b..169a855 100644
--- a/arch/arm/boot/dts/dm8168-evm.dts
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -29,10 +29,10 @@
dm816x_pinmux {
mcspi1_pins: pinmux_mcspi1_pins {
pinctrl-single,pins =
- DM816X_IOPAD(0x0a94, PIN_INPUT | MUX_MODE0) /*
SPI_SCLK */
- DM816X_IOPAD(0x0a98, PIN_OUTPUT | MUX_MODE0)/*
SPI_SCS0 */
- DM816X_IOPAD(0x0aa8, PIN_INPUT | MUX_MODE0) /*
SPI_D0 */
- DM816X_IOPAD(0x0aac, PIN_INPUT | MUX_MODE0) /*
SPI_D1 */
+ DM816X_IOPAD(0x0a94, MUX_MODE0) /*
SPI_SCLK */
+ DM816X_IOPAD(0x0a98, MUX_MODE0) /*
SPI_SCS0 */
+ DM816X_IOPAD(0x0aa8, MUX_MODE0) /*
SPI_D0 */
+ DM816X_IOPAD(0x0aac, MUX_MODE0) /*
SPI_D1 */
;
};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: Fix gpio interrupts for dm816x
Commit 7800064ba507 (ARM: dts: Add basic dm816x device tree
configuration) added basic devices for dm816x, but I was not able
to test the GPIO interrupts earlier until I found some suitable pins
to test with. We can mux the MMC card detect and write protect pins
from SD_SDCD and SD_SDWP mode to use a normal GPIO interrupts that
are also suitable for the MMC subsystem.
This turned out several issues that need to be fixed:
- I set the GPIO type wrong to be compatible with omap3 instead
of omap4. The GPIO controller on dm816x has EOI interrupt
register like omap4 and am335x.
- I got the GPIO interrupt numbers wrong as each bank has two
and we only use one. They need to be set up the same way as
on am335x.
- The gpio banks are missing interrupt controller related
properties.
With these changes the GPIO interrupts can be used with the
MMC card detect pin, so let's wire that up. Let's also mux all
the MMC lines for completeness while at it.
For the first GPIO bank I tested using GPMC lines temporarily
muxed to GPIOs on the dip switch 10.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Matthijs van Duin matthijsvand...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/dm8168-evm.dts | 19 +++
arch/arm/boot/dts/dm816x.dtsi| 18 ++
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
index d3a29c1..afe678f 100644
--- a/arch/arm/boot/dts/dm8168-evm.dts
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -36,6 +36,20 @@
;
};
+ mmc_pins: pinmux_mmc_pins {
+ pinctrl-single,pins =
+ DM816X_IOPAD(0x0a70, MUX_MODE0) /*
SD_POW */
+ DM816X_IOPAD(0x0a74, MUX_MODE0) /*
SD_CLK */
+ DM816X_IOPAD(0x0a78, MUX_MODE0) /*
SD_CMD */
+ DM816X_IOPAD(0x0a7C, MUX_MODE0) /*
SD_DAT0 */
+ DM816X_IOPAD(0x0a80, MUX_MODE0) /*
SD_DAT1 */
+ DM816X_IOPAD(0x0a84, MUX_MODE0) /*
SD_DAT2 */
+ DM816X_IOPAD(0x0a88, MUX_MODE0) /*
SD_DAT2 */
+ DM816X_IOPAD(0x0a8c, MUX_MODE2) /*
GP1[7] */
+ DM816X_IOPAD(0x0a90, MUX_MODE2) /*
GP1[8] */
+ ;
+ };
+
usb0_pins: pinmux_usb0_pins {
pinctrl-single,pins =
DM816X_IOPAD(0x0d00, MUX_MODE0) /*
USB0_DRVVBUS */
@@ -137,7 +151,12 @@
};
mmc1 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc_pins;
vmmc-supply = vmmcsd_fixed;
+ bus-width = 4;
+ cd-gpios = gpio2 7 GPIO_ACTIVE_LOW;
+ wp-gpios = gpio2 8 GPIO_ACTIVE_LOW;
};
/* At least dm8168-evm rev c won't support multipoint, later may */
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 3c97b5f..f35715b 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -150,17 +150,27 @@
};
gpio1: gpio@48032000 {
- compatible = ti,omap3-gpio;
+ compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
+ ti,gpio-always-on;
reg = 0x48032000 0x1000;
- interrupts = 97;
+ interrupts = 96;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
};
gpio2: gpio@4804c000 {
- compatible = ti,omap3-gpio;
+ compatible = ti,omap4-gpio;
ti,hwmods = gpio2;
+ ti,gpio-always-on;
reg = 0x4804c000 0x1000;
- interrupts = 99;
+ interrupts = 98;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
};
gpmc: gpmc@5000 {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: Add cppi41 support for dm816x MUSB
Looks like we have cppi41 on dm816x just like on am335x.
Cc: Bin Liu binml...@gmail.com
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Felipe Balbi ba...@ti.com
Cc: Matthijs van Duin matthijsvand...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/dm816x.dtsi | 60 +++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index f35715b..de8427b 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -396,6 +396,29 @@
mentor,num-eps = 16;
mentor,ram-bits = 12;
mentor,power = 500;
+
+ dmas = cppi41dma 0 0 cppi41dma 1 0
+ cppi41dma 2 0 cppi41dma 3 0
+ cppi41dma 4 0 cppi41dma 5 0
+ cppi41dma 6 0 cppi41dma 7 0
+ cppi41dma 8 0 cppi41dma 9 0
+ cppi41dma 10 0 cppi41dma 11 0
+ cppi41dma 12 0 cppi41dma 13 0
+ cppi41dma 14 0 cppi41dma 0 1
+ cppi41dma 1 1 cppi41dma 2 1
+ cppi41dma 3 1 cppi41dma 4 1
+ cppi41dma 5 1 cppi41dma 6 1
+ cppi41dma 7 1 cppi41dma 8 1
+ cppi41dma 9 1 cppi41dma 10 1
+ cppi41dma 11 1 cppi41dma 12 1
+ cppi41dma 13 1 cppi41dma 14 1;
+ dma-names =
+ rx1, rx2, rx3, rx4, rx5,
rx6, rx7,
+ rx8, rx9, rx10, rx11, rx12,
rx13,
+ rx14, rx15,
+ tx1, tx2, tx3, tx4, tx5,
tx6, tx7,
+ tx8, tx9, tx10, tx11, tx12,
tx13,
+ tx14, tx15;
};
usb1: usb@47401800 {
@@ -413,6 +436,43 @@
mentor,num-eps = 16;
mentor,ram-bits = 12;
mentor,power = 500;
+
+ dmas = cppi41dma 15 0 cppi41dma 16 0
+ cppi41dma 17 0 cppi41dma 18 0
+ cppi41dma 19 0 cppi41dma 20 0
+ cppi41dma 21 0 cppi41dma 22 0
+ cppi41dma 23 0 cppi41dma 24 0
+ cppi41dma 25 0 cppi41dma 26 0
+ cppi41dma 27 0 cppi41dma 28 0
+ cppi41dma 29 0 cppi41dma 15 1
+ cppi41dma 16 1 cppi41dma 17 1
+ cppi41dma 18 1 cppi41dma 19 1
+ cppi41dma 20 1 cppi41dma 21 1
+ cppi41dma 22 1 cppi41dma 23 1
+ cppi41dma 24 1 cppi41dma 25 1
+ cppi41dma 26 1 cppi41dma 27 1
+ cppi41dma 28 1 cppi41dma 29 1;
+ dma-names =
+ rx1, rx2, rx3, rx4, rx5,
rx6, rx7,
+ rx8, rx9, rx10, rx11, rx12,
rx13,
+ rx14, rx15,
+ tx1, tx2, tx3, tx4, tx5,
tx6, tx7,
+ tx8, tx9, tx10, tx11, tx12,
tx13,
+ tx14, tx15;
+ };
+
+ cppi41dma: dma-controller@47402000 {
+ compatible = ti,am3359-cppi41;
+ reg = 0x4740 0x1000
+ 0x47402000 0x1000
+ 0x47403000 0x1000
+ 0x47404000 0x4000;
+ reg-names = glue, controller, scheduler,
queuemgr;
+ interrupts = 17;
+ interrupt-names = glue;
+ #dma-cells = 2;
+ #dma-channels = 30;
+ #dma-requests = 256;
};
};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Few dm816x fixes and improvments
Hi all, Here are few dm816x related fixes and improvments. Mostly to get GPIO interrupts working, and add DMA for the USB. Note that the USB still depends on the USB PHY driver posted in [PATCH v2] phy: Add a driver for dm816x USB PHY. Regards, Tony Tony Lindgren (4): ARM: dts: Fix gpio interrupts for dm816x ARM: dts: Fix typo for dm816x usb0_pins ARM: dts: Add cppi41 support for dm816x MUSB ARM: dts: Remove PIN_INPUT for dm816x McSPI arch/arm/boot/dts/dm8168-evm.dts | 33 + arch/arm/boot/dts/dm816x.dtsi| 78 +--- 2 files changed, 100 insertions(+), 11 deletions(-) -- 2.1.4 -- 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
omap voltage driver errors
Hello, I receive the following errors in boot: omap_voltage_early_init: voltage driver support not added regulator: core version 0.5 regulator: dummy: NET: Registered protocol family 16 omap_voltage_domain_lookup: Voltage driver init not yet happened.Faulting! omap_voltage_add_dev: VDD specified does not exist! . It seems that omap_voltage_early_init should be called somehow, but I don't see it being called anywhere in kernel. Is anyone familiar with this ? Regards, Ran -- 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 17.03.2015 um 11:37 schrieb Pavel Machek pa...@ucw.cz: Hi! to introduce coefficients for temperature and discharge rate? What do you mean? Nothing like that is used in current driver why do we need to add it? Well, conversion between Li-ion's voltage and state of charge at 0 current is well known: We can’t measure at 0 current since the OMAP is driven from battery and charger and may also draw some mA… Yes, but you know how many mA you are taking just now. So if you knew the internal resistance, you could compute the voltage at 0 current. (And it should also work during charging, as long as you know how much current is going in.) As far as I understand the twl4030 charger and MADC it is not possible to separate these values. It is only reporting the inflow from charger to battery + system. So you don’t know how many mA are supplying the system and how many mA are left over for charging. You can only assume how much the system is drawing while running (something between 50 and 600 mA but this depends on system activities, power state of peripherald and e.g. backlight being switched on). I think your basic assumption that we know any time how many mA the system is taking is not given. def percent(m, v): u = 0.0387-(1.4523*(3.7835-v)) if u 0: return 0 return (0.1966+math.sqrt(u))*100 And there's not much to calibrate there, and it should become library helper function; there's no need to write it to every single dts. The charge/discharge difference is due to internal battery resistance, and Ohm's law. (Then, you should not need different values for charging/discharging case.) Yes, and that also depends on the board and battery type. So you always need to specify some battery specific coefficient for that in the DT. Yes, and that coefficient should be internal battery resistance ;-). But where do you know this value from to write it into a DT file? Usually you can’t measure it easily and for some batteries you don’t have a data sheet. Contrary, the calibration curves can easily be measured on the device (assuming that the charge level decreases/increases linearly over time between Full and Empty). I tend to make software easy to use for the user (developer of a board support package) of a driver, not theoretically correct or mathematically elegant. We simply did choose a table, because calculating the right coefficients is more complex and getting the table values can easily be done from running one full charge-discharge-charge cycle. Well.. One set of coefficients would be kind of ok. But you are doing two, because it really depends on current, not charge/discharge. So why not do it right, for all currents…? Because the right solution for all these issues is to use a fuel gauge chip (bq27xxx). This driver is just for systems where the hardware designer did forget (or did not want to spend money) for such a chip, but user space expects some /sys/class/power_supply indication (e.g. Android/Replicant). The missing optimal precision is something we can live with. With your aproach, you'll get lower percentage when phone is under load vs. idle. Taking internal resistance into account would give you more precise readings. (Attached, old patch for zaurus shows the needed computation). This is why we have a charging and a discharging table to compensate for this effect. Yes, but there's very different current during idle phone and during call (for example). So yes, you are compensating for different current during charge and discharge, but it is possible to do better. I am not convinced that it can be really done better, considering the limitations of the twl4030 circuits, and I doubt that it is worth the efforts of doing it better. I guess this should go into library somewhere, because many machines need similar code. Is a library easier to maintain and handle than just a set of table values? I think so, yes, because otherwise you need a set of tables for each machine. Yes, but what is the problem? We have different device trees for each machine anyways. And as soon as they differ in battery characteristics the coefficients for your calculation have to be defined for each machine. So someone has to write in some DT values (difficult to understand and derive coefficients or two simple mapping tables). To me it looks as if you want to make it a 100% solution while I am happy with the 80% solution, which already exists as a platform data driver and just want to get it back into DT based boards. So I would suggest that Mareks patches to make the platform data driver DT compatible are applied first, and you are invited to submit a technically better solution for testing on real hardware. BR, Nikolaus -- 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
[RESEND PATCH 2/2] bus: ocp2scp: SYNC2 value should be changed to 0x6
As per the TRMs of AM572x, OMAP4430, OMAP4460, OMAP543x, the value of
SYNC2 must be set to 0x6 in order to ensure correct operation.
So modified the SYNC2 value of OCP2SCP TIMING register to 0x6 in all the
platforms that use OCP2SCP driver except AM437x. Also introduced a new
compatible property since we don't want to modify the OCP2SCP TIMING
register for AM437x.
The sections in TRM where the above caution can be found is mentioned below.
AM572x TRM SPRUHZ6 (http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf) under
section 26.3.2.2, table 26-26.
OMAP4430 TRM SWPU231AP (http://www.ti.com/lit/ug/swpu231ap/swpu231ap.pdf)
under section 23.12.6.2.2 , Table 23-1213.
OMAP4460 TRM SWPU235AB (http://www.ti.com/lit/ug/swpu235ab/swpu235ab.pdf)
under section 23.12.6.2.2, Table 23-1213.
OMAP543x TRM SWPU249 (http://www.ti.com/lit/pdf/swpu249)
under section 27.3.2.2, Table 27-27.
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Praneeth Bajjuri prane...@ti.com
---
drivers/bus/omap-ocp2scp.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index 723ec06..9f18569 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -16,6 +16,7 @@
*
*/
+#include linux/io.h
#include linux/module.h
#include linux/platform_device.h
#include linux/err.h
@@ -23,6 +24,9 @@
#include linux/of.h
#include linux/of_platform.h
+#define OCP2SCP_TIMING 0x18
+#define SYNC2_MASK 0xf
+
static int ocp2scp_remove_devices(struct device *dev, void *c)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -35,6 +39,9 @@ static int ocp2scp_remove_devices(struct device *dev, void *c)
static int omap_ocp2scp_probe(struct platform_device *pdev)
{
int ret;
+ u32 reg;
+ void __iomem *regs;
+ struct resource *res;
struct device_node *np = pdev-dev.of_node;
if (np) {
@@ -47,6 +54,32 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
}
pm_runtime_enable(pdev-dev);
+ /*
+* As per AM572x TRM: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf
+* under section 26.3.2.2, table 26-26 OCP2SCP TIMING Caution;
+* As per OMAP4430 TRM: http://www.ti.com/lit/ug/swpu231ap/swpu231ap.pdf
+* under section 23.12.6.2.2 , Table 23-1213 OCP2SCP TIMING Caution;
+* As per OMAP4460 TRM: http://www.ti.com/lit/ug/swpu235ab/swpu235ab.pdf
+* under section 23.12.6.2.2, Table 23-1213 OCP2SCP TIMING Caution;
+* As per OMAP543x TRM http://www.ti.com/lit/pdf/swpu249
+* under section 27.3.2.2, Table 27-27 OCP2SCP TIMING Caution;
+*
+* Read path of OCP2SCP is not working properly due to low reset value
+* of SYNC2 parameter in OCP2SCP. Suggested reset value is 0x6 or more.
+*/
+ if (!of_device_is_compatible(np, ti,am437x-ocp2scp)) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ regs = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(regs))
+ goto err0;
+
+ pm_runtime_get_sync(pdev-dev);
+ reg = readl_relaxed(regs + OCP2SCP_TIMING);
+ reg = ~(SYNC2_MASK);
+ reg |= 0x6;
+ writel_relaxed(reg, regs + OCP2SCP_TIMING);
+ pm_runtime_put_sync(pdev-dev);
+ }
return 0;
@@ -67,6 +100,7 @@ static int omap_ocp2scp_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id omap_ocp2scp_id_table[] = {
{ .compatible = ti,omap-ocp2scp },
+ { .compatible = ti,am437x-ocp2scp },
{}
};
MODULE_DEVICE_TABLE(of, omap_ocp2scp_id_table);
--
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
[RESEND PATCH 1/2] ARM: dts: am4372: Add ti,am437x-ocp2scp as compatible string for OCP2SCP
Added a new compatible string ti,am437x-ocp2scp for OCP2SCP module.
This is needed since except for the OCP2SCP used in AM437x, SYNC2 value
in OCP2SCP TIMING should be changed whereas the default value is sufficient
in AM437x.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt |3 ++-
arch/arm/boot/dts/am4372.dtsi |4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
index 63dd805..18729f6 100644
--- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -1,7 +1,8 @@
* OMAP OCP2SCP - ocp interface to scp interface
properties:
-- compatible : Should be ti,omap-ocp2scp
+- compatible : Should be ti,am437x-ocp2scp for AM437x processor
+ Should be ti,omap-ocp2scp for all others
- reg : Address and length of the register set for the device
- #address-cells, #size-cells : Must be present if the device has sub-nodes
- ranges : the child address space are mapped 1:1 onto the parent address space
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 1943fc3..286e317 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -787,7 +787,7 @@
};
ocp2scp0: ocp2scp@483a8000 {
- compatible = ti,omap-ocp2scp;
+ compatible = ti,am437x-ocp2scp, ti,omap-ocp2scp;
#address-cells = 1;
#size-cells = 1;
ranges;
@@ -806,7 +806,7 @@
};
ocp2scp1: ocp2scp@483e8000 {
- compatible = ti,omap-ocp2scp;
+ compatible = ti,am437x-ocp2scp, ti,omap-ocp2scp;
#address-cells = 1;
#size-cells = 1;
ranges;
--
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 02/35 linux-next] regulator: constify of_device_id array
On Mon, Mar 16, 2015 at 08:17:08PM +0100, Fabian Frederick wrote: of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Applied, thanks. Please remember to always include people in the cover letter for patch serieses so they know what's going on with regard to dependencies and so on. signature.asc Description: Digital signature
Re: [PATCH 0/2] regulator: TPS659038: Fixes for REGEN2 and REGEN3
On Tue, Mar 17, 2015 at 03:56:03PM +0530, Keerthy wrote: The series fixes couple of issues in the driver w.r.t TPS659038 PMICs. 1) Correcting the REGEN2_CTRL address. 2) REGEN3 is not present hence adding a check not to register for TPS659038. Applied both, thanks. regulator: palmas: Correct TPS659038 register definition for REGEN2 regulator: Palmas: Add has_regen3 check for TPS659038 Please try to keep the style of the subject lines consistent... signature.asc Description: Digital signature
Re: Serious memory leak in TI EDMA driver (drivers/dma/edma.c)
Hi,
On 03/16/2015 09:26 PM, Petr Kulhavy wrote:
Hi,
I have found a memory leak in the TI EDMA driver, which happens every time a
DMA transfer is performed.
The leak is in kernel 3.17, however the same problem seems to exist also in
3.19.
I have issues booting the 3.17, 3.18 and 3.19 on my am335x-evmsk so I could
only test this with 4.0-rc4 and linux-next.
In particular this was found on our custom TI AM1808 based hardware while
accessing the MMC/SD card interface.
When extensively using the SD card (e.g. downloading files to it) you can
virtually see the SUnreclaim memory in /proc/meminfo growing few kB every
few seconds.
I've done the test dd-ing to/from the mmc, running a recursive grep on the
filesystem on the mmc. This should have generated enough edma requests.
After few days of operation a device with 128MB of RAM renders unusable (lack
of memory, system slow, processes being killed, etc.), the unreclaimed SLAB
memory is over 50MB.
The kernel memory leak debug mechanism revealed the leak to happen in
edma_prep_slave_sg(), however the same pattern repeats all over the edma.c
file (see below).
unreferenced object 0xc5abe3c0 (size 128):
comm mmcqd/0, pid 1099, jiffies 4294948151 (age 5865.330s)
hex dump (first 32 bytes):
b7 02 00 00 03 00 00 00 00 00 00 00 80 bb 81 c7
18 b4 23 c0 00 00 00 00 00 00 00 00 00 00 00 00 ..#.
backtrace:
[c023c8d0] edma_prep_slave_sg+0x98/0x344
[c030b350] mmc_davinci_request+0x3d4/0x53c
[c02f86c8] mmc_start_request+0xc4/0xe8
[c02f9654] mmc_start_req+0x18c/0x354
[c0307c84] mmc_blk_issue_rw_rq+0xc0/0xc94
[c0308a0c] mmc_blk_issue_rq+0x1b4/0x4f4
[c0309648] mmc_queue_thread+0xb8/0x168
[c0034930] kthread+0xb4/0xd0
[c0009730] ret_from_fork+0x14/0x24
[] 0x
But I have not seen a single report from kmemleak suggesting edma.
The structure edma_desc is allocated using kzalloc in the edma_prep_slave_sg()
function, then a pointer to a member of its substructure
(dma_async_tx_descriptor) is returned.
Therefore the edma_desc structure cannot be freed since the allocated address
is nowhere stored and therefore lost.
the allocated edesc is freed up in edma_desc_free(), which is going to be
called either from vchan_dma_desc_free_list() or vchan_cookie_complete() when
we terminate the dma transfer or when the transfer is completed.
I also haven't found that the dma_async_tx_descriptor would be freed, but not
sure whether the kernel does this in some other place?
It is freed when the edesc is freed up since the dma_async_tx_descriptor is
part of the edma_desc :
struct edma_desc {
struct virt_dma_descvdesc;
...
};
struct virt_dma_desc {
struct dma_async_tx_descriptor tx;
/* protected by vc.lock */
struct list_head node;
};
and the vdesc-tx is returned from vchan_tx_prep().
Basically every time there is edma_prep_slave_sg 128 bytes of memory is
allocated but it's never freed.
I'm not sure what is the right way to fix this issue, but it seems to me that
the driver needs a more significant change to keep e.g. a pool of resources
which is reused and eventually freed, like some other EDMA drivers do.
Could you please advise what to do.
I can not reproduce the leak from edma driver, but I could get leaks from the
ethernet:
unreferenced object 0xcbe2f400 (size 176):
comm softirq, pid 0, jiffies 358465 (age 84.320s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 98 99 cb 00 00 00 00 00 00 00 00
backtrace:
[c04fc4c8] __alloc_rx_skb+0x58/0xdc
[c04fc564] __netdev_alloc_skb+0x18/0x40
[c045c750] cpsw_rx_handler+0x70/0x1c0
[c04599f8] __cpdma_chan_process+0xf0/0x130
[c0459a74] cpdma_chan_process+0x3c/0x5c
[c045bd20] cpsw_poll+0x28/0xd8
[c050ce34] net_rx_action+0x1d4/0x334
[c0042404] __do_softirq+0xd4/0x348
[c0042998] irq_exit+0xbc/0x130
[c0090b10] __handle_domain_irq+0x6c/0xe0
[c00086fc] omap_intc_handle_irq+0xb4/0xc4
[c05e3724] __irq_svc+0x44/0x5c
[c05e2f0c] _raw_spin_unlock_irqrestore+0x34/0x44
[c05e2f0c] _raw_spin_unlock_irqrestore+0x34/0x44
[c014fe94] scan_gray_list+0x150/0x18c
[c01500ec] kmemleak_scan+0x21c/0x4d8
by just pinging the board (ping -s 2000 192.168.1.120).
It might be possible that you are seeing this cpdma leak in the edma driver.
If you download and store it to mmc, this might be something which is plausible.
--
Péter
--
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 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! to introduce coefficients for temperature and discharge rate? What do you mean? Nothing like that is used in current driver why do we need to add it? Well, conversion between Li-ion's voltage and state of charge at 0 current is well known: We can’t measure at 0 current since the OMAP is driven from battery and charger and may also draw some mA… Yes, but you know how many mA you are taking just now. So if you knew the internal resistance, you could compute the voltage at 0 current. (And it should also work during charging, as long as you know how much current is going in.) As far as I understand the twl4030 charger and MADC it is not possible to separate these values. It is only reporting the inflow from charger to battery + system. So you don’t know how many mA are supplying the system and how many mA are left over for charging. You can only assume how much the system is drawing while running (something between 50 and 600 mA but this depends on system activities, power state of peripherald and e.g. backlight being switched on). I think your basic assumption that we know any time how many mA the system is taking is not given. So.. you won't be able to get exact value while charging, but you get one while discharging, which is what really matters...? Yes, and that coefficient should be internal battery resistance ;-). But where do you know this value from to write it into a DT file? Usually you can’t measure it easily and for some batteries you don’t have a data sheet. Contrary, the calibration curves can easily be measured on the device (assuming that the charge level decreases/increases linearly over time between Full and Empty). If you can copy it from the data sheet, that's the easiest option. If not, you should be able to easily compute it from the charge/discharge curves or from measured voltage at different loads. 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: [GIT PULL] OMAP-GPMC driver updates for v4.1
Hi Arnd, I think you might have missed this as I'm not in your usual list of maintainers :). So a gentle reminder. Please let me know if anything is not as per your requirements. cheers, -roger On 09/03/15 14:09, Roger Quadros wrote: Hi Arnd, Based on Tony's request I will be sending you pull requests for OMAP-GPMC driver hence forth. Please pull in these OMAP-GPMC driver fixes for v4.1. Patches have been tested for GPMC-NAND on dra7-evm and omap3-beagle. Thanks. The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: g...@github.com:rogerq/linux.git tags/gpmc-omap-for-v4.1 for you to fetch changes up to 4b613e9b4bbe94545a588a100e09006d827a7ebe: ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters (2015-03-06 12:55:32 +0200) OMAP-GPMC driver fixes for v4.1 * Fixed WAITMONITORINGTIME programming to be based on GPMC_CLK instead of GPMC_FCLK. The GPMC clock divider programming is fixed for both synchronous and asynchronous modes. * Allow GPMC's children of default bus type to be populated in the device tree. * Improved DEBUG output data and format. * Prevent writing 1 into reserved bits of GPMC_CONFIG7. Robert ABEL (8): ARM OMAP2+ GPMC: don't undef DEBUG ARM OMAP2+ GPMC: add bus children ARM OMAP2+ GPMC: fix debug output alignment ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters Semen Protsenko (2): ARM: OMAP2+: gpmc: Fix writing in gpmc_cs_set_memconf ARM: OMAP2+: gpmc: make gpmc_cs_get_name() static arch/arm/mach-omap2/gpmc-nand.c| 18 + arch/arm/mach-omap2/gpmc-onenand.c | 4 +- arch/arm/mach-omap2/usb-tusb6010.c | 4 +- drivers/memory/omap-gpmc.c | 358 +++- include/linux/omap-gpmc.h | 3 +- 5 files changed, 305 insertions(+), 82 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 17.03.2015 um 14:59 schrieb Pavel Machek pa...@ucw.cz: Hi! to introduce coefficients for temperature and discharge rate? What do you mean? Nothing like that is used in current driver why do we need to add it? Well, conversion between Li-ion's voltage and state of charge at 0 current is well known: We can’t measure at 0 current since the OMAP is driven from battery and charger and may also draw some mA… Yes, but you know how many mA you are taking just now. So if you knew the internal resistance, you could compute the voltage at 0 current. (And it should also work during charging, as long as you know how much current is going in.) As far as I understand the twl4030 charger and MADC it is not possible to separate these values. It is only reporting the inflow from charger to battery + system. So you don’t know how many mA are supplying the system and how many mA are left over for charging. You can only assume how much the system is drawing while running (something between 50 and 600 mA but this depends on system activities, power state of peripherald and e.g. backlight being switched on). I think your basic assumption that we know any time how many mA the system is taking is not given. So.. you won't be able to get exact value while charging, but you get one while discharging, which is what really matters…? Is it the same during charging? And, as we already discussed it depends on the situation. In addition, GSM power consumption runs in bursts and I don’t know if the sample rate of the MADC is good enough to track that correctly. Yes, and that coefficient should be internal battery resistance ;-). But where do you know this value from to write it into a DT file? Usually you can’t measure it easily and for some batteries you don’t have a data sheet. Contrary, the calibration curves can easily be measured on the device (assuming that the charge level decreases/increases linearly over time between Full and Empty). If you can copy it from the data sheet, that's the easiest option. If not, you should be able to easily compute it from the charge/discharge curves or from measured voltage at different loads. Well, this again assumes that you can generate/control different loads easily (e.g. turn on/off this and that peripheral) to check the voltage drop. Sounds good in theory, but I don’t want to do it in practice to derive this parameter. And, don’t forget that the MADC signals are nosiy and don’t have the best precision. So it is likely that you get wrong values. As said, I think it is not worth the effort around the imperfect twl4030/MADC charging system. If someone wants precise data, that is what fuel gauge chips are good for. And we already have drivers for them. BR, Nikolaus -- 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: dra7x-evm: beagle-x14: Fix USB Peripheral
Hi, On Tue, Mar 17, 2015 at 11:43:51AM +0200, Roger Quadros wrote: Now that we have EXTCON_USB_GPIO queued for v4.1, revert commit addfcde7c485 (ARM: dts: dra7x-evm: beagle-x15: Fix USB Host) On these EVMs, the USB cable state has to be determined via the ID pin tied to a GPIO line. We use the gpio-usb-extcon driver to read the ID pin and the extcon framework to forward the USB cable state information to the USB driver so the controller can be configured in the right mode (host/peripheral). Gets USB peripheral mode to work on this EVM. Signed-off-by: Roger Quadros rog...@ti.com on subject: x14 ? other than that Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
[PATCH] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used
Set a rule constraints to allow only combinations of sample-rate and
number of frame-bits that can be played/captured with a reasonable
sample-rate accuracy.
Also, takes the number of serializers into account when implicitly
selecting the BLCK divider.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
Now this works as it should.
Thanks,
Jyri
sound/soc/davinci/davinci-mcasp.c | 150 +++---
1 file changed, 140 insertions(+), 10 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index de3b155..3ecee3b 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/of_platform.h
#include linux/of_device.h
+#include linux/math64.h
#include sound/asoundef.h
#include sound/core.h
@@ -64,6 +65,11 @@ struct davinci_mcasp_context {
u32 *xrsr_regs; /* for serializer configuration */
};
+struct davinci_mcasp_ruledata {
+ struct davinci_mcasp *mcasp;
+ int serializers;
+};
+
struct davinci_mcasp {
struct davinci_pcm_dma_params dma_params[2];
struct snd_dmaengine_dai_dma_data dma_data[2];
@@ -98,6 +104,8 @@ struct davinci_mcasp {
#ifdef CONFIG_PM_SLEEP
struct davinci_mcasp_context context;
#endif
+
+ struct davinci_mcasp_ruledata ruledata[2];
};
static inline void mcasp_set_bits(struct davinci_mcasp *mcasp, u32 offset,
@@ -855,6 +863,30 @@ static int mcasp_dit_hw_param(struct davinci_mcasp *mcasp,
return 0;
}
+static int davinci_mcasp_calc_clk_div(struct davinci_mcasp *mcasp,
+ unsigned int bclk_freq,
+ int *error_ppm)
+{
+ int div = mcasp-sysclk_freq / bclk_freq;
+ int rem = mcasp-sysclk_freq % bclk_freq;
+
+ if (rem != 0) {
+ if (div == 0 ||
+ ((mcasp-sysclk_freq / div) - bclk_freq)
+ (bclk_freq - (mcasp-sysclk_freq / (div+1 {
+ div++;
+ rem = rem - bclk_freq;
+ }
+ }
+ if (error_ppm)
+ *error_ppm =
+ (div*100 + (int)div64_long(100LL*rem,
+ (int)bclk_freq))
+ /div - 100;
+
+ return div;
+}
+
static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *cpu_dai)
@@ -872,16 +904,19 @@ static int davinci_mcasp_hw_params(struct
snd_pcm_substream *substream,
* the machine driver, we need to calculate the ratio.
*/
if (mcasp-bclk_master mcasp-bclk_div == 0 mcasp-sysclk_freq) {
- unsigned int bclk_freq = snd_soc_params_to_bclk(params);
- unsigned int div = mcasp-sysclk_freq / bclk_freq;
- if (mcasp-sysclk_freq % bclk_freq != 0) {
- if (((mcasp-sysclk_freq / div) - bclk_freq)
- (bclk_freq - (mcasp-sysclk_freq / (div+1
- div++;
- dev_warn(mcasp-dev,
-Inaccurate BCLK: %u Hz / %u != %u Hz\n,
-mcasp-sysclk_freq, div, bclk_freq);
- }
+ uint bclk_freq = snd_soc_params_to_bclk(params);
+ int dir = substream-stream == SNDRV_PCM_STREAM_PLAYBACK ?
+ TX_MODE : RX_MODE;
+ int ppm, div;
+
+ bclk_freq /= mcasp-ruledata[dir].serializers;
+
+ div = davinci_mcasp_calc_clk_div(mcasp, bclk_freq, ppm);
+
+ if (ppm)
+ dev_info(mcasp-dev, Sample-rate is off by %d PPM\n,
+ppm);
+
__davinci_mcasp_set_clkdiv(cpu_dai, 1, div, 0);
}
@@ -973,6 +1008,74 @@ static int davinci_mcasp_trigger(struct snd_pcm_substream
*substream,
return ret;
}
+static const unsigned int davinci_mcasp_dai_rates[] = {
+ 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000,
+ 88200, 96000, 176400, 192000,
+};
+
+#define DAVINCI_MAX_RATE_ERROR_PPM 1000
+
+static int davinci_mcasp_hw_rule_rate(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+ struct davinci_mcasp_ruledata *rd = rule-private;
+ unsigned int list[ARRAY_SIZE(davinci_mcasp_dai_rates)];
+ int frame_size;
+ int i, count = 0;
+
+ frame_size = snd_soc_params_to_frame_size(params);
+ if (frame_size 0)
+ return frame_size;
+
+ for (i = 0; i ARRAY_SIZE(davinci_mcasp_dai_rates); i++) {
+ uint bclk_freq = frame_size*davinci_mcasp_dai_rates[i]/
+ rd-serializers;
+ int ppm;
+
+
Re: [PATCH] ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
On 3/16/2015 4:30 PM, Tony Lindgren wrote: * Stefan Hengelein stefan.hengel...@fau.de [150225 10:48]: The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a contradiction in it's dependencies. The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be enabled. These options inherit a dependency from an enclosing menu, that requires ARCH_MULTIPLATFORM to be 'enabled'. This is a contradiction and made this option also unavailable for non-multiplatform configurations. Since there are no selects on OMAP4_ERRATA_I688, which would ignore dependencies, the code related to that option is dead and can be removed. This (logical) defect has been found with the undertaker tool. (https://undertaker.cs.fau.de) Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de --- Tony Lindgren suggested to remove the code since nobody complained for a few years and Santosh Shilimkar agreed. https://lkml.org/lkml/2015/2/25/449 --- As far as I see, this should remove all the code related to OMAP4_ERRATA_I688, I hope I didn't remove too much. Seems to boot fine, so applying into omap-for-v4.1/fixes-not-urgent. Acked-by: Santosh Shilimkar ssant...@kernel.org -- 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: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
* Nishanth Menon n...@ti.com [150317 09:32]: On 03/17/2015 11:26 AM, santosh shilimkar wrote: On 3/16/2015 4:30 PM, Tony Lindgren wrote: * Stefan Hengelein stefan.hengel...@fau.de [150225 10:48]: The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a contradiction in it's dependencies. The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be enabled. These options inherit a dependency from an enclosing menu, that requires ARCH_MULTIPLATFORM to be 'enabled'. This is a contradiction and made this option also unavailable for non-multiplatform configurations. Since there are no selects on OMAP4_ERRATA_I688, which would ignore dependencies, the code related to that option is dead and can be removed. This (logical) defect has been found with the undertaker tool. (https://undertaker.cs.fau.de) Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de --- Tony Lindgren suggested to remove the code since nobody complained for a few years and Santosh Shilimkar agreed. https://lkml.org/lkml/2015/2/25/449 --- As far as I see, this should remove all the code related to OMAP4_ERRATA_I688, I hope I didn't remove too much. Seems to boot fine, so applying into omap-for-v4.1/fixes-not-urgent. Acked-by: Santosh Shilimkar ssant...@kernel.org We no longer need i688? I do understand the need to cleanup the macros for multi-arch etc.. but loosing a bug workaround for a real silicon bug is really an invitation for hard to debug issues IMHO. Well that code has not been selectable for a few years now. Naturally we can add it back when it actually does something with multiarch. 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
