Re: [PATCH] OMAPDSS: restore name sysfs entry.
On Tue, 24 Feb 2015 12:40:32 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, On 24/02/15 11:37, NeilBrown wrote: commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b OMAPDSS: rename display-sysfs 'name' entry broke the xorg X server on my device as it couldn't find the display any more. It needs the 'name' file and now there isn't one. That commit claims that 'name' is not compatible with i2c or spi. i2c does register it own 'name' file, but spi does not, hence my problem - I have an spi display. So create a special case for i2c: add the name attribute for non-i2c devices. What X driver is that? What's it doing with the display name? Is it just using the display name to show something for the user, and the returned value can be essentially any string? Tomi /usr/lib/xorg/modules/drivers/omapfb_drv.so from package xserver-xorg-video-omap3 in Debian. I don't know where the main upstream source is, but here: https://gitorious.org/gnutoo-s-programs-for-shr/xf86-video-omapfb/source/28c006c94e57ea71df11ec4fff79d7ffcfc4860f:src/omapfb-output-dss.c#L258 is the code which reads /sys/devices/platform/omapdss/display0/name and fails if that file cannot be opened. Thanks, NeilBrown pgpU5K5ew1vFC.pgp Description: OpenPGP digital signature
Re: [PATCH 0/4] Enhancements to twl4030 phy to support better charging.
* NeilBrown ne...@suse.de [150223 19:45]: Hi, the following 4 patches make some improvements to the twl4030 phy. Together with some other patches I have for twl4030_charger, they allow for better automatic control of charging. In particular, the status of the ID pin is assessed and the result in communicated to the charger drivers. There is also support for conveying the max current negotiated by a host to the charger. Comments most welcome. Looks good to me, for the whole series, please feel free to add: Tested-by: Tony Lindgren t...@atomide.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
[GIT PULL] omap fixes against v4.0-rc1
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/fixes-v4.0-rc1 for you to fetch changes up to 67fd14b3eca63b14429350e9eadc5fab709a8821: ARM: dts: am335x-bone*: usb0 is hardwired for peripheral (2015-02-24 10:35:44 -0800) Fixes for various omap devices. It's all dts and defconfig changes for this set: - Fix wrong DMA properties for dma to avoid them getting copied wrong again before we start actually using them - USB fixes to revert the extcon changes as the driver did not get merged yet and cause issues - Omap5 and dra7 fixes to boot from sata - Fix few am437x issues for i2c and pinctrl - Fix beaglebone for hardwared USB configuration - Defconfig changes for NAND, SATA and TPS62362 - Fix n900 i2c numbering for legacy user space and smc91x register offset so it works also for qemu - Fix incomplete USB configuration for dm816x Felipe Balbi (3): ARM: dts: am437x-idk: fix TPS62362 i2c bus ARM: omap2plus_defconfig: enable TPS62362 regulator ARM: dts: am437x-idk: fix sleep pinctrl state Ivaylo Dimitrov (1): ARM: dts: n900: fix i2c bus numbering Pali Rohár (1): ARM: dts: n900: Fix offset for smc91x ethernet Peter Ujfalusi (5): ARM: dts: omap2: Correct the dma controller's property names ARM: dts: omap3: Correct the dma controller's property names ARM: dts: omap4: Correct the dma controller's property names ARM: dts: omap5: Correct the dma controller's property names ARM: dts: dra7: Correct the dma controller's property names Robert Nelson (1): ARM: dts: am335x-bone*: usb0 is hardwired for peripheral Roger Quadros (5): ARM: dts: DRA7: Fix SATA PHY node ARM: dts: OMAP5: Fix SATA PHY node ARM: omap2plus_defconfig: Enable OMAP NAND BCH driver ARM: omap2plus_defconfig: Fix SATA boot ARM: dts: dra7x-evm: beagle-x15: Fix USB Host Tony Lindgren (1): ARM: dts: Fix USB dts configuration for dm816x arch/arm/boot/dts/am335x-bone-common.dtsi | 1 + arch/arm/boot/dts/am437x-idk-evm.dts | 25 ++- arch/arm/boot/dts/am57xx-beagle-x15.dts | 8 arch/arm/boot/dts/dm8168-evm.dts | 25 +++ arch/arm/boot/dts/dm816x.dtsi | 34 +++ arch/arm/boot/dts/dra7-evm.dts| 8 arch/arm/boot/dts/dra7.dtsi | 8 arch/arm/boot/dts/dra72-evm.dts | 8 arch/arm/boot/dts/omap2.dtsi | 4 ++-- arch/arm/boot/dts/omap3-n900.dts | 9 +++- arch/arm/boot/dts/omap3.dtsi | 4 ++-- arch/arm/boot/dts/omap4.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 8 arch/arm/configs/omap2plus_defconfig | 4 +++- 14 files changed, 83 insertions(+), 67 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/15] twl4030_charger: allow max_current to be managed via sysfs.
'max_current' sysfs attributes are created which allow the
max to be set.
Whenever a current source changes, the default is restored.
This will be followed by a uevent, so user-space can decide to
update again.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index bfc9b808301e..b0242786d047 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -473,6 +473,8 @@ static irqreturn_t twl4030_charger_interrupt(int irq, void
*arg)
struct twl4030_bci *bci = arg;
dev_dbg(bci-dev, CHG_PRES irq\n);
+ /* reset current on each 'plug' event */
+ bci-ac_cur = 50;
twl4030_charger_update_current(bci);
power_supply_changed(bci-ac);
power_supply_changed(bci-usb);
@@ -527,6 +529,67 @@ static irqreturn_t twl4030_bci_interrupt(int irq, void
*arg)
return IRQ_HANDLED;
}
+/*
+ * sysfs max_current store
+ */
+static ssize_t
+twl4030_bci_max_current_store(struct device *dev, struct device_attribute
*attr,
+ const char *buf, size_t n)
+{
+ struct twl4030_bci *bci = dev_get_drvdata(dev-parent);
+ int cur = 0;
+ int status = 0;
+ status = kstrtoint(buf, 10, cur);
+ if (status)
+ return status;
+ if (cur 0)
+ return -EINVAL;
+ if (dev == bci-ac.dev) {
+ if (bci-ac_cur == cur)
+ return n;
+ bci-ac_cur = cur;
+ } else {
+ if (bci-usb_cur == cur)
+ return n;
+ bci-usb_cur = cur;
+ }
+ twl4030_charger_update_current(bci);
+ return (status == 0) ? n : status;
+}
+
+/*
+ * sysfs max_current show
+ */
+static ssize_t twl4030_bci_max_current_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int status = 0;
+ int cur = -1;
+ u8 bcictl1;
+ struct twl4030_bci *bci = dev_get_drvdata(dev-parent);
+
+ if (dev == bci-ac.dev) {
+ if (!bci-ac_is_active)
+ cur = bci-ac_cur;
+ } else {
+ if (bci-ac_is_active)
+ cur = bci-usb_cur;
+ }
+ if (cur 0) {
+ cur = twl4030bci_read_adc_val(TWL4030_BCIIREF1);
+ if (cur 0)
+ return cur;
+ status = twl4030_bci_read(TWL4030_BCICTL1, bcictl1);
+ if (status 0)
+ return status;
+ cur = regval2ua(cur, bcictl1 TWL4030_CGAIN);
+ }
+ return scnprintf(buf, PAGE_SIZE, %u\n, cur);
+}
+
+static DEVICE_ATTR(max_current, 0644, twl4030_bci_max_current_show,
+ twl4030_bci_max_current_store);
+
static void twl4030_bci_usb_work(struct work_struct *data)
{
struct twl4030_bci *bci = container_of(data, struct twl4030_bci, work);
@@ -549,6 +612,12 @@ static int twl4030_bci_usb_ncb(struct notifier_block *nb,
unsigned long val,
dev_dbg(bci-dev, OTG notify %lu\n, val);
+ /* reset current on each 'plug' event */
+ if (allow_usb)
+ bci-usb_cur = 50;
+ else
+ bci-usb_cur = 10;
+
bci-event = val;
schedule_work(bci-work);
@@ -809,6 +878,11 @@ static int __init twl4030_bci_probe(struct platform_device
*pdev)
dev_warn(pdev-dev, failed to unmask interrupts: %d\n, ret);
twl4030_charger_update_current(bci);
+ if (device_create_file(bci-usb.dev, dev_attr_max_current))
+ dev_warn(pdev-dev, could not create sysfs file\n);
+ if (device_create_file(bci-ac.dev, dev_attr_max_current))
+ dev_warn(pdev-dev, could not create sysfs file\n);
+
twl4030_charger_enable_ac(true);
if (!IS_ERR_OR_NULL(bci-transceiver))
twl4030_bci_usb_ncb(bci-usb_nb,
@@ -836,6 +910,8 @@ static int __exit twl4030_bci_remove(struct platform_device
*pdev)
twl4030_charger_enable_usb(bci, false);
twl4030_charger_enable_backup(0, 0);
+ device_remove_file(bci-usb.dev, dev_attr_max_current);
+ device_remove_file(bci-ac.dev, dev_attr_max_current);
/* mask interrupts */
twl_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xff,
TWL4030_INTERRUPTS_BCIIMR1A);
--
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 15/15] twl4030_charger: assume a 'charger' can supply maximum current.
If it cannot, we will stop pulling more current when voltage drops.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 7ad6b4b531d7..89e2c121dd22 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -691,8 +691,10 @@ static void twl4030_bci_usb_work(struct work_struct *data)
struct twl4030_bci *bci = container_of(data, struct twl4030_bci, work);
switch (bci-event) {
- case USB_EVENT_VBUS:
case USB_EVENT_CHARGER:
+ bci-usb_cur = USB_MAX_CURRENT;
+ /* FALL THROUGH */
+ case USB_EVENT_VBUS:
case USB_EVENT_ENUMERATED:
twl4030_charger_enable_usb(bci, true);
break;
--
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 14/15] twl4030_charger: Increase current carefully while watching voltage.
The USB Battery Charging spec (BC1.2) suggests a dedicated
charging port can deliver from 0.5 to 5.0A at between 4.75 and 5.25
volts.
To choose the correct current voltage setting requires a trial
and error approach: try to draw current and see if the voltage drops
too low.
Even with a configure Standard Downstream Port, it may not be possible
to reliably pull 500mA - depending on cable quality and source
quality I have reports of charging failure due to the voltage dropping
too low.
To address both these concern, this patch introduce incremental
current setting.
The current pull from VBUS is increased in steps of 20mA every 100ms
until the target is reached or until the measure voltage drops below
4.75V. If the voltage does go too long, the target current is reduced
by 20mA and kept there.
This applies to currents selected automatically, or to values
set via sysfs. So setting a large value will cause the maximum
available to be used - up to the limit of 1.7mA imposed by the
hardware.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c | 54 ++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index e5a0225ea87e..7ad6b4b531d7 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -117,6 +117,18 @@ struct twl4030_bci {
#defineCHARGE_AUTO 1
#defineCHARGE_LINEAR 2
+ /* When setting the USB current we slowly increase the
+* requested current until target is reached or the voltage
+* drops below 4.75V. In the latter case we set back one
+* step.
+*/
+ int usb_cur_actual;
+ struct delayed_work current_worker;
+#defineUSB_CUR_STEP2 /* 20mA at a time */
+#defineUSB_MIN_VOLT475 /* 4.75V */
+#defineUSB_CUR_DELAY msecs_to_jiffies(100)
+#defineUSB_MAX_CURRENT 170 /* TWL4030 caps at 1.7mA */
+
unsigned long event;
};
@@ -249,8 +261,14 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
cur = bci-ac_cur;
bci-ac_is_active = 1;
} else {
- cur = bci-usb_cur;
+ cur = bci-usb_cur_actual;
bci-ac_is_active = 0;
+ if (cur bci-usb_cur) {
+ cur = bci-usb_cur;
+ bci-usb_cur_actual = cur;
+ }
+ if (cur bci-usb_cur)
+ schedule_delayed_work(bci-current_worker,
USB_CUR_DELAY);
}
/* First, check thresholds and see if cgain is needed */
@@ -379,6 +397,38 @@ static int twl4030_charger_update_current(struct
twl4030_bci *bci)
return 0;
}
+static void twl4030_current_worker(struct work_struct *data)
+{
+ int v;
+ int res;
+ struct twl4030_bci *bci = container_of(data, struct twl4030_bci,
+ current_worker.work);
+
+ res = twl4030bci_read_adc_val(TWL4030_BCIVBUS);
+ if (res 0)
+ v = 0;
+ else
+ /* BCIVBUS uses ADCIN8, 7/1023 V/step */
+ v = res * 6843;
+
+ printk(v=%d cur=%d target=%d\n, v, bci-usb_cur_actual,
+ bci-usb_cur);
+
+ if (v USB_MIN_VOLT) {
+ /* Back up and stop adjusting. */
+ bci-usb_cur_actual -= USB_CUR_STEP;
+ bci-usb_cur = bci-usb_cur_actual;
+ } else if (bci-usb_cur_actual = bci-usb_cur ||
+ bci-usb_cur_actual + USB_CUR_STEP USB_MAX_CURRENT) {
+ /* Reach target and volts are OK - stop */
+ return;
+ } else {
+ bci-usb_cur_actual += USB_CUR_STEP;
+ schedule_delayed_work(bci-current_worker, USB_CUR_DELAY);
+ }
+ twl4030_charger_update_current(bci);
+}
+
/*
* Enable/Disable USB Charge functionality.
*/
@@ -441,6 +491,7 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
pm_runtime_put_autosuspend(bci-transceiver-dev);
bci-usb_enabled = 0;
}
+ bci-usb_cur_actual = 0;
}
return ret;
@@ -972,6 +1023,7 @@ static int __init twl4030_bci_probe(struct platform_device
*pdev)
}
INIT_WORK(bci-work, twl4030_bci_usb_work);
+ INIT_DELAYED_WORK(bci-current_worker, twl4030_current_worker);
bci-usb_nb.notifier_call = twl4030_bci_usb_ncb;
if (bci-dev-of_node) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8 v2] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS
DTS output was formatted to require additional work when copy-pasting into DTS.
Nano-second timings were removed, because they were not a confidence interval
nor
an indication what timing values would result in the same #ticks
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index b5c8305..ff1a1e7 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -337,32 +337,45 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
}
#ifdef DEBUG
+/**
+ * get_gpmc_timing_reg - read a timing parameter and print DTS settings for it.
+ * @cs Chip Select Region
+ * @reg GPMC_CS_CONFIGn register offset.
+ * @st_bit Start Bit
+ * @end_bit End Bit. Must be = @st_bit.
+ * @nameDTS node name, w/o gpmc,
+ * @raw Raw Format Option.
+ * raw format: gpmc,name = value
+ * tick format: gpmc,name = value /zwj;* x ticks *zwj;/
+ * @noval Parameter values equal to 0 are not printed.
+ * @shift Parameter value left shifts @shift, which is then printed instead
of value.
+ *
+ */
static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
bool raw, bool noval, int shift,
const char *name)
{
u32 l;
- int nr_bits, max_value, mask;
+ int nr_bits;
+ int mask;
l = gpmc_cs_read_reg(cs, reg);
nr_bits = end_bit - st_bit + 1;
- max_value = (1 nr_bits) - 1;
- mask = max_value st_bit;
- l = (l mask) st_bit;
+ mask = (1 nr_bits) - 1;;
+ l = (l st_bit) mask;
if (shift)
l = (shift l);
if (noval (l == 0))
return 0;
if (!raw) {
- unsigned int time_ns_min, time_ns, time_ns_max;
+ /* DTS tick format for timings in ns */
+ unsigned int time_ns;
- time_ns_min = gpmc_ticks_to_ns(l ? l - 1 : 0);
time_ns = gpmc_ticks_to_ns(l);
- time_ns_max = gpmc_ticks_to_ns(l + 1 max_value ?
- max_value : l + 1);
- pr_info(gpmc,%s = %u (%u - %u ns, %i ticks)\n,
- name, time_ns, time_ns_min, time_ns_max, l);
+ pr_info(gpmc,%s = %u /* %i ticks */\n,
+ name, time_ns, l);
} else {
+ /* raw format */
pr_info(gpmc,%s = %u\n, name, l);
}
--
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 0/8 v2] ARM OMAP2+ GPMC: fixes and bus children
On Tue, Feb 24, 2015 at 9:05 PM, Robert ABEL ra...@cit-ec.uni-bielefeld.de wrote: These are the changes I proposed in two separate patchsets #([1], [2]) rebased to 3.19 as well as new changes for little bugs I noticed while preparing this patchset. It seems my m4d s3d sk177z failed me. Disregard the missing Patch 2, the numbering is off, but the contents are correct. Regards, Robert -- 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 10/15] twl4030_charger: only draw USB current as negotiated with host.
If the phy has been told what current it can draw, it tells us
and now we use that number.
Note that 'vbus_draw' is in mA, while usb_cur is in uA.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index b0242786d047..01090a440583 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -597,6 +597,7 @@ static void twl4030_bci_usb_work(struct work_struct *data)
switch (bci-event) {
case USB_EVENT_VBUS:
case USB_EVENT_CHARGER:
+ case USB_EVENT_ENUMERATED:
twl4030_charger_enable_usb(bci, true);
break;
case USB_EVENT_NONE:
@@ -609,6 +610,7 @@ static int twl4030_bci_usb_ncb(struct notifier_block *nb,
unsigned long val,
void *priv)
{
struct twl4030_bci *bci = container_of(nb, struct twl4030_bci, usb_nb);
+ unsigned *vbus_draw = priv;
dev_dbg(bci-dev, OTG notify %lu\n, val);
@@ -619,6 +621,9 @@ static int twl4030_bci_usb_ncb(struct notifier_block *nb,
unsigned long val,
bci-usb_cur = 10;
bci-event = val;
+ if (val == USB_EVENT_ENUMERATED vbus_draw
+ *vbus_draw * 1000 bci-usb_cur)
+ bci-usb_cur = *vbus_draw * 1000;
schedule_work(bci-work);
return NOTIFY_OK;
--
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 11/15] twl4030_charger: enable manual enable/disable of usb charging.
'off' or 'auto' to
/sys/class/power/twl4030_usb/mode
will now enable or disable charging from USB port. Normally this is
enabled on 'plug' and disabled on 'unplug'.
Unplug will still disable charging. 'plug' will only enable it if
'auto' if selected.
Signed-off-by: NeilBrown ne...@suse.de
Conflicts:
drivers/power/twl4030_charger.c
---
drivers/power/twl4030_charger.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 01090a440583..19e8dbb1303e 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -107,6 +107,9 @@ struct twl4030_bci {
int ichg_eoc, ichg_lo, ichg_hi;
int usb_cur, ac_cur;
boolac_is_active;
+ int usb_mode; /* charging mode requested */
+#defineCHARGE_OFF 0
+#defineCHARGE_AUTO 1
unsigned long event;
};
@@ -377,6 +380,8 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
{
int ret;
+ if (bci-usb_mode == CHARGE_OFF)
+ enable = false;
if (enable !IS_ERR_OR_NULL(bci-transceiver)) {
twl4030_charger_update_current(bci);
@@ -629,6 +634,54 @@ static int twl4030_bci_usb_ncb(struct notifier_block *nb,
unsigned long val,
return NOTIFY_OK;
}
+/*
+ * sysfs charger enabled store
+ */
+static char *modes[] = { off, auto };
+static ssize_t
+twl4030_bci_mode_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t n)
+{
+ struct twl4030_bci *bci = dev_get_drvdata(dev-parent);
+ int mode;
+ int status;
+
+ if (sysfs_streq(buf, modes[0]))
+ mode = 0;
+ else if (sysfs_streq(buf, modes[1]))
+ mode = 1;
+ else
+ return -EINVAL;
+ twl4030_charger_enable_usb(bci, false);
+ bci-usb_mode = mode;
+ status = twl4030_charger_enable_usb(bci, true);
+ return (status == 0) ? n : status;
+}
+
+/*
+ * sysfs charger enabled show
+ */
+static ssize_t
+twl4030_bci_mode_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct twl4030_bci *bci = dev_get_drvdata(dev-parent);
+ int len = 0;
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(modes); i++)
+ if (bci-usb_mode == i)
+ len += snprintf(buf+len, PAGE_SIZE-len,
+ [%s] , modes[i]);
+ else
+ len += snprintf(buf+len, PAGE_SIZE-len,
+ %s , modes[i]);
+ buf[len-1] = '\n';
+ return len;
+}
+static DEVICE_ATTR(mode, 0644, twl4030_bci_mode_show,
+ twl4030_bci_mode_store);
+
static int twl4030_charger_get_current(void)
{
int curr;
@@ -799,6 +852,7 @@ static int __init twl4030_bci_probe(struct platform_device
*pdev)
bci-usb_cur = 50; /* 500mA */
else
bci-usb_cur = 10; /* 100mA */
+ bci-usb_mode = CHARGE_AUTO;
bci-dev = pdev-dev;
bci-irq_chg = platform_get_irq(pdev, 0);
@@ -885,6 +939,8 @@ static int __init twl4030_bci_probe(struct platform_device
*pdev)
twl4030_charger_update_current(bci);
if (device_create_file(bci-usb.dev, dev_attr_max_current))
dev_warn(pdev-dev, could not create sysfs file\n);
+ if (device_create_file(bci-usb.dev, dev_attr_mode))
+ dev_warn(pdev-dev, could not create sysfs file\n);
if (device_create_file(bci-ac.dev, dev_attr_max_current))
dev_warn(pdev-dev, could not create sysfs file\n);
@@ -917,6 +973,7 @@ static int __exit twl4030_bci_remove(struct platform_device
*pdev)
device_remove_file(bci-usb.dev, dev_attr_max_current);
device_remove_file(bci-ac.dev, dev_attr_max_current);
+ device_remove_file(bci-usb.dev, dev_attr_mode);
/* mask interrupts */
twl_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xff,
TWL4030_INTERRUPTS_BCIIMR1A);
--
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 12/15] twl4030_charger: add software controlled linear charging mode.
Add a 'continuous' option for usb charging which enabled
the linear charging mode of the twl4030.
Linear charging does a good job with not so reliable power sources, since
several voltage controlling is then often too intelligent.
It was used with a bike hub dynamo since a year or so. In that case there
are automatically charging stops when the cyclist needs a break.
Orignal-by: Andreas Kemnade andr...@kemnade.info
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c | 57 ---
1 file changed, 52 insertions(+), 5 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 19e8dbb1303e..6c53f0b601a4 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -24,6 +24,8 @@
#include linux/usb/otg.h
#include linux/i2c/twl4030-madc.h
+#define TWL4030_BCIMDEN0x00
+#define TWL4030_BCIMDKEY 0x01
#define TWL4030_BCIMSTATEC 0x02
#define TWL4030_BCIICHG0x08
#define TWL4030_BCIVAC 0x0a
@@ -35,13 +37,16 @@
#define TWL4030_BCIIREF1 0x27
#define TWL4030_BCIIREF2 0x28
#define TWL4030_BCIMFKEY 0x11
+#define TWL4030_BCIMFEN3 0x14
#define TWL4030_BCIMFTH8 0x1d
#define TWL4030_BCIMFTH9 0x1e
+#define TWL4030_BCIWDKEY 0x21
#define TWL4030_BCIMFSTS1 0x01
#define TWL4030_BCIAUTOWEN BIT(5)
#define TWL4030_CONFIG_DONEBIT(4)
+#define TWL4030_CVENAC BIT(2)
#define TWL4030_BCIAUTOUSB BIT(1)
#define TWL4030_BCIAUTOAC BIT(0)
#define TWL4030_CGAIN BIT(5)
@@ -110,6 +115,7 @@ struct twl4030_bci {
int usb_mode; /* charging mode requested */
#defineCHARGE_OFF 0
#defineCHARGE_AUTO 1
+#defineCHARGE_LINEAR 2
unsigned long event;
};
@@ -392,16 +398,44 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
bci-usb_enabled = 1;
}
- /* forcing the field BCIAUTOUSB (BOOT_BCI[1]) to 1 */
- ret = twl4030_clear_set_boot_bci(0, TWL4030_BCIAUTOUSB);
- if (ret 0)
- return ret;
+ if (bci-usb_mode == CHARGE_AUTO) {
+ /* forcing the field BCIAUTOUSB (BOOT_BCI[1]) to 1 */
+ ret = twl4030_clear_set_boot_bci(0, TWL4030_BCIAUTOUSB);
+ twl4030_clear_set_boot_bci(0,
TWL4030_BCIAUTOAC|TWL4030_CVENAC);
+ }
/* forcing USBFASTMCHG(BCIMFSTS4[2]) to 1 */
ret = twl4030_clear_set(TWL_MODULE_MAIN_CHARGE, 0,
TWL4030_USBFASTMCHG, TWL4030_BCIMFSTS4);
+ if (bci-usb_mode == CHARGE_LINEAR) {
+
twl4030_clear_set_boot_bci(TWL4030_BCIAUTOAC|TWL4030_CVENAC, 0);
+ /* Watch dog key: WOVF acknowledge */
+ ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x33,
+ TWL4030_BCIWDKEY);
+ /* 0x24 + EKEY6: off mode */
+ ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x2a,
+ TWL4030_BCIMDKEY);
+ /* EKEY2: Linear charge: usb path */
+ ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x26,
+ TWL4030_BCIMDKEY);
+ /* WDKEY5: stop watchdog count */
+ ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0xf3,
+ TWL4030_BCIWDKEY);
+ /* enable MFEN3 access */
+ ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x9c,
+ TWL4030_BCIMFKEY);
+/* ICHGEOCEN - end-of-charge monitor (current 80mA)
+ * (charging continues)
+ * ICHGLOWEN - current level monitor (charge continues)
+ * don't monitor over-current or heat save
+ */
+ ret = twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0xf0,
+ TWL4030_BCIMFEN3);
+ }
} else {
ret = twl4030_clear_set_boot_bci(TWL4030_BCIAUTOUSB, 0);
+ ret |= twl_i2c_write_u8(TWL_MODULE_MAIN_CHARGE, 0x2a,
+ TWL4030_BCIMDKEY);
if (bci-usb_enabled) {
pm_runtime_mark_last_busy(bci-transceiver-dev);
pm_runtime_put_autosuspend(bci-transceiver-dev);
@@ -637,7 +671,7 @@ static int twl4030_bci_usb_ncb(struct notifier_block *nb,
unsigned long val,
/*
* sysfs charger enabled store
*/
-static char *modes[] = { off, auto };
+static char
[PATCH 13/15] twl4030_charger: add ac/mode to match usb/mode
This allows AC charging to be turned off, much like usb charging.
continuous (aka linear) mode maps to the CVENAC (constant voltage)
feature of the twl4030.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c | 40 +--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 6c53f0b601a4..e5a0225ea87e 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -112,7 +112,7 @@ struct twl4030_bci {
int ichg_eoc, ichg_lo, ichg_hi;
int usb_cur, ac_cur;
boolac_is_active;
- int usb_mode; /* charging mode requested */
+ int usb_mode, ac_mode; /* charging mode requested */
#defineCHARGE_OFF 0
#defineCHARGE_AUTO 1
#defineCHARGE_LINEAR 2
@@ -449,12 +449,18 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
/*
* Enable/Disable AC Charge funtionality.
*/
-static int twl4030_charger_enable_ac(bool enable)
+static int twl4030_charger_enable_ac(struct twl4030_bci *bci, bool enable)
{
int ret;
- if (enable)
- ret = twl4030_clear_set_boot_bci(0, TWL4030_BCIAUTOAC);
+ if (bci-ac_mode == CHARGE_OFF)
+ enable = false;
+
+ if (enable bci-ac_mode == CHARGE_LINEAR)
+ ret = twl4030_clear_set_boot_bci(0, (TWL4030_CVENAC |
+TWL4030_BCIAUTOAC));
+ else if (enable)
+ ret = twl4030_clear_set_boot_bci(TWL4030_CVENAC,
TWL4030_BCIAUTOAC);
else
ret = twl4030_clear_set_boot_bci(TWL4030_BCIAUTOAC, 0);
@@ -688,9 +694,15 @@ twl4030_bci_mode_store(struct device *dev, struct
device_attribute *attr,
mode = 2;
else
return -EINVAL;
- twl4030_charger_enable_usb(bci, false);
- bci-usb_mode = mode;
- status = twl4030_charger_enable_usb(bci, true);
+ if (dev == bci-ac.dev) {
+ twl4030_charger_enable_ac(bci, false);
+ bci-ac_mode = mode;
+ status = twl4030_charger_enable_ac(bci, true);
+ } else {
+ twl4030_charger_enable_usb(bci, false);
+ bci-usb_mode = mode;
+ status = twl4030_charger_enable_usb(bci, true);
+ }
return (status == 0) ? n : status;
}
@@ -704,9 +716,13 @@ twl4030_bci_mode_show(struct device *dev,
struct twl4030_bci *bci = dev_get_drvdata(dev-parent);
int len = 0;
int i;
+ int mode = bci-usb_mode;
+
+ if (dev == bci-ac.dev)
+ mode = bci-ac_mode;
for (i = 0; i ARRAY_SIZE(modes); i++)
- if (bci-usb_mode == i)
+ if (mode == i)
len += snprintf(buf+len, PAGE_SIZE-len,
[%s] , modes[i]);
else
@@ -900,6 +916,7 @@ static int __init twl4030_bci_probe(struct platform_device
*pdev)
else
bci-usb_cur = 10; /* 100mA */
bci-usb_mode = CHARGE_AUTO;
+ bci-ac_mode = CHARGE_AUTO;
bci-dev = pdev-dev;
bci-irq_chg = platform_get_irq(pdev, 0);
@@ -988,10 +1005,12 @@ static int __init twl4030_bci_probe(struct
platform_device *pdev)
dev_warn(pdev-dev, could not create sysfs file\n);
if (device_create_file(bci-usb.dev, dev_attr_mode))
dev_warn(pdev-dev, could not create sysfs file\n);
+ if (device_create_file(bci-ac.dev, dev_attr_mode))
+ dev_warn(pdev-dev, could not create sysfs file\n);
if (device_create_file(bci-ac.dev, dev_attr_max_current))
dev_warn(pdev-dev, could not create sysfs file\n);
- twl4030_charger_enable_ac(true);
+ twl4030_charger_enable_ac(bci, true);
if (!IS_ERR_OR_NULL(bci-transceiver))
twl4030_bci_usb_ncb(bci-usb_nb,
bci-transceiver-last_event,
@@ -1014,13 +1033,14 @@ static int __exit twl4030_bci_remove(struct
platform_device *pdev)
{
struct twl4030_bci *bci = platform_get_drvdata(pdev);
- twl4030_charger_enable_ac(false);
+ twl4030_charger_enable_ac(bci, false);
twl4030_charger_enable_usb(bci, false);
twl4030_charger_enable_backup(0, 0);
device_remove_file(bci-usb.dev, dev_attr_max_current);
device_remove_file(bci-ac.dev, dev_attr_max_current);
device_remove_file(bci-usb.dev, dev_attr_mode);
+ device_remove_file(bci-ac.dev, dev_attr_mode);
/* mask interrupts */
twl_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xff,
TWL4030_INTERRUPTS_BCIIMR1A);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH v5 0/7] irqchip: Move OMAP{4,5}/DRA7 to use stacked domains
On 2/23/2015 9:44 AM, Marc Zyngier wrote:
This series is extracted from [4], which is trying to remove all
traces of gic_arch_extn from the tree. As some maintainers are more
responsive than others (understatement of the year...), I've decided
to split it per sub-arch, and get it moving, at least partially.
This series addresses OMAP{4,5} by converting the WUGEN to stacked
domains. The DRA7 crossbar gets the same treatment.
It is worth realizing that:
- I haven't been able to test this as much as I would have wanted to
(it's only been tested on omap4 and omap5).
- This actively *breaks* existing setups. Once you boot a new kernel
with an old DT, suspend/resume *will* be broken. Old kernels on a
new DT won't even boot! You've been warned. This really outline the
necessity of actually describing the HW in device trees...
Based on 4.0-rc1.
* From v4: [4]
- Extracted from the full series
- Rebased on 4.0-rc1
* From v3 [3]:
- Rebased on top of the patch working around hardcoded IRQ on OMAP4/5 [4]
- Fixed more iMX6 DTs (Stephan)
- Fixed Exynos4/5 DTs
* From v2 [2]:
- Addressed numerous comments from Thierry
- Merged bug fixes from Nishanth
- Merged bug fix from Stefan
* From v1 [1]:
- Rebased on 3.19-rc3
- Fixed a number of additional platforms
- Added crossbar conversion to stacked domains
- Merged bug fixes from Nishanth
[4]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317531.html
[3]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315385.html
[2]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314041.html
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307338.html
Marc Zyngier (7):
genirq: Add irqchip_set_wake_parent
irqchip: crossbar: convert dra7 crossbar to stacked domains
DT: update ti,irq-crossbar binding
irqchip: GIC: get rid of routable domain
DT: arm,gic: kill arm,routable-irqs
DT: omap4/5: add binding for the wake-up generator
ARM: omap: convert wakeupgen to stacked domains
Acked-by: Santosh Shilimkar ssant...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8 v2] ARM OMAP2+ GPMC: fixes and bus children
These are the changes I proposed in two separate patchsets #([1], [2]) rebased to 3.19 as well as new changes for little bugs I noticed while preparing this patchset. 1. DEBUG was undefined in source code -- remove offending lines 2. add capability to have busses as children of the GPMC and multiple devices on a bus. See [2] for an example DTS syntax. 3. debug output was unaligned -- align it 4. output for copy-pasting to DTS had erroneous timing outputs and made it hard to copy-paste -- remove timing values, add comments as DTS comments. 5. WAITMONITORINGTIME is expressed as GPMC_CLK cycles for all accesses. GPMCFCLKDIVIDER is used as a divider, so it must always be programmed. 6. GPMCFCLKDIVIDER is calculated according to WAITMONITORINGTIME for asynchronous accesses inside the driver -- asynchronous accesses now completely decoupled from gpmc,sync-clk-ps. 7. WAITMONITORINGTIME was being programmed/shown in GPMC_FCLK cycles instead of GPMC_CLK cycles -- add clock domain information where necessary. 8. Calculated values for WAITMONITORINGTIME and CLKACTIVATIONTIME that were outside the defined range would not raise an error. DEVICESIZE, ATTACHEDDEVICEPAGELENGTH, WAITMONITORINGTIME and CLKACTIVATIONTIME would not be marked as incorrect on DTS output. -- Fix all of these. [1]: https://lkml.org/lkml/2015/2/12/495 [2]: https://lkml.org/lkml/2015/2/16/337 Robert ABEL (9): ARM OMAP2+ GPMC: don't undef DEBUG ARM OMAP2+ GPMC: add bus children ARM OMAP2+ GPMC: fix debug output alignment ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters arch/arm/mach-omap2/gpmc-nand.c| 17 +-- arch/arm/mach-omap2/gpmc-onenand.c | 4 +- drivers/memory/Makefile| 2 + drivers/memory/omap-gpmc.c | 287 + include/linux/omap-gpmc.h | 2 +- 5 files changed, 240 insertions(+), 72 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 1/4] usb: phy: twl4030: make runtime pm more reliable.
* NeilBrown ne...@suse.de [150223 19:45]:
A construct like:
if (pm_runtime_suspended(twl-dev))
pm_runtime_get_sync(twl-dev);
is against the spirit of the runtime_pm interface as it
makes the internal refcounting useless.
In this case it is also racy, particularly as 'put_autosuspend'
is use to drop a reference.
When that happens a timer is started and the device is
runtime-suspended after the timeout.
If the above code runs in this window, the device will not be
found to be suspended so no pm_runtime reference is taken.
When the timer expires the device will be suspended, which is
against the intention of the code.
So be more direct is taking and dropping references.
If twl-linkstat is VBUS_VALID or ID_GROUND, then hold a
pm_runtime reference, otherwise don't.
Looks good to me, thanks for fixing it. I've tested this series
on beagleboard-xm by plugging and unplugging devices and
switching between host and peripheral mode, things still
idle properly for off-idle. So please feel free to add:
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/phy/phy-twl4030-usb.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 8e87f54671f3..97c59074233f 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -536,8 +536,13 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
mutex_lock(twl-lock);
if (status = 0 status != twl-linkstat) {
+ status_changed =
+ (twl-linkstat == OMAP_MUSB_VBUS_VALID ||
+ twl-linkstat == OMAP_MUSB_ID_GROUND)
+ !=
+ (status == OMAP_MUSB_VBUS_VALID ||
+ status == OMAP_MUSB_ID_GROUND);
twl-linkstat = status;
- status_changed = true;
}
mutex_unlock(twl-lock);
@@ -555,13 +560,10 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
*/
if ((status == OMAP_MUSB_VBUS_VALID) ||
(status == OMAP_MUSB_ID_GROUND)) {
- if (pm_runtime_suspended(twl-dev))
- pm_runtime_get_sync(twl-dev);
+ pm_runtime_get_sync(twl-dev);
} else {
- if (pm_runtime_active(twl-dev)) {
- pm_runtime_mark_last_busy(twl-dev);
- pm_runtime_put_autosuspend(twl-dev);
- }
+ pm_runtime_mark_last_busy(twl-dev);
+ pm_runtime_put_autosuspend(twl-dev);
}
omap_musb_mailbox(status);
}
@@ -768,6 +770,10 @@ static int twl4030_usb_remove(struct platform_device
*pdev)
/* disable complete OTG block */
twl4030_usb_clear_bits(twl, POWER_CTRL, POWER_CTRL_OTG_ENAB);
+
+ if (twl-linkstat == OMAP_MUSB_VBUS_VALID ||
+ twl-linkstat == OMAP_MUSB_ID_GROUND)
+ pm_runtime_put_noidle(twl-dev);
pm_runtime_mark_last_busy(twl-dev);
pm_runtime_put(twl-dev);
--
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 8/8 v2] ARM OMAP2+ GPMC: fix WAITMONITORINGTIME divider bug
The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.
This patch correctly computes WAITMONITORINGTIME in GPMC_CLK cycles instead of
GPMC_FCLK cycles,
both during programming (gpmc_cs_set_timings) and during retrieval
(gpmc_cs_show_timings).
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 125 +++--
1 file changed, 99 insertions(+), 26 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 9cf8d21..6591991 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -170,6 +170,11 @@
*/
#defineGPMC_NR_IRQ 2
+enum gpmc_clk_domain {
+ GPMC_CD_FCLK,
+ GPMC_CD_CLK
+};
+
struct gpmc_cs_data {
const char *name;
@@ -268,16 +273,55 @@ static unsigned long gpmc_get_fclk_period(void)
return rate;
}
-static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+/**
+ * gpmc_get_clk_period - get period of selected clock domain in ps
+ * @cs Chip Select Region.
+ * @cd Clock Domain.
+ *
+ * GPMC_CS_CONFIG1 GPMCFCLKDIVIDER for cs has to be setup
+ * prior to calling this function with GPMC_CD_CLK.
+ *
+ */
+static unsigned long gpmc_get_clk_period(int cs, enum gpmc_clk_domain cd)
+{
+
+ unsigned long tick_ps = gpmc_get_fclk_period();
+ u32 l;
+ int div;
+
+ switch (cd) {
+ case GPMC_CD_CLK:
+ /* get current clk divider */
+ l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ div = (l 0x03) + 1;
+ /* get GPMC_CLK period */
+ tick_ps *= div;
+ break;
+ case GPMC_CD_FCLK:
+ /* FALL-THROUGH */
+ default:
+ break;
+ }
+
+ return tick_ps;
+
+}
+
+static unsigned int gpmc_ns_to_clk_ticks(unsigned int time_ns, int cs, enum
gpmc_clk_domain cd)
{
unsigned long tick_ps;
/* Calculate in picosecs to yield more exact results */
- tick_ps = gpmc_get_fclk_period();
+ tick_ps = gpmc_get_clk_period(cs, cd);
return (time_ns * 1000 + tick_ps - 1) / tick_ps;
}
+static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+{
+ return gpmc_ns_to_clk_ticks(time_ns, /* any CS */ 0, GPMC_CD_FCLK);
+}
+
static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
{
unsigned long tick_ps;
@@ -288,9 +332,14 @@ static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
return (time_ps + tick_ps - 1) / tick_ps;
}
+unsigned int gpmc_clk_ticks_to_ns(unsigned ticks, int cs, enum gpmc_clk_domain
cd)
+{
+ return ticks * gpmc_get_clk_period(cs, cd) / 1000;
+}
+
unsigned int gpmc_ticks_to_ns(unsigned int ticks)
{
- return ticks * gpmc_get_fclk_period() / 1000;
+ return gpmc_clk_ticks_to_ns(ticks, /* any CS */ 0, GPMC_CD_FCLK);
}
static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
@@ -346,16 +395,22 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
* @st_bit Start Bit
* @end_bit End Bit. Must be = @st_bit.
* @nameDTS node name, w/o gpmc,
+ * @cd Clock Domain of timing parameter.
+ * @shift Parameter value left shifts @shift, which is then printed instead
of value.
* @raw Raw Format Option.
* raw format: gpmc,name = value
* tick format: gpmc,name = value /zwj;* x ticks *zwj;/
* @noval Parameter values equal to 0 are not printed.
- * @shift Parameter value left shifts @shift, which is then printed instead
of value.
*
*/
-static int get_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit,
- bool raw, bool noval, int shift,
- const char *name)
+static int get_gpmc_timing_reg(
+ /* timing specifiers */
+ int cs, int reg, int st_bit, int end_bit,
+ const char *name, const enum gpmc_clk_domain cd,
+ /* value transform */
+ int shift,
+ /* format specifiers */
+ bool raw, bool noval)
{
u32 l;
int nr_bits;
@@ -373,7 +428,7 @@ static int get_gpmc_timing_reg(int cs, int reg, int st_bit,
int end_bit,
/* DTS tick format for timings in ns */
unsigned int time_ns;
- time_ns = gpmc_ticks_to_ns(l);
+ time_ns = gpmc_clk_ticks_to_ns(l, cs, cd);
pr_info(gpmc,%s = %u /* %i ticks */\n,
name, time_ns, l);
} else {
@@ -388,13 +443,15 @@ static int get_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
pr_info(cs%i %s: 0x%08x\n, cs, #config, \
gpmc_cs_read_reg(cs, config))
#define GPMC_GET_RAW(reg, st, end, field) \
-
[PATCH 9/8 v2] ARM OMAP2+ GPMC: fix programming/showing reserved timing parameters
GPMC_CONFIG1_i parameters CLKACTIVATIONTIME and WAITMONITORINGTIME
have reserved values.
Raise an error if calculated timings try to program reserved values.
GPMC_CONFIG1_i ATTCHEDDEVICEPAGELENGTH and DEVICESIZE were already checked
when parsing the DT.
Explicitly comment invalid values on gpmc_cs_show_timings for
-CLKACTIVATIONTIME
-WAITMONITORINGTIME
-DEVICESIZE
-ATTACHEDDEVICEPAGELENGTH
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 69 ++
1 file changed, 46 insertions(+), 23 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 6591991..cc2e6d0 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -135,6 +135,8 @@
#define GPMC_CONFIG1_WRITETYPE_ASYNC(0 27)
#define GPMC_CONFIG1_WRITETYPE_SYNC (1 27)
#define GPMC_CONFIG1_CLKACTIVATIONTIME(val) ((val 3) 25)
+/** CLKACTIVATIONTIME Max Ticks */
+#define GPMC_CONFIG1_CLKACTIVATIONTIME_MAX 2
#define GPMC_CONFIG1_PAGE_LEN(val) ((val 3) 23)
#define GPMC_CONFIG1_WAIT_READ_MON (1 22)
#define GPMC_CONFIG1_WAIT_WRITE_MON (1 21)
@@ -144,6 +146,8 @@
#define GPMC_CONFIG1_WAIT_PIN_SEL(val) ((val 3) 16)
#define GPMC_CONFIG1_DEVICESIZE(val)((val 3) 12)
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
+/** DEVICESIZE Max Value */
+#define GPMC_CONFIG1_DEVICESIZE_MAX GPMC_CONFIG1_DEVICESIZE_16
#define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10)
#define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
#define GPMC_CONFIG1_MUXTYPE(val) ((val 3) 8)
@@ -394,18 +398,21 @@ static void gpmc_cs_bool_timings(int cs, const struct
gpmc_bool_timings *p)
* @reg GPMC_CS_CONFIGn register offset.
* @st_bit Start Bit
* @end_bit End Bit. Must be = @st_bit.
+ * @max Maximum parameter value (after optional @shift).
+ * If 0, maximum is as high as @st_bit and @end_bit allow.
* @nameDTS node name, w/o gpmc,
* @cd Clock Domain of timing parameter.
* @shift Parameter value left shifts @shift, which is then printed instead
of value.
* @raw Raw Format Option.
* raw format: gpmc,name = value
* tick format: gpmc,name = value /zwj;* x ticks *zwj;/
+ * When @max is exceeded, invalid is printed inside comment.
* @noval Parameter values equal to 0 are not printed.
*
*/
static int get_gpmc_timing_reg(
/* timing specifiers */
- int cs, int reg, int st_bit, int end_bit,
+ int cs, int reg, int st_bit, int end_bit, int max,
const char *name, const enum gpmc_clk_domain cd,
/* value transform */
int shift,
@@ -415,11 +422,15 @@ static int get_gpmc_timing_reg(
u32 l;
int nr_bits;
int mask;
+ bool invalid;
l = gpmc_cs_read_reg(cs, reg);
nr_bits = end_bit - st_bit + 1;
mask = (1 nr_bits) - 1;;
l = (l st_bit) mask;
+ if (!max)
+ max = mask;
+ invalid = l max;
if (shift)
l = (shift l);
if (noval (l == 0))
@@ -429,11 +440,11 @@ static int get_gpmc_timing_reg(
unsigned int time_ns;
time_ns = gpmc_clk_ticks_to_ns(l, cs, cd);
- pr_info(gpmc,%s = %u /* %i ticks */\n,
- name, time_ns, l);
+ pr_info(gpmc,%s = %u /* %i ticks %s*/\n,
+ name, time_ns, l, invalid ? ; invalid : );
} else {
/* raw format */
- pr_info(gpmc,%s = %u\n, name, l);
+ pr_info(gpmc,%s = %u%s\n, name, l, invalid ? /* invalid
*/ : );
}
return l;
@@ -443,15 +454,19 @@ static int get_gpmc_timing_reg(
pr_info(cs%i %s: 0x%08x\n, cs, #config, \
gpmc_cs_read_reg(cs, config))
#define GPMC_GET_RAW(reg, st, end, field) \
- get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 1,
0)
+ get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0,
1, 0)
+#define GPMC_GET_RAW_MAX(reg, st, end, max, field) \
+ get_gpmc_timing_reg(cs, (reg), (st), (end), (max), field, GPMC_CD_FCLK,
0, 1, 0)
#define GPMC_GET_RAW_BOOL(reg, st, end, field) \
- get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 1,
1)
-#define GPMC_GET_RAW_SHIFT(reg, st, end, shift, field) \
- get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK,
(shift), 1, 1)
+ get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0,
1, 1)
+#define GPMC_GET_RAW_SHIFT(reg, st, end, shift, max, field) \
+ get_gpmc_timing_reg(cs, (reg), (st), (end), (max), field, GPMC_CD_FCLK,
(shift), 1, 1)
#define GPMC_GET_TICKS(reg, st, end, field) \
- get_gpmc_timing_reg(cs, (reg), (st), (end), field, GPMC_CD_FCLK, 0, 0,
0)
+ get_gpmc_timing_reg(cs, (reg), (st), (end), 0, field, GPMC_CD_FCLK, 0,
0, 0)
#define
[PATCH 1/8 v2] ARM OMAP2+ GPMC: don't undef DEBUG
OMAP2+ GPMC driver undefines DEBUG, which makes it unnecessarily hard to turn DEBUG on. Remove the offending lines. Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- drivers/memory/omap-gpmc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 24696f5..5cabac8 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -12,8 +12,6 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#undef DEBUG - #include linux/irq.h #include linux/kernel.h #include linux/init.h -- 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 4/8 v2] ARM OMAP2+ GPMC: fix debug output alignment
GPMC debug output is aligned to 10 characters for field names. However, some fields have bigger names, screwing up the alignment. Consequently, alignment was changed to longest field name (17 chars) for now. Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- drivers/memory/omap-gpmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 78b78a64..b5c8305 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -482,7 +482,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit, int end_bit, l = gpmc_cs_read_reg(cs, reg); #ifdef DEBUG printk(KERN_INFO - GPMC CS%d: %-10s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n, + GPMC CS%d: %-17s: %3d ticks, %3lu ns (was %3i ticks) %3d ns\n, cs, name, ticks, gpmc_get_fclk_period() * ticks / 1000, (l st_bit) mask, time); #endif -- 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 7/8 v2] ARM OMAP2+ GPMC: calculate GPMCFCLKDIVIDER based on WAITMONITORINGTIME
The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.
Calculate GPMCFCLKDIVIDER independent of gpmc,sync-clk-ps in DT for
truly asynchronous accesses, i.e. both read and write asynchronous.
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
arch/arm/mach-omap2/gpmc-nand.c| 17 -
arch/arm/mach-omap2/gpmc-onenand.c | 4 +--
drivers/memory/omap-gpmc.c | 74 ++
include/linux/omap-gpmc.h | 2 +-
4 files changed, 80 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index d5951b1..e863a59 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -96,14 +96,6 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
- if (gpmc_t) {
- err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
- if (err 0) {
- pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n,
err);
- return err;
- }
- }
-
memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
@@ -111,6 +103,15 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_set_legacy(gpmc_nand_data, s);
s.device_nand = true;
+
+ if (gpmc_t) {
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t, s);
+ if (err 0) {
+ pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n,
err);
+ return err;
+ }
+ }
+
err = gpmc_cs_program_settings(gpmc_nand_data-cs, s);
if (err 0)
goto out_free_cs;
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 53d197e..f899e77 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -293,7 +293,7 @@ static int omap2_onenand_setup_async(void __iomem
*onenand_base)
if (ret 0)
return ret;
- ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t);
+ ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t, onenand_async);
if (ret 0)
return ret;
@@ -331,7 +331,7 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
if (ret 0)
return ret;
- ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t);
+ ret = gpmc_cs_set_timings(gpmc_onenand_data-cs, t, onenand_sync);
if (ret 0)
return ret;
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index a6abaf0..9cf8d21 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -139,6 +139,8 @@
#define GPMC_CONFIG1_WAIT_READ_MON (1 22)
#define GPMC_CONFIG1_WAIT_WRITE_MON (1 21)
#define GPMC_CONFIG1_WAIT_MON_IIME(val) ((val 3) 18)
+/** WAITMONITORINGTIME Max Ticks */
+#define GPMC_CONFIG1_WAIT_MON_TIME_MAX 2
#define GPMC_CONFIG1_WAIT_PIN_SEL(val) ((val 3) 16)
#define GPMC_CONFIG1_DEVICESIZE(val)((val 3) 12)
#define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1)
@@ -511,13 +513,41 @@ static int set_gpmc_timing_reg(int cs, int reg, int
st_bit, int end_bit,
t-field, #field) 0) \
return -1
+/**
+ * gpmc_calc_waitmonitoring_divider - calculate proper GPMCFCLKDIVIDER based
on WAITMONITORINGTIME
+ * @wait_monitoring WAITMONITORINGTIME in ns.
+ * @return -1 on failure to scale, else proper divider 0.
+ * @noteWAITMONITORINGTIME will be _at least_ as long as desired.
+ * i.e. read timings should be kept- don't
sample bus too early
+ * while write timings should work out as well - data is
longer on bus
+ */
+static int gpmc_calc_waitmonitoring_divider(unsigned int wait_monitoring)
+{
+
+ int div = gpmc_ns_to_ticks(wait_monitoring);
+
+ div += GPMC_CONFIG1_WAIT_MON_TIME_MAX - 1;
+ div /= GPMC_CONFIG1_WAIT_MON_TIME_MAX;
+
+ if (div 4)
+ return -1;
+ if (div = 0)
+ div = 1;
+
+ return div;
+
+}
+
+/**
+ * gpmc_calc_divider - calculate GPMC_FCLK divider for sync_clk GPMC_CLK
period.
+ * @sync_clk GPMC_CLK period in ps.
+ * @return Returns at least 1 if GPMC_FCLK can be divided to GPMC_CLK.
+ * Else, returns -1.
+ */
int gpmc_calc_divider(unsigned int sync_clk)
{
- int
[PATCH 6/8 v2] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER
The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
even though the access is defined as asynchronous, and no GPMC_CLK clock
is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
for the GPMC clock, so it must be programmed to define the
correct WAITMONITORINGTIME delay.
Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de
---
drivers/memory/omap-gpmc.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index ff1a1e7..a6abaf0 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -566,19 +566,14 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
if (gpmc_capability GPMC_HAS_WR_ACCESS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
- /* caller is expected to have initialized CONFIG1 to cover
-* at least sync vs async
-*/
l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
- if (l (GPMC_CONFIG1_READTYPE_SYNC | GPMC_CONFIG1_WRITETYPE_SYNC)) {
#ifdef DEBUG
- printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
- cs, (div * gpmc_get_fclk_period()) / 1000, div);
+ printk(KERN_INFO GPMC CS%d CLK period is %lu ns (div %d)\n,
+ cs, (div * gpmc_get_fclk_period()) / 1000, div);
#endif
- l = ~0x03;
- l |= (div - 1);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
- }
+ l = ~0x03;
+ l |= (div - 1);
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
gpmc_cs_bool_timings(cs, t-bool_timings);
gpmc_cs_show_timings(cs, after gpmc_cs_set_timings);
--
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 3/8 v2] ARM OMAP2+ GPMC: add bus children
This patch adds support for spawning busses as children of the GPMC. Signed-off-by: Robert ABEL ra...@cit-ec.uni-bielefeld.de --- drivers/memory/omap-gpmc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index 5cabac8..78b78a64 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -27,6 +27,7 @@ #include linux/of_address.h #include linux/of_mtd.h #include linux/of_device.h +#include linux/of_platform.h #include linux/omap-gpmc.h #include linux/mtd/nand.h #include linux/pm_runtime.h @@ -1800,7 +1801,7 @@ static int gpmc_probe_generic_child(struct platform_device *pdev, gpmc_cs_enable_mem(cs); no_timings: - if (of_platform_device_create(child, NULL, pdev-dev)) + if (!of_platform_populate(child, of_default_bus_match_table, NULL, pdev-dev)) return 0; dev_err(pdev-dev, failed to create gpmc child %s\n, child-name); -- 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] OMAPDSS: restore name sysfs entry.
* NeilBrown ne...@suse.de [150224 12:35]: On Tue, 24 Feb 2015 12:40:32 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, On 24/02/15 11:37, NeilBrown wrote: commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b OMAPDSS: rename display-sysfs 'name' entry broke the xorg X server on my device as it couldn't find the display any more. It needs the 'name' file and now there isn't one. That commit claims that 'name' is not compatible with i2c or spi. i2c does register it own 'name' file, but spi does not, hence my problem - I have an spi display. So create a special case for i2c: add the name attribute for non-i2c devices. What X driver is that? What's it doing with the display name? Is it just using the display name to show something for the user, and the returned value can be essentially any string? Tomi /usr/lib/xorg/modules/drivers/omapfb_drv.so from package xserver-xorg-video-omap3 in Debian. I don't know where the main upstream source is, but here: https://gitorious.org/gnutoo-s-programs-for-shr/xf86-video-omapfb/source/28c006c94e57ea71df11ec4fff79d7ffcfc4860f:src/omapfb-output-dss.c#L258 is the code which reads /sys/devices/platform/omapdss/display0/name and fails if that file cannot be opened. Sounds like a kernel interface we need to support forever and fix the regression. 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 v5 0/7] irqchip: Move OMAP{4,5}/DRA7 to use stacked domains
On 23/02/15 23:02, Tony Lindgren wrote:
* Marc Zyngier marc.zyng...@arm.com [150223 09:48]:
This series is extracted from [4], which is trying to remove all
traces of gic_arch_extn from the tree. As some maintainers are more
responsive than others (understatement of the year...), I've decided
to split it per sub-arch, and get it moving, at least partially.
This series addresses OMAP{4,5} by converting the WUGEN to stacked
domains. The DRA7 crossbar gets the same treatment.
It is worth realizing that:
- I haven't been able to test this as much as I would have wanted to
(it's only been tested on omap4 and omap5).
- This actively *breaks* existing setups. Once you boot a new kernel
with an old DT, suspend/resume *will* be broken. Old kernels on a
new DT won't even boot! You've been warned. This really outline the
necessity of actually describing the HW in device trees...
Could we parse still the old binding and produce warning for the
case when a new kernel is booted with the old DT? That would make
it easier for people to debug what's going on.
There's a number of strategies:
- Looking up the default, top-level interrupt controller:
if that's the GIC, scream.
- Lookup the crossbar:
if it exists, but is not an interrupt controller, scream as well.
- Lookup the WUGEN:
if it doesn't exist, scream again.
The last one is pretty easy to implement:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index fba1ba7..7bb116a 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -277,6 +277,12 @@ void __init omap_gic_of_init(void)
{
struct device_node *np;
+ intc_node = of_find_matching_node(NULL, intc_match);
+ if (WARN_ON(!intc_node)) {
+ pr_err(No WUGEN found in DT, system will misbehave.\n);
+ pr_err(UPDATE YOUR DEVICE TREE!\n);
+ }
+
/* Extract GIC distributor and TWD bases for OMAP4460 ROM Errata WA */
if (!cpu_is_omap446x())
goto skip_errata_init;
This should cover both OMAP4, OMAP5 and DRA7.
What do you think?
M.
--
Jazz is not dead. It just smells funny...
--
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 v5 0/7] irqchip: Move OMAP{4,5}/DRA7 to use stacked domains
On 24/02/15 03:45, Subramaniam Chanderashekarapuram wrote: Tested this on DRA7 for smp_affinity. Needs these minor fixes attached. Note: I do not have a OMAP4/5 with me now. Hope to test that tomorrow. Log for DRA7 are here: http://pastebin.ubuntu.com/10382176/ Looks good to me. I've folded that into the existing series. Thanks, M. -- Jazz is not dead. It just smells funny... -- 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] OMAPDSS: restore name sysfs entry.
commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b
OMAPDSS: rename display-sysfs 'name' entry
broke the xorg X server on my device as it couldn't find the display
any more. It needs the 'name' file and now there isn't one.
That commit claims that 'name' is not compatible with i2c or spi.
i2c does register it own 'name' file, but spi does not, hence my
problem - I have an spi display.
So create a special case for i2c: add the name attribute for non-i2c
devices.
Fixes: 303e4697e762dc92a40405f4e4b8aac02cd0d70b
Signed-off-by: NeilBrown ne...@suse.de
--
Hi Tomi,
I wonder if you would consider this for the next merge window (or maybe even
sooner as a bug-fix).
I haven't tested it with an i2c display, but it certainly allows xorg to work
on my spi-attached display.
Thanks,
NeilBrown
diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c
b/drivers/video/fbdev/omap2/dss/display-sysfs.c
index 5a2095a98ed8..53897b743130 100644
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -25,6 +25,15 @@
#include linux/platform_device.h
#include linux/sysfs.h
+#if IS_ENABLED(CONFIG_I2C)
+#include linux/i2c.h
+#else
+static inline int i2c_verify_client(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
#include video/omapdss.h
#include dss.h
@@ -278,6 +287,7 @@ static ssize_t display_wss_store(struct device *dev,
}
static DEVICE_ATTR(display_name, S_IRUGO, display_name_show, NULL);
+static DEVICE_ATTR(name, S_IRUGO, display_name_show, NULL);
static DEVICE_ATTR(enabled, S_IRUGO|S_IWUSR,
display_enabled_show, display_enabled_store);
static DEVICE_ATTR(tear_elim, S_IRUGO|S_IWUSR,
@@ -315,6 +325,17 @@ int display_init_sysfs(struct platform_device *pdev)
DSSERR(failed to create sysfs files\n);
goto err;
}
+ if (!i2c_verify_client(dssdev-dev)) {
+ /*
+* Add 'name' file - not compatible with i2c, but
+* need by Xorg for other devices.
+*/
+ r = sysfs_create_file(kobj, dev_attr_name.attr);
+ if (r) {
+ DSSERR(fail to create 'name' sysfs file\n);
+ goto err;
+ }
+ }
r = sysfs_create_link(pdev-dev.kobj, kobj, dssdev-alias);
if (r) {
@@ -341,5 +362,7 @@ void display_uninit_sysfs(struct platform_device *pdev)
sysfs_remove_link(pdev-dev.kobj, dssdev-alias);
sysfs_remove_files(dssdev-dev-kobj,
display_sysfs_attrs);
+ sysfs_remove_file(dssdev-dev-kobj,
+ dev_attr_name.attr);
}
}
pgpkhJV_A17Yn.pgp
Description: OpenPGP digital signature
Re: [PATCH] OMAPDSS: restore name sysfs entry.
Hi, On 24/02/15 11:37, NeilBrown wrote: commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b OMAPDSS: rename display-sysfs 'name' entry broke the xorg X server on my device as it couldn't find the display any more. It needs the 'name' file and now there isn't one. That commit claims that 'name' is not compatible with i2c or spi. i2c does register it own 'name' file, but spi does not, hence my problem - I have an spi display. So create a special case for i2c: add the name attribute for non-i2c devices. What X driver is that? What's it doing with the display name? Is it just using the display name to show something for the user, and the returned value can be essentially any string? Tomi signature.asc Description: OpenPGP digital signature
[PATCH][v4.0-rc] ARM: dts: dra7x-evm: beagle-x15: Fix USB Host
In commit 87517d26d888 (ARM: dts: dra7-evm: Add extcon nodes for USB)
we enabled Extcon USB gpio to tackle the USB ID pin and get
peripheral mode to work.
But the extcon-gpio-usb driver [1] didn't make it into v4.0
and this makes the USB driver defer probe indefinitely breaking
USB Host functionality.
As a temporary fix we remove the extcon handle from the
USB controller and add it back when the extcon driver
merges in v4.1.
[1] - https://lkml.org/lkml/2015/2/2/187
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 8
arch/arm/boot/dts/dra7-evm.dts | 8
arch/arm/boot/dts/dra72-evm.dts | 8
3 files changed, 24 deletions(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 03750af..6463f9e 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -549,14 +549,6 @@
pinctrl-0 = usb1_pins;
};
-omap_dwc3_1 {
- extcon = extcon_usb1;
-};
-
-omap_dwc3_2 {
- extcon = extcon_usb2;
-};
-
usb2 {
dr_mode = peripheral;
};
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 746cddb..3290a96 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -543,14 +543,6 @@
};
};
-omap_dwc3_1 {
- extcon = extcon_usb1;
-};
-
-omap_dwc3_2 {
- extcon = extcon_usb2;
-};
-
usb1 {
dr_mode = peripheral;
pinctrl-names = default;
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 4d87117..e0264d0 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -380,14 +380,6 @@
phy-supply = ldo4_reg;
};
-omap_dwc3_1 {
- extcon = extcon_usb1;
-};
-
-omap_dwc3_2 {
- extcon = extcon_usb2;
-};
-
usb1 {
dr_mode = peripheral;
pinctrl-names = default;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER
On 23/02/15 23:38, Robert Abel wrote: On Tue, Feb 17, 2015 at 3:25 PM, Roger Quadros rog...@ti.com wrote: one more thing to note is that just specifying sync-clk-ps in DT is not enough for asynchronous devices. The driver doesn't set gpmc_t-sync_clk if gpmc,sync-read or gpmc,sync-write was not set in the DT, which would be the case for asynchronous devices. You're mistaken. It's always parsed, no matter what. See [1]. But I You are right. did implement your suggestion of computing the divider in the mean time. I'm going to send the patches rebased to 3.19 tomorrow, after I tested them. What is your proposal to make things better? And what is your use case that doesn't work with existing setup? Well, the current setup was obviously inspired by an asynchronous-only use-case, where all the timings are in seconds and get converted on-the-fly. Of course, currently, there is no support to re-compute them once the gpmc_fclk changes frequency, but I guess that's what the TODO about the clock framework is about? Yes. Anyway, my synchronous use-case is inherently... synchronous. Synchronous protocols shouldn't be specified in ns at all. They should directly be specified in clock ticks. This is also advantageous, as changes in gpmc_fclk don't need to propagate to the registers. I haven't looked much at synchronous memories except oneNAND which has both asynchronous and synchronous modes. In the datasheet, synchronous timings are specified in seconds and change depending on device speed grade. So seems to be the case with the Spansion NOR flash you mentioned. IMO the DT entries should directly match the unit specified in the memory device datasheet. Translations are best left to sw. My main grief with the current setup is its dependency on the *unknown* gpmc_fclk period at startup when the DT is processed and GPMC code is called. For instance, my private DT currently operates on the assumption of 166 Mhz L3 clk (and therefore gpmc_fclk), so all my timings are in multiples of 6 ns. Should now a colleague of mine think it would be a splendid idea to change this frequency by means of bootloader options [to save power, to process data even faster, etc], everything would break, because the L3 might have to be clocked at 100 MHz (due to divider limits along the clock tree for example) thus making my gpmc_fclk period 10ns. Now all my synchronous timings are wrong, because all DT values round to different clock ticks. gpmc_fclk is L3 bus clock and is not configurable by the driver but preset at boot time or might be scaled by cpufreq driver. GPMC_CLK is configurable to some extent by the divisor. If some parameters of newer devices are specified in CLK ticks instead of seconds then I agree that we need to add new DT bindings to specify them. Can you specify which parameters are specified in CLKs in the device you are using. One solution would obviously be very verbose: Split synchronous and asynchronous timings completely. Have a time-ns and a time-tck (where time is waitmonitoring, or readaccess etc) setting for different use cases. This would work for truly asynchronous (read _and_ write asynchronous) as well as truly synchronous (read _and_ write synchronous) setups. This 'simple' model breaks for parts where one form of access is synchronous while the other is asynchronous, e.g. Spansion WS/NS/VS parts, see [2] pg. 10. There's no easy solution for mixed timings, because some timing parameters are shared between synchronous and asynchronous accesses (WAITMONITORINGTIME, CSONTIME, ADVONTIME, WRDATAONADMUXBUS etc.). One obvious solution is to try to slow the synchronous side down until asynchronous timings can be met, but that would make for very slow accesses in most cases. There was a hackish way this was made to work with OneNAND devices. It still needs a major cleanup. The oneNAND driver starts up with asynchronous timings and then calculates the synchronous timings on the fly based on device speed grade. http://lxr.free-electrons.com/source/arch/arm/mach-omap2/gpmc-onenand.c#L345 For instance, I originally started out thinking the GPMC would run at 100 MHz externally -- because it's the max frequency rating -- only to be surprised when the clock looked weird on the GPMC_CLK pin, because it was at 166 MHz. I'm not sure how to completely remedy this, but specifying timings in ns in DT and then depending on the correct board frequency is kind of shady... :( Right. I get the picture now. Let's address the issues one by one. - for deterministic gpmc_fclk, gpmc,sync-clk-ps allows you to specify the external GPMC_CLK period. GPMC driver doesn't have control of gpmc_fclk frequency but it should try to set GPMC_CLK as close as possible to the specified DT gpmc,sync-clk-ps by using the fclk divider. - Identify what parameters are better specified in GPMC_CLK ticks instead of seconds and provide DT bindings for them - If gpmc_fclk changes
Re: [PATCH v5 0/7] irqchip: Move OMAP{4,5}/DRA7 to use stacked domains
On 23/02/15 20:39, Nishanth Menon wrote:
On 02/23/2015 02:32 PM, Nishanth Menon wrote:
On 17:44-20150223, Marc Zyngier wrote:
This series is extracted from [4], which is trying to remove all
traces of gic_arch_extn from the tree. As some maintainers are more
responsive than others (understatement of the year...), I've decided
to split it per sub-arch, and get it moving, at least partially.
This series addresses OMAP{4,5} by converting the WUGEN to stacked
domains. The DRA7 crossbar gets the same treatment.
It is worth realizing that:
- I haven't been able to test this as much as I would have wanted to
(it's only been tested on omap4 and omap5).
- This actively *breaks* existing setups. Once you boot a new kernel
with an old DT, suspend/resume *will* be broken. Old kernels on a
new DT won't even boot! You've been warned. This really outline the
necessity of actually describing the HW in device trees...
Based on 4.0-rc1.
* From v4: [4]
- Extracted from the full series
- Rebased on 4.0-rc1
* From v3 [3]:
- Rebased on top of the patch working around hardcoded IRQ on OMAP4/5 [4]
- Fixed more iMX6 DTs (Stephan)
- Fixed Exynos4/5 DTs
* From v2 [2]:
- Addressed numerous comments from Thierry
- Merged bug fixes from Nishanth
- Merged bug fix from Stefan
* From v1 [1]:
- Rebased on 3.19-rc3
- Fixed a number of additional platforms
- Added crossbar conversion to stacked domains
- Merged bug fixes from Nishanth
[4]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/317531.html
[3]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/315385.html
[2]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314041.html
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307338.html
Marc Zyngier (7):
genirq: Add irqchip_set_wake_parent
irqchip: crossbar: convert dra7 crossbar to stacked domains
DT: update ti,irq-crossbar binding
irqchip: GIC: get rid of routable domain
DT: arm,gic: kill arm,routable-irqs
DT: omap4/5: add binding for the wake-up generator
ARM: omap: convert wakeupgen to stacked domains
Documentation/devicetree/bindings/arm/gic.txt | 6 -
.../devicetree/bindings/arm/omap/crossbar.txt | 18 +-
.../interrupt-controller/ti,omap4-wugen-mpu| 33
arch/arm/boot/dts/am4372.dtsi | 11 +-
arch/arm/boot/dts/am437x-gp-evm.dts| 1 -
arch/arm/boot/dts/am437x-sk-evm.dts| 1 -
arch/arm/boot/dts/am43x-epos-evm.dts | 1 -
arch/arm/boot/dts/am57xx-beagle-x15.dts| 3 +-
arch/arm/boot/dts/dra7-evm.dts | 2 +-
arch/arm/boot/dts/dra7.dtsi| 43 +++--
arch/arm/boot/dts/dra72-evm.dts| 1 -
arch/arm/boot/dts/dra72x.dtsi | 3 +-
arch/arm/boot/dts/dra74x.dtsi | 5 +-
arch/arm/boot/dts/omap4-duovero.dtsi | 2 -
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +-
arch/arm/boot/dts/omap4-sdp.dts| 8 +-
arch/arm/boot/dts/omap4-var-som-om44.dtsi | 2 -
arch/arm/boot/dts/omap4.dtsi | 18 +-
arch/arm/boot/dts/omap5-cm-t54.dts | 1 -
arch/arm/boot/dts/omap5-uevm.dts | 2 -
arch/arm/boot/dts/omap5.dtsi | 26 ++-
arch/arm/mach-omap2/omap-wakeupgen.c | 125 ++---
arch/arm/mach-omap2/omap-wakeupgen.h | 1 -
arch/arm/mach-omap2/omap4-common.c | 21 +--
drivers/irqchip/irq-crossbar.c | 207
-
drivers/irqchip/irq-gic.c | 59 +-
include/linux/irq.h| 1 +
include/linux/irqchip/arm-gic.h| 6 -
include/linux/irqchip/irq-crossbar.h | 11 --
kernel/irq/chip.c | 16 ++
30 files changed, 364 insertions(+), 278 deletions(-)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
delete mode 100644 include/linux/irqchip/irq-crossbar.h
marc-test-irq (Applied the series to v4.0-rc1) - boot logs:
1: am335x-evm: BOOT: PASS:
http://paste.ubuntu.org.cn/2469913
2: am335x-sk: BOOT: PASS:
http://paste.ubuntu.org.cn/2469914
3: am3517-evm: BOOT: PASS:
http://paste.ubuntu.org.cn/2469915
4: am37x-evm: BOOT: PASS:
http://paste.ubuntu.org.cn/2469916
5: am437x-sk: BOOT: PASS:
http://paste.ubuntu.org.cn/2469917
6:am43xx-epos: BOOT: PASS:
http://paste.ubuntu.org.cn/2469918
7: am43xx-gpevm: BOOT: PASS:
http://paste.ubuntu.org.cn/2469919
8: BeagleBoard-XM: BOOT: PASS:
Re: [PATCH v5 0/7] irqchip: Move OMAP{4,5}/DRA7 to use stacked domains
* Marc Zyngier marc.zyng...@arm.com [150224 01:08]:
On 23/02/15 23:02, Tony Lindgren wrote:
* Marc Zyngier marc.zyng...@arm.com [150223 09:48]:
This series is extracted from [4], which is trying to remove all
traces of gic_arch_extn from the tree. As some maintainers are more
responsive than others (understatement of the year...), I've decided
to split it per sub-arch, and get it moving, at least partially.
This series addresses OMAP{4,5} by converting the WUGEN to stacked
domains. The DRA7 crossbar gets the same treatment.
It is worth realizing that:
- I haven't been able to test this as much as I would have wanted to
(it's only been tested on omap4 and omap5).
- This actively *breaks* existing setups. Once you boot a new kernel
with an old DT, suspend/resume *will* be broken. Old kernels on a
new DT won't even boot! You've been warned. This really outline the
necessity of actually describing the HW in device trees...
Could we parse still the old binding and produce warning for the
case when a new kernel is booted with the old DT? That would make
it easier for people to debug what's going on.
There's a number of strategies:
- Looking up the default, top-level interrupt controller:
if that's the GIC, scream.
- Lookup the crossbar:
if it exists, but is not an interrupt controller, scream as well.
- Lookup the WUGEN:
if it doesn't exist, scream again.
The last one is pretty easy to implement:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index fba1ba7..7bb116a 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -277,6 +277,12 @@ void __init omap_gic_of_init(void)
{
struct device_node *np;
+ intc_node = of_find_matching_node(NULL, intc_match);
+ if (WARN_ON(!intc_node)) {
+ pr_err(No WUGEN found in DT, system will misbehave.\n);
+ pr_err(UPDATE YOUR DEVICE TREE!\n);
+ }
+
/* Extract GIC distributor and TWD bases for OMAP4460 ROM Errata WA */
if (!cpu_is_omap446x())
goto skip_errata_init;
This should cover both OMAP4, OMAP5 and DRA7.
What do you think?
This should do the job for the case of old dtb and people trying to
suspend the device.
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] thermal: ti-soc-thermal: bandgap: Fix build warning if !CONFIG_PM_SLEEP
Hi Rui,
On 02/09/2015 05:01 PM, Nishanth Menon wrote:
On 16:55-20150206, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Fix following build warning if CONFIG_PM_SLEEP is not set:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
'ti_bandgap_suspend' defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
^
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1492:12: warning:
'ti_bandgap_resume' defined but not used [-Wunused-function]
static int ti_bandgap_resume(struct device *dev)
^
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 74c0e34..5d46660 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1402,7 +1402,7 @@ int ti_bandgap_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int ti_bandgap_save_ctxt(struct ti_bandgap *bgp)
{
int i;
--
1.9.1
Suggest aligning with Paul as well:
https://patchwork.kernel.org/patch/5795391/
^Paul Walmsley wrote: Oh, nothing to be confused by, I just missed the
earlier patch. I withdraw mine.
Otherwise:
Acked-by: Nishanth Menon n...@ti.com
It looks like this patch is missed in 4.0-rc1, so could it be merged
during rc cycle or you'd like me to resend it?
(I've rechecked - it can be applied on top of Linux 4.0-rc1 without any issues)
--
regards,
-grygorii
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On Thu, Feb 19, 2015 at 01:32:33PM -0800, Mike Turquette wrote: Quoting Stephen Boyd (2015-02-06 11:30:18) On 02/06/15 05:39, Russell King - ARM Linux wrote: On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote: From what I can tell this code is now broken because we made all clk getting functions (there's quite a few...) return unique pointers every time they're called. It seems that the driver wants to know if extclk and clk are the same so it can do something differently in kirkwood_set_rate(). Do we need some sort of clk_equal(struct clk *a, struct clk *b) function for drivers like this? Well, the clocks in question are the SoC internal clock (which is more or less fixed, but has a programmable divider) and an externally supplied clock, and the IP has a multiplexer on its input which allows us to select between those two sources. If it were possible to bind both to the same clock, it wouldn't be a useful configuration - nothing would be gained from doing so in terms of available rates. What the comparison is there for is to catch the case with legacy lookups where a clkdev lookup entry with a NULL connection ID results in matching any connection ID passed to clk_get(). If the patch changes this, then we will have a regression - and this is something which needs fixing _before_ we do this return unique clocks. Ok. It seems that we might need a clk_equal() or similar API after all. My understanding is that this driver is calling clk_get() twice with NULL for the con_id and then extclk in attempts to get the SoC internal clock and the externally supplied clock. If we're using legacy lookups then both clk_get() calls may map to the same clk_lookup entry and before Tomeu's patch that returns unique clocks the driver could detect this case and know that there isn't an external clock. Looking at arch/arm/mach-dove/common.c it seems that there is only one lookup per device and it has a wildcard NULL for con_id so both clk_get() calls here are going to find the same lookup and get a unique struct clk pointer. Why don't we make the legacy lookup more specific and actually indicate internal for the con_id? Then the external clock would fail to be found, but we can detect that case and figure out that it's not due to probe defer, but instead due to the fact that there really isn't any mapping. It looks like the code is already prepared for this anyway. 8 From: Stephen Boyd sb...@codeaurora.org Subject: [PATCH] ARM: dove: Remove wildcard from mvebu-audio device clk lookup This i2s driver is using the wildcard nature of clkdev lookups to figure out if there's an external clock or not. It does this by calling clk_get() twice with NULL for the con_id first and then external for the con_id the second time around and then compares the two pointers. With DT the wildcard feature of clk_get() is gone and so the driver has to handle an error from the second clk_get() call as meaning no external clock specified. Let's use that logic even with clk lookups to simplify the code and remove the struct clk pointer comparisons which may not work in the future when clk_get() returns unique pointers. Signed-off-by: Stephen Boyd sb...@codeaurora.org Russell et al, I'm happy to take this patch through the clock tree (where the problem shows up) with an ack. It's not up to me - I don't maintain this driver. I'm just an interested party. Note that much more than just this has now broken. The iMX6 code has broken as well, and it's not going to take such a simple fix there to fix it either. Please either revert the patches creating this breakage (and have another attempt at the next merge window) or supply fixes for these places. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 4/6] dmaengine: omap-dma: Take DMA request number from DT if it is available
On Tue, Feb 24, 2015 at 04:21:21PM +0200, Peter Ujfalusi wrote:
Use the dma-requests property from DT to get the number of DMA requests.
In case of legacy boot or failure to find the property, use the default
127 as number of requests.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 56c33e93dd24..7def31c919f4 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -34,6 +34,7 @@ struct omap_dmadev {
const struct omap_dma_reg *reg_map;
struct omap_system_dma_plat_info *plat;
bool legacy;
+ unsigned dma_requests;
spinlock_t irq_lock;
uint32_t irq_enable_mask;
struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
@@ -1118,7 +1119,15 @@ static int omap_dma_probe(struct platform_device *pdev)
tasklet_init(od-task, omap_dma_sched, (unsigned long)od);
- for (i = 0; i OMAP_SDMA_REQUESTS; i++) {
+ if (!pdev-dev.of_node || of_property_read_u32(pdev-dev.of_node,
+dma-requests,
+od-dma_requests)) {
+ dev_info(pdev-dev,
+ DMA request lines not specified, using 127\n);
+ od-dma_requests = 127;
What happened to OMAP_SDMA_REQUESTS?
If you're not going to use OMAP_SDMA_REQUESTS, then don't add it. If
you are going to use it, please also change the dev_info() line to use
that macro too.
Thanks.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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/6] dmaengine: Add driver for TI DMA crossbar on DRA7x
The DRA7x has more peripherals with DMA requests than the sDMA can handle:
205 vs 127. All DMA requests are routed through the DMA crossbar, which can
be configured to route selected incoming DMA requests to specific sDMA
request.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/Kconfig | 4 +
drivers/dma/Makefile | 1 +
drivers/dma/ti-dma-crossbar.c | 191 ++
3 files changed, 196 insertions(+)
create mode 100644 drivers/dma/ti-dma-crossbar.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a874b6ec6650..dfe72a0f46dc 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -245,6 +245,9 @@ config TI_EDMA
Enable support for the TI EDMA controller. This DMA
engine is found on TI DaVinci and AM33xx parts.
+config TI_DMA_CROSSBAR
+ bool
+
config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
bool
@@ -330,6 +333,7 @@ config DMA_OMAP
depends on ARCH_OMAP
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
+ select TI_DMA_CROSSBAR if SOC_DRA7XX
config DMA_BCM2835
tristate BCM2835 DMA engine support
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index f915f61ec574..bc12f9a4e62b 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
obj-$(CONFIG_DMA_OMAP) += omap-dma.o
+obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
new file mode 100644
index ..bf01434df46a
--- /dev/null
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include linux/slab.h
+#include linux/err.h
+#include linux/init.h
+#include linux/list.h
+#include linux/io.h
+#include linux/regmap.h
+#include linux/idr.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/module.h
+
+static DEFINE_IDR(map_idr);
+
+struct ti_dma_xbar_data {
+ struct dma_router dmarouter;
+ struct regmap *regmap;
+
+ uint safe_val; /* Value to rest the crossbar lines */
+ uint xbar_requests; /* number of DMA requests connected to XBAR */
+ uint dma_requests; /* number of DMA requests forwarded to DMA */
+
+ void __iomem *iomem;
+};
+
+struct ti_dma_xbar_map {
+ int xbar_in;
+ int xbar_out;
+};
+
+static void ti_dma_xbar_free(struct device *dev, void *route_data)
+{
+ struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
+ struct ti_dma_xbar_map *map = route_data;
+
+ dev_dbg(dev, Unmapping XBAR%d (was routed to %d)\n,
+ map-xbar_in, map-xbar_out);
+
+ regmap_write(xbar-regmap, map-xbar_out * 2, 0);
+ idr_remove(map_idr, map-xbar_out);
+ kfree(map);
+}
+
+static void *ti_dma_xbar_route_allocate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct platform_device *pdev = of_find_device_by_node(ofdma-of_node);
+ struct ti_dma_xbar_data *xbar = platform_get_drvdata(pdev);
+ struct ti_dma_xbar_map *map;
+
+ if (dma_spec-args[0] = xbar-xbar_requests) {
+ dev_err(pdev-dev, Invalid XBAR request number: %d\n,
+ dma_spec-args[0]);
+ return NULL;
+ }
+
+ map = kzalloc(sizeof(*map), GFP_KERNEL);
+ if (!map)
+ return NULL;
+
+ map-xbar_out = idr_alloc(map_idr, NULL, 0, xbar-dma_requests,
+ GFP_KERNEL);
+ map-xbar_in = dma_spec-args[0];
+
+ /* The DMA request is 1 based in sDMA */
+ dma_spec-args[0] = map-xbar_out + 1;
+
+ dev_dbg(pdev-dev, Mapping XBAR%d to DMA%d\n,
+ map-xbar_in, map-xbar_out);
+
+ regmap_write(xbar-regmap, map-xbar_out * 2, map-xbar_in);
+
+ return map;
+}
+
+static const struct regmap_config ti_dma_xbar_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 2,
+ .val_bits = 16,
+ .max_register = 0xfc,
+ .cache_type = REGCACHE_FLAT,
+};
+
+static int ti_dma_xbar_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *dma_node;
+ struct ti_dma_xbar_data *xbar;
+ struct resource *res;
+ void __iomem *iomem;
+ int i, ret;
+
+ if (!node)
+ return -ENODEV;
+
+ dma_node = of_parse_phandle(node,
[PATCH 3/6] dmaengine: omap-dma: Use defines for dma channels and request count
Instead of magic numbers in the code, use define for number of logical DMA
channels and DMA requests.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 7dd6dd121681..56c33e93dd24 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -22,6 +22,9 @@
#include virt-dma.h
+#define OMAP_SDMA_REQUESTS 127
+#define OMAP_SDMA_CHANNELS 32
+
struct omap_dmadev {
struct dma_device ddev;
spinlock_t lock;
@@ -33,7 +36,7 @@ struct omap_dmadev {
bool legacy;
spinlock_t irq_lock;
uint32_t irq_enable_mask;
- struct omap_chan *lch_map[32];
+ struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
};
struct omap_chan {
@@ -1115,7 +1118,7 @@ static int omap_dma_probe(struct platform_device *pdev)
tasklet_init(od-task, omap_dma_sched, (unsigned long)od);
- for (i = 0; i 127; i++) {
+ for (i = 0; i OMAP_SDMA_REQUESTS; i++) {
rc = omap_dma_chan_init(od, i);
if (rc) {
omap_dma_free(od);
--
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 4/6] dmaengine: omap-dma: Take DMA request number from DT if it is available
Use the dma-requests property from DT to get the number of DMA requests.
In case of legacy boot or failure to find the property, use the default
127 as number of requests.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 56c33e93dd24..7def31c919f4 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -34,6 +34,7 @@ struct omap_dmadev {
const struct omap_dma_reg *reg_map;
struct omap_system_dma_plat_info *plat;
bool legacy;
+ unsigned dma_requests;
spinlock_t irq_lock;
uint32_t irq_enable_mask;
struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
@@ -1118,7 +1119,15 @@ static int omap_dma_probe(struct platform_device *pdev)
tasklet_init(od-task, omap_dma_sched, (unsigned long)od);
- for (i = 0; i OMAP_SDMA_REQUESTS; i++) {
+ if (!pdev-dev.of_node || of_property_read_u32(pdev-dev.of_node,
+ dma-requests,
+ od-dma_requests)) {
+ dev_info(pdev-dev,
+DMA request lines not specified, using 127\n);
+ od-dma_requests = 127;
+ }
+
+ for (i = 0; i od-dma_requests; i++) {
rc = omap_dma_chan_init(od, i);
if (rc) {
omap_dma_free(od);
--
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 0/6] dmaengine/dra7x: DMA router (crossbar support)
Hi, The series adds support for DMA router type of devices. They are used in SoCs which has more peripherals with DMA request lines than the DMA controller can handle. The router itself is not part of the DMA controller and it's operation should be transparent (as it is in the HW) for the SW stack. This series takes into accound the comments Sricharan received for his version of the crossbar driver: https://lkml.org/lkml/2014/3/7/199 This implementation is not tied to any DMA driver so it is possible to use the framework by other vendors, also ACPI version of binding can be easy enough to be added. The omap-dma part of changes are based on the dma property name change series: https://lkml.org/lkml/2015/2/20/182 but the code has fallback so it is working w/o the changes in that series. Regards, Peter --- Peter Ujfalusi (6): dmaengine: of_dma: Support for DMA routers dmaengine: Add driver for TI DMA crossbar on DRA7x dmaengine: omap-dma: Use defines for dma channels and request count dmaengine: omap-dma: Take DMA request number from DT if it is available dmaengine: omap-dma: Remove mapping between virtual channels and requests ARM: DTS: dra7x: Integrate sDMA crossbar Documentation/devicetree/bindings/dma/dma.txt | 27 arch/arm/boot/dts/dra7.dtsi | 57 drivers/dma/Kconfig | 4 + drivers/dma/Makefile | 1 + drivers/dma/dmaengine.c | 7 + drivers/dma/of-dma.c | 92 + drivers/dma/omap-dma.c| 24 +++- drivers/dma/ti-dma-crossbar.c | 191 ++ include/linux/dmaengine.h | 17 +++ include/linux/of_dma.h| 21 +++ 10 files changed, 413 insertions(+), 28 deletions(-) create mode 100644 drivers/dma/ti-dma-crossbar.c -- 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 5/6] dmaengine: omap-dma: Remove mapping between virtual channels and requests
Do not direct map the virtual channels to sDMA request number. When the
sDMA is behind of a crossbar this direct mapping can cause situations when
certain channel can not be requested since the crossbar request number
will no longer match with the sDMA request line.
The direct mapping for virtual channels with HW request lines will make it
harder to implement MEM_TO_MEM mode for the driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 7def31c919f4..1d759b81e1be 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -593,6 +593,7 @@ static void omap_dma_free_chan_resources(struct dma_chan
*chan)
omap_free_dma(c-dma_ch);
dev_dbg(od-ddev.dev, freeing channel for %u\n, c-dma_sig);
+ c-dma_sig = 0;
}
static size_t omap_dma_sg_size(struct omap_sg *sg)
@@ -1049,7 +1050,6 @@ static int omap_dma_chan_init(struct omap_dmadev *od, int
dma_sig)
return -ENOMEM;
c-reg_map = od-reg_map;
- c-dma_sig = dma_sig;
c-vc.desc_free = omap_dma_desc_free;
vchan_init(c-vc, od-ddev);
INIT_LIST_HEAD(c-node);
@@ -1219,10 +1219,14 @@ static struct platform_driver omap_dma_driver = {
bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
{
if (chan-device-dev-driver == omap_dma_driver.driver) {
+ struct omap_dmadev *od = to_omap_dma_dev(chan-device);
struct omap_chan *c = to_omap_dma_chan(chan);
unsigned req = *(unsigned *)param;
- return req == c-dma_sig;
+ if (req = od-dma_requests) {
+ c-dma_sig = req;
+ return true;
+ }
}
return false;
}
--
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/6] dmaengine: of_dma: Support for DMA routers
DMA routers are transparent devices used to mux DMA requests from
peripherals to DMA controllers. They are used when the SoC integrates more
devices with DMA requests then their controller can handle.
DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
lines, but in SoC level it has 205 DMA requests.
The of_dma_router will be registered as of_dma_controller with special
xlate function and additional parameters and the code will translate and
requests a DMA channel from the real DMA controller.
This way the router can be transparent for the system while remaining generic
enough to be used in different environments.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/dma.txt | 27
drivers/dma/dmaengine.c | 7 ++
drivers/dma/of-dma.c | 92 +++
include/linux/dmaengine.h | 17 +
include/linux/of_dma.h| 21 ++
5 files changed, 164 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index 82104271e754..75fcfc733858 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -31,6 +31,33 @@ Example:
dma-requests = 127;
};
+* DMA router
+
+DMA routers are transparent IP blocks used to route DMA request lines from
+devices to the DMA controller. Some SoCs (like TI DRA7x) have more peripherals
+integrated with DMA requests than what the DMA controller can handle directly.
+
+Required property:
+- dma-device: phandle of the DMA controller. The router is modifying
+ the DMA requests for this controller.
+- #dma-cells: Must be set to be the same as the dma-device's
+ #dma-cells
+
+Optional properties:
+- dma-requests:Number of incoming request lines the router can handle.
+- dma-device
+ - dma-requests: The router driver might need to look for this in order
+ to configure the routing.
+
+Example:
+ sdma_xbar: dma-router@4a002b78 {
+ compatible = ti,dra7-dma-crossbar;
+ reg = 0x4a002b78 0xfc;
+ #dma-cells = 1;
+ dma-requests = 205;
+ ti,dma-safe-map = 0;
+ dma-device = sdma;
+ };
* DMA client
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index f15712f2fec6..ba60f1f0ddd3 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -271,6 +271,13 @@ static void dma_chan_put(struct dma_chan *chan)
/* This channel is not in use anymore, free it */
if (!chan-client_count chan-device-device_free_chan_resources)
chan-device-device_free_chan_resources(chan);
+
+ /* If the channel is used via a DMA request router, free the mapping */
+ if (chan-router chan-router-route_free) {
+ chan-router-route_free(chan-router-dev, chan-route_data);
+ chan-router = NULL;
+ chan-route_data = NULL;
+ }
}
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index ca31f1b45366..c86f8823da0d 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -45,6 +45,53 @@ static struct of_dma *of_dma_find_controller(struct
of_phandle_args *dma_spec)
}
/**
+ * of_dma_router_xlate - translation function for router devices
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ * @of_dma:pointer to DMA controller data (router information)
+ *
+ * The function creates new dma_spec to be passed to the router driver's
+ * of_dma_route_allocate() function to prepare a dma_spec which will be used
+ * to request channel from the real DMA controller.
+ */
+static struct dma_chan *of_dma_router_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct dma_chan *chan;
+ struct of_dma *ofdma_target;
+ struct device_node *dma_target;
+ struct of_phandle_args dma_spec_target;
+ void*route_data;
+
+ dma_target = of_parse_phandle(dma_spec-np, dma-device, 0);
+ if (!dma_target) {
+ pr_err(%s: Can't get target DMA\n, __func__);
+ return NULL;
+ }
+
+ /* translate the request for the real DMA controller */
+ memcpy(dma_spec_target, dma_spec, sizeof(dma_spec_target));
+ dma_spec_target.np = dma_target;
+ route_data = ofdma-of_dma_route_allocate(dma_spec_target, ofdma);
+
+ ofdma_target = of_dma_find_controller(dma_spec_target);
+ if (!ofdma_target) {
+ pr_err(%s: Can't get target ofDMA\n, __func__);
+ return NULL;
+ }
+
+ chan =
Re: [PATCH 5/6] dmaengine: omap-dma: Remove mapping between virtual channels and requests
On Tue, Feb 24, 2015 at 04:21:22PM +0200, Peter Ujfalusi wrote: Do not direct map the virtual channels to sDMA request number. When the sDMA is behind of a crossbar this direct mapping can cause situations when certain channel can not be requested since the crossbar request number will no longer match with the sDMA request line. The direct mapping for virtual channels with HW request lines will make it harder to implement MEM_TO_MEM mode for the driver. I assume when you talk about MEM_TO_MEM, you're referring to a DMA_MEMCPY driver. mem2mem should not be handled by the slave driver. This should be a separate DMA engine driver structure which does not have DMA_SLAVE set. See how amba-pl08x handles this. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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: New l3-noc error with CPUFREQ_DT built-in with v4.0-rc1
Hi, On Mon, Feb 23, 2015 at 07:24:50PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150223 19:29]: * Felipe Balbi ba...@ti.com [150223 19:19]: On Mon, Feb 23, 2015 at 07:01:42PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150223 18:43]: Looks like the address is 0 for Custom Error. Anyways, reverting yeah, that's because the error comes from l4per2, not l3 :-) Right so it seems :) a fix for similar issue found on omap3 so far seems to help, that's 3d009c8c61f9 (gpio: omap: Fix bad device access with setup_irq()). if we revert that, we regress omap3, right ? Yes we saw that getting triggered on omap3/4 before 3d009c8c61f9. Now looking at the stack trace again, it actually has something: ... [c05999a4] (__irq_svc) from [c0599164] (_raw_spin_unlock_irqrestore+0x34/0x44) [c0599164] (_raw_spin_unlock_irqrestore) from [c0027120] (omap_hwmod_idle+0x34/0x44) [c0027120] (omap_hwmod_idle) from [c00283f8] (omap_device_idle+0x38/0x78) [c00283f8] (omap_device_idle) from [c0028454] (_od_runtime_suspend+0x1c/0x24) [c0028454] (_od_runtime_suspend) from [c03b5214] (__rpm_callback+0x2c/0x60) [c03b5214] (__rpm_callback) from [c03b5268] (rpm_callback+0x20/0x80) [c03b5268] (rpm_callback) from [c03b56b8] (rpm_suspend+0xe8/0x55c) [c03b56b8] (rpm_suspend) from [c03b6bdc] (pm_runtime_work+0x74/0xa8) [c03b6bdc] (pm_runtime_work) from [c0054608] (process_one_work+0x1b0/0x4a0) ... If it's the gpio-omap, there's probably some confusion still in the driver regarding the GPIO bank idle status. Anyways, will look more into it tomorrow. And now I'm seeing the error with 3d009c8c61f9 reverted, so it does not seem to be that either.. well, that's good :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/6] dmaengine: omap-dma: Take DMA request number from DT if it is available
On 02/24/2015 04:25 PM, Russell King - ARM Linux wrote:
On Tue, Feb 24, 2015 at 04:21:21PM +0200, Peter Ujfalusi wrote:
Use the dma-requests property from DT to get the number of DMA requests.
In case of legacy boot or failure to find the property, use the default
127 as number of requests.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 56c33e93dd24..7def31c919f4 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -34,6 +34,7 @@ struct omap_dmadev {
const struct omap_dma_reg *reg_map;
struct omap_system_dma_plat_info *plat;
bool legacy;
+unsigned dma_requests;
spinlock_t irq_lock;
uint32_t irq_enable_mask;
struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
@@ -1118,7 +1119,15 @@ static int omap_dma_probe(struct platform_device
*pdev)
tasklet_init(od-task, omap_dma_sched, (unsigned long)od);
-for (i = 0; i OMAP_SDMA_REQUESTS; i++) {
+if (!pdev-dev.of_node || of_property_read_u32(pdev-dev.of_node,
+ dma-requests,
+ od-dma_requests)) {
+dev_info(pdev-dev,
+ DMA request lines not specified, using 127\n);
+od-dma_requests = 127;
What happened to OMAP_SDMA_REQUESTS?
If you're not going to use OMAP_SDMA_REQUESTS, then don't add it. If
you are going to use it, please also change the dev_info() line to use
that macro too.
Aargh, yes you are right. Will fix this up in v2.
--
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
[PATCH 6/6] ARM: DTS: dra7x: Integrate sDMA crossbar
The sDMA requests are routed through the DMA crossbar and without the
crossbar only peripherals using DMA request 0-127 can be used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 57 ++---
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index aefa4192533a..bbda4261caf4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -253,6 +253,15 @@
dma-requests = 127;
};
+ sdma_xbar: dma-router@4a002b78 {
+ compatible = ti,dra7-dma-crossbar;
+ reg = 0x4a002b78 0xfc;
+ #dma-cells = 1;
+ dma-requests = 205;
+ ti,dma-safe-map = 0;
+ dma-device = sdma;
+ };
+
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
reg = 0x4ae1 0x200;
@@ -348,7 +357,7 @@
ti,hwmods = uart1;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 49, sdma 50;
+ dmas = sdma_xbar 49, sdma_xbar 50;
dma-names = tx, rx;
};
@@ -359,7 +368,7 @@
ti,hwmods = uart2;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 51, sdma 52;
+ dmas = sdma_xbar 51, sdma_xbar 52;
dma-names = tx, rx;
};
@@ -370,7 +379,7 @@
ti,hwmods = uart3;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 53, sdma 54;
+ dmas = sdma_xbar 53, sdma_xbar 54;
dma-names = tx, rx;
};
@@ -381,7 +390,7 @@
ti,hwmods = uart4;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 55, sdma 56;
+ dmas = sdma_xbar 55, sdma_xbar 56;
dma-names = tx, rx;
};
@@ -392,7 +401,7 @@
ti,hwmods = uart5;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 63, sdma 64;
+ dmas = sdma_xbar 63, sdma_xbar 64;
dma-names = tx, rx;
};
@@ -403,7 +412,7 @@
ti,hwmods = uart6;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 79, sdma 80;
+ dmas = sdma_xbar 79, sdma_xbar 80;
dma-names = tx, rx;
};
@@ -819,7 +828,7 @@
ti,hwmods = mmc1;
ti,dual-volt;
ti,needs-special-reset;
- dmas = sdma 61, sdma 62;
+ dmas = sdma_xbar 61, sdma_xbar 62;
dma-names = tx, rx;
status = disabled;
pbias-supply = pbias_mmc_reg;
@@ -831,7 +840,7 @@
interrupts = GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmc2;
ti,needs-special-reset;
- dmas = sdma 47, sdma 48;
+ dmas = sdma_xbar 47, sdma_xbar 48;
dma-names = tx, rx;
status = disabled;
};
@@ -842,7 +851,7 @@
interrupts = GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmc3;
ti,needs-special-reset;
- dmas = sdma 77, sdma 78;
+ dmas = sdma_xbar 77, sdma_xbar 78;
dma-names = tx, rx;
status = disabled;
};
@@ -853,7 +862,7 @@
interrupts = GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmc4;
ti,needs-special-reset;
- dmas = sdma 57, sdma 58;
+ dmas = sdma_xbar 57, sdma_xbar 58;
dma-names = tx, rx;
status = disabled;
};
@@ -998,14 +1007,14 @@
#size-cells = 0;
ti,hwmods = mcspi1;
ti,spi-num-cs = 4;
- dmas = sdma 35,
- sdma 36,
- sdma 37,
- sdma 38,
- sdma 39,
-
[PATCH] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral
Fixes: http://bugs.elinux.org/issues/127
the bb.org community was seeing random reboots before this change.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6cc25ed..2c6248d 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -195,6 +195,7 @@
usb0 {
status = okay;
+ dr_mode = peripheral;
};
usb1 {
--
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: [PATCH] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral
On Tue, Feb 24, 2015 at 10:10:43AM -0600, Robert Nelson wrote:
Fixes: http://bugs.elinux.org/issues/127
the bb.org community was seeing random reboots before this change.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
that's a dead giveaway considering the connector in the board :-)
Thanks
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6cc25ed..2c6248d 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -195,6 +195,7 @@
usb0 {
status = okay;
+ dr_mode = peripheral;
};
usb1 {
--
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
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/2] ARM: DRA7x/OMAP5: Clock: DPLL Clock fixes
* Ravikumar Kattekola r...@ti.com [150219 08:13]: On 1/31/2015 10:36 PM, Ravikumar Kattekola wrote: Fix bypass clock source for a few DPLLs. On DRA7x/OMAP5, for a few DPLLs, both CLKINP and CLKINPULOW are connected to a mux and the output from mux is routed to the bypass clkout. Add a mux-clock as bypass clock with CLKINP and CLKINPULOW as parents. Tested against: tree: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git branch: master On: CPU : OMAP5432 ES2.0 Board: OMAP5432 uEVM and CPU : DRA752 ES1.0 Board: DRA7xx Ravikumar Kattekola (2): ARM: DRA7x: dts: Fix the bypass clock source for dpll_iva and others ARM: OMAP5: dts: Fix the bypass clock source for dpll_iva and others arch/arm/boot/dts/dra7xx-clocks.dtsi | 90 arch/arm/boot/dts/omap54xx-clocks.dtsi | 41 +-- 2 files changed, 118 insertions(+), 13 deletions(-) Hi Benoit, Can these fixes be looked into for 3.20-rc? Seem like valid fixes to me. Tero, care to take a look at these and ack if 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: am335x: USB DMA IRQ issue
Hi,
On Thu, Feb 05, 2015 at 12:19:23PM +0100, Yegor Yefremov wrote:
I have a problem with my am335x based board and USB.
Kernel: Linux version 3.18.1 (YegorYefremov@development1) (gcc version
4.9.2 (Buildroot 2015.02-git-00797-gf1b07c0) ) #1 SMP Thu Jan 15
15:31:27 CET 2015
I took two devices and equipped them with USB WLAN cards: Bus 001
Device 003: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless
Adapter. One device as AP and another as client. Client makes
permanent ping to AP. And from time to time I start nuttcp session.
After 2-3 days I get following errors:
2-3 days ? oh man... :-)
Here's one thing to try. Can you do some variable size pingtest ?
Something like below should do ?
random()
{
size=$(dd if=/dev/urandom count=1 2/dev/null|cksum|
cut -f1 -d |tr '-' '\0')
size=$(expr $size % 6)
}
num=$1
if [ -z $num ]
then
num=1
fi
while ! ifconfig usb0 /dev/null 21; do
printf waiting for usb0\n
sleep 1;
done
ifconfig usb0 192.168.2.14
for i in $(seq 1 $num); do
random
printf %d: \t pinging with size %-27d $i $size
if ! ping -c 6 192.168.2.15 -s $size -q -i 0 /dev/null 21; then
printf FAILED\n
break
fi
printf PASSED\n
done
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral
On Tue, Feb 24, 2015 at 10:10 AM, Robert Nelson robertcnel...@gmail.com wrote: Fixes: http://bugs.elinux.org/issues/127 the bb.org community was seeing random reboots before this change. Sorry.. ^ beagleboard.org i shouldn't use shorthand in mainline commits.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: restore name sysfs entry.
I have tested it with
X.Org X Server 1.12.4
Release Date: 2012-08-27
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-4-mx5 armv7l Debian
(coming from Debian Wheezy) on:
* gta04 (SPI panel)
* openpandora (SPI panel)
* BeagleBoard XM (with RGB panel)
* PandaBoard ES (w/o panel)
* omap5432-evm + Pyra prototype (MIPI panel)
Without this patch, X Server simply fails with:
Fatal server error:
no screens found
So please add
Tested-by: Nikolaus Schaller h...@goldelico.com
Thanks,
Nikolaus
Am 24.02.2015 um 10:37 schrieb NeilBrown ne...@suse.de:
commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b
OMAPDSS: rename display-sysfs 'name' entry
broke the xorg X server on my device as it couldn't find the display
any more. It needs the 'name' file and now there isn't one.
That commit claims that 'name' is not compatible with i2c or spi.
i2c does register it own 'name' file, but spi does not, hence my
problem - I have an spi display.
So create a special case for i2c: add the name attribute for non-i2c
devices.
Fixes: 303e4697e762dc92a40405f4e4b8aac02cd0d70b
Signed-off-by: NeilBrown ne...@suse.de
--
Hi Tomi,
I wonder if you would consider this for the next merge window (or maybe even
sooner as a bug-fix).
I haven't tested it with an i2c display, but it certainly allows xorg to work
on my spi-attached display.
Thanks,
NeilBrown
diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c
b/drivers/video/fbdev/omap2/dss/display-sysfs.c
index 5a2095a98ed8..53897b743130 100644
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -25,6 +25,15 @@
#include linux/platform_device.h
#include linux/sysfs.h
+#if IS_ENABLED(CONFIG_I2C)
+#include linux/i2c.h
+#else
+static inline int i2c_verify_client(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
#include video/omapdss.h
#include dss.h
@@ -278,6 +287,7 @@ static ssize_t display_wss_store(struct device *dev,
}
static DEVICE_ATTR(display_name, S_IRUGO, display_name_show, NULL);
+static DEVICE_ATTR(name, S_IRUGO, display_name_show, NULL);
static DEVICE_ATTR(enabled, S_IRUGO|S_IWUSR,
display_enabled_show, display_enabled_store);
static DEVICE_ATTR(tear_elim, S_IRUGO|S_IWUSR,
@@ -315,6 +325,17 @@ int display_init_sysfs(struct platform_device *pdev)
DSSERR(failed to create sysfs files\n);
goto err;
}
+ if (!i2c_verify_client(dssdev-dev)) {
+ /*
+ * Add 'name' file - not compatible with i2c, but
+ * need by Xorg for other devices.
+ */
+ r = sysfs_create_file(kobj, dev_attr_name.attr);
+ if (r) {
+ DSSERR(fail to create 'name' sysfs file\n);
+ goto err;
+ }
+ }
r = sysfs_create_link(pdev-dev.kobj, kobj, dssdev-alias);
if (r) {
@@ -341,5 +362,7 @@ void display_uninit_sysfs(struct platform_device *pdev)
sysfs_remove_link(pdev-dev.kobj, dssdev-alias);
sysfs_remove_files(dssdev-dev-kobj,
display_sysfs_attrs);
+ sysfs_remove_file(dssdev-dev-kobj,
+ dev_attr_name.attr);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] fix ehrpwm tbclk data on am33xx and am43xx
* Vignesh R vigne...@ti.com [150209 22:43]: In am33xx and am43xx, ehrpwm tbclk is derived from functional clock of PWMSS. The schematics and TRMs show that there is only one input clock to the PWMSS. But currently, tbclk is wrongly shown to be deriving from dpll_per_m2_ck instead of functional clock l4ls_gclk in the DT. Fixing ehrpwm tbclk data to reflect the right clk source. Tested on beaglebone and am437x-gp-evm. Vignesh R (2): ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx arch/arm/boot/dts/am33xx-clocks.dtsi | 6 +++--- arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) Tero, care to check this one too and ack if OK? 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 5/6] dmaengine: omap-dma: Remove mapping between virtual channels and requests
On 02/24/2015 04:28 PM, Russell King - ARM Linux wrote: On Tue, Feb 24, 2015 at 04:21:22PM +0200, Peter Ujfalusi wrote: Do not direct map the virtual channels to sDMA request number. When the sDMA is behind of a crossbar this direct mapping can cause situations when certain channel can not be requested since the crossbar request number will no longer match with the sDMA request line. The direct mapping for virtual channels with HW request lines will make it harder to implement MEM_TO_MEM mode for the driver. I assume when you talk about MEM_TO_MEM, you're referring to a DMA_MEMCPY driver. mem2mem should not be handled by the slave driver. This should be a separate DMA engine driver structure which does not have DMA_SLAVE set. See how amba-pl08x handles this. Thanks for the pointer. I'm just planning to add the DMA_MEMCPY support for omap-dma. With that in place we can convert the remaining legacy API users to use dmaengine (as I recall all of them are using DMA for memcopy) -- 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: Nokia N900: omap aes is broken
* Pali Rohár pali.ro...@gmail.com [150218 16:03]:
On Wednesday 18 February 2015 22:02:30 Pali Rohár wrote:
On Wednesday 18 February 2015 13:21:03 Pali Rohár wrote:
Hello,
I tried to test OMAP AES driver on Nokia N900 with special
Nokia bootloader which enable L3 firewall for OMAP AES HW
support.
I modified arch/arm/boot/dts/omap34xx-hs.dtsi file and
commented aes line which disable aes support in DT.
Then I booted kernel and loaded omap-aes.ko module. And I
got this output in dmesg:
[0.222930] platform 480c5000.aes: Cannot lookup hwmod
'aes' [ 27.758148] omap-aes 480c5000.aes:
_od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info
[ 27.765960] omap-aes 480c5000.aes: omap_aes_probe: failed
to get_sync(-19)
[ 29.257690] omap-aes 480c5000.aes: initialization failed.
So it looks like some initialization data are missing for
Nokia N900 (omap3430 device).
Can somebody look at it? I have patched 2.6.28 kernel were
omap aes support on this N900 device (with special
bootloader) is working.
Maybe some other data are missing in DT or in hwmod?
dma channels are missing in DT. I applied this patch:
diff --git a/arch/arm/boot/dts/omap3.dtsi
b/arch/arm/boot/dts/omap3.dtsi index 01b7111..473d460 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -92,6 +92,8 @@
ti,hwmods = aes;
reg = 0x480c5000 0x50;
interrupts = 0;
+ dmas = sdma 65 sdma 66;
+ dma-names = tx, rx;
};
prm: prm@48306000 {
@@ -550,6 +552,8 @@
ti,hwmods = sham;
reg = 0x480c3000 0x64;
interrupts = 49;
+ dmas = sdma 96;
+ dma-names = rx;
};
smartreflex_core: smartreflex@480cb000 {
and omap-aes driver was successfully loaded. now it is in
/proc/crypto
I copied dma names and numbers from file
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
And I also needed to apply this patch:
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 11468ee..3281f30 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3938,8 +3938,9 @@ int __init omap3xxx_hwmod_init(void)
if (r 0)
return r;
- /* Register GP-only hwmod links. */
- if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+// /* Register GP-only hwmod links. */
+// if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+ if (h_gp) {
r = omap_hwmod_register_links(h_gp);
if (r 0)
return r;
aes hwmod is defined in GP-only hwmod...
Doesn't this depend on the bootloader version of n900 to work?
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: Nokia N900: omap aes is broken
On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150218 16:03]:
On Wednesday 18 February 2015 22:02:30 Pali Rohár wrote:
On Wednesday 18 February 2015 13:21:03 Pali Rohár wrote:
Hello,
I tried to test OMAP AES driver on Nokia N900 with
special Nokia bootloader which enable L3 firewall for
OMAP AES HW support.
I modified arch/arm/boot/dts/omap34xx-hs.dtsi file and
commented aes line which disable aes support in DT.
Then I booted kernel and loaded omap-aes.ko module. And
I got this output in dmesg:
[0.222930] platform 480c5000.aes: Cannot lookup
hwmod 'aes' [ 27.758148] omap-aes 480c5000.aes:
_od_fail_runtime_resume: FIXME: missing hwmod/omap_dev
info [ 27.765960] omap-aes 480c5000.aes:
omap_aes_probe: failed to get_sync(-19)
[ 29.257690] omap-aes 480c5000.aes: initialization
failed.
So it looks like some initialization data are missing
for Nokia N900 (omap3430 device).
Can somebody look at it? I have patched 2.6.28 kernel
were omap aes support on this N900 device (with special
bootloader) is working.
Maybe some other data are missing in DT or in hwmod?
dma channels are missing in DT. I applied this patch:
diff --git a/arch/arm/boot/dts/omap3.dtsi
b/arch/arm/boot/dts/omap3.dtsi index 01b7111..473d460
100644 --- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -92,6 +92,8 @@
ti,hwmods = aes;
reg = 0x480c5000 0x50;
interrupts = 0;
+ dmas = sdma 65 sdma 66;
+ dma-names = tx, rx;
};
prm: prm@48306000 {
@@ -550,6 +552,8 @@
ti,hwmods = sham;
reg = 0x480c3000 0x64;
interrupts = 49;
+ dmas = sdma 96;
+ dma-names = rx;
};
smartreflex_core: smartreflex@480cb000 {
and omap-aes driver was successfully loaded. now it is in
/proc/crypto
I copied dma names and numbers from file
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
And I also needed to apply this patch:
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index
11468ee..3281f30 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3938,8 +3938,9 @@ int __init omap3xxx_hwmod_init(void)
if (r 0)
return r;
- /* Register GP-only hwmod links. */
- if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+// /* Register GP-only hwmod links. */
+// if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+ if (h_gp) {
r = omap_hwmod_register_links(h_gp);
if (r 0)
return r;
aes hwmod is defined in GP-only hwmod...
Doesn't this depend on the bootloader version of n900 to work?
Regards,
Tony
Ok, it looks like second patch (omap_hwmod_3xxx_data.c) needs
that aes-enabled bootloader.
But first patch (omap3.dtsi) is needed for proper definitions.
Otherwise omap-aes driver will never work on DT systems.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: Nokia N900: omap aes is broken
* Pali Rohár pali.ro...@gmail.com [150224 09:42]:
On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150218 16:03]:
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3938,8 +3938,9 @@ int __init omap3xxx_hwmod_init(void)
if (r 0)
return r;
- /* Register GP-only hwmod links. */
- if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+// /* Register GP-only hwmod links. */
+// if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+ if (h_gp) {
r = omap_hwmod_register_links(h_gp);
if (r 0)
return r;
aes hwmod is defined in GP-only hwmod...
Doesn't this depend on the bootloader version of n900 to work?
Regards,
Tony
Ok, it looks like second patch (omap_hwmod_3xxx_data.c) needs
that aes-enabled bootloader.
OK we need some runtime detection somehow for what's enabled..
But first patch (omap3.dtsi) is needed for proper definitions.
Otherwise omap-aes driver will never work on DT systems.
Yeah that one makes sense to me, I guess you'll do a proper
fix for that one.
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: Nokia N900: omap aes is broken
On Tuesday 24 February 2015 18:37:34 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150224 09:42]:
On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150218 16:03]:
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3938,8 +3938,9 @@ int __init
omap3xxx_hwmod_init(void)
if (r 0)
return r;
- /* Register GP-only hwmod links. */
- if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+// /* Register GP-only hwmod links. */
+// if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+ if (h_gp) {
r = omap_hwmod_register_links(h_gp);
if (r 0)
return r;
aes hwmod is defined in GP-only hwmod...
Doesn't this depend on the bootloader version of n900 to
work?
Regards,
Tony
Ok, it looks like second patch (omap_hwmod_3xxx_data.c)
needs that aes-enabled bootloader.
OK we need some runtime detection somehow for what's enabled..
What about checking DT if omap-aes is disabled or not?
But first patch (omap3.dtsi) is needed for proper
definitions. Otherwise omap-aes driver will never work on
DT systems.
Yeah that one makes sense to me, I guess you'll do a proper
fix for that one.
Regards,
Tony
Yes, I will send patches via correct git format-patch.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: Nokia N900: omap aes is broken
* Pali Rohár pali.ro...@gmail.com [150224 09:52]:
On Tuesday 24 February 2015 18:37:34 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150224 09:42]:
On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150218 16:03]:
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3938,8 +3938,9 @@ int __init
omap3xxx_hwmod_init(void)
if (r 0)
return r;
- /* Register GP-only hwmod links. */
- if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+// /* Register GP-only hwmod links. */
+// if (h_gp omap_type() == OMAP2_DEVICE_TYPE_GP) {
+ if (h_gp) {
r = omap_hwmod_register_links(h_gp);
if (r 0)
return r;
aes hwmod is defined in GP-only hwmod...
Doesn't this depend on the bootloader version of n900 to
work?
Regards,
Tony
Ok, it looks like second patch (omap_hwmod_3xxx_data.c)
needs that aes-enabled bootloader.
OK we need some runtime detection somehow for what's enabled..
What about checking DT if omap-aes is disabled or not?
In general that's not a good solution as marking something with
status = disabled means the device is completely ignored and
we will never have the struct device entry created for it and
we can never idle it.
But in this case however, it may be the right thing to do if the
secure mode is using that device.
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] thermal: ti-soc-thermal: bandgap: Fix build warning if !CONFIG_PM_SLEEP
On Tue, Feb 24, 2015 at 06:01:23PM +0200, grygorii.stras...@linaro.org wrote:
Hi Rui,
On 02/09/2015 05:01 PM, Nishanth Menon wrote:
On 16:55-20150206, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Fix following build warning if CONFIG_PM_SLEEP is not set:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
'ti_bandgap_suspend' defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
^
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1492:12: warning:
'ti_bandgap_resume' defined but not used [-Wunused-function]
static int ti_bandgap_resume(struct device *dev)
^
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 74c0e34..5d46660 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1402,7 +1402,7 @@ int ti_bandgap_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int ti_bandgap_save_ctxt(struct ti_bandgap *bgp)
{
int i;
--
1.9.1
Suggest aligning with Paul as well:
https://patchwork.kernel.org/patch/5795391/
^Paul Walmsley wrote: Oh, nothing to be confused by, I just missed the
earlier patch. I withdraw mine.
Otherwise:
Acked-by: Nishanth Menon n...@ti.com
It looks like this patch is missed in 4.0-rc1, so could it be merged
during rc cycle or you'd like me to resend it?
(I've rechecked - it can be applied on top of Linux 4.0-rc1 without any
issues)
No need to resend. I will add to my -fixes queue.
BR,
Eduardo Valentin
--
regards,
-grygorii
signature.asc
Description: Digital signature
Re: [PATCH] ARM: DTS: omap3-n900.dts: fix i2c bus numbering
* Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com [150209 08:07]: On 9.02.2015 17:02, Nishanth Menon wrote: On 17:48-20150208, Ivaylo Dimitrov wrote: With legacy boot i2c buses on Nokia N900 are numbered i2c1, i2c2 and i2c3. Commit 20b80942ef4e (ARM: dts: OMAP3+: Add i2c aliases) fixed the numbering with DT boot, but introduced a regression on N900 - aliases become i2c0, i2c1 and i2c2. Fix that by providing the correct aliases in the board dts. Signed-off-by: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com --- I suppose this is due to some legacy userspace breakage? if yes, we do not intend to break userspace :), So: Yes, legacy userspace breakage :) Applying into omap-for-v4.0/fixes 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 v3 0/4] phy: ti-pipe3: fixes for 3.19-rc
* Roger Quadros rog...@ti.com [150218 00:13]: On 18/02/15 10:00, Roger Quadros wrote: On 13/01/15 17:54, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [150113 04:26]: Hi, During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks remain active on the DRA7 platform. This is because the pipe3 driver doesn't shut them off as part of .suspend(). Patch 1 addresses this issue. SATA on both OMAP5 and DRA7 breaks when SATA drive is plugged in after a system suspend/resume or if AHCI_PLATFORM driver is used as module. Patches 2,3,4 fix it. Hope to get these patches in through the 3.19-rc cycle. Tony, Do you wish to take the DTS patches or let them go in through PHY tree? Those look ok to me to merge along with the fixes, will ack those two. Looks like this missed 3.19-rc. My bad for not following up. Kishon, can you please queue these for 3.20-rc? Thanks. Well the PHY patches (1 and 2) are already queued for v3.20-rc1 via Greg's usb-next tree. Tony can you please queue the DT side patches for v3.20? Thanks. Applying these into omap-for-v4.0/fixes. Lookse like we're a few kernel releases behind with these :) 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-N900: Fix offset for smc91x ethernet
* Tony Lindgren t...@atomide.com [150220 07:47]: * Pali Rohár pali.ro...@gmail.com [150220 01:56]: On Friday 20 February 2015 10:24:35 Arnd Bergmann wrote: On Thursday 19 February 2015 17:49:50 Pali Rohár wrote: Offset for smc91x must be zero otherwise smc91x linux kernel driver does not detect smc91x ethernet hardware in qemu N900 machine. Signed-off-by: Pali Rohár pali.ro...@gmail.com Is that the same offset on real hardware, or could this be a mistake in the qemu model? Arnd In original Nokia 2.6.28 kernel is offset also set to 0, see: https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L42 https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L274 Tony already tested offset 0 on real HW and wrote that it is working too, just show some warning. But qemu with offset 0x300 does not work. Yes it works with offset 0, except the smc91x warns about not using the default offset 0x300 based on the EEPROM. As only three address lines seem to be connected, we can use offset 0 just fine, and update the EEPROM configuration as needed. Applying into omap-for-v4.0/fixes with updated comments. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: boot: dts: am437x-idk: fix TPS62362 i2c bus
* Felipe Balbi ba...@ti.com [150219 10:08]: As it turns out, tps62362 is actually on I2C bus0, not bus1. This has gone unnoticed because Linux doesn't use (as of now) that regulator at all, it's setup by the bootloader and left as is. While at that, also add missing reg property for our regulator. Applying both into omap-for-v4.0/fixes 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 0/5] ARM: DTS: OMAP/DRA7: dma property name correction
* Peter Ujfalusi peter.ujfal...@ti.com [150220 05:45]: Hi, While working on the DMA crossbar support for DRA7 typo of devices I have noticed that the dma-channels and dma-requests properties of sdma wrongly has # at the beginning. According to the documentation, it should not have: Documentation/devicetree/bindings/dma/dma.txt Since these properties are not in use at the moment, but it is going to be needed for the crossbar driver it is better to fix it right now so we do not need to patch .dtsi and .c files at the same time later. Tony: I would really appreciate if this could go in within the current merge window. Yeah applying into omap-for-v4.0/fixes, let's get it out of the way to avoid more cut-n-paste errors. Regards, Tony Peter Ujfalusi (5): ARM: DTS: omap2: Correct the dma controller's property names ARM: DTS: omap3: Correct the dma controller's property names ARM: DTS: omap4: Correct the dma controller's property names ARM: DTS: omap5: Correct the dma controller's property names ARM: DTS: dra7: Correct the dma controller's property names arch/arm/boot/dts/dra7.dtsi | 4 ++-- arch/arm/boot/dts/omap2.dtsi | 4 ++-- arch/arm/boot/dts/omap3.dtsi | 4 ++-- arch/arm/boot/dts/omap4.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 4 ++-- 5 files changed, 10 insertions(+), 10 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] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral
* Felipe Balbi ba...@ti.com [150224 08:23]: On Tue, Feb 24, 2015 at 10:10:43AM -0600, Robert Nelson wrote: Fixes: http://bugs.elinux.org/issues/127 the bb.org community was seeing random reboots before this change. Signed-off-by: Robert Nelson robertcnel...@gmail.com that's a dead giveaway considering the connector in the board :-) Thanks Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com Applying into omap-for-v4.0/fixes 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][v4.0-rc] ARM: dts: dra7x-evm: beagle-x15: Fix USB Host
* Roger Quadros rog...@ti.com [150224 04:40]: In commit 87517d26d888 (ARM: dts: dra7-evm: Add extcon nodes for USB) we enabled Extcon USB gpio to tackle the USB ID pin and get peripheral mode to work. But the extcon-gpio-usb driver [1] didn't make it into v4.0 and this makes the USB driver defer probe indefinitely breaking USB Host functionality. As a temporary fix we remove the extcon handle from the USB controller and add it back when the extcon driver merges in v4.1. Uhh OK, If there are dependencies, can you please start splitting your patches so the dts changes that cause issues are sent only after the related driver changes are in Linux next? Anyways, applying into omap-for-v4.0/fixes. Tony [1] - https://lkml.org/lkml/2015/2/2/187 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: omap2plus_defconfig: Fix SATA and NAND for v4.0-rc
* Roger Quadros rog...@ti.com [150223 07:22]: Hi, These changes fix SATA boot and NAND for OMAP based boards. I must also point out that basic SATA operation is also broken when TI_PIPE3 driver is built as a module. I will be investigating that on lower priority. OK applying into omap-for-v4.0/fixes. At some point we're going to make everything use loadable modules and initramfs so best to make sure things work as loadable modules. Regards, Tony Roger Quadros (2): ARM: omap2plus_defconfig: Enable OMAP NAND BCH driver ARM: omap2plus_defconfig: Fix SATA boot arch/arm/configs/omap2plus_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 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 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Wed, 07 Jan 2015, Vignesh R wrote:
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing these steps at a later
stage.
Also, when ADC wakes up Sequencer should not be busy executing any of the
config steps except for the charge step. Previously charge step was 1 ADC
clock cycle and hence it was ignored.
TSC steps are always disabled at the end of each conversion cycle, hence
there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
Signed-off-by: Vignesh R vigne...@ti.com
---
v5:
- Remove unnecessary clearing of REG_SE
drivers/mfd/ti_am335x_tscadc.c | 13 +
include/linux/mfd/ti_am335x_tscadc.h | 1 +
2 files changed, 6 insertions(+), 8 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 467c80e1c4ae..e4e4b22eebc9 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -68,12 +68,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
DEFINE_WAIT(wait);
u32 reg;
- /*
- * disable TSC steps so it does not run while the ADC is using it. If
- * write 0 while it is running (it just started or was already running)
- * then it completes all steps that were enabled and stops then.
- */
- tscadc_writel(tsadc, REG_SE, 0);
reg = tscadc_readl(tsadc, REG_ADCFSM);
if (reg SEQ_STATUS) {
tsadc-adc_waiting = true;
@@ -86,8 +80,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
spin_lock_irq(tsadc-reg_lock);
finish_wait(tsadc-reg_se_wait, wait);
+ /*
+ * Sequencer should either be idle or
+ * busy applying the charge step.
+ */
reg = tscadc_readl(tsadc, REG_ADCFSM);
- WARN_ON(reg SEQ_STATUS);
+ WARN_ON((reg SEQ_STATUS) !(reg CHARGE_STEP));
tsadc-adc_waiting = false;
}
tsadc-adc_in_use = true;
@@ -96,7 +94,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
{
spin_lock_irq(tsadc-reg_lock);
- tsadc-reg_se_cache |= val;
am335x_tscadc_need_adc(tsadc);
tscadc_writel(tsadc, REG_SE, val);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index 3f4e994ace2b..1fd50dcfe47c 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -128,6 +128,7 @@
/* Sequencer Status */
#define SEQ_STATUS BIT(5)
+#define CHARGE_STEP 0x11
#define ADC_CLK 300
#define TOTAL_STEPS 16
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 04/15] twl4030_charger: use runtime_pm to keep usb phy active while charging.
On Tue, 24 Feb 2015, NeilBrown wrote:
The twl4030 usb phy needs to be active while we are using
the USB VBUS as a current source for charging.
In particular, the usb3v1 regulator must be enabled and the
PHY_PWR_PHYPWD bit must be set to keep the phy powered.
commit ab37813f4093a5f59cb8e083cde277289dc72ed3
twl4030_charger: Allow charger to control the regulator that feeds it
Gave the charger control over the regulator, but didn't resolve
the PHY_PWR_PHYPWD issue.
Now that both of these are controlled by runtime_pm in
phy-twl4030-usb, we can simply take a runtime_pm reference to the USB
phy whenever the charger wants to use it as a current source.
So this patch reverts the above commit, and adds the necessary
runtime_pm calls.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/mfd/twl-core.c |9 -
Acked-by: Lee Jones lee.jo...@linaro.org
drivers/power/twl4030_charger.c | 18 +-
2 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 489674a2497e..831696ee2472 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -788,9 +788,8 @@ add_children(struct twl4030_platform_data *pdata,
unsigned irq_base,
static struct regulator_consumer_supply usb1v8 = {
.supply = usb1v8,
};
- static struct regulator_consumer_supply usb3v1[] = {
- { .supply = usb3v1 },
- { .supply = bci3v1 },
+ static struct regulator_consumer_supply usb3v1 = {
+ .supply = usb3v1,
};
/* First add the regulators so that they can be used by transceiver */
@@ -818,7 +817,7 @@ add_children(struct twl4030_platform_data *pdata,
unsigned irq_base,
return PTR_ERR(child);
child = add_regulator_linked(TWL4030_REG_VUSB3V1,
- usb_fixed, usb3v1, 2,
+ usb_fixed, usb3v1, 1,
features);
if (IS_ERR(child))
return PTR_ERR(child);
@@ -838,7 +837,7 @@ add_children(struct twl4030_platform_data *pdata,
unsigned irq_base,
if (IS_ENABLED(CONFIG_REGULATOR_TWL4030) child) {
usb1v5.dev_name = dev_name(child);
usb1v8.dev_name = dev_name(child);
- usb3v1[0].dev_name = dev_name(child);
+ usb3v1.dev_name = dev_name(child);
}
}
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 51321f0c5548..11f352a5ef55 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -22,7 +22,6 @@
#include linux/power_supply.h
#include linux/notifier.h
#include linux/usb/otg.h
-#include linux/regulator/machine.h
#define TWL4030_BCIMSTATEC 0x02
#define TWL4030_BCIICHG 0x08
@@ -94,7 +93,6 @@ struct twl4030_bci {
struct work_struct work;
int irq_chg;
int irq_bci;
- struct regulator*usb_reg;
int usb_enabled;
unsigned long event;
@@ -208,7 +206,7 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
{
int ret;
- if (enable) {
+ if (enable !IS_ERR_OR_NULL(bci-transceiver)) {
/* Check for USB charger connected */
if (!twl4030_bci_have_vbus(bci))
return -ENODEV;
@@ -222,14 +220,9 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
return -EACCES;
}
- /* Need to keep regulator on */
+ /* Need to keep phy powered */
if (!bci-usb_enabled) {
- ret = regulator_enable(bci-usb_reg);
- if (ret) {
- dev_err(bci-dev,
- Failed to enable regulator\n);
- return ret;
- }
+ pm_runtime_get_sync(bci-transceiver-dev);
bci-usb_enabled = 1;
}
@@ -244,7 +237,8 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
} else {
ret = twl4030_clear_set_boot_bci(TWL4030_BCIAUTOUSB, 0);
if (bci-usb_enabled) {
- regulator_disable(bci-usb_reg);
+ pm_runtime_mark_last_busy(bci-transceiver-dev);
+ pm_runtime_put_autosuspend(bci-transceiver-dev);
bci-usb_enabled = 0;
}
}
@@ -602,8 +596,6 @@
Re: [PATCH 0/2] ARM: DRA7x/OMAP5: Clock: DPLL Clock fixes
On 02/24/2015 06:27 PM, Tony Lindgren wrote: * Ravikumar Kattekola r...@ti.com [150219 08:13]: On 1/31/2015 10:36 PM, Ravikumar Kattekola wrote: Fix bypass clock source for a few DPLLs. On DRA7x/OMAP5, for a few DPLLs, both CLKINP and CLKINPULOW are connected to a mux and the output from mux is routed to the bypass clkout. Add a mux-clock as bypass clock with CLKINP and CLKINPULOW as parents. Tested against: tree: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git branch: master On: CPU : OMAP5432 ES2.0 Board: OMAP5432 uEVM and CPU : DRA752 ES1.0 Board: DRA7xx Ravikumar Kattekola (2): ARM: DRA7x: dts: Fix the bypass clock source for dpll_iva and others ARM: OMAP5: dts: Fix the bypass clock source for dpll_iva and others arch/arm/boot/dts/dra7xx-clocks.dtsi | 90 arch/arm/boot/dts/omap54xx-clocks.dtsi | 41 +-- 2 files changed, 118 insertions(+), 13 deletions(-) Hi Benoit, Can these fixes be looked into for 3.20-rc? Seem like valid fixes to me. Tero, care to take a look at these and ack if OK? Yes, both are good to go. Acked-by: Tero Kristo t-kri...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] fix ehrpwm tbclk data on am33xx and am43xx
On 02/24/2015 07:15 PM, Tony Lindgren wrote: * Vignesh R vigne...@ti.com [150209 22:43]: In am33xx and am43xx, ehrpwm tbclk is derived from functional clock of PWMSS. The schematics and TRMs show that there is only one input clock to the PWMSS. But currently, tbclk is wrongly shown to be deriving from dpll_per_m2_ck instead of functional clock l4ls_gclk in the DT. Fixing ehrpwm tbclk data to reflect the right clk source. Tested on beaglebone and am437x-gp-evm. Vignesh R (2): ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx arch/arm/boot/dts/am33xx-clocks.dtsi | 6 +++--- arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++-- 2 files changed, 9 insertions(+), 9 deletions(-) Tero, care to check this one too and ack if OK? These look fine also, just verified from TRM. These two were actually buried in my mailbox, sorry about that. Acked-by: Tero Kristo t-kri...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: restore name sysfs entry.
On 24/02/15 22:31, NeilBrown wrote: On Tue, 24 Feb 2015 12:40:32 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, On 24/02/15 11:37, NeilBrown wrote: commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b OMAPDSS: rename display-sysfs 'name' entry broke the xorg X server on my device as it couldn't find the display any more. It needs the 'name' file and now there isn't one. That commit claims that 'name' is not compatible with i2c or spi. i2c does register it own 'name' file, but spi does not, hence my problem - I have an spi display. So create a special case for i2c: add the name attribute for non-i2c devices. What X driver is that? What's it doing with the display name? Is it just using the display name to show something for the user, and the returned value can be essentially any string? Tomi /usr/lib/xorg/modules/drivers/omapfb_drv.so from package xserver-xorg-video-omap3 in Debian. I don't know where the main upstream source is, but here: https://gitorious.org/gnutoo-s-programs-for-shr/xf86-video-omapfb/source/28c006c94e57ea71df11ec4fff79d7ffcfc4860f:src/omapfb-output-dss.c#L258 is the code which reads /sys/devices/platform/omapdss/display0/name and fails if that file cannot be opened. Thanks. Unfortunately it looks to me that the omapfb_drv uses the display name to configure things, and as in i2c's case the 'name' is not the correct dss name, X will probably fail in interesting ways. Of course, it's already broken in that way, so this fix improves the situation for non-i2c displays. I'll have a look if I can figure out how to fix this for all displays. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
Hi, On Thursday 05 February 2015 11:51 AM, Vignesh R wrote: On Wednesday 21 January 2015 03:44 PM, Vignesh R wrote: On Tuesday 20 January 2015 09:34 PM, Lee Jones wrote: On Tue, 20 Jan 2015, R, Vignesh wrote: On 1/20/2015 5:23 PM, Lee Jones wrote: On Wed, 07 Jan 2015, Vignesh R wrote: In one shot mode, sequencer automatically disables all enabled steps at the end of each cycle. (both ADC steps and TSC steps) Hence these steps need not be saved in reg_se_cache for clearing these steps at a later stage. Also, when ADC wakes up Sequencer should not be busy executing any of the config steps except for the charge step. Previously charge step was 1 ADC clock cycle and hence it was ignored. TSC steps are always disabled at the end of each conversion cycle, hence there is no need to explicitly disable TSC steps by writing 0 to REG_SE. Signed-off-by: Vignesh R vigne...@ti.com --- v5: - Remove unnecessary clearing of REG_SE drivers/mfd/ti_am335x_tscadc.c | 13 + include/linux/mfd/ti_am335x_tscadc.h | 1 + 2 files changed, 6 insertions(+), 8 deletions(-) Looks fine. For my own reference: Acked-by: Lee Jones lee.jo...@linaro.org Can this patch be applied on its own? I prefer to wait until input patches are picked up. I have no problem with that, but is there a technical reason why? Nothing, in particular. This patch alone has no impact on the performance of TSC/ADC unit. Patch 2/6 is necessary to observe the changes caused by this series. Hence, please wait until those patches are picked up. Input maintainer has applied other patches. You can pick this one. Gentle ping... Can you pull this patch into 4.0-rc? Other patches of this series are already in mainline. Regards Vignesh -- 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
