Re: [PATCH v4 4/6] ARM: dts: omap3-gta04: Add battery support
* Marek Belisko ma...@goldelico.com [150310 14:28]:
Added battery support for gta04 devices.
Signed-off-by: Marek Belisko ma...@goldelico.com
Picking up this patch into omap-for-v4.1/dt branch thanks.
Tony
---
arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index fb3a696..cbf515a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -49,6 +49,32 @@
ti,codec = twl_audio;
};
+ battery {
+ compatible = ti,twl4030-madc-battery;
+ capacity-uah = 120;
+ ti,volt-to-capacity-charging-map = 4200 100,
+ 4100 75,
+ 4000 55,
+ 3900 25,
+ 3800 5,
+ 3700 2,
+ 3600 1,
+ 3300 0;
+ ti,volt-to-capacity-discharging-map = 4200 100,
+ 4100 95,
+ 4000 70,
+ 3800 50,
+ 3700 10,
+ 3600 5,
+ 3300 0;
+ io-channels = twl_madc 1,
+ twl_madc 10,
+ twl_madc 12;
+ io-channel-names = temp,
+ichg,
+vbat;
+ };
+
spi_lcd {
compatible = spi-gpio;
#address-cells = 0x1;
@@ -518,3 +544,7 @@
mcbsp2 {
status = okay;
};
+
+twl_madc {
+ ti,system-uses-second-madc-irq;
+};
--
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 v6 6/6] wlcore: remove wl12xx_platform_data
On Monday 16 March 2015 16:29:39 Tony Lindgren wrote: I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali. No. In DT boot there is missing /proc/atags file (readable by userspace processes). And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek pa...@ucw.cz wrote: On Wed 2015-02-04 23:14:32, Marek Belisko wrote: Signed-off-by: Marek Belisko ma...@goldelico.com --- .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 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. + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values + for charging calibration (see example) + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values + for discharging calibration (see example) Would mV-to-capacity... be more accurate? Also, would it make sense Again maybe mv but it can be added also later. 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? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [1] - http://lists.openwall.net/linux-kernel/2014/10/09/104 BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP3: Remove legacy support for EMA-Tech Stalker board
We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree. As it seems this board only has minimal support upstreamed for the legacy booting and has not seen activity for on the mailing lists for a few years, let's attempt to remove the related legacy board-*.c file. I do not have this board, but it seems getting the same level of support with device tree based booting is mostly just configuring the .dts file. And there is no need to upgrade the boot loader as we can boot with appended DTB too. And most of the omap3 boards seem to be related to omap3-evm, and omap3beagleboard that are supported with device tree based booting. If somebody is using this board actively with the mainline kernel, please communicate this to the linux-omap mailing list so we can get the board booting with device tree based support. I can help some too getting the minimal device tree based booting going if help is needed. The reason for attempting to remove this board now is that I'd rather get the remaining omap3 legacy booting support into a known state where we at least have a .dts file being written for the remaining legacy boards. That is because for the next few merge cycles we can still revert this patch if absolutely necessary, but I'd rather not get suprised by missing .dts files at the point where we are ready to drop all remaining omap3 legacy booting support later on. Also looks like this board is no longer listed on ema-tech.com product page at: http://ema-tech.com/en/categories.html Cc: Jason Lam l...@ema-tech.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig | 6 - arch/arm/mach-omap2/Makefile | 2 - arch/arm/mach-omap2/board-omap3stalker.c | 433 --- 3 files changed, 441 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-omap3stalker.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 2b8e477..88e3eaf 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -260,12 +260,6 @@ config MACH_CM_T35 config MACH_CM_T3730 bool -config MACH_SBC3530 - bool OMAP3 SBC STALKER board - depends on ARCH_OMAP3 - default y - select OMAP_PACKAGE_CUS - config OMAP3_SDRC_AC_TIMING bool Enable SDRC AC timing register changes depends on ARCH_OMAP3 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index b83f18f..10b9563 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -256,8 +256,6 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-video.o obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o obj-$(CONFIG_MACH_TOUCHBOOK) += board-omap3touchbook.o -obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o - # Platform specific device init code omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o diff --git a/arch/arm/mach-omap2/board-omap3stalker.c b/arch/arm/mach-omap2/board-omap3stalker.c deleted file mode 100644 index 6311f4b..000 --- a/arch/arm/mach-omap2/board-omap3stalker.c +++ /dev/null @@ -1,433 +0,0 @@ -/* - * linux/arch/arm/mach-omap2/board-omap3evm.c - * - * Copyright (C) 2008 Guangzhou EMA-Tech - * - * Modified from mach-omap2/board-omap3evm.c - * - * Initial code: Syed Mohammed Khasim - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include linux/kernel.h -#include linux/init.h -#include linux/platform_device.h -#include linux/delay.h -#include linux/err.h -#include linux/clk.h -#include linux/io.h -#include linux/leds.h -#include linux/gpio.h -#include linux/input.h -#include linux/gpio_keys.h - -#include linux/regulator/fixed.h -#include linux/regulator/machine.h -#include linux/i2c/twl.h -#include linux/mmc/host.h -#include linux/input/matrix_keypad.h -#include linux/spi/spi.h -#include linux/interrupt.h -#include linux/smsc911x.h -#include linux/platform_data/at24.h -#include linux/usb/phy.h - -#include asm/mach-types.h -#include asm/mach/arch.h -#include asm/mach/map.h -#include asm/mach/flash.h - -#include common.h -#include gpmc.h -#include linux/platform_data/mtd-nand-omap2.h -#include video/omapdss.h -#include video/omap-panel-data.h - -#include linux/platform_data/spi-omap2-mcspi.h - -#include sdram-micron-mt46h32m32lf-6.h -#include mux.h -#include hsmmc.h -#include common-board-devices.h - -#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE) -#include gpmc-smsc911x.h - -#define OMAP3STALKER_ETHR_START0x2c00 -#define OMAP3STALKER_ETHR_SIZE 1024 -#define OMAP3STALKER_ETHR_GPIO_IRQ 19 -#define OMAP3STALKER_SMC911X_CS5 - -static struct
Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data
On Monday 16 March 2015 22:01:43 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150316 13:59]: On Monday 16 March 2015 16:29:39 Tony Lindgren wrote: I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali. No. In DT boot there is missing /proc/atags file (readable by userspace processes). Oh OK thanks for the update. And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent. But this is not a regression in mainline with legacy boot vs device tree based booting, right? Sounds like it never worked in the mainline or am thinking of some other set of patches? Regards, Tony In legacy board code are DMA channels defined. In DT files not. So I think this is regression. Omap secure devices are broken in both legacy DT code, but non secure could work with legacy code. But all devices booted with DT are broken. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Am 16.03.2015 um 22:20 schrieb Belisko Marek marek.beli...@gmail.com: On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek pa...@ucw.cz wrote: On Wed 2015-02-04 23:14:32, Marek Belisko wrote: Signed-off-by: Marek Belisko ma...@goldelico.com --- .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 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. + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values + for charging calibration (see example) + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values + for discharging calibration (see example) Would mV-to-capacity... be more accurate? Also, would it make sense Again maybe mv but it can be added also later. 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? 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. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [1] - http://lists.openwall.net/linux-kernel/2014/10/09/104 BR, marek 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 06/10] ARM: dts: omap3: Add missing dmas for crypto
* Pavel Machek pa...@ucw.cz [150228 08:49]: On Thu 2015-02-26 14:49:56, Pali Rohár wrote: This patch adds missing dma DTS definitions for omap aes and sham drivers. Without it kernel drivers do not work. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: PavelMachek pa...@ucw.cz Applying this into omap-for-v4.0/fixes to remove the regression for legacy vs DT based booting for GP omap3 boards. 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 14/15] omap3isp: Add support for the Device Tree
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:26:09 Sakari Ailus wrote:
Add the ISP device to omap3 DT include file and add support to the driver to
use it.
Also obtain information on the external entities and the ISP configuration
related to them through the Device Tree in addition to the platform data.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/platform/omap3isp/isp.c | 209 ++--
drivers/media/platform/omap3isp/isp.h | 11 ++
drivers/media/platform/omap3isp/ispcsiphy.c |7 +
3 files changed, 215 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index 992e74c..0d6012a 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -64,6 +64,7 @@
#include media/v4l2-common.h
#include media/v4l2-device.h
+#include media/v4l2-of.h
#include isp.h
#include ispreg.h
@@ -1991,6 +1992,14 @@ static int isp_register_entities(struct isp_device
*isp) if (ret 0)
goto done;
+ /*
+ * Device Tree --- the external of the sub-devices will be
What do you mean by the external of the sub-devices ?
+ * registered later. Same goes for the sub-device node
+ * registration.
+ */
+ if (isp-dev-of_node)
+ return 0;
+
/* Register external entities */
for (isp_subdev = pdata ? pdata-subdevs : NULL;
isp_subdev isp_subdev-board_info; isp_subdev++) {
@@ -2016,8 +2025,10 @@ static int isp_register_entities(struct isp_device
*isp) ret = v4l2_device_register_subdev_nodes(isp-v4l2_dev);
done:
- if (ret 0)
+ if (ret 0) {
isp_unregister_entities(isp);
+ v4l2_async_notifier_unregister(isp-notifier);
+ }
return ret;
}
@@ -2232,6 +2243,7 @@ static int isp_remove(struct platform_device *pdev)
{
struct isp_device *isp = platform_get_drvdata(pdev);
+ v4l2_async_notifier_unregister(isp-notifier);
isp_unregister_entities(isp);
isp_cleanup_modules(isp);
isp_xclk_cleanup(isp);
@@ -2243,6 +2255,151 @@ static int isp_remove(struct platform_device *pdev)
return 0;
}
+enum isp_of_phy {
+ ISP_OF_PHY_PARALLEL = 0,
+ ISP_OF_PHY_CSIPHY1,
+ ISP_OF_PHY_CSIPHY2,
+};
+
+static int isp_of_parse_node(struct device *dev, struct device_node *node,
+ struct isp_async_subdev *isd)
+{
+ struct isp_bus_cfg *buscfg = isd-bus;
+ struct v4l2_of_endpoint vep;
+ unsigned int i;
+
+ v4l2_of_parse_endpoint(node, vep);
+
+ dev_dbg(dev, interface %u\n, vep.base.port);
The message seems a bit terse to me, I would also print the endpoint node name
to give a bit of context.
dev_dbg(dev, parsing endpoint %s, interface %u\n, node-full_name,
vep.base.port);
+
+ switch (vep.base.port) {
+ case ISP_OF_PHY_PARALLEL:
+ buscfg-interface = ISP_INTERFACE_PARALLEL;
+ buscfg-bus.parallel.data_lane_shift =
+ vep.bus.parallel.data_shift;
+ buscfg-bus.parallel.clk_pol =
+ !!(vep.bus.parallel.flags
+ V4L2_MBUS_PCLK_SAMPLE_FALLING);
+ buscfg-bus.parallel.hs_pol =
+ !!(vep.bus.parallel.flags V4L2_MBUS_VSYNC_ACTIVE_LOW);
+ buscfg-bus.parallel.vs_pol =
+ !!(vep.bus.parallel.flags V4L2_MBUS_HSYNC_ACTIVE_LOW);
+ buscfg-bus.parallel.fld_pol =
+ !!(vep.bus.parallel.flags V4L2_MBUS_FIELD_EVEN_LOW);
+ buscfg-bus.parallel.data_pol =
+ !!(vep.bus.parallel.flags V4L2_MBUS_DATA_ACTIVE_LOW);
+ break;
+
+ case ISP_OF_PHY_CSIPHY1:
+ case ISP_OF_PHY_CSIPHY2:
+ /* FIXME: always assume CSI-2 for now. */
+ switch (vep.base.port) {
+ case ISP_OF_PHY_CSIPHY1:
I'd use an if - else here, but that's up to you.
+ buscfg-interface = ISP_INTERFACE_CSI2C_PHY1;
+ break;
+ case ISP_OF_PHY_CSIPHY2:
+ buscfg-interface = ISP_INTERFACE_CSI2A_PHY2;
+ break;
+ }
+ buscfg-bus.csi2.lanecfg.clk.pos = vep.bus.mipi_csi2.clock_lane;
+ buscfg-bus.csi2.lanecfg.clk.pol =
+ vep.bus.mipi_csi2.lane_polarity[0];
+ dev_dbg(dev, clock lane polarity %u, pos %u\n,
+ buscfg-bus.csi2.lanecfg.clk.pol,
+ buscfg-bus.csi2.lanecfg.clk.pos);
+
+ for (i = 0; i ISP_CSIPHY2_NUM_DATA_LANES; i++) {
+ buscfg-bus.csi2.lanecfg.data[i].pos =
+ vep.bus.mipi_csi2.data_lanes[i];
+ buscfg-bus.csi2.lanecfg.data[i].pol =
+
Re: [PATCH 15/15] omap3isp: Deprecate platform data support
Hi Sakari, Thank you for the patch. On Monday 16 March 2015 02:26:10 Sakari Ailus wrote: Print a warning when the driver is used with platform data. Existing platform data user should move to DT now. s/user/users/ Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/platform/omap3isp/isp.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index 0d6012a..82940fe 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2447,6 +2447,8 @@ static int isp_probe(struct platform_device *pdev) isp-syscon = syscon_regmap_lookup_by_pdevname(syscon.0); if (IS_ERR(isp-syscon)) return PTR_ERR(isp-syscon); + dev_warn(pdev-dev, + Platform data support is deprecated! Please move to DT now! \n); } isp-autoidle = autoidle; -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
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 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.
I have plan to use standard cable name for extcon driver instead of that
each extcon driver define the cable name.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP2+: Remove legacy support for omap3 TouchBook
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.
As it seems this board only has minimal support upstreamed for the
legacy booting and has not seen activity for on the mailing lists
for a few years, let's attempt to remove the related legacy board-*.c
file.
I do not have this board, but it seems getting the same level of
support with device tree based booting is mostly just configuring
the .dts file. And there is no need to upgrade the boot loader as
we can boot with appended DTB too. And most of the omap3 boards
seem to be related to omap3-evm, and omap3beagleboard that are
supported with device tree based booting.
If somebody is using this board actively with the mainline kernel,
please communicate this to the linux-omap mailing list so we can
get the board booting with device tree based support. I can help
some too getting the minimal device tree based booting going if
help is needed.
The reason for attempting to remove this board now is that I'd
rather get the remaining omap3 legacy booting support into a known
state where we at least have a .dts file being written for the
remaining legacy boards. That is because for the next few merge
cycles we can still revert this patch if absolutely necessary,
but I'd rather not get suprised by missing .dts files at the point
where we are ready to drop all remaining omap3 legacy booting
support later on.
Cc: Gregoire Gentil grego...@gentil.com
Cc: Radek Pilar mr...@mrkva.eu
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig| 6 -
arch/arm/mach-omap2/Makefile | 1 -
arch/arm/mach-omap2/board-omap3touchbook.c | 395 -
3 files changed, 402 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-omap3touchbook.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 559e287..276a755 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -219,12 +219,6 @@ config MACH_OMAP3_PANDORA
select OMAP_PACKAGE_CBB
select REGULATOR_FIXED_VOLTAGE if REGULATOR
-config MACH_TOUCHBOOK
- bool OMAP3 Touch Book
- depends on ARCH_OMAP3
- default y
- select OMAP_PACKAGE_CBB
-
config MACH_NOKIA_N810
bool
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c346b48..ec002bd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -253,7 +253,6 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
sdram-nokia.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-peripherals.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-video.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o
-obj-$(CONFIG_MACH_TOUCHBOOK) += board-omap3touchbook.o
# Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c
b/arch/arm/mach-omap2/board-omap3touchbook.c
deleted file mode 100644
index a01993e..000
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ /dev/null
@@ -1,395 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/board-omap3touchbook.c
- *
- * Copyright (C) 2009 Always Innovating
- *
- * Modified from mach-omap2/board-omap3beagleboard.c
- *
- * Initial code: Grégoire Gentil, Tim Yamin
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/delay.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/leds.h
-#include linux/gpio.h
-#include linux/input.h
-#include linux/gpio_keys.h
-
-#include linux/mtd/mtd.h
-#include linux/mtd/partitions.h
-#include linux/mtd/nand.h
-#include linux/mmc/host.h
-#include linux/usb/phy.h
-
-#include linux/platform_data/spi-omap2-mcspi.h
-#include linux/spi/spi.h
-
-#include linux/spi/ads7846.h
-
-#include linux/regulator/machine.h
-#include linux/i2c/twl.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-#include asm/mach/flash.h
-#include asm/system_info.h
-
-#include common.h
-#include gpmc.h
-#include linux/platform_data/mtd-nand-omap2.h
-
-#include mux.h
-#include hsmmc.h
-#include board-flash.h
-#include common-board-devices.h
-
-#include asm/setup.h
-
-#define OMAP3_AC_GPIO 136
-#define OMAP3_TS_GPIO 162
-#define TB_BL_PWM_TIMER9
-#define TB_KILL_POWER_GPIO 168
-
-#defineNAND_CS 0
-
-static unsigned long touchbook_revision;
-
-static struct mtd_partition omap3touchbook_nand_partitions[] = {
- /* All the partition sizes are listed in terms of NAND block size */
- {
- .name =
[PATCH 2/3] ARM: OMAP3: Remove legacy support for devkit8000
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.
As it seems this board only has minimal support upstreamed for the
legacy booting and has not seen activity for on the mailing lists
for a few years, let's attempt to remove the related legacy board-*.c
file.
I do not have this board, but it seems getting the same level of
support with device tree based booting is mostly just configuring
the .dts file. And there is no need to upgrade the boot loader as
we can boot with appended DTB too. And most of the omap3 boards
seem to be related to omap3-evm, and omap3beagleboard that are
supported with device tree based booting.
If somebody is using this board actively with the mainline kernel,
please communicate this to the linux-omap mailing list so we can
get the board booting with device tree based support. I can help
some too getting the minimal device tree based booting going if
help is needed.
The reason for attempting to remove this board now is that I'd
rather get the remaining omap3 legacy booting support into a known
state where we at least have a .dts file being written for the
remaining legacy boards. That is because for the next few merge
cycles we can still revert this patch if absolutely necessary,
but I'd rather not get suprised by missing .dts files at the point
where we are ready to drop all remaining omap3 legacy booting
support later on.
http://www.embest-tech.com/product/single-board-computers/index.html
Cc: Thomas Weber tho...@tomweber.eu
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Kconfig| 6 -
arch/arm/mach-omap2/Makefile | 1 -
arch/arm/mach-omap2/board-devkit8000.c | 654 -
3 files changed, 661 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-devkit8000.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 88e3eaf..559e287 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -175,12 +175,6 @@ config MACH_OMAP3_BEAGLE
default y
select OMAP_PACKAGE_CBB
-config MACH_DEVKIT8000
- bool DEVKIT8000 board
- depends on ARCH_OMAP3
- default y
- select OMAP_PACKAGE_CUS
-
config MACH_OMAP_LDP
bool OMAP3 LDP board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 10b9563..c346b48 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -243,7 +243,6 @@ obj-$(CONFIG_SOC_OMAP2420) += msdi.o
# Specific board support
obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
pdata-quirks.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o
-obj-$(CONFIG_MACH_DEVKIT8000) += board-devkit8000.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o
obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o
obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
deleted file mode 100644
index d8e4f34..000
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ /dev/null
@@ -1,654 +0,0 @@
-/*
- * board-devkit8000.c - TimLL Devkit8000
- *
- * Copyright (C) 2009 Kim Botherway
- * Copyright (C) 2010 Thomas Weber
- *
- * Modified from mach-omap2/board-omap3beagle.c
- *
- * Initial code: Syed Mohammed Khasim
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/delay.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/leds.h
-#include linux/gpio.h
-#include linux/input.h
-#include linux/gpio_keys.h
-
-#include linux/mtd/mtd.h
-#include linux/mtd/partitions.h
-#include linux/mtd/nand.h
-#include linux/mmc/host.h
-#include linux/usb/phy.h
-
-#include linux/regulator/machine.h
-#include linux/i2c/twl.h
-#include id.h
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-#include asm/mach/flash.h
-
-#include common.h
-#include gpmc.h
-#include linux/platform_data/mtd-nand-omap2.h
-#include video/omapdss.h
-#include video/omap-panel-data.h
-
-#include linux/platform_data/spi-omap2-mcspi.h
-#include linux/input/matrix_keypad.h
-#include linux/spi/spi.h
-#include linux/dm9000.h
-#include linux/interrupt.h
-
-#include sdram-micron-mt46h32m32lf-6.h
-#include mux.h
-#include hsmmc.h
-#include board-flash.h
-#include common-board-devices.h
-
-#defineNAND_CS 0
-
-#define OMAP_DM9000_GPIO_IRQ 25
-#define OMAP3_DEVKIT_TS_GPIO 27
-
-static struct mtd_partition devkit8000_nand_partitions[] = {
-
[PATCH 0/3] Remove few inactive omap3 legacy board-*.c files
Hi all, I'm hoping to get the status of the remaining omap3 legacy board-*.c files into a known state. And I figured the best way to do that is by removing few of them that I think are all inactive. If you are using these, please yell now! The reason for trying to remove them now is that I don't want any suprises with missing .dts files later on when we remove the remaining omap3 legacy booting support. For now, we can just simply revert these patches as needed until we have the related .dts files done. After we've dropped the remaining omap3 legacy booting support in a few merge cycles, reverting will be much harder. Regards, Tony Tony Lindgren (3): ARM: OMAP3: Remove legacy support for EMA-Tech Stalker board ARM: OMAP3: Remove legacy support for devkit8000 ARM: OMAP2+: Remove legacy support for omap3 TouchBook arch/arm/mach-omap2/Kconfig| 18 - arch/arm/mach-omap2/Makefile | 4 - arch/arm/mach-omap2/board-devkit8000.c | 654 - arch/arm/mach-omap2/board-omap3stalker.c | 433 --- arch/arm/mach-omap2/board-omap3touchbook.c | 395 - 5 files changed, 1504 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-devkit8000.c delete mode 100644 arch/arm/mach-omap2/board-omap3stalker.c delete mode 100644 arch/arm/mach-omap2/board-omap3touchbook.c -- 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 2/2] ARM: OMAP: dmtimer: disable pm runtime on remove
Disable the pm_runtime of the device upon remove. This is added to balance the pm_runtime_enable() invoked in the probe. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/plat-omap/dmtimer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index f32c74c0e1de..8ca94d379bc3 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -910,6 +910,8 @@ static int omap_dm_timer_remove(struct platform_device *pdev) } spin_unlock_irqrestore(dm_timer_lock, flags); + pm_runtime_disable(pdev-dev); + return ret; } -- 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] phy: Add a driver for dm816x USB PHY
* Matthijs van Duin matthijsvand...@gmail.com [150316 14:17]: *gets increasingly confused* :) The datasheet (sprs614e) only contains register addresses, and they seem to match the TRM's USB chapter. The only disagreement I can spot is related to USB_CTRL register(s) in the control module (offsets 0x620 and 0x628) where * the TRM claims both exist in the control module chapter (1.16.1.3), one for each both * the TRM's USB chapter claims only one exists, and its layout (24.9.8.2) doesn't resemble the former one Yes the second entry is the closest thing to a documentation here it seems. * the datasheet agrees only one exists (but gives no layout) * reality seems to disagree with both: I booted up our evm816x, plugged in a mouse to confirm USB is functional, and attached JTAG: both registers read as zero (contradicting both layouts) and appear to ignore writes. Yes so it seem here too, this is dm816x rev c, what do you have? Anyways, I'll add a note that at least rev c does not seems to do anything with USB_CTRL but that we follow what the TI tree is doing in case some other revisions of the hardware use it. There doesn't seem to be any disagreement in the docs about the USBPHY_CTRL regs (offsets 0x624 and 0x62c in control module) as far as I can tell, and the documented reset values also match what I see via JTAG. Yes agreed. But dm814x [..] seems to be wired up like am335x. This I mentioned: the only difference is related to GPIO mode (which on the dm814x yields exactly that: GPIO, while the am335x uses it to hook up UARTs). Yes I checked am3517 trm, and that too mentions Synopsys once Only in its ECHI/OCHI host controller, not the OTG one... Oh OK I missed that part. Anyhow, I didn't expect this small observation to end up becoming a device archeology expedition, sorry about that ;-) Well thanks for spotting the weirdness :) BTW, da850? Is that yet another instance of Primus? (i.e. omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) Yes it's the arm926 based series, l-138 is da850 I believe. Ah, but there are two such series: Freon and Primus. Just to be different, their part numbers are both allocated from the omap-L1xx (arm+dsp) / tms320c674x (dsp only) / am1xxx (arm only) ranges, but distinguished by Freon having even final digit while Primus has odd final digit. Of course this doesn't hold for the da8xx parts, that would be too consistent. I can't keep up with these part numbers.. But you're right, da850 indeed seems to be a Freon rather than a Primus based on some more googling (apparently da850 has SATA -- Primus doesn't). OK 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] ARM: dts: am437x-gp-evm: add DT nodes for ov2659 sensor
* Lad, Prabhakar prabhakar.cse...@gmail.com [150316 18:20]: Hi Tony, On Mon, Mar 16, 2015 at 10:17 PM, Tony Lindgren t...@atomide.com wrote: * Lad Prabhakar prabhakar.cse...@gmail.com [150312 16:38]: From: Lad, Prabhakar prabhakar.cse...@gmail.com this patch does the following: 1: adds DT node for fixed oscillator. 2: adds DT node entries for ov2659 sensor 3: adds remote-endpoint entry for VPFE. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Applying into omap-for-v4.1/dt thanks. I would like to get this one in via media tree to avoid dependency as I am still waiting for Acks from DT maintainers for the sensor driver. OK dropping it. If I can get your Ack on this I'll queue it up along with sensor driver via media tree. Sorry the chances are too big for pointless merge conflicts with these files with constant patching going on. Please just resend this patch alone again to me later on once the driver changes are merged into Linux next and on their way to the mainline kernel. 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
[PATCH 0/2] Couple of dmtimer fixes
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. regards Suman [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
[PATCH 1/2] ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure
The current OMAP dmtimer probe does not check for the return
status of pm_runtime_get_sync() before initializing the timer
registers. Any timer with missing hwmod data would return a
failure here, and the access of registers without enabling the
clocks for the timer would trigger a l3_noc interrupt and a
kernel boot hang. Add proper checking so that the probe would
return a failure graciously without hanging the kernel boot.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index db10169a08de..f32c74c0e1de 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -799,6 +799,7 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
struct device *dev = pdev-dev;
const struct of_device_id *match;
const struct dmtimer_platform_data *pdata;
+ int ret;
match = of_match_device(of_match_ptr(omap_timer_match), dev);
pdata = match ? match-data : dev-platform_data;
@@ -860,7 +861,12 @@ static int omap_dm_timer_probe(struct platform_device
*pdev)
}
if (!timer-reserved) {
- pm_runtime_get_sync(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret 0) {
+ dev_err(dev, %s: pm_runtime_get_sync failed!\n,
+ __func__);
+ goto err_get_sync;
+ }
__omap_dm_timer_init_regs(timer);
pm_runtime_put(dev);
}
@@ -873,6 +879,11 @@ static int omap_dm_timer_probe(struct platform_device
*pdev)
dev_dbg(dev, Device Probed.\n);
return 0;
+
+err_get_sync:
+ pm_runtime_put_noidle(dev);
+ pm_runtime_disable(dev);
+ return ret;
}
/**
--
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: dts: am437x-gp-evm: add DT nodes for ov2659 sensor
Hi Tony,
On Mon, Mar 16, 2015 at 10:17 PM, Tony Lindgren t...@atomide.com wrote:
* Lad Prabhakar prabhakar.cse...@gmail.com [150312 16:38]:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
this patch does the following:
1: adds DT node for fixed oscillator.
2: adds DT node entries for ov2659 sensor
3: adds remote-endpoint entry for VPFE.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Applying into omap-for-v4.1/dt thanks.
I would like to get this one in via media tree to avoid dependency
as I am still waiting for Acks from DT maintainers for the sensor
driver.
If I can get your Ack on this I'll queue it up along with sensor
driver via media tree.
Cheers,
--Prabhakar Lad
Tony
---
Note this patch depends on
https://patchwork.kernel.org/patch/6000161/
arch/arm/boot/dts/am437x-gp-evm.dts | 42
+++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index f84d971..195f452 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -106,6 +106,14 @@
};
};
};
+
+ /* fixed 12MHz oscillator */
+ refclk: oscillator {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+ };
+
};
am43xx_pinmux {
@@ -404,6 +412,21 @@
regulator-always-on;
};
};
+
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = refclk 0;
+ clock-names = xvclk;
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = vpfe1_ep;
+ link-frequencies = /bits/ 64 7000;
+ };
+ };
+ };
};
i2c1 {
@@ -423,6 +446,21 @@
touchscreen-size-x = 1024;
touchscreen-size-y = 600;
};
+
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = refclk 0;
+ clock-names = xvclk;
+
+ port {
+ ov2659_1: endpoint {
+ remote-endpoint = vpfe0_ep;
+ link-frequencies = /bits/ 64 7000;
+ };
+ };
+ };
};
epwmss0 {
@@ -626,7 +664,7 @@
port {
vpfe0_ep: endpoint {
- /* remote-endpoint = sensor; add once we have it */
+ remote-endpoint = ov2659_1;
ti,am437x-vpfe-interface = 0;
bus-width = 8;
hsync-active = 0;
@@ -643,7 +681,7 @@
port {
vpfe1_ep: endpoint {
- /* remote-endpoint = sensor; add once we have it */
+ remote-endpoint = ov2659_0;
ti,am437x-vpfe-interface = 0;
bus-width = 8;
hsync-active = 0;
--
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 1/3] ARM: omap2plus_defconfig: Enable leds-pwm
This is used on many omap boards. Signed-off-by: Tony Lindgren t...@atomide.com --- 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 4e3e93d..df41f2c 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -348,6 +348,7 @@ CONFIG_MMC_OMAP_HS=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m CONFIG_LEDS_GPIO=m +CONFIG_LEDS_PWM=m CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_ONESHOT=m -- 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/3] ARM: omap2plus_defconfig: Enable n900 modem as loadable modules
Enable n900 modem as loadable modules. Cc: Sebastian Reichel s...@ring0.de Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6c7722d..cd1c0f3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -87,6 +87,7 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_INET_LRO is not set CONFIG_NETFILTER=y +CONFIG_PHONET=m CONFIG_CAN=m CONFIG_CAN_C_CAN=m CONFIG_CAN_C_CAN_PLATFORM=m @@ -178,6 +179,7 @@ CONFIG_USB_EPSON2888=y CONFIG_USB_EHCI_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_KC2190=y +CONFIG_USB_CDC_PHONET=m CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m @@ -224,6 +226,11 @@ CONFIG_I2C_CHARDEV=y CONFIG_SPI=y CONFIG_SPI_OMAP24XX=y CONFIG_SPI_TI_QSPI=m +CONFIG_HSI=m +CONFIG_OMAP_SSI=m +CONFIG_NOKIA_MODEM=m +CONFIG_SSI_PROTOCOL=m +CONFIG_HSI_CHAR=m CONFIG_PINCTRL_SINGLE=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y @@ -348,6 +355,7 @@ CONFIG_USB_CONFIGFS_ECM=y CONFIG_USB_CONFIGFS_ECM_SUBSET=y CONFIG_USB_CONFIGFS_RNDIS=y CONFIG_USB_CONFIGFS_EEM=y +CONFIG_USB_CONFIGFS_PHONET=y CONFIG_USB_CONFIGFS_MASS_STORAGE=y CONFIG_USB_CONFIGFS_F_LB_SS=y CONFIG_USB_CONFIGFS_F_FS=y @@ -356,6 +364,7 @@ CONFIG_USB_CONFIGFS_F_UAC2=y CONFIG_USB_CONFIGFS_F_MIDI=y CONFIG_USB_CONFIGFS_F_HID=y CONFIG_USB_ZERO=m +CONFIG_USB_G_NOKIA=m CONFIG_MMC=y CONFIG_SDIO_UART=y CONFIG_MMC_OMAP=y @@ -405,6 +414,7 @@ CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y +CONFIG_CONFIGFS_FS=y CONFIG_JFFS2_FS=y CONFIG_JFFS2_SUMMARY=y CONFIG_JFFS2_FS_XATTR=y -- 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/2] clk: ti: OMAP3: McBSP clock fixes
Hi, This series will fix the following error during boot (both DT and legacy boot): [0.307739] omap_hwmod: mcbsp2: _wait_target_ready failed: -16 [0.307769] omap_hwmod: mcbsp2: cannot be enabled for reset (3) The clock definitions/aliases for McBSP ports were not correct. In case of DT boot we still have the following warning printed from hwmod: [0.222900] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp [0.225311] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp These are there because mcbsp is using two hwmods in the DT and hwmod prints out a warning for these. In legacy mode we also have 2 hwmods for McBSP2/3. One for the McBSP itself and the other for the sidetone block attached to them. I'll try to look into this one next. Since this series fixes the _wait_target_ready issue, can this be sent for 4.0? Regards, Peter --- Peter Ujfalusi (2): clk: ti: clk-3xxx: Correct McBSP related DT clock definitions clk: ti: clk-3xxx-legacy: Correct McBSP related clock aliases drivers/clk/ti/clk-3xxx-legacy.c | 16 +--- drivers/clk/ti/clk-3xxx.c| 19 +++ 2 files changed, 16 insertions(+), 19 deletions(-) -- 2.3.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] mfd: twl6040: match wait_for_completion_timeout return type
On 03/16/2015 10:17 AM, Nicholas Mc Guire wrote:
Return type of wait_for_completion_timeout is unsigned long not int. As
time_left is exclusively used for wait_for_completion_timeout here its
type is simply changed to unsigned long.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
Patch was compile tested with x86_64_defconfig + CONFIG_TWL6040_CORE=y
Patch is against 4.0-rc3 (localversion-next is -next-20150316)
drivers/mfd/twl6040.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index f71ee3d..d6f9761 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -259,7 +259,7 @@ static irqreturn_t twl6040_thint_handler(int irq, void
*data)
static int twl6040_power_up_automatic(struct twl6040 *twl6040)
{
- int time_left;
+ unsigned long time_left;
gpio_set_value(twl6040-audpwron, 1);
--
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] regulator: tps65910: Add missing #include linux/of.h
On Sun, Mar 15, 2015 at 02:03:50PM +0100, Geert Uytterhoeven wrote: drivers/regulator/tps65910-regulator.c: In function ‘tps65910_parse_dt_reg_data’: drivers/regulator/tps65910-regulator.c:1018: error: implicit declaration of function ‘of_get_child_by_name’ Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
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,
+};
snip
+
+static int usb_extcon_probe(struct platform_device *pdev)
+{
snip
+
+ ret = devm_request_threaded_irq(dev, info-id_irq, NULL,
+ usb_irq_handler,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
Shouldn't triggers be defined in DTS files?
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
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[][].
snip
+
+static int usb_extcon_probe(struct platform_device *pdev)
+{
snip
+
+ ret = devm_request_threaded_irq(dev, info-id_irq, NULL,
+ usb_irq_handler,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
Shouldn't triggers be defined in DTS files?
Could be but we're sure that we always need the trigger for both rising/falling
edges
in this case. So the usage is more appropriately decided from application point
of view
rather than h/w point of view. h/w is generic GPIO.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phy: Add a driver for dm816x USB PHY
* Matthijs van Duin matthijsvand...@gmail.com [150314 14:04]: On 13 March 2015 at 20:30, Tony Lindgren t...@atomide.com wrote: Hmm OK have to check that. It could also be that dm816x documentation is copy-paste from da850 or am3517 and the PHY got changed in the hardware as the registers don't match the documentation. Only the dm816x errata has right documentation for the USB PHY. Hmm? While I see plenty of usb errata (mostly DMA bugs), I don't see anything about registers being different. Sorry it seems to be the partially updated TRM instead, it's the sprs614e.pdf instead. That has the USBPHY_CTRL registers right. No mention of Synopsys in sprs614e.pdf though so who knows. It seems something got swapped compared to the TRM as the USB_CTRL registers totally changed. I'll just add a comments you mentioned earlier about it probably being Synopsys phy. I do see something curious: advisory 70, the only PHY-related erratum I see, is also present in the DM814x errata and even in AM335x r1.0. This strongly suggests the PHYs must at least be closely related... Hmm interesting. But dm814x has again different USB_CTRL registers, seems to be wired up like am335x. Also there's no USBPHY_CTRL registers on dm814x or am335x. Chances are that dm814x is wired up the same way as am335x. The dm816x TRM makes three separate mentions of the synopsys usb phy though, while I found no other TRMs that mention it, so if it's a copy-paste error (which certainly would not be exceptional) I don't know where from. Yes I checked am3517 trm, and that too mentions Synopsys once, but has different registers. And also checked the l-138/da850 TRM, and that does not have USB_CTRL and USBPHY_CTRL registers either.. Looks like the copy paste errors come from tms320dm6446.pdf that has the USB_CTRL and USBPHY_CTRL registers, but then no mention of Synopsys. I suppose it's still possible TI acquired a sufficiently permissive license for the synopsys phy to fork it and call it a TI PHY as they do in the AM335x docs. (No mention of its origin is made in the DM814x docs.) BTW, da850? Is that yet another instance of Primus? (i.e. omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) Yes it's the arm926 based series, l-138 is da850 I believe. 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 v6 6/6] wlcore: remove wl12xx_platform_data
* 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. 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 v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
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 and strings already defined in
extcon_cable_name[][] global variable. It is defined extern in
extcon.h file exactly for this purpose, no?
snip
+
+static int usb_extcon_probe(struct platform_device *pdev)
+{
snip
+
+ ret = devm_request_threaded_irq(dev, info-id_irq, NULL,
+ usb_irq_handler,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING |
IRQF_ONESHOT,
Shouldn't triggers be defined in DTS files?
Could be but we're sure that we always need the trigger for both
rising/falling edges
in this case. So the usage is more appropriately decided from application
point of view
rather than h/w point of view. h/w is generic GPIO.
No strong opinion on this. Could it be that GPIO did't support edge
triggered interrupt, but just level triggered?
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 v6 2/6] wl12xx: use frequency instead of enumerations for pdata clocks
* Kalle Valo kv...@codeaurora.org [150315 23:50]: Arnd Bergmann a...@arndb.de writes: On Sunday 15 March 2015 10:43:35 Eliad Peller wrote: The other option would be to have the whole series in a immutable branch against v3.0-rc1 that can be merged into both wirelss tree and omap tree. i think that could be easier. or maybe you can just take them all through the omap tree? the wlcore tree is not under active development, so i don't expect conflicts there. I'm fine with both these approaches. I prefer these going through the omap tree. Like Eliad said, drivers/net/wireless/ti does not get that many changes nowadays so the chances of this patchset conflicting with something is very small. OK great. In that case no need to rearrange the patches, I can apply them into an immutable branch once the pending issues have been fixed if Kalle acks them. To avoid merge conflicts that branch is easiest done against v4.0-rc4. Kalle and Arnd, does that work for you guys? I can also base it on 5b7610f23562 (ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot) that's on top of -rc2 plus few other fixes now merged to -rc4 mainline if we need a branch based on an earlier tag. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB
* 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. 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
OMAP baseline test results for v4.0-rc4
Here are some basic OMAP test results for Linux v4.0-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc4/20150315232818/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 2/17): 5912osk, 3517evm Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54, 2420n800 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0-rc3 (9eccca0843205f87c00404b663188b88eb248051)): text data bsstotal kernel +377 +1280 +505 omap1_defconfig +377 +1040 +481 omap1_defconfig_1510innovator_only +377 +960 +473 omap1_defconfig_5912osk_only +1316 -104+1472+2684 multi_v7_defconfig -2948+40880+1140 omap2plus_defconfig +700 +320 +732 omap2plus_defconfig_2430sdp_only +1048 +6800+1728 omap2plus_defconfig_am33xx_only +1116 +7440+1860 omap2plus_defconfig_am43xx_only -2948+40320+1084
[PATCH] ARM: dts: DRA7: Remove ti,timer-dsp and ti,timer-pwm properties
Remove the 'ti,timer-dsp' and 'ti,timer-pwm' properties from the timer
nodes that still have them. This seems to be copied from OMAP5, on
which only certain timers are capable of providing PWM functionality
or be able to interrupt the DSP. All the GPTimers On DRA7 are capable
of PWM and interrupting any core (due to the presence of Crossbar).
These properties were used by the driver to add capabilities to each
timer, and support requesting timers by capability. In the DT world,
we expect any users of timers to use phandles to the respective timer,
and use the omap_dm_timer_request_by_node() API. The API to request
using capabilities, omap_dm_timer_request_by_cap() API should be
deprecated eventually.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5827fedafd43..318d9409e8cd 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -658,7 +658,6 @@
reg = 0x4882 0x80;
interrupts = GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer5;
- ti,timer-dsp;
};
timer6: timer@48822000 {
@@ -666,8 +665,6 @@
reg = 0x48822000 0x80;
interrupts = GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer6;
- ti,timer-dsp;
- ti,timer-pwm;
};
timer7: timer@48824000 {
@@ -675,7 +672,6 @@
reg = 0x48824000 0x80;
interrupts = GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer7;
- ti,timer-dsp;
};
timer8: timer@48826000 {
@@ -683,8 +679,6 @@
reg = 0x48826000 0x80;
interrupts = GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer8;
- ti,timer-dsp;
- ti,timer-pwm;
};
timer9: timer@4803e000 {
@@ -706,7 +700,6 @@
reg = 0x48088000 0x80;
interrupts = GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer11;
- ti,timer-pwm;
};
timer13: timer@48828000 {
--
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] rtc: OMAP: Add external 32k clock feature
On Tuesday 03 March 2015 03:12 PM, Keerthy wrote:
Add external 32k clock feature. The internal clock will be gated during suspend.
Hence make use of the external 32k clock so that rtc is functional accross
suspend/resume.
A gentle ping on this.
Signed-off-by: Keerthy j-keer...@ti.com
---
Tested on DRA7-EVM.
drivers/rtc/rtc-omap.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 8e5851a..4f803ca 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -107,6 +107,8 @@
/* OMAP_RTC_OSC_REG bit fields: */
#define OMAP_RTC_OSC_32KCLK_ENBIT(6)
+#define OMAP_RTC_OSC_OSC32K_GZ BIT(4)
+#define OMAP_RTC_OSC_EXT_32K BIT(3)
/* OMAP_RTC_IRQWAKEEN bit fields: */
#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN BIT(1)
@@ -120,6 +122,7 @@
struct omap_rtc_device_type {
bool has_32kclk_en;
+ bool has_osc_ext_32k;
bool has_kicker;
bool has_irqwakeen;
bool has_pmic_mode;
@@ -446,6 +449,7 @@ static const struct omap_rtc_device_type
omap_rtc_default_type = {
static const struct omap_rtc_device_type omap_rtc_am3352_type = {
.has_32kclk_en = true,
+ .has_osc_ext_32k = true,
.has_kicker = true,
.has_irqwakeen = true,
.has_pmic_mode = true,
@@ -543,7 +547,16 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
if (rtc-type-has_32kclk_en) {
reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
rtc_writel(rtc, OMAP_RTC_OSC_REG,
- reg | OMAP_RTC_OSC_32KCLK_EN);
+ reg | OMAP_RTC_OSC_32KCLK_EN);
+ }
+
+ /* Enable External clock as the source */
+
+ if (rtc-type-has_osc_ext_32k) {
+ rtc_writel(rtc, OMAP_RTC_OSC_REG,
+ (OMAP_RTC_OSC_EXT_32K |
+ rtc_read(rtc, OMAP_RTC_OSC_REG))
+ (~OMAP_RTC_OSC_OSC32K_GZ));
}
/* clear old status */
--
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 Wed 2015-02-04 23:14:32, Marek Belisko wrote: Signed-off-by: Marek Belisko ma...@goldelico.com --- .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt 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 ? + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values + for charging calibration (see example) + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values + for discharging calibration (see example) Would mV-to-capacity... be more accurate? Also, would it make sense to introduce coefficients for temperature and discharge rate? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: boot: dts: am437x-idk: enable i2c2
* Felipe Balbi ba...@ti.com [150219 12:02]:
i2c2 goes to an expansion connector which we
want to use.
Applying into omap-for-v4.1/dt thanks.
Tony
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-idk-evm.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts
b/arch/arm/boot/dts/am437x-idk-evm.dts
index 2471f1ebd4ed..22c2031dea17 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -133,6 +133,20 @@
;
};
+ i2c2_pins_default: i2c2_pins_default {
+ pinctrl-single,pins =
+ 0x1e8 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE3) /*
cam1_data1.i2c2_scl */
+ 0x1ec (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE3) /*
cam1_data0.i2c2_sda */
+ ;
+ };
+
+ i2c2_pins_sleep: i2c2_pins_sleep {
+ pinctrl-single,pins =
+ 0x1e8 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ 0x1ec (PIN_INPUT_PULLDOWN | MUX_MODE7)
+ ;
+ };
+
mmc1_pins_default: pinmux_mmc1_pins_default {
pinctrl-single,pins =
0x100 (PIN_INPUT | MUX_MODE0) /* mmc0_clk.mmc0_clk */
@@ -263,6 +277,14 @@
};
};
+i2c2 {
+ status = okay;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = i2c2_pins_default;
+ pinctrl-1 = i2c2_pins_sleep;
+ clock-frequency = 10;
+};
+
epwmss0 {
status = okay;
};
--
2.3.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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] ARM: dts: add openpandora device support
* Marek Belisko ma...@goldelico.com [150227 13:30]: changes from v2: - fix missing PIN_INPUT for penirq node - added Reviewed-by and Tested-by changes from v1: - add new boards to makefile in patch 2,3 (don't add them in separate commit together), fix gpmc issues (reported by Tony Lindgren) - fix various issues reported by Grazvydas Ignotas (drop internal pullups from pinmux as external are in place, fix gpio buttons active state ...) This series of patches adds initial device tree support for the OpenPandora. The most important parts are working (display, keyboard, touch, charging, fuel gauge, musb port, sd/mmc ports, leds, buttons). Not yet supported are: usb host port, nubs, wifi, bluetooth, audio. First patch add common dtsi file which is then used in 600mhz and 1ghz variants of openpandora which support is added in patches 2 and 3. H. Nikolaus Schaller (3): ARM: dts: omap3-pandora: add common device tree ARM: dts: omap3-pandora: add OMAP3530 600 MHz version ARM: dts: omap3-pandora: add DM3730 1 GHz version Thanks everybody for doing this, applying into omap-for-v4.1/dt. 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] ARM: DTS: am57xx-beagle-x15: Do not include the atl header
* Peter Ujfalusi peter.ujfal...@ti.com [150226 05:46]: AM57xx does not have ATL block integrated. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Applying into omap-for-v4.1/dt thanks. Tony --- arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts index 6463f9ef2b54..c1d82e830a96 100644 --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -8,7 +8,6 @@ /dts-v1/; #include dra74x.dtsi -#include dt-bindings/clk/ti-dra7-atl.h #include dt-bindings/gpio/gpio.h #include dt-bindings/interrupt-controller/irq.h -- 2.3.0 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: DT: omap_serial: document missing properties and add an example
* Matt Porter mpor...@konsulko.com [150226 07:42]:
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter mpor...@konsulko.com
I'll apply this into omap-for-v4.1/dt thanks.
Regards,
Tony
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be ti,omap2-uart for OMAP2 controllers
- compatible : should be ti,omap3-uart for OMAP3 controllers
- compatible : should be ti,omap4-uart for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be uartn, n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : rx for receive channel, tx for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = ti,omap3-uart;
+reg = 0x49042000 0x400;
+interrupts = 80;
+dmas = sdma 81 sdma 82;
+dma-names = tx, rx;
+ti,hwmods = uart4;
+clock-frequency = 4800;
+};
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DTS: dra7xx-clocks: Add gate clock for CLKOUT2
* Peter Ujfalusi peter.ujfal...@ti.com [150226 05:43]:
To be able to control the gate for the clkout2 clock output.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
Applying into omap-for-v4.1/dt thanks.
Tony
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 4bdcbd61ce47..2a9994f73974 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1421,6 +1421,14 @@
ti,dividers = 1, 8;
};
+ clkout2_clk: clkout2_clk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = clkoutmux2_clk_mux;
+ ti,bit-shift = 8;
+ reg = 0x06b0;
+ };
+
l3init_960m_gfclk: l3init_960m_gfclk {
#clock-cells = 0;
compatible = ti,gate-clock;
--
2.3.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] ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
* 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. 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 v3 4/6] ARM: dts: omap3-gta04: Add battery support
* Sebastian Reichel s...@kernel.org [150304 16:41]: Hi, On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote: Signed-off-by: Marek Belisko ma...@goldelico.com --- arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++ 1 file changed, 30 insertions(+) DTS changes must go via omap-dt tree once the driver changes have been merged. And looks like you wanted to add ti, prefix to the binding. I'll mark this one as read, please repost this one separately once the driver changes are in Linux next. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Couple of DRA7 hwmod patches on Timers
Hi Paul, Following are couple of DRA7 hwmod patches for the GPTimers. Patches based on 4.0-rc1. The first patch adds the data for timers 13 through 16, the DT nodes are already present, and when enabled without the hwmod data triggers a l3_noc interrupt and hangs the kernel boot [1]. The boot hang can also be fixed by checking the return status of pm_runtime_get_sync() in the OMAP dmtimer probe, I will post a separate fix for that. Second patch is a minor fix. regards Suman [1] http://pastebin.ubuntu.com/10611882/ Suman Anna (2): ARM: DRA7: hwmod: Add data for GPTimers 13 through 16 ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 98 ++- 1 file changed, 97 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
[PATCH 2/2] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index d0f03e73add4..2875d4bdb924 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1841,7 +1841,7 @@ static struct omap_hwmod dra7xx_timer3_hwmod = {
/* timer4 */
static struct omap_hwmod dra7xx_timer4_hwmod = {
.name = timer4,
- .class = dra7xx_timer_secure_hwmod_class,
+ .class = dra7xx_timer_hwmod_class,
.clkdm_name = l4per_clkdm,
.main_clk = timer4_gfclk_mux,
.prcm = {
--
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 v3 4/6] ARM: dts: omap3-gta04: Add battery support
* Belisko Marek marek.beli...@gmail.com [150316 13:47]: Hi Tony, On Mon, Mar 16, 2015 at 9:35 PM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@kernel.org [150304 16:41]: Hi, On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote: Signed-off-by: Marek Belisko ma...@goldelico.com --- arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++ 1 file changed, 30 insertions(+) DTS changes must go via omap-dt tree once the driver changes have been merged. And looks like you wanted to add ti, prefix to the binding. I'll mark this one as read, please repost this one separately once the driver changes are in Linux next. ti prefix Iis done in v4 series already [1] Regards, Tony [1] - http://lkml.iu.edu/hypermail/linux/kernel/1503.1/02157.html OK will pick it from there 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 v2 3/3] ARM: dts: AM4372: update hdq compatible property
* Vignesh R vigne...@ti.com [150302 02:53]:
This patch updates hdq node compatible property to ti,am4372-hdq.
Signed-off-by: Vignesh R vigne...@ti.com
Looks like this is safe to apply even with the driver changes pending
as the driver is currently only parsing ti,omap3-1w property.
So applying this patch into omap-for-v4.1/dt thanks.
Tony
---
arch/arm/boot/dts/am4372.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 1943fc333e7c..ae0e8c15a6df 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -884,7 +884,7 @@
};
hdq: hdq@48347000 {
- compatible = ti,am43xx-hdq;
+ compatible = ti,am4372-hdq;
reg = 0x48347000 0x1000;
interrupts = GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH;
clocks = func_12m_clk;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] MAINTAINERS: add OMAP defconfigs under OMAP SUPPORT
* Felipe Balbi ba...@ti.com [150119 14:18]: omap2plus_defconfig and omap1_defconfig are also part of the OMAP Support maintained, because of that it's best to list them under OMAP SUPPORT on MAINTAINERS so people know to Cc linux-omap when patching them. Reported-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk Signed-off-by: Felipe Balbi ba...@ti.com Applying into omap-for-v4.1/fixes-not-urgent thanks. Tony --- Add omap1_defconfig too MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 97de006f38f0..7423e9759187 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6783,6 +6783,8 @@ Q: http://patchwork.kernel.org/project/linux-omap/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git S: Maintained F: arch/arm/*omap*/ +F: arch/arm/configs/omap1_defconfig +F: arch/arm/configs/omap2plus_defconfig F: drivers/i2c/busses/i2c-omap.c F: drivers/irqchip/irq-omap-intc.c F: drivers/mfd/*omap*.c -- 2.2.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 -- 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: DRA7: Remove ti,timer-dsp and ti,timer-pwm properties
* Suman Anna s-a...@ti.com [150316 10:21]:
Remove the 'ti,timer-dsp' and 'ti,timer-pwm' properties from the timer
nodes that still have them. This seems to be copied from OMAP5, on
which only certain timers are capable of providing PWM functionality
or be able to interrupt the DSP. All the GPTimers On DRA7 are capable
of PWM and interrupting any core (due to the presence of Crossbar).
These properties were used by the driver to add capabilities to each
timer, and support requesting timers by capability. In the DT world,
we expect any users of timers to use phandles to the respective timer,
and use the omap_dm_timer_request_by_node() API. The API to request
using capabilities, omap_dm_timer_request_by_cap() API should be
deprecated eventually.
Signed-off-by: Suman Anna s-a...@ti.com
Applying into omap-for-v4.1/dt thanks.
Tony
---
arch/arm/boot/dts/dra7.dtsi | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5827fedafd43..318d9409e8cd 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -658,7 +658,6 @@
reg = 0x4882 0x80;
interrupts = GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer5;
- ti,timer-dsp;
};
timer6: timer@48822000 {
@@ -666,8 +665,6 @@
reg = 0x48822000 0x80;
interrupts = GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer6;
- ti,timer-dsp;
- ti,timer-pwm;
};
timer7: timer@48824000 {
@@ -675,7 +672,6 @@
reg = 0x48824000 0x80;
interrupts = GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer7;
- ti,timer-dsp;
};
timer8: timer@48826000 {
@@ -683,8 +679,6 @@
reg = 0x48826000 0x80;
interrupts = GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer8;
- ti,timer-dsp;
- ti,timer-pwm;
};
timer9: timer@4803e000 {
@@ -706,7 +700,6 @@
reg = 0x48088000 0x80;
interrupts = GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = timer11;
- ti,timer-pwm;
};
timer13: timer@48828000 {
--
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: omap-device: add missed callback for suspend-to-disk
* Tony Lindgren t...@atomide.com [150225 08:10]:
* Grygorii Strashko grygorii.stras...@ti.com [150225 07:56]:
On 02/25/2015 05:44 PM, Tony Lindgren wrote:
* grygorii.stras...@linaro.org grygorii.stras...@linaro.org [150225
06:17]:
From: Grygorii Strashko grygorii.stras...@linaro.org
Add missed callback needed for supporting suspend-to-disk (hibernation)
mode.
Is this needed as a fix for the -rc series or are there still
other missing dependencies?
This one is not critical fix.
OK thanks for confirming that.
Applying into omap-for-v4.1/soc thanks.
Tony
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
arch/arm/mach-omap2/omap_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index fcd2c9e..345e18e 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -739,6 +739,9 @@ struct dev_pm_domain omap_device_pm_domain = {
USE_PLATFORM_PM_SLEEP_OPS
.suspend_noirq = _od_suspend_noirq,
.resume_noirq = _od_resume_noirq,
+ .freeze_noirq = _od_suspend_noirq,
+ .thaw_noirq = _od_resume_noirq,
+ .restore_noirq = _od_resume_noirq,
}
};
--
1.9.1
regards,
-grygorii
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support
Hi Tony, On Mon, Mar 16, 2015 at 9:35 PM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@kernel.org [150304 16:41]: Hi, On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote: Signed-off-by: Marek Belisko ma...@goldelico.com --- arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++ 1 file changed, 30 insertions(+) DTS changes must go via omap-dt tree once the driver changes have been merged. And looks like you wanted to add ti, prefix to the binding. I'll mark this one as read, please repost this one separately once the driver changes are in Linux next. ti prefix Iis done in v4 series already [1] Regards, Tony [1] - http://lkml.iu.edu/hypermail/linux/kernel/1503.1/02157.html BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: am335x: Add DTS for ChiliSOM module
* Rostislav Lisovy lis...@gmail.com [150209 06:51]:
Since this is a SOM (System on Module) that will be part
of another embedded board (and can't really exist on its own)
define it as a dtsi that will be included in the Device tree
describing the whole system later on.
Hardware specification:
* AM335x SoC
* up to 512 MB RAM
* NAND Flash (8x interface, cs0)
* UART0
* PMIC
* I2C0 (for PMIC)
* 1x Ethernet MAC
Applying all three into omap-for-v4.1/dt with one change
below.
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
+
+gpmc {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = nandflash_pins;
+ ranges = 0 0 0x0800 0x0100; /* CS0 0 @addr 0x0800, size
0x0100 */
+ nand@0,0 {
+ reg = 0 0 0x0100; /* CS0 */
I've changed this to say just:
reg = 0 0 4; /* CS0, offset 0, IO size 4 */
As for NAND the device has just one IO register. The 0x0100
is the size of a minimum GPMC partition.
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
[PATCH 1/2] ARM: DRA7: hwmod: Add data for GPTimers 13 through 16
Add the hwmod data for GPTimers 13, 14, 15 and 16. All these
timers are present in the L4PER3 clock domain.
The corresponding DT nodes are already present but disabled.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 96 +++
1 file changed, 96 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e8692e7675b8..d0f03e73add4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1958,6 +1958,66 @@ static struct omap_hwmod dra7xx_timer11_hwmod = {
},
};
+/* timer13 */
+static struct omap_hwmod dra7xx_timer13_hwmod = {
+ .name = timer13,
+ .class = dra7xx_timer_hwmod_class,
+ .clkdm_name = l4per3_clkdm,
+ .main_clk = timer13_gfclk_mux,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4PER3_TIMER13_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4PER3_TIMER13_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* timer14 */
+static struct omap_hwmod dra7xx_timer14_hwmod = {
+ .name = timer14,
+ .class = dra7xx_timer_hwmod_class,
+ .clkdm_name = l4per3_clkdm,
+ .main_clk = timer14_gfclk_mux,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4PER3_TIMER14_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4PER3_TIMER14_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* timer15 */
+static struct omap_hwmod dra7xx_timer15_hwmod = {
+ .name = timer15,
+ .class = dra7xx_timer_hwmod_class,
+ .clkdm_name = l4per3_clkdm,
+ .main_clk = timer15_gfclk_mux,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4PER3_TIMER15_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4PER3_TIMER15_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* timer16 */
+static struct omap_hwmod dra7xx_timer16_hwmod = {
+ .name = timer16,
+ .class = dra7xx_timer_hwmod_class,
+ .clkdm_name = l4per3_clkdm,
+ .main_clk = timer16_gfclk_mux,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4PER3_TIMER16_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4PER3_TIMER16_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/*
* 'uart' class
*
@@ -3112,6 +3172,38 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer11
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per3 - timer13 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer13 = {
+ .master = dra7xx_l4_per3_hwmod,
+ .slave = dra7xx_timer13_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 - timer14 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer14 = {
+ .master = dra7xx_l4_per3_hwmod,
+ .slave = dra7xx_timer14_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 - timer15 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer15 = {
+ .master = dra7xx_l4_per3_hwmod,
+ .slave = dra7xx_timer15_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per3 - timer16 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer16 = {
+ .master = dra7xx_l4_per3_hwmod,
+ .slave = dra7xx_timer16_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_per1 - uart1 */
static struct omap_hwmod_ocp_if dra7xx_l4_per1__uart1 = {
.master = dra7xx_l4_per1_hwmod,
@@ -3350,6 +3442,10 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_per1__timer9,
dra7xx_l4_per1__timer10,
dra7xx_l4_per1__timer11,
+ dra7xx_l4_per3__timer13,
+ dra7xx_l4_per3__timer14,
+ dra7xx_l4_per3__timer15,
+ dra7xx_l4_per3__timer16,
dra7xx_l4_per1__uart1,
dra7xx_l4_per1__uart2,
dra7xx_l4_per1__uart3,
--
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 v6 6/6] wlcore: remove wl12xx_platform_data
* Pali Rohár pali.ro...@gmail.com [150316 13:59]: On Monday 16 March 2015 16:29:39 Tony Lindgren wrote: I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali. No. In DT boot there is missing /proc/atags file (readable by userspace processes). Oh OK thanks for the update. And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent. But this is not a regression in mainline with legacy boot vs device tree based booting, right? Sounds like it never worked in the mainline or am thinking of some other set of patches? 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] ARM: dts: omap3-beagle: Add NAND device
* Roger Quadros rog...@ti.com [150306 07:10]:
The beagle board contains a 16-bit NAND device connected to
chip select 0 of the GPMC controller.
Signed-off-by: Roger Quadros rog...@ti.com
Applying into omap-for-v4.1/dt thanks.
Tony
---
arch/arm/boot/dts/omap3-beagle.dts | 52
++
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index c792391..bf28502 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -379,3 +379,55 @@
};
};
};
+
+gpmc {
+ status = ok;
+ ranges = 0 0 0x3000 0x100;/* CS0 space, 16MB */
+
+ /* Chip select 0 */
+ nand@0,0 {
+ reg = 0 0 4; /* NAND I/O window, 4 bytes */
+ interrupts = 20;
+ ti,nand-ecc-opt = ham1;
+ nand-bus-width = 16;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ gpmc,device-width = 2;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 36;
+ gpmc,cs-wr-off-ns = 36;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 24;
+ gpmc,adv-wr-off-ns = 36;
+ gpmc,oe-on-ns = 6;
+ gpmc,oe-off-ns = 48;
+ gpmc,we-on-ns = 6;
+ gpmc,we-off-ns = 30;
+ gpmc,rd-cycle-ns = 72;
+ gpmc,wr-cycle-ns = 72;
+ gpmc,access-ns = 54;
+ gpmc,wr-access-ns = 30;
+
+ partition@0 {
+ label = X-Loader;
+ reg = 0 0x8;
+ };
+ partition@8 {
+ label = U-Boot;
+ reg = 0x8 0x1e;
+ };
+ partition@1c {
+ label = U-Boot Env;
+ reg = 0x26 0x2;
+ };
+ partition@28 {
+ label = Kernel;
+ reg = 0x28 0x40;
+ };
+ partition@78 {
+ label = Filesystem;
+ reg = 0x68 0xf98;
+ };
+ };
+};
--
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] ARM: dts: am437x-gp-evm: add DT nodes for ov2659 sensor
* Lad Prabhakar prabhakar.cse...@gmail.com [150312 16:38]:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
this patch does the following:
1: adds DT node for fixed oscillator.
2: adds DT node entries for ov2659 sensor
3: adds remote-endpoint entry for VPFE.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Applying into omap-for-v4.1/dt thanks.
Tony
---
Note this patch depends on
https://patchwork.kernel.org/patch/6000161/
arch/arm/boot/dts/am437x-gp-evm.dts | 42
+++--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index f84d971..195f452 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -106,6 +106,14 @@
};
};
};
+
+ /* fixed 12MHz oscillator */
+ refclk: oscillator {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+ };
+
};
am43xx_pinmux {
@@ -404,6 +412,21 @@
regulator-always-on;
};
};
+
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = refclk 0;
+ clock-names = xvclk;
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = vpfe1_ep;
+ link-frequencies = /bits/ 64 7000;
+ };
+ };
+ };
};
i2c1 {
@@ -423,6 +446,21 @@
touchscreen-size-x = 1024;
touchscreen-size-y = 600;
};
+
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = refclk 0;
+ clock-names = xvclk;
+
+ port {
+ ov2659_1: endpoint {
+ remote-endpoint = vpfe0_ep;
+ link-frequencies = /bits/ 64 7000;
+ };
+ };
+ };
};
epwmss0 {
@@ -626,7 +664,7 @@
port {
vpfe0_ep: endpoint {
- /* remote-endpoint = sensor; add once we have it */
+ remote-endpoint = ov2659_1;
ti,am437x-vpfe-interface = 0;
bus-width = 8;
hsync-active = 0;
@@ -643,7 +681,7 @@
port {
vpfe1_ep: endpoint {
- /* remote-endpoint = sensor; add once we have it */
+ remote-endpoint = ov2659_0;
ti,am437x-vpfe-interface = 0;
bus-width = 8;
hsync-active = 0;
--
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 13/15] v4l: of: Read lane-polarity endpoint property
Hi Laurent,
On Mon, Mar 16, 2015 at 11:05:38AM +0200, Laurent Pinchart wrote:
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:26:08 Sakari Ailus wrote:
Add lane_polarity field to struct v4l2_of_bus_mipi_csi2 and write the
contents of the lane polarity property to it. The field tells the polarity
of the physical lanes starting from the first one. Any unused lanes are
ignored, i.e. only the polarity of the used lanes is specified.
Also rework reading the data-lanes property a little.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/v4l2-core/v4l2-of.c | 41 ++
include/media/v4l2-of.h |3 +++
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c index b4ed9a9..e44cc15 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -19,11 +19,10 @@
#include media/v4l2-of.h
-static void v4l2_of_parse_csi_bus(const struct device_node *node,
- struct v4l2_of_endpoint *endpoint)
+static int v4l2_of_parse_csi_bus(const struct device_node *node,
+struct v4l2_of_endpoint *endpoint)
{
struct v4l2_of_bus_mipi_csi2 *bus = endpoint-bus.mipi_csi2;
- u32 data_lanes[ARRAY_SIZE(bus-data_lanes)];
struct property *prop;
bool have_clk_lane = false;
unsigned int flags = 0;
@@ -32,16 +31,34 @@ static void v4l2_of_parse_csi_bus(const struct
device_node *node, prop = of_find_property(node, data-lanes, NULL);
if (prop) {
const __be32 *lane = NULL;
- int i;
+ unsigned int i;
- for (i = 0; i ARRAY_SIZE(data_lanes); i++) {
- lane = of_prop_next_u32(prop, lane, data_lanes[i]);
+ for (i = 0; i ARRAY_SIZE(bus-data_lanes); i++) {
+ lane = of_prop_next_u32(prop, lane, v);
if (!lane)
break;
+ bus-data_lanes[i] = v;
}
bus-num_data_lanes = i;
- while (i--)
- bus-data_lanes[i] = data_lanes[i];
+ }
+
+ prop = of_find_property(node, lane-polarity, NULL);
+ if (prop) {
+ const __be32 *polarity = NULL;
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(bus-lane_polarity); i++) {
+ polarity = of_prop_next_u32(prop, polarity, v);
+ if (!polarity)
+ break;
+ bus-lane_polarity[i] = v;
+ }
+
+ if (i 1 + bus-num_data_lanes /* clock + data */) {
+ pr_warn(bad size of lane-polarity array in node %s,
was %u,
should be
%u\n,
How about
pr_warn(%s: too few lane-polarity entries (need %u, got %u)\n,
node-full_name, 1 + bus-num_data_lanes, i);
Fixed.
+ node-full_name, i, 1 + bus-num_data_lanes);
+ return -EINVAL;
+ }
}
if (!of_property_read_u32(node, clock-lanes, v)) {
@@ -56,6 +73,8 @@ static void v4l2_of_parse_csi_bus(const struct device_node
*node,
bus-flags = flags;
endpoint-bus_type = V4L2_MBUS_CSI2;
+
+ return 0;
}
static void v4l2_of_parse_parallel_bus(const struct device_node *node,
@@ -127,11 +146,15 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node, int v4l2_of_parse_endpoint(const struct device_node
*node,
struct v4l2_of_endpoint *endpoint)
{
+ int rval;
+
of_graph_parse_endpoint(node, endpoint-base);
endpoint-bus_type = 0;
memset(endpoint-bus, 0, sizeof(endpoint-bus));
- v4l2_of_parse_csi_bus(node, endpoint);
+ rval = v4l2_of_parse_csi_bus(node, endpoint);
+ if (rval)
+ return rval;
/*
* Parse the parallel video bus properties only if none
* of the MIPI CSI-2 specific properties were found.
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 70fa7b7..a70eb52 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -29,12 +29,15 @@ struct device_node;
* @data_lanes: an array of physical data lane indexes
* @clock_lane: physical lane index of the clock lane
* @num_data_lanes: number of data lanes
+ * @lane_polarity: polarity of the lanes. The order is the same of
+ *the physical lanes.
*/
struct v4l2_of_bus_mipi_csi2 {
unsigned int flags;
unsigned char data_lanes[4];
unsigned char clock_lane;
unsigned short num_data_lanes;
+ bool lane_polarity[5];
A bit of bike-shedding here, should this be lane_polarities ? And, thinking
about it, should the DT property be renamed to lane-polarities as well ?
This would
Re: [PATCH RESEND] serial: omap_serial: document missing properties and add an example
* Matt Porter mpor...@konsulko.com [150306 07:16]:
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter mpor...@konsulko.com
Applying the original version as they seem to be the same.
Regards,
Tony
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be ti,omap2-uart for OMAP2 controllers
- compatible : should be ti,omap3-uart for OMAP3 controllers
- compatible : should be ti,omap4-uart for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be uartn, n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : rx for receive channel, tx for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = ti,omap3-uart;
+reg = 0x49042000 0x400;
+interrupts = 80;
+dmas = sdma 81 sdma 82;
+dma-names = tx, rx;
+ti,hwmods = uart4;
+clock-frequency = 4800;
+};
--
1.8.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
Re: [PATCH v2 0/2] ARM: devicetree: Remove unused ti,codec property
* Peter Ujfalusi peter.ujfal...@ti.com [150316 00:16]: On 03/13/2015 10:40 PM, Marek Belisko wrote: ti,codec in not parsed in omap-twl4030 sound driver. It's not necessary to specify this property in DT because ti,twl4030-audio which ti,codec was pointing to by phandle is mfd driver and device for ASoC ic created w/o any DT property (codec name is hardcoded in ASoC driver). Please see reply [1] from Peter Ujfalusi. All: Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Applying both into omap-for-v4.1/dt thanks. Tony Changes from v1: - keep ti,codec property in Documentation as optional that the existing dtbs do not become noncompliant after the change [1]: http://comments.gmane.org/gmane.linux.ports.arm.omap/124273 Marek Belisko (2): ARM: dts: omap3: Remove all references to ti,codec property Documentation: omap-twl4030: Move ti,codec property to optional Documentation/devicetree/bindings/sound/omap-twl4030.txt | 3 +-- arch/arm/boot/dts/omap3-beagle-xm.dts| 1 - arch/arm/boot/dts/omap3-beagle.dts | 1 - arch/arm/boot/dts/omap3-cm-t3x30.dtsi| 1 - arch/arm/boot/dts/omap3-devkit8000.dts | 1 - arch/arm/boot/dts/omap3-gta04.dtsi | 1 - arch/arm/boot/dts/omap3-igep.dtsi| 1 - arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 1 - arch/arm/boot/dts/omap3-overo-base.dtsi | 1 - arch/arm/boot/dts/omap3-tao3530.dtsi | 1 - 10 files changed, 1 insertion(+), 11 deletions(-) -- 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] ARM: OMAP2+: Fix socbus family info for AM33xx devices
* Suman Anna s-a...@ti.com [150311 16:39]: The family information in the soc-bus data is currently not classified properly for AM33xx devices, and a read of /sys/bus/soc/devices/soc0/family currently shows Unknown. Fix the same. Signed-off-by: Suman Anna s-a...@ti.com Thanks applying into omap-for-v4.0/fixes. Tony --- arch/arm/mach-omap2/id.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 2a2f4d56e4c8..25f1beea453e 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -720,6 +720,8 @@ static const char * __init omap_get_family(void) return kasprintf(GFP_KERNEL, OMAP4); else if (soc_is_omap54xx()) return kasprintf(GFP_KERNEL, OMAP5); + else if (soc_is_am33xx() || soc_is_am335x()) + return kasprintf(GFP_KERNEL, AM33xx); else if (soc_is_am43xx()) return kasprintf(GFP_KERNEL, AM43xx); else if (soc_is_dra7xx()) -- 2.3.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 v4 4/6] ARM: dts: omap3-gta04: Add battery support
* Tony Lindgren t...@atomide.com [150316 13:59]:
* Marek Belisko ma...@goldelico.com [150310 14:28]:
Added battery support for gta04 devices.
Signed-off-by: Marek Belisko ma...@goldelico.com
Picking up this patch into omap-for-v4.1/dt branch thanks.
Actually not yet applying this as looks like Pavel just
had few comments on these properties.
Tony
---
arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index fb3a696..cbf515a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -49,6 +49,32 @@
ti,codec = twl_audio;
};
+ battery {
+ compatible = ti,twl4030-madc-battery;
+ capacity-uah = 120;
+ ti,volt-to-capacity-charging-map = 4200 100,
+4100 75,
+4000 55,
+3900 25,
+3800 5,
+3700 2,
+3600 1,
+3300 0;
+ ti,volt-to-capacity-discharging-map = 4200 100,
+ 4100 95,
+ 4000 70,
+ 3800 50,
+ 3700 10,
+ 3600 5,
+ 3300 0;
+ io-channels = twl_madc 1,
+ twl_madc 10,
+ twl_madc 12;
+ io-channel-names = temp,
+ ichg,
+ vbat;
+ };
+
spi_lcd {
compatible = spi-gpio;
#address-cells = 0x1;
@@ -518,3 +544,7 @@
mcbsp2 {
status = okay;
};
+
+twl_madc {
+ ti,system-uses-second-madc-irq;
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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] phy: Add a driver for dm816x USB PHY
*gets increasingly confused* The datasheet (sprs614e) only contains register addresses, and they seem to match the TRM's USB chapter. The only disagreement I can spot is related to USB_CTRL register(s) in the control module (offsets 0x620 and 0x628) where * the TRM claims both exist in the control module chapter (1.16.1.3), one for each both * the TRM's USB chapter claims only one exists, and its layout (24.9.8.2) doesn't resemble the former one * the datasheet agrees only one exists (but gives no layout) * reality seems to disagree with both: I booted up our evm816x, plugged in a mouse to confirm USB is functional, and attached JTAG: both registers read as zero (contradicting both layouts) and appear to ignore writes. There doesn't seem to be any disagreement in the docs about the USBPHY_CTRL regs (offsets 0x624 and 0x62c in control module) as far as I can tell, and the documented reset values also match what I see via JTAG. But dm814x [..] seems to be wired up like am335x. This I mentioned: the only difference is related to GPIO mode (which on the dm814x yields exactly that: GPIO, while the am335x uses it to hook up UARTs). Yes I checked am3517 trm, and that too mentions Synopsys once Only in its ECHI/OCHI host controller, not the OTG one... Anyhow, I didn't expect this small observation to end up becoming a device archeology expedition, sorry about that ;-) BTW, da850? Is that yet another instance of Primus? (i.e. omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) Yes it's the arm926 based series, l-138 is da850 I believe. Ah, but there are two such series: Freon and Primus. Just to be different, their part numbers are both allocated from the omap-L1xx (arm+dsp) / tms320c674x (dsp only) / am1xxx (arm only) ranges, but distinguished by Freon having even final digit while Primus has odd final digit. Of course this doesn't hold for the da8xx parts, that would be too consistent. But you're right, da850 indeed seems to be a Freon rather than a Primus based on some more googling (apparently da850 has SATA -- Primus doesn't). Matthijs On 16 March 2015 at 17:49, Tony Lindgren t...@atomide.com wrote: * Matthijs van Duin matthijsvand...@gmail.com [150314 14:04]: On 13 March 2015 at 20:30, Tony Lindgren t...@atomide.com wrote: Hmm OK have to check that. It could also be that dm816x documentation is copy-paste from da850 or am3517 and the PHY got changed in the hardware as the registers don't match the documentation. Only the dm816x errata has right documentation for the USB PHY. Hmm? While I see plenty of usb errata (mostly DMA bugs), I don't see anything about registers being different. Sorry it seems to be the partially updated TRM instead, it's the sprs614e.pdf instead. That has the USBPHY_CTRL registers right. No mention of Synopsys in sprs614e.pdf though so who knows. It seems something got swapped compared to the TRM as the USB_CTRL registers totally changed. I'll just add a comments you mentioned earlier about it probably being Synopsys phy. I do see something curious: advisory 70, the only PHY-related erratum I see, is also present in the DM814x errata and even in AM335x r1.0. This strongly suggests the PHYs must at least be closely related... Hmm interesting. But dm814x has again different USB_CTRL registers, seems to be wired up like am335x. Also there's no USBPHY_CTRL registers on dm814x or am335x. Chances are that dm814x is wired up the same way as am335x. The dm816x TRM makes three separate mentions of the synopsys usb phy though, while I found no other TRMs that mention it, so if it's a copy-paste error (which certainly would not be exceptional) I don't know where from. Yes I checked am3517 trm, and that too mentions Synopsys once, but has different registers. And also checked the l-138/da850 TRM, and that does not have USB_CTRL and USBPHY_CTRL registers either.. Looks like the copy paste errors come from tms320dm6446.pdf that has the USB_CTRL and USBPHY_CTRL registers, but then no mention of Synopsys. I suppose it's still possible TI acquired a sufficiently permissive license for the synopsys phy to fork it and call it a TI PHY as they do in the AM335x docs. (No mention of its origin is made in the DM814x docs.) BTW, da850? Is that yet another instance of Primus? (i.e. omap-L1xx/c674x/am1xxx with odd final digit, also da830/da828) Yes it's the arm926 based series, l-138 is da850 I believe. 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 v6 6/6] wlcore: remove wl12xx_platform_data
* Pali Rohár pali.ro...@gmail.com [150316 14:15]: On Monday 16 March 2015 22:01:43 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150316 13:59]: On Monday 16 March 2015 16:29:39 Tony Lindgren wrote: I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali. No. In DT boot there is missing /proc/atags file (readable by userspace processes). Oh OK thanks for the update. And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent. But this is not a regression in mainline with legacy boot vs device tree based booting, right? Sounds like it never worked in the mainline or am thinking of some other set of patches? Regards, Tony In legacy board code are DMA channels defined. In DT files not. So I think this is regression. Omap secure devices are broken in both legacy DT code, but non secure could work with legacy code. But all devices booted with DT are broken. OK I'll apply the DMA channels into omap-for-v4.0/fixes in that case. 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] ARM: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
* Jon Hunter jgchun...@gmail.com [150212 04:37]: On 02/12/2015 11:26 AM, Jon Hunter wrote: On 02/11/2015 09:14 PM, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150211 13:03]: On Wed, 11 Feb 2015, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [150210 18:28]: On Tue, 10 Feb 2015, Jon Hunter wrote: On 07/02/2015 00:23, Paul Walmsley wrote: Unfortunately, there is not a single TRM for the omap5910 but individual documents for each chapter in the original TRM. Check out the OMAP5910 Dual-Core Processor Timer Reference Guide and possibly the OMAP5910 Dual-Core Processor Clock Generation and System Reset Management Reference Guide The omap15xx/5910 did have a 32k timer but as you can see it appears it was never supported by the kernel for this device (not sure why). I do recall that there is some errata regarding the 32k timer, if you look at the omap5910 errata document and search for 32k you should find it. OK thanks for the context. I probably am not going to investigate adding support for this timer on OMAP1510/5910 - am primarily trying to avoid causing a regression on the existing platforms. At least I've never seen the 32KiHz timer registers in any 15xx documentation. Jon are you sure you're not mixing up 5910 (15xx) and 5912 (16xx)? It's documented in the OMAP5910 Timer Reference Guide (SPRU682A) Section 3 32-kHz Timer, at the link Jon mentioned. Have not checked the errata that Jon mentioned though. Interesting. Looks like it's the same as on 16xx at 0xfffb9000. AFAIK that never worked on 15xx. Or maybe the issue was that 15xx is missing the constantly running 32KiHz counter making the timer unusable from PM point of view as the clockevent alone is not enough. Regarding the patch: I'd suggest keeping the compilation warning fixes (which was the original purpose of the patch) from anything that changes the logic too much. That way if there's an error in the patch that changes the logic and it needs to be reverted, it won't also revert the warning fixes. Makes sense to me. Yes that's fine with me as well, I don't wish to over complicate matters. I have a couple minor comments though and will respond to the latest patch rev. Actually, nevermind the latest version is fine with me. Jon Applying the second version into omap-for-v4.1/fixes-not-urgent. 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 v6 2/6] wl12xx: use frequency instead of enumerations for pdata clocks
Arnd Bergmann a...@arndb.de writes: On Sunday 15 March 2015 10:43:35 Eliad Peller wrote: The other option would be to have the whole series in a immutable branch against v3.0-rc1 that can be merged into both wirelss tree and omap tree. i think that could be easier. or maybe you can just take them all through the omap tree? the wlcore tree is not under active development, so i don't expect conflicts there. I'm fine with both these approaches. I prefer these going through the omap tree. Like Eliad said, drivers/net/wireless/ti does not get that many changes nowadays so the chances of this patchset conflicting with something is very small. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] ARM: devicetree: Remove unused ti,codec property
On 03/13/2015 10:40 PM, Marek Belisko wrote: ti,codec in not parsed in omap-twl4030 sound driver. It's not necessary to specify this property in DT because ti,twl4030-audio which ti,codec was pointing to by phandle is mfd driver and device for ASoC ic created w/o any DT property (codec name is hardcoded in ASoC driver). Please see reply [1] from Peter Ujfalusi. All: Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Changes from v1: - keep ti,codec property in Documentation as optional that the existing dtbs do not become noncompliant after the change [1]: http://comments.gmane.org/gmane.linux.ports.arm.omap/124273 Marek Belisko (2): ARM: dts: omap3: Remove all references to ti,codec property Documentation: omap-twl4030: Move ti,codec property to optional Documentation/devicetree/bindings/sound/omap-twl4030.txt | 3 +-- arch/arm/boot/dts/omap3-beagle-xm.dts| 1 - arch/arm/boot/dts/omap3-beagle.dts | 1 - arch/arm/boot/dts/omap3-cm-t3x30.dtsi| 1 - arch/arm/boot/dts/omap3-devkit8000.dts | 1 - arch/arm/boot/dts/omap3-gta04.dtsi | 1 - arch/arm/boot/dts/omap3-igep.dtsi| 1 - arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 1 - arch/arm/boot/dts/omap3-overo-base.dtsi | 1 - arch/arm/boot/dts/omap3-tao3530.dtsi | 1 - 10 files changed, 1 insertion(+), 11 deletions(-) -- 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 v6 6/6] wlcore: remove wl12xx_platform_data
* 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. 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
[PATCH 21/35 linux-next] mfd: constify of_device_id array
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick f...@skynet.be
---
drivers/mfd/hi6421-pmic-core.c | 2 +-
drivers/mfd/rk808.c| 2 +-
drivers/mfd/twl4030-power.c| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/hi6421-pmic-core.c b/drivers/mfd/hi6421-pmic-core.c
index 7210ae2..95b2ff8 100644
--- a/drivers/mfd/hi6421-pmic-core.c
+++ b/drivers/mfd/hi6421-pmic-core.c
@@ -93,7 +93,7 @@ static int hi6421_pmic_remove(struct platform_device *pdev)
return 0;
}
-static struct of_device_id of_hi6421_pmic_match_tbl[] = {
+static const struct of_device_id of_hi6421_pmic_match_tbl[] = {
{ .compatible = hisilicon,hi6421-pmic, },
{ },
};
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 7cf25c7..4b1e439 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -246,7 +246,7 @@ static int rk808_remove(struct i2c_client *client)
return 0;
}
-static struct of_device_id rk808_of_match[] = {
+static const struct of_device_id rk808_of_match[] = {
{ .compatible = rockchip,rk808 },
{ },
};
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 3935092..f440aed 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -829,7 +829,7 @@ static struct twl4030_power_data osc_off_idle = {
.board_config = osc_off_rconfig,
};
-static struct of_device_id twl4030_power_of_match[] = {
+static const struct of_device_id twl4030_power_of_match[] = {
{
.compatible = ti,twl4030-power,
},
--
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 00/35 linux-next] constify of_device_id array
This small patchset adds const to of_device_id arrays in drivers branch. Fabian Frederick (35): ata: constify of_device_id array regulator: constify of_device_id array thermal: constify of_device_id array tty/hvc_opal: constify of_device_id array tty: constify of_device_id array power: constify of_device_id array char: constify of_device_id array dma: constify of_device_id array iio: constify of_device_id array misc: constify of_device_id array usb: gadget: constify of_device_id array mtd: constify of_device_id array w1: constify of_device_id array ide: pmac: constify of_device_id array spi: constify of_device_id array video: constify of_device_id array coresight-replicator: constify of_device_id array macintosh: constify of_device_id array virtio_mmio: constify of_device_id array swim3: constify of_device_id array mfd: constify of_device_id array soc: ti: constify of_device_id array [media]: constify of_device_id array Input: constify of_device_id array PCI: constify of_device_id array hwmon: constify of_device_id array reset: sti: constify of_device_id array uio: constify of_device_id array gpu: constify of_device_id array devfreq: constify of_device_id array EDAC: constify of_device_id array clk: constify of_device_id array mmc: constify of_device_id array Staging: octeon: constify of_device_id array pinctrl: constify of_device_id array drivers/ata/pata_macio.c | 2 +- drivers/ata/pata_mpc52xx.c | 2 +- drivers/ata/pata_octeon_cf.c | 2 +- drivers/ata/pata_of_platform.c | 2 +- drivers/ata/sata_fsl.c | 2 +- drivers/ata/sata_mv.c| 2 +- drivers/ata/sata_rcar.c | 2 +- drivers/block/swim3.c| 2 +- drivers/char/hw_random/pasemi-rng.c | 2 +- drivers/char/hw_random/powernv-rng.c | 2 +- drivers/char/hw_random/ppc4xx-rng.c | 2 +- drivers/char/ipmi/ipmi_si_intf.c | 4 ++-- drivers/char/xillybus/xillybus_of.c | 2 +- drivers/clk/clk-palmas.c | 2 +- drivers/clk/st/clkgen-fsyn.c | 2 +- drivers/clk/st/clkgen-mux.c | 8 drivers/clk/st/clkgen-pll.c | 4 ++-- drivers/clk/ti/clk-dra7-atl.c| 2 +- drivers/clk/ti/clockdomain.c | 2 +- drivers/clk/versatile/clk-vexpress-osc.c | 2 +- drivers/coresight/coresight-replicator.c | 2 +- drivers/devfreq/event/exynos-ppmu.c | 2 +- drivers/devfreq/tegra-devfreq.c | 2 +- drivers/dma/bestcomm/bestcomm.c | 4 ++-- drivers/dma/k3dma.c | 2 +- drivers/dma/mmp_pdma.c | 2 +- drivers/dma/mmp_tdma.c | 2 +- drivers/dma/mpc512x_dma.c| 2 +- drivers/dma/mv_xor.c | 2 +- drivers/dma/sirf-dma.c | 2 +- drivers/dma/sun6i-dma.c | 2 +- drivers/edac/highbank_mc_edac.c | 2 +- drivers/edac/mpc85xx_edac.c | 4 ++-- drivers/edac/ppc4xx_edac.c | 2 +- drivers/edac/synopsys_edac.c | 2 +- drivers/gpio/gpio-mpc8xxx.c | 2 +- drivers/gpio/gpio-octeon.c | 2 +- drivers/gpio/gpio-tz1090-pdc.c | 2 +- drivers/gpio/gpio-tz1090.c | 2 +- drivers/gpio/gpio-zynq.c | 2 +- drivers/gpu/drm/armada/armada_crtc.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/exynos/exynos_mixer.c| 2 +- drivers/gpu/drm/panel/panel-ld9040.c | 2 +- drivers/gpu/drm/panel/panel-s6e8aa0.c| 2 +- drivers/gpu/drm/sti/sti_dvo.c| 2 +- drivers/gpu/drm/sti/sti_hqvdp.c | 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++-- drivers/gpu/drm/tilcdc/tilcdc_panel.c| 2 +- drivers/gpu/drm/tilcdc/tilcdc_slave.c| 4 ++-- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 4 ++-- drivers/gpu/host1x/dev.c | 2 +- drivers/gpu/host1x/mipi.c| 2 +- drivers/hwmon/pwm-fan.c | 2 +- drivers/hwmon/vexpress.c | 2 +- drivers/ide/pmac.c | 2 +- drivers/iio/common/ssp_sensors/ssp_dev.c | 2 +- drivers/input/misc/palmas-pwrbutton.c| 2 +- drivers/input/misc/regulator-haptic.c| 2 +- drivers/input/misc/tps65218-pwrbutton.c | 2 +- drivers/input/touchscreen/ar1021_i2c.c | 2 +- drivers/macintosh/mediabay.c | 2 +- drivers/macintosh/rack-meter.c | 2 +- drivers/media/i2c/adv7604.c | 2 +- drivers/media/platform/fsl-viu.c | 2 +- drivers/media/platform/soc_camera/rcar_vin.c
[PATCH 02/35 linux-next] regulator: constify of_device_id array
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick f...@skynet.be
---
drivers/regulator/palmas-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 9205f43..eecce1e 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1505,7 +1505,7 @@ static void palmas_dt_to_pdata(struct device *dev,
pdata-ldo6_vibrator = of_property_read_bool(node, ti,ldo6-vibrator);
}
-static struct of_device_id of_palmas_match_tbl[] = {
+static const struct of_device_id of_palmas_match_tbl[] = {
{
.compatible = ti,palmas-pmic,
.data = palmas_ddata,
--
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 v6 6/6] wlcore: remove wl12xx_platform_data
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. -- Sebastian signature.asc Description: Digital signature
Serious memory leak in TI EDMA driver (drivers/dma/edma.c)
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. 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. 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 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. 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? 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. Thank you Petr -- Petr Kulhavy, MSc System Architect Barix AG, Zürich, Switzerland -- 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: config: omap2plus_defconfig: switch over to LZMA compression
* Felipe Balbi ba...@ti.com [150130 09:22]: LZMA compression makes about 33% smaller zImage with just a slight extra decompression time. Before this patch, zImage built with o2+_dc is 4.5MiB and after it's about 3.3MiB. Suggested-by: David Cohen david.a.co...@linux.intel.com Signed-off-by: Felipe Balbi ba...@ti.com Applying this into omap-for-v4.1/defconfig thanks. 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 b7386524c356..742c62b6d663 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -1,3 +1,4 @@ +CONFIG_KERNEL_LZMA=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_FHANDLE=y -- 2.3.0-rc1 -- 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: omap1_defconfig: drop obsolete Kconfig symbols
* Paul Walmsley p...@pwsan.com [150206 16:29]: scripts/checkkconfigsymbols.py indicates that omap1_defconfig references the following obsolete Kconfig symbols: CONFIG_BT_L2CAP CONFIG_BT_SCO CONFIG_DEBUG_ERRORS CONFIG_EXPERIMENTAL CONFIG_FB_OMAP_BOOTLOADER_INIT CONFIG_LEDS_CPU CONFIG_MACH_OMAP_HTCWIZARD CONFIG_MTD_CHAR CONFIG_MTD_DEBUG CONFIG_MTD_DEBUG_VERBOSE CONFIG_MTD_PARTITIONS CONFIG_NET_ETHERNET CONFIG_RCU_CPU_STALL_DETECTOR CONFIG_SCSI_MULTI_LUN CONFIG_USB_DEVICE_CLASS CONFIG_VIDEO_OUTPUT_CONTROL Drop them from omap1_defconfig. Applying this one into omap-for-v4.1/defconfig 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
Serious memory leak in TI EDMA driver (drivers/dma/edma.c)
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. 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. 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 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. 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? 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. Thank you Petr -- Petr Kulhavy, MSc System Architect Barix AG, Zürich, Switzerland -- 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] clk: ti: clk-3xxx-legacy: Correct McBSP related clock aliases
Correct the McBSP2/4 ick mapping (they were 2-4 and 4-2).
Add missing mcbsp clock aliases.
Collect the McBSP clock definition in one location at the same time.
Fixes the following warning on boot:
[0.307739] omap_hwmod: mcbsp2: _wait_target_ready failed: -16
[0.307769] omap_hwmod: mcbsp2: cannot be enabled for reset (3)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/clk/ti/clk-3xxx-legacy.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/ti/clk-3xxx-legacy.c b/drivers/clk/ti/clk-3xxx-legacy.c
index e0732a4c8f26..0b61548d569b 100644
--- a/drivers/clk/ti/clk-3xxx-legacy.c
+++ b/drivers/clk/ti/clk-3xxx-legacy.c
@@ -4320,7 +4320,6 @@ static struct ti_clk_alias omap3xxx_clks[] = {
CLK(NULL, dpll3_m3x2_ck, dpll3_m3x2_ck),
CLK(etb, emu_core_alwon_ck, emu_core_alwon_ck),
CLK(NULL, sys_altclk, sys_altclk),
- CLK(NULL, mcbsp_clks, mcbsp_clks),
CLK(NULL, sys_clkout1, sys_clkout1),
CLK(NULL, dpll3_m2_ck, dpll3_m2_ck),
CLK(NULL, core_ck, core_ck),
@@ -4369,8 +4368,6 @@ static struct ti_clk_alias omap3xxx_clks[] = {
CLK(NULL, i2c3_fck, i2c3_fck),
CLK(NULL, i2c2_fck, i2c2_fck),
CLK(NULL, i2c1_fck, i2c1_fck),
- CLK(NULL, mcbsp5_fck, mcbsp5_fck),
- CLK(NULL, mcbsp1_fck, mcbsp1_fck),
CLK(NULL, core_48m_fck, core_48m_fck),
CLK(NULL, mcspi4_fck, mcspi4_fck),
CLK(NULL, mcspi3_fck, mcspi3_fck),
@@ -4409,8 +4406,6 @@ static struct ti_clk_alias omap3xxx_clks[] = {
CLK(NULL, uart1_ick, uart1_ick),
CLK(NULL, gpt11_ick, gpt11_ick),
CLK(NULL, gpt10_ick, gpt10_ick),
- CLK(omap-mcbsp.5, ick, mcbsp5_ick),
- CLK(omap-mcbsp.1, ick, mcbsp1_ick),
CLK(NULL, mcbsp5_ick, mcbsp5_ick),
CLK(NULL, mcbsp1_ick, mcbsp1_ick),
CLK(NULL, omapctrl_ick, omapctrl_ick),
@@ -4467,15 +4462,22 @@ static struct ti_clk_alias omap3xxx_clks[] = {
CLK(NULL, gpt4_ick, gpt4_ick),
CLK(NULL, gpt3_ick, gpt3_ick),
CLK(NULL, gpt2_ick, gpt2_ick),
+ CLK(NULL, mcbsp_clks, mcbsp_clks),
+ CLK(omap-mcbsp.1, ick, mcbsp1_ick),
CLK(omap-mcbsp.2, ick, mcbsp2_ick),
CLK(omap-mcbsp.3, ick, mcbsp3_ick),
CLK(omap-mcbsp.4, ick, mcbsp4_ick),
- CLK(NULL, mcbsp4_ick, mcbsp2_ick),
+ CLK(omap-mcbsp.5, ick, mcbsp5_ick),
+ CLK(NULL, mcbsp1_ick, mcbsp1_ick),
+ CLK(NULL, mcbsp2_ick, mcbsp2_ick),
CLK(NULL, mcbsp3_ick, mcbsp3_ick),
- CLK(NULL, mcbsp2_ick, mcbsp4_ick),
+ CLK(NULL, mcbsp4_ick, mcbsp4_ick),
+ CLK(NULL, mcbsp5_ick, mcbsp5_ick),
+ CLK(NULL, mcbsp1_fck, mcbsp1_fck),
CLK(NULL, mcbsp2_fck, mcbsp2_fck),
CLK(NULL, mcbsp3_fck, mcbsp3_fck),
CLK(NULL, mcbsp4_fck, mcbsp4_fck),
+ CLK(NULL, mcbsp5_fck, mcbsp5_fck),
CLK(NULL, emu_src_mux_ck, emu_src_mux_ck),
CLK(etb, emu_src_ck, emu_src_ck),
CLK(NULL, emu_src_mux_ck, emu_src_mux_ck),
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] clk: ti: clk-3xxx: Correct McBSP related DT clock definitions
In DT boot we do not have devices named as omap-mcbsp.X.
Correct the McBSP2/4 ick mapping (they were 2-4 and 4-2).
Collect the McBSP clock definition in one location at the same time.
Fixes the following warning on boot:
[0.307739] omap_hwmod: mcbsp2: _wait_target_ready failed: -16
[0.307769] omap_hwmod: mcbsp2: cannot be enabled for reset (3)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/clk/ti/clk-3xxx.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index 383a06e49b09..757636d166cf 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -34,7 +34,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck),
DT_CLK(etb, emu_core_alwon_ck, emu_core_alwon_ck),
DT_CLK(NULL, sys_altclk, sys_altclk),
- DT_CLK(NULL, mcbsp_clks, mcbsp_clks),
DT_CLK(NULL, sys_clkout1, sys_clkout1),
DT_CLK(NULL, dpll1_ck, dpll1_ck),
DT_CLK(NULL, dpll1_x2_ck, dpll1_x2_ck),
@@ -82,8 +81,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, i2c3_fck, i2c3_fck),
DT_CLK(NULL, i2c2_fck, i2c2_fck),
DT_CLK(NULL, i2c1_fck, i2c1_fck),
- DT_CLK(NULL, mcbsp5_fck, mcbsp5_fck),
- DT_CLK(NULL, mcbsp1_fck, mcbsp1_fck),
DT_CLK(NULL, core_48m_fck, core_48m_fck),
DT_CLK(NULL, mcspi4_fck, mcspi4_fck),
DT_CLK(NULL, mcspi3_fck, mcspi3_fck),
@@ -122,10 +119,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, uart1_ick, uart1_ick),
DT_CLK(NULL, gpt11_ick, gpt11_ick),
DT_CLK(NULL, gpt10_ick, gpt10_ick),
- DT_CLK(omap-mcbsp.5, ick, mcbsp5_ick),
- DT_CLK(omap-mcbsp.1, ick, mcbsp1_ick),
- DT_CLK(NULL, mcbsp5_ick, mcbsp5_ick),
- DT_CLK(NULL, mcbsp1_ick, mcbsp1_ick),
DT_CLK(NULL, omapctrl_ick, omapctrl_ick),
DT_CLK(NULL, dss_tv_fck, dss_tv_fck),
DT_CLK(NULL, dss_96m_fck, dss_96m_fck),
@@ -179,15 +172,17 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, gpt4_ick, gpt4_ick),
DT_CLK(NULL, gpt3_ick, gpt3_ick),
DT_CLK(NULL, gpt2_ick, gpt2_ick),
- DT_CLK(omap-mcbsp.2, ick, mcbsp2_ick),
- DT_CLK(omap-mcbsp.3, ick, mcbsp3_ick),
- DT_CLK(omap-mcbsp.4, ick, mcbsp4_ick),
- DT_CLK(NULL, mcbsp4_ick, mcbsp2_ick),
+ DT_CLK(NULL, mcbsp_clks, mcbsp_clks),
+ DT_CLK(NULL, mcbsp1_ick, mcbsp1_ick),
+ DT_CLK(NULL, mcbsp2_ick, mcbsp2_ick),
DT_CLK(NULL, mcbsp3_ick, mcbsp3_ick),
- DT_CLK(NULL, mcbsp2_ick, mcbsp4_ick),
+ DT_CLK(NULL, mcbsp4_ick, mcbsp4_ick),
+ DT_CLK(NULL, mcbsp5_ick, mcbsp5_ick),
+ DT_CLK(NULL, mcbsp1_fck, mcbsp1_fck),
DT_CLK(NULL, mcbsp2_fck, mcbsp2_fck),
DT_CLK(NULL, mcbsp3_fck, mcbsp3_fck),
DT_CLK(NULL, mcbsp4_fck, mcbsp4_fck),
+ DT_CLK(NULL, mcbsp5_fck, mcbsp5_fck),
DT_CLK(etb, emu_src_ck, emu_src_ck),
DT_CLK(NULL, emu_src_ck, emu_src_ck),
DT_CLK(NULL, pclk_fck, pclk_fck),
--
2.3.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: Serious memory leak in TI EDMA driver (drivers/dma/edma.c)
Hi, * Petr Kulhavy p...@barix.com [150316 12:26]: 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. 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. 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 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. 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? 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. Thanks for reporting it. This sounds like something for Peter to look at. 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
[PATCH 32/35 linux-next] clk: constify of_device_id array
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick f...@skynet.be
---
drivers/clk/clk-palmas.c | 2 +-
drivers/clk/st/clkgen-fsyn.c | 2 +-
drivers/clk/st/clkgen-mux.c | 8
drivers/clk/st/clkgen-pll.c | 4 ++--
drivers/clk/ti/clk-dra7-atl.c| 2 +-
drivers/clk/ti/clockdomain.c | 2 +-
drivers/clk/versatile/clk-vexpress-osc.c | 2 +-
7 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
index 8d45992..45a535a 100644
--- a/drivers/clk/clk-palmas.c
+++ b/drivers/clk/clk-palmas.c
@@ -161,7 +161,7 @@ static struct palmas_clks_of_match_data
palmas_of_clk32kgaudio = {
},
};
-static struct of_device_id palmas_clks_of_match[] = {
+static const struct of_device_id palmas_clks_of_match[] = {
{
.compatible = ti,palmas-clk32kg,
.data = palmas_of_clk32kg,
diff --git a/drivers/clk/st/clkgen-fsyn.c b/drivers/clk/st/clkgen-fsyn.c
index af94ed8..a917c4c 100644
--- a/drivers/clk/st/clkgen-fsyn.c
+++ b/drivers/clk/st/clkgen-fsyn.c
@@ -1057,7 +1057,7 @@ static struct clk * __init st_clk_register_quadfs_fsynth(
return clk;
}
-static struct of_device_id quadfs_of_match[] = {
+static const struct of_device_id quadfs_of_match[] = {
{
.compatible = st,stih416-quadfs216,
.data = st_fs216c65_416
diff --git a/drivers/clk/st/clkgen-mux.c b/drivers/clk/st/clkgen-mux.c
index 9a15ec3..fdcff10 100644
--- a/drivers/clk/st/clkgen-mux.c
+++ b/drivers/clk/st/clkgen-mux.c
@@ -341,7 +341,7 @@ static struct clkgena_divmux_data st_divmux_c32odf3 = {
.fb_start_bit_idx = 24,
};
-static struct of_device_id clkgena_divmux_of_match[] = {
+static const struct of_device_id clkgena_divmux_of_match[] = {
{
.compatible = st,clkgena-divmux-c65-hs,
.data = st_divmux_c65hs,
@@ -479,7 +479,7 @@ static struct clkgena_prediv_data prediv_c32_data = {
.table = prediv_table16,
};
-static struct of_device_id clkgena_prediv_of_match[] = {
+static const struct of_device_id clkgena_prediv_of_match[] = {
{ .compatible = st,clkgena-prediv-c65, .data = prediv_c65_data },
{ .compatible = st,clkgena-prediv-c32, .data = prediv_c32_data },
{}
@@ -586,7 +586,7 @@ static struct clkgen_mux_data stih407_a9_mux_data = {
.width = 2,
};
-static struct of_device_id mux_of_match[] = {
+static const struct of_device_id mux_of_match[] = {
{
.compatible = st,stih416-clkgenc-vcc-hd,
.data = clkgen_mux_c_vcc_hd_416,
@@ -693,7 +693,7 @@ static struct clkgen_vcc_data st_clkgenf_vcc_416 = {
.lock = clkgenf_lock,
};
-static struct of_device_id vcc_of_match[] = {
+static const struct of_device_id vcc_of_match[] = {
{ .compatible = st,stih416-clkgenc, .data = st_clkgenc_vcc_416 },
{ .compatible = st,stih416-clkgenf, .data = st_clkgenf_vcc_416 },
{}
diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index 29769d7..d204ba8 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -593,7 +593,7 @@ static struct clk * __init clkgen_odf_register(const char
*parent_name,
return clk;
}
-static struct of_device_id c32_pll_of_match[] = {
+static const struct of_device_id c32_pll_of_match[] = {
{
.compatible = st,plls-c32-a1x-0,
.data = st_pll3200c32_a1x_0,
@@ -708,7 +708,7 @@ err:
}
CLK_OF_DECLARE(clkgen_c32_pll, st,clkgen-plls-c32, clkgen_c32_pll_setup);
-static struct of_device_id c32_gpu_pll_of_match[] = {
+static const struct of_device_id c32_gpu_pll_of_match[] = {
{
.compatible = st,stih415-gpu-pll-c32,
.data = st_pll1200c32_gpu_415,
diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c
index 59bb4b3..d86bc46 100644
--- a/drivers/clk/ti/clk-dra7-atl.c
+++ b/drivers/clk/ti/clk-dra7-atl.c
@@ -294,7 +294,7 @@ static int of_dra7_atl_clk_remove(struct platform_device
*pdev)
return 0;
}
-static struct of_device_id of_dra7_atl_clk_match_tbl[] = {
+static const struct of_device_id of_dra7_atl_clk_match_tbl[] = {
{ .compatible = ti,dra7-atl, },
{},
};
diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
index b4c5fac..35fe108 100644
--- a/drivers/clk/ti/clockdomain.c
+++ b/drivers/clk/ti/clockdomain.c
@@ -52,7 +52,7 @@ static void __init of_ti_clockdomain_setup(struct device_node
*node)
}
}
-static struct of_device_id ti_clkdm_match_table[] __initdata = {
+static const struct of_device_id ti_clkdm_match_table[] __initconst = {
{ .compatible = ti,clockdomain },
{ }
};
diff --git a/drivers/clk/versatile/clk-vexpress-osc.c
b/drivers/clk/versatile/clk-vexpress-osc.c
index 765f1e0..89c0609
[PATCH 0/3] Few omap2plus_defconfig updates
Hi all, Here are few minor updates to add support for things as loadable modules to omap2plus_defconfig for a few devices I noticed we are not enabling by default. Regards, Tony Tony Lindgren (3): ARM: omap2plus_defconfig: Enable leds-pwm ARM: omap2plus_defconfig: Update bluetooth options ARM: omap2plus_defconfig: Enable n900 modem as loadable modules arch/arm/configs/omap2plus_defconfig | 26 ++ 1 file changed, 26 insertions(+) -- 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 2/3] ARM: omap2plus_defconfig: Update bluetooth options
Many omaps have bluetooth, so let's make it available as modules. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/configs/omap2plus_defconfig | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index df41f2c..6c7722d 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -91,13 +91,28 @@ CONFIG_CAN=m CONFIG_CAN_C_CAN=m CONFIG_CAN_C_CAN_PLATFORM=m CONFIG_BT=m +CONFIG_BT_RFCOMM=m +CONFIG_BT_RFCOMM_TTY=y +CONFIG_BT_BNEP=m +CONFIG_BT_BNEP_MC_FILTER=y +CONFIG_BT_BNEP_PROTO_FILTER=y +CONFIG_BT_HIDP=m +CONFIG_BT_HCIBTUSB=m +CONFIG_BT_HCIBTSDIO=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_LL=y +CONFIG_BT_HCIUART_3WIRE=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_CFG80211=m +CONFIG_BT_HCIBFUSB=m +CONFIG_BT_HCIVHCI=m +CONFIG_BT_MRVL=m +CONFIG_BT_MRVL_SDIO=m +CONFIG_AF_RXRPC=m +CONFIG_RXKAD=m CONFIG_MAC80211=m CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y -- 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
Re: [RFC PATCH] dts: Add am335x-wega-rdk.dtb sources for phyBOARD-Wega-AM335x
* Matwey V. Kornilov mat...@sai.msu.ru [150312 23:58]: Hi, Teresa replied me, but unfortunately I found that the answer not reached the public maillists. Briefly, we don't need this patch, PhyTec will send better one this year. OK will ignore this one then. This year sounds a bit long time to wait though.. How about maybe send it a bit sooner? :) 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
[PATCH] mfd: twl6040: match wait_for_completion_timeout return type
Return type of wait_for_completion_timeout is unsigned long not int. As
time_left is exclusively used for wait_for_completion_timeout here its
type is simply changed to unsigned long.
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
Patch was compile tested with x86_64_defconfig + CONFIG_TWL6040_CORE=y
Patch is against 4.0-rc3 (localversion-next is -next-20150316)
drivers/mfd/twl6040.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index f71ee3d..d6f9761 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -259,7 +259,7 @@ static irqreturn_t twl6040_thint_handler(int irq, void
*data)
static int twl6040_power_up_automatic(struct twl6040 *twl6040)
{
- int time_left;
+ unsigned long time_left;
gpio_set_value(twl6040-audpwron, 1);
--
1.7.10.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
Re: [PATCH] gpio: pcf857x: restore the initial line state of all pcf lines
Hi,
On Wednesday 14 January 2015 05:28 PM, Linus Walleij wrote:
On Mon, Jan 5, 2015 at 7:26 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
On Thursday 18 December 2014 07:41 PM, Nishanth Menon wrote:
On 12/18/2014 12:18 AM, Kishon Vijay Abraham I wrote:
On Tuesday 16 December 2014 02:20 AM, Nishanth Menon wrote:
On 12/12/2014 02:06 AM, Kishon Vijay Abraham I wrote:
The reset values for all the PCF lines are high and hence on shutdown
we should drive all the lines high in order to bring it to the reset state.
This is actually required since pcf doesn't have a reset line and even after
warm reset (by invoking reboot in prompt) the pcf lines maintains it's
previous programmed state. This becomes a problem if the boards are designed
to work with the default initial state.
DRA7XX_evm uses PCF8575 and one of the PCF output lines feeds to MMC/SD and
this line should be driven high in order for the MMC/SD to be detected.
This line is modelled as regulator and the hsmmc driver takes care of enabling
and disabling it. In the case of 'reboot', during shutdown path as part of it's
cleanup process the hsmmc driver disables this regulator. This makes MMC boot
not functional.
Fixed it by driving high all the pcf lines.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/gpio/gpio-pcf857x.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 236708a..00b15b2 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -448,6 +448,14 @@ static int pcf857x_remove(struct i2c_client *client)
return status;
}
+static void pcf857x_shutdown(struct i2c_client *client)
+{
+ struct pcf857x *gpio = i2c_get_clientdata(client);
+
+ /* Drive all the I/O lines high */
+ gpio-write(gpio-client, BIT(gpio-chip.ngpio) - 1);
you might force a contention here - depending on System configuration.
example:
+---+
| |
| U1 | +--+ +---+
| +- | | |
+---+ | | | |
| Switch-+SoC|
+---+ | | | |
| | | | | |
| U2-+--^---+ +---+
| ||
| ||
+---+|
+--+--+
| |
| PCF |
| |
+-+
At low, SoC pin is connected to U2 as drive. when reset to high, you
now have U1 driving to the same pin that SoC has, potentially
resulting in contention.
Unfortunately, at this level, you do not know what the state of the
system is, blindly forcing a pin level will potentially cause
contention risk depending on pin configuration.
Assume we are doing a reset when the system is powered on, irrespective of the
state of the system, we'll be forcing the pin level to the default state.
Yes, I dont deny that system will be fine *after* reset sequence is
started or completed. However there is a duration between the pcf
shutdown handler is called and the final reset handler is invoked -
that is the duration when the contention might cause device behavior.
Essentially ignoring the state various drivers have asked PCF to setup
the pins and doing a hands down configuration may have side effects we
cant properly expect.
The solution might be to invoke the shutdown handler of the various drivers
using the PCF before the shutdown handler of the PCF driver itself gets
invoked? But I'm not sure how can that be achieved in linux kernel :-(
#include linux/reboot.h
static int foo_reboot_handler(struct notifier_block *this,
unsigned long code,
void *unused)
{
pr_crit(do some last minute stuff\n);
return NOTIFY_OK;
}
static struct notifier_block foo_reboot_notifier = {
.notifier_call = foo_reboot_handler,
};
register_reboot_notifier(foo_reboot_notifier);
Added debug prints and found the reboot notifier gets invoked before the
shutdown handler which means some stuff can be done after this reboot
notifier:-(
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Hi Sakari, Thank you for the patch. On Monday 16 March 2015 02:26:07 Sakari Ailus wrote: Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..27cfa4e 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,12 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarity: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + If the lane-polarity property is omitted, the value must be interpreted as 0 + (normal). This property is valid for serial busses only. Example -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/15] v4l: of: Read lane-polarity endpoint property
Hi Sakari,
Thank you for the patch.
On Monday 16 March 2015 02:26:08 Sakari Ailus wrote:
Add lane_polarity field to struct v4l2_of_bus_mipi_csi2 and write the
contents of the lane polarity property to it. The field tells the polarity
of the physical lanes starting from the first one. Any unused lanes are
ignored, i.e. only the polarity of the used lanes is specified.
Also rework reading the data-lanes property a little.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/v4l2-core/v4l2-of.c | 41 ++
include/media/v4l2-of.h |3 +++
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c index b4ed9a9..e44cc15 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -19,11 +19,10 @@
#include media/v4l2-of.h
-static void v4l2_of_parse_csi_bus(const struct device_node *node,
- struct v4l2_of_endpoint *endpoint)
+static int v4l2_of_parse_csi_bus(const struct device_node *node,
+ struct v4l2_of_endpoint *endpoint)
{
struct v4l2_of_bus_mipi_csi2 *bus = endpoint-bus.mipi_csi2;
- u32 data_lanes[ARRAY_SIZE(bus-data_lanes)];
struct property *prop;
bool have_clk_lane = false;
unsigned int flags = 0;
@@ -32,16 +31,34 @@ static void v4l2_of_parse_csi_bus(const struct
device_node *node, prop = of_find_property(node, data-lanes, NULL);
if (prop) {
const __be32 *lane = NULL;
- int i;
+ unsigned int i;
- for (i = 0; i ARRAY_SIZE(data_lanes); i++) {
- lane = of_prop_next_u32(prop, lane, data_lanes[i]);
+ for (i = 0; i ARRAY_SIZE(bus-data_lanes); i++) {
+ lane = of_prop_next_u32(prop, lane, v);
if (!lane)
break;
+ bus-data_lanes[i] = v;
}
bus-num_data_lanes = i;
- while (i--)
- bus-data_lanes[i] = data_lanes[i];
+ }
+
+ prop = of_find_property(node, lane-polarity, NULL);
+ if (prop) {
+ const __be32 *polarity = NULL;
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(bus-lane_polarity); i++) {
+ polarity = of_prop_next_u32(prop, polarity, v);
+ if (!polarity)
+ break;
+ bus-lane_polarity[i] = v;
+ }
+
+ if (i 1 + bus-num_data_lanes /* clock + data */) {
+ pr_warn(bad size of lane-polarity array in node %s,
was %u,
should be
%u\n,
How about
pr_warn(%s: too few lane-polarity entries (need %u, got %u)\n,
node-full_name, 1 + bus-num_data_lanes, i);
+ node-full_name, i, 1 + bus-num_data_lanes);
+ return -EINVAL;
+ }
}
if (!of_property_read_u32(node, clock-lanes, v)) {
@@ -56,6 +73,8 @@ static void v4l2_of_parse_csi_bus(const struct device_node
*node,
bus-flags = flags;
endpoint-bus_type = V4L2_MBUS_CSI2;
+
+ return 0;
}
static void v4l2_of_parse_parallel_bus(const struct device_node *node,
@@ -127,11 +146,15 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node, int v4l2_of_parse_endpoint(const struct device_node
*node,
struct v4l2_of_endpoint *endpoint)
{
+ int rval;
+
of_graph_parse_endpoint(node, endpoint-base);
endpoint-bus_type = 0;
memset(endpoint-bus, 0, sizeof(endpoint-bus));
- v4l2_of_parse_csi_bus(node, endpoint);
+ rval = v4l2_of_parse_csi_bus(node, endpoint);
+ if (rval)
+ return rval;
/*
* Parse the parallel video bus properties only if none
* of the MIPI CSI-2 specific properties were found.
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index 70fa7b7..a70eb52 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -29,12 +29,15 @@ struct device_node;
* @data_lanes: an array of physical data lane indexes
* @clock_lane: physical lane index of the clock lane
* @num_data_lanes: number of data lanes
+ * @lane_polarity: polarity of the lanes. The order is the same of
+ * the physical lanes.
*/
struct v4l2_of_bus_mipi_csi2 {
unsigned int flags;
unsigned char data_lanes[4];
unsigned char clock_lane;
unsigned short num_data_lanes;
+ bool lane_polarity[5];
A bit of bike-shedding here, should this be lane_polarities ? And, thinking
about it, should the DT property be renamed to lane-polarities as well ?
This would match data-lanes.
};
/**
--
Regards,
Laurent Pinchart
--
To unsubscribe from this
