RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi Guido,
From: Guido Martínez
On Thu, Jun 26, 2014 at 03:40:44AM -0700, Tony Lindgren wrote:
* Pekon Gupta pe...@ti.com [140624 05:26]:
+
+gpmc {
+ ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC
partition) */
+ nand@0,0 {
+ status = disabled;
+ reg = 0 0 4; /* device IO registers */
Hmm so what about other capes potentially also using GPMC CS0?
Can you please do a check with two .dtsi files trying to use
GPMC CS0 and see what the produced .dtb file looks like after
decompiling it with dtc?
I'd assume the 16MB GPMC partition will be just fine for many
devices and can be also be larger if NOR needs it so maybe it
can be handled for almost all the cases.
The names for devices must be unique though to avoid them
getting merged. And I don't know if gpmc.c skips disabled devices
properly.
It doesn't. I've just sent a patch for it.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
I don't think we need above patch.
Helper macro for_each_available_child_of_node internally takes care
of skipping nodes with status=disabled.
$KERNEL/include/linux/of.h
#define for_each_available_child_of_node(parent, child) \
for (child = of_get_next_available_child(parent, NULL); child != NULL; \
child = of_get_next_available_child(parent, child))
$KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
...
if (!__of_device_is_available(next))
continue;
...
with regards, pekon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/6] regulator: palmas: Rename reg_info to palmas_reg_info
On Mon, 30 Jun 2014, Nishanth Menon wrote:
reg_info is a generic term which might cause conflict at a later point
in time. To prevent such a thing from occuring in future, rename to
palmas_reg_info.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/regulator/palmas-regulator.c |4 ++--
include/linux/mfd/palmas.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 91f60fa..05f11b9 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -41,7 +41,7 @@ static const struct regulator_linear_range
smps_high_ranges[] = {
REGULATOR_LINEAR_RANGE(330, 0x7A, 0x7f, 0),
};
-static struct regs_info palmas_regs_info[] = {
+static struct palmas_regs_info palmas_regs_info[] = {
{
.name = SMPS12,
.sname = smps1-in,
@@ -227,7 +227,7 @@ static struct regs_info palmas_regs_info[] = {
},
};
-static struct regs_info tps65917_regs_info[] = {
+static struct palmas_regs_info tps65917_regs_info[] = {
{
.name = SMPS1,
.sname = smps1-in,
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 1a045ba..fb0390a 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -102,7 +102,7 @@ struct palmas_sleep_requestor_info {
int bit_pos;
};
-struct regs_info {
+struct palmas_regs_info {
char*name;
char*sname;
u8 vsel_addr;
@@ -117,7 +117,7 @@ struct palmas_pmic_driver_data {
int ldo_begin;
int ldo_end;
int max_reg;
- struct regs_info *palmas_regs_info;
+ struct palmas_regs_info *palmas_regs_info;
struct of_regulator_match *palmas_matches;
struct palmas_sleep_requestor_info *sleep_req_info;
int (*smps_register)(struct palmas_pmic *pmic,
--
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: OMAP 3630 random crashes
* Michael Trimarchi mich...@amarulasolutions.com [140630 06:49]: On Mon, Jun 30, 2014 at 3:43 PM, Casper Lyngesen Mogensen clmogen...@grundfos.com wrote: I got two new Overo AirStorm today, and they have same behavior. I tried disabling the SMSC9xxx again and booted from MMC. This seems to make the backtrace a little more consistent(Tried on both new and old). There is (almost) always something about Alignment trap, the crash log itself differs every time. Also i get to allocate a lot more memory before crash with these settings. What kernel version are you using? We should have v3.15 working fine, but PM features are not merged in util for v3.16. I would try dding calls to omap_sdrc_init to pdata-quirks.c the same way board-over.c is doing: omap_sdrc_init(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params); If the memory timings are not correctly set by the bootloader that could explain the issues. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 00/16] irqchip: crossbar: Driver fixes
* Jason Cooper ja...@lakedaemon.net [140630 12:30]: Whole series applied to irqchip/crossbar, I'll give it a day or two in -next, then I'll merge it into irqchip/core. Tony: Right now, it's immutable unless you tell me I applied something incorrectly. Once it goes into irqchip/core, it's immutable no matter what you say. ;-) Thanks, looks good to me. Sricharan and Nishant, can you please check that we can now apply the related .dts changes on top of Jason's branch at: git://git.infradead.org/users/jcooper/linux.git irqchip/crossbar 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Gupta, Pekon pe...@ti.com [140627 14:08]:
From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
[...]
+gpmc {
+ ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC
partition) */
+ nand@0,0 {
+ status = disabled;
+ reg = 0 0 4; /* device IO registers */
+ pinctrl-names = default;
+ pinctrl-0 = bbcape_nand_flash_pins;
This doesn't seem to work as pinctrl properties are not parsed for
childs of the gpmc node. Did this work for you?
Putting this in the gpmc node makes it work, but how will we control
pins for the nand and nor independently? I believe there is currently no
support for muxing individual gpmc devices. If we want to add both
devices to the DT and enable them as needed we'd need to add support for
this, right?
Yes, And that should be the case, because different devices would be
connected to different chip-selects, so there should be support of
providing individual pin-mux for different GPMC devices.
Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
capes will not work simultaneously. But I'm planning to modify NOR cape
hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
- NAND on GPMC_CS0
- NOR on GPMC_CS1
Hmm but we should have these working with both using CS0 without
any need to modify the hardware though?
In that case we should make sure we always set large enough GPMC
partition and that the pins are muxed for the connected GPMC
devices only.
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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
From: Tony Lindgren [mailto:t...@atomide.com]
* Gupta, Pekon pe...@ti.com [140627 14:08]:
From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
[...]
+gpmc {
+ ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC
partition) */
+ nand@0,0 {
+ status = disabled;
+ reg = 0 0 4; /* device IO registers */
+ pinctrl-names = default;
+ pinctrl-0 = bbcape_nand_flash_pins;
This doesn't seem to work as pinctrl properties are not parsed for
childs of the gpmc node. Did this work for you?
Putting this in the gpmc node makes it work, but how will we control
pins for the nand and nor independently? I believe there is currently no
support for muxing individual gpmc devices. If we want to add both
devices to the DT and enable them as needed we'd need to add support for
this, right?
Yes, And that should be the case, because different devices would be
connected to different chip-selects, so there should be support of
providing individual pin-mux for different GPMC devices.
Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
capes will not work simultaneously. But I'm planning to modify NOR cape
hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
- NAND on GPMC_CS0
- NOR on GPMC_CS1
Hmm but we should have these working with both using CS0 without
any need to modify the hardware though?
Yes, but one at a time. That mean either of 'NAND cape' or 'NOR cape'.
If you need both working simultaneously as 2 separate devices attached
to GPMC, then you need 2 separate chip-selects, which is what I'm trying
to test with [1].
In that case we should make sure we always set large enough GPMC
partition
Yes, this is taken care with introduction of NOR cape in
[PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
gpmc {
- ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC
partition) */
+ ranges = 0 0 0x0800 0x0100; /* address offset=128MB,
range=128Mb=16MB */
This GPMC partition suffices for both NAND and NOR requirements.
and that the pins are muxed for the connected GPMC
devices only.
Pin mux is something I need to re-work, because currently
I've tested either NAND or NOR individually, not together.
Also as mentioned above by Guido, pin-ctrl property is not parsed individually
for GPMC children, Instead pin-ctrl is set once for GPMC as a whole.
Do you have any suggestions on how pin-ctrl should be set if we have
multiple devices connected to GPMC like;
All these devices will share:
- control lines (gpmc_wait, gpmc_ben_cle, gpmc_advn_ale, gpmc_we, gpmc_oe_ren)
- *some* data lines (gpmc_ad[])
- *some* address lines (gpmc_a[])
- but chip-selects will be different:
gpmc_cs0: NAND
gpmc_cs1: NOR
gpmc_cs2: SMSC91xx
gpmc_cs3: Camera
with regards, Pekon
Regards,
Tony
[1] http://www.spinics.net/lists/linux-omap/msg107950.html
Re: [PATCH V4 00/16] irqchip: crossbar: Driver fixes
Hi Tony, On Tuesday 01 July 2014 01:29 PM, Tony Lindgren wrote: * Jason Cooper ja...@lakedaemon.net [140630 12:30]: Whole series applied to irqchip/crossbar, I'll give it a day or two in -next, then I'll merge it into irqchip/core. Tony: Right now, it's immutable unless you tell me I applied something incorrectly. Once it goes into irqchip/core, it's immutable no matter what you say. ;-) Thanks, looks good to me. Sricharan and Nishant, can you please check that we can now apply the related .dts changes on top of Jason's branch at: git://git.infradead.org/users/jcooper/linux.git irqchip/crossbar I applied the dts patches on top of this and it worked fine for me on dra72 evm Regards, Sricharan -- 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
atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
Nick, I have been using your for-next branch to base my development of touchscreen support on TI's DRA7x EVM. With the recent updates, it has worked out great and once I got the configuration right, it was just a question of adding DT data for the platform. Now, there is one problem with Stephen's patch defaulting the irqflags to IRQF_TRIGGER_FALLING. The interrupt controller I am using (ARM GIC) does not seem to support that and the device fails to probe: [1.932798] genirq: Setting trigger mode 2 for irq 151 failed (gic_set_type+0x0/0xf0) [1.941340] atmel_mxt_ts 0-004a: Failed to register interrupt [1.947452] atmel_mxt_ts: probe of 0-004a failed with error -22 Attached patch does the trick for me: diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c index 71154c2..f2d3f72 100644 --- a/drivers/input/touchscreen/atmel_mxt_ts.c +++ b/drivers/input/touchscreen/atmel_mxt_ts.c @@ -3155,9 +3155,6 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client) pdata-gpio_reset = of_get_named_gpio_flags(dev-of_node, atmel,reset-gpio, 0, NULL); - /* Default to this. Properties can be added to configure it later */ - pdata-irqflags = IRQF_TRIGGER_FALLING; - of_property_read_string(dev-of_node, atmel,cfg_name, pdata-cfg_name); Can you switch to leaving the platform to specify flags (at least for the DT case)? Thanks, Sekhar -- 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/3] phy: omap-usb2: Manage PHY 3.3V supply regulator
Hi Roger,
On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
On some SoCs e.g. J6 the 3.3V supply to the USB2 PHY can be
powered down when the PHY is not in use. Add regulator
management code to control this power line.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-usb2.c | 25 +
include/linux/phy/omap_usb.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..2afc79c 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -30,6 +30,7 @@
#include linux/phy/omap_control_phy.h
#include linux/phy/phy.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
#define USB2PHY_DISCON_BYP_LATCH (1 31)
#define USB2PHY_ANA_CONFIG1 0x4c
@@ -107,6 +108,14 @@ static int omap_usb_power_off(struct phy *x)
omap_control_phy_power(phy-control_dev, 0);
+ if (phy-pwr) {
+ int ret;
+
+ ret = regulator_disable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
@@ -114,6 +123,14 @@ static int omap_usb_power_on(struct phy *x)
{
struct omap_usb *phy = phy_get_drvdata(x);
+ if (phy-pwr) {
+ int ret;
+
+ ret = regulator_enable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
Shouldn't we do this in phy_power_on/phy_power_off in phy-core?
Cheers
Kishon
omap_control_phy_power(phy-control_dev, 1);
return 0;
@@ -253,6 +270,14 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-control_dev = control_pdev-dev;
omap_control_phy_power(phy-control_dev, 0);
+ /* phy-supply */
+ phy-pwr = devm_regulator_get_optional(phy-dev, phy);
+ if (IS_ERR(phy-pwr)) {
+ if (PTR_ERR(phy-pwr) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ phy-pwr = NULL;
+ }
+
otg-set_host = omap_usb_set_host;
otg-set_peripheral = omap_usb_set_peripheral;
if (phy_data-flags OMAP_USB2_HAS_SET_VBUS)
diff --git a/include/linux/phy/omap_usb.h b/include/linux/phy/omap_usb.h
index dc2c541..e2c46df 100644
--- a/include/linux/phy/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -40,6 +40,7 @@ struct omap_usb {
struct clk *wkupclk;
struct clk *optclk;
u8 flags;
+ struct regulator*pwr;
};
struct usb_phy_data {
--
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 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
+Mark, Alexander, Ivan Hi Tony, On 06/13/2014 03:08 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140613 04:43]: On 06/13/2014 01:46 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140613 01:24]: On 06/13/2014 11:13 AM, Gupta, Pekon wrote: From: Tony Lindgren [mailto:t...@atomide.com] * Roger Quadros rog...@ti.com [140613 00:40]: On 06/13/2014 10:18 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140611 01:58]: OK. But wait pin edge detection was not yet being used and I couldn't think of how it would ever be used. Any ideas? Maybe to wake-up the system on bus activity or something? Sorry, I wasn't able to review this series. But just as pointer, GPMC driver was used for interfacing many non-memory devices like Ethernet (smc91x) and in past GPMC has been proved to work with camera devices too, but that's wasn't mainlined. So keeping IRQ and few other things in GPMC driver is helpful. On further study it seems that the wait pin edge detection is only used in the NAND controller use case. see section 10.1.5.14.2.2 Ready Pin Monitored by Hardware Interrupt It seems they can be used for anything slow like NOR and NAND. But NOR driver never requests for any IRQ. We should not confuse this wait pin edge interrupt with NOR bus cycle WAIT pin mechanism. That is configured using GPMC_CONFIG1 register via WAITPINSELECT and WAITREAD/WRITEMONITORING bits. That wait pin handling is done completely in hardware and doesn't need any software intervention. Imagine using it for interrupt for every bus cycle wait. It will be dead slow and unusable. The WAIT edge interrupt mechanism is exclusively for NAND use case to notify the status of READY pin after a block/page operation. OK thanks for clarifying it. For memory devices, no software wait pin intervention is necessary and doesn't even make sense. Still seems that it's use can be generic though, not limited to NAND. So I don't agree on managing the IRQSTATUS and IRQENABLE register in the GPMC driver. It is adding unnecessary complexity. I don't mind having a wrapper around it though like the other nand registers. But all the consumer driver should need to do is request_irq() on it? That's pretty much the most common interface we have for drivers :) the client driver side is easy, but it adds unnecessary complication to model it as IRQ chip and assign a line for each event. Since it is going to be used exclusively by NAND we should avoid IRQ chip modeling. OK up to you if there are no other users for it. To be frank, I think it is cleaner if the NAND driver directly accesses the NAND registers. I don't see why we should make things complicated just because the hardware designers didn't create a clear register split between GPMC and NAND. Because they are in separate hardware modules :) Who knows why it was set up this way. Maybe the plan was to have the common features in GPMC that then can be used by various MTD devices. Only the GPMC_CONFIG register needs to remain with the GPMC driver. And managing clocks and runtime PM in general. In any case, let's not let drivers tinker with the GPMC registers directly though. Some kind of abstraction via existing frameworks or with regmap is needed. OK. I agree about using some kind of abstraction instead of direct access. Yes and like we chatted on irc, adding a syscon mapping for for the NAND specific registers might do the trick here. After looking at the syscon driver, which relies on regmap, it seems that regmap was designed for slow control busses like I2C/SPI and using it for NAND controller register access will have a significant negative impact on performance. In the NAND case the register writes are used for each NAND command cycle and the reads for ECC checks (every page). See how much code regmap_read and regmap_mmio_read() translates to for a simple register read i.e. readl(). http://lxr.free-electrons.com/source/drivers/base/regmap/regmap.c#L1944 http://lxr.free-electrons.com/source/drivers/base/regmap/regmap-mmio.c#L129 So I'm not so sure of using regmap/syscon for NAND controller register access. Could there be any other abstraction method of sharing the register space between GPMC and NAND driver? I've also added Ivan to the thread, the author of memory/ti-aemif.c driver, to check if he faced any issues with shared register access of the AEMIF/NAND registers. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] phy: omap-usb2: Manage PHY 3.3V supply regulator
On 07/01/2014 12:56 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
On some SoCs e.g. J6 the 3.3V supply to the USB2 PHY can be
powered down when the PHY is not in use. Add regulator
management code to control this power line.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-usb2.c | 25 +
include/linux/phy/omap_usb.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..2afc79c 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -30,6 +30,7 @@
#include linux/phy/omap_control_phy.h
#include linux/phy/phy.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
#define USB2PHY_DISCON_BYP_LATCH (1 31)
#define USB2PHY_ANA_CONFIG1 0x4c
@@ -107,6 +108,14 @@ static int omap_usb_power_off(struct phy *x)
omap_control_phy_power(phy-control_dev, 0);
+if (phy-pwr) {
+int ret;
+
+ret = regulator_disable(phy-pwr);
+if (ret)
+return ret;
+}
+
return 0;
}
@@ -114,6 +123,14 @@ static int omap_usb_power_on(struct phy *x)
{
struct omap_usb *phy = phy_get_drvdata(x);
+if (phy-pwr) {
+int ret;
+
+ret = regulator_enable(phy-pwr);
+if (ret)
+return ret;
+}
+
Shouldn't we do this in phy_power_on/phy_power_off in phy-core?
I thought about that earlier, but could not find a way to defer probing if the
regulator is not-yet probed.
Any clues how it could be done in phy-core?
cheers,
-roger
omap_control_phy_power(phy-control_dev, 1);
return 0;
@@ -253,6 +270,14 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-control_dev = control_pdev-dev;
omap_control_phy_power(phy-control_dev, 0);
+/* phy-supply */
+phy-pwr = devm_regulator_get_optional(phy-dev, phy);
+if (IS_ERR(phy-pwr)) {
+if (PTR_ERR(phy-pwr) == -EPROBE_DEFER)
+return -EPROBE_DEFER;
+phy-pwr = NULL;
+}
+
otg-set_host = omap_usb_set_host;
otg-set_peripheral = omap_usb_set_peripheral;
if (phy_data-flags OMAP_USB2_HAS_SET_VBUS)
diff --git a/include/linux/phy/omap_usb.h b/include/linux/phy/omap_usb.h
index dc2c541..e2c46df 100644
--- a/include/linux/phy/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -40,6 +40,7 @@ struct omap_usb {
struct clk *wkupclk;
struct clk *optclk;
u8 flags;
+struct regulator*pwr;
};
struct usb_phy_data {
--
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/3] phy: omap-usb2: Manage PHY 3.3V supply regulator
Hi,
On Tuesday 01 July 2014 03:43 PM, Roger Quadros wrote:
On 07/01/2014 12:56 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
On some SoCs e.g. J6 the 3.3V supply to the USB2 PHY can be
powered down when the PHY is not in use. Add regulator
management code to control this power line.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-usb2.c | 25 +
include/linux/phy/omap_usb.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..2afc79c 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -30,6 +30,7 @@
#include linux/phy/omap_control_phy.h
#include linux/phy/phy.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
#define USB2PHY_DISCON_BYP_LATCH (1 31)
#define USB2PHY_ANA_CONFIG1 0x4c
@@ -107,6 +108,14 @@ static int omap_usb_power_off(struct phy *x)
omap_control_phy_power(phy-control_dev, 0);
+ if (phy-pwr) {
+ int ret;
+
+ ret = regulator_disable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
@@ -114,6 +123,14 @@ static int omap_usb_power_on(struct phy *x)
{
struct omap_usb *phy = phy_get_drvdata(x);
+ if (phy-pwr) {
+ int ret;
+
+ ret = regulator_enable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
Shouldn't we do this in phy_power_on/phy_power_off in phy-core?
I thought about that earlier, but could not find a way to defer probing if
the regulator is not-yet probed.
Any clues how it could be done in phy-core?
We can try to do regulator_get in phy_create and return EPROBE_DEFER if the
regulator_get returns EPROBE_DEFER no?
Cheers
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] phy: omap-usb2: Manage PHY 3.3V supply regulator
On 07/01/2014 01:20 PM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 01 July 2014 03:43 PM, Roger Quadros wrote:
On 07/01/2014 12:56 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
On some SoCs e.g. J6 the 3.3V supply to the USB2 PHY can be
powered down when the PHY is not in use. Add regulator
management code to control this power line.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-usb2.c | 25 +
include/linux/phy/omap_usb.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..2afc79c 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -30,6 +30,7 @@
#include linux/phy/omap_control_phy.h
#include linux/phy/phy.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
#define USB2PHY_DISCON_BYP_LATCH (1 31)
#define USB2PHY_ANA_CONFIG1 0x4c
@@ -107,6 +108,14 @@ static int omap_usb_power_off(struct phy *x)
omap_control_phy_power(phy-control_dev, 0);
+ if (phy-pwr) {
+ int ret;
+
+ ret = regulator_disable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
@@ -114,6 +123,14 @@ static int omap_usb_power_on(struct phy *x)
{
struct omap_usb *phy = phy_get_drvdata(x);
+ if (phy-pwr) {
+ int ret;
+
+ ret = regulator_enable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
Shouldn't we do this in phy_power_on/phy_power_off in phy-core?
I thought about that earlier, but could not find a way to defer probing if
the regulator is not-yet probed.
Any clues how it could be done in phy-core?
We can try to do regulator_get in phy_create and return EPROBE_DEFER if the
regulator_get returns EPROBE_DEFER no?
Yes indeed, we can. I missed the phy_create() and was only looking at
phy_init() and phy_power_*() :P.
I'll post a v2 soon.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP 3630 random crashes
Hi You are right. I used a different bootloader for the newer kernels, because of another build system and did not think about it. The u-boot from github/gumstix sets the memory timings different than the u-boot directly from denx.de. I switched to the gumstix-uboot and i can now allocate all the memory in the system with all peripherals enabled, and i just get killed by the OOM a some point. But thanks for the help so far, even though it was not a kernel issue :-) Med venlig hilsen/Best regards Casper Mogensen From: Tony Lindgren t...@atomide.com Sent: Tuesday, July 01, 2014 09:54 To: Michael Trimarchi Cc: Casper Lyngesen Mogensen; Ash Charles; linux-omap@vger.kernel.org Subject: Re: OMAP 3630 random crashes * Michael Trimarchi mich...@amarulasolutions.com [140630 06:49]: On Mon, Jun 30, 2014 at 3:43 PM, Casper Lyngesen Mogensen clmogen...@grundfos.com wrote: I got two new Overo AirStorm today, and they have same behavior. I tried disabling the SMSC9xxx again and booted from MMC. This seems to make the backtrace a little more consistent(Tried on both new and old). There is (almost) always something about Alignment trap, the crash log itself differs every time. Also i get to allocate a lot more memory before crash with these settings. What kernel version are you using? We should have v3.15 working fine, but PM features are not merged in util for v3.16. I would try dding calls to omap_sdrc_init to pdata-quirks.c the same way board-over.c is doing: omap_sdrc_init(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params); If the memory timings are not correctly set by the bootloader that could explain the issues. 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/3] phy: omap-usb2: Manage PHY 3.3V supply regulator
On Tuesday 01 July 2014 03:55 PM, Roger Quadros wrote:
On 07/01/2014 01:20 PM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 01 July 2014 03:43 PM, Roger Quadros wrote:
On 07/01/2014 12:56 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 30 June 2014 04:30 PM, Roger Quadros wrote:
On some SoCs e.g. J6 the 3.3V supply to the USB2 PHY can be
powered down when the PHY is not in use. Add regulator
management code to control this power line.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/phy/phy-omap-usb2.c | 25 +
include/linux/phy/omap_usb.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 7007c11..2afc79c 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -30,6 +30,7 @@
#include linux/phy/omap_control_phy.h
#include linux/phy/phy.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
#define USB2PHY_DISCON_BYP_LATCH (1 31)
#define USB2PHY_ANA_CONFIG1 0x4c
@@ -107,6 +108,14 @@ static int omap_usb_power_off(struct phy *x)
omap_control_phy_power(phy-control_dev, 0);
+ if (phy-pwr) {
+ int ret;
+
+ ret = regulator_disable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
@@ -114,6 +123,14 @@ static int omap_usb_power_on(struct phy *x)
{
struct omap_usb *phy = phy_get_drvdata(x);
+ if (phy-pwr) {
+ int ret;
+
+ ret = regulator_enable(phy-pwr);
+ if (ret)
+ return ret;
+ }
+
Shouldn't we do this in phy_power_on/phy_power_off in phy-core?
I thought about that earlier, but could not find a way to defer probing if
the regulator is not-yet probed.
Any clues how it could be done in phy-core?
We can try to do regulator_get in phy_create and return EPROBE_DEFER if the
regulator_get returns EPROBE_DEFER no?
Yes indeed, we can. I missed the phy_create() and was only looking at
phy_init() and phy_power_*() :P.
I'll post a v2 soon.
cool. Thanks :-)
-Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 00/16] irqchip: crossbar: Driver fixes
On Tue, Jul 01, 2014 at 03:06:36PM +0530, Sricharan R wrote: Hi Tony, On Tuesday 01 July 2014 01:29 PM, Tony Lindgren wrote: * Jason Cooper ja...@lakedaemon.net [140630 12:30]: Whole series applied to irqchip/crossbar, I'll give it a day or two in -next, then I'll merge it into irqchip/core. Tony: Right now, it's immutable unless you tell me I applied something incorrectly. Once it goes into irqchip/core, it's immutable no matter what you say. ;-) Thanks, looks good to me. Sricharan and Nishant, can you please check that we can now apply the related .dts changes on top of Jason's branch at: git://git.infradead.org/users/jcooper/linux.git irqchip/crossbar I applied the dts patches on top of this and it worked fine for me on dra72 evm Awesome, thanks. irqchip/crossbar has been merged into irqchip/core. thx, Jason. -- 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: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Hi Suman, On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote: The hwspinlock_device structure is used for registering a bank of locks with the driver core. The structure already contains the necessary members to identify the bank of locks. The core does not maintain the hwspinlock_devices itself, but maintains only a radix tree for all the registered locks. A specific lock can be requested by users using a global lock id, and any device-specific fields can be retrieved through a reference to the hwspinlock_device in each lock. The global lock id, however, is not friendly to be requested for users using the device-tree model. The device-tree representation will typically have each of the hwspinlock devices represented as a DT node, and a specific lock can be requested using the device's phandle and a lock specifier. Add support to the core therefore to maintain all the registered hwspinlock_devices, so that a device can be looked up and a specific lock belonging to the device requested through a phandle + args approach. Signed-off-by: Suman Anna s-a...@ti.com I'm not sure we need this patch. It seems to me that the global lock id can be the base_id + lock index, where the former should be a property of the parent dt node, and the latter can just be the phandle argument. Then, with the global lock id in hand, drivers could just use the existing hwspin_lock_request_specific API. If future hardware will bring a more complex scenario, we could then introduce the xlate proposal to resolve it. As long as we're not changing the dt data, and this is all handled by kernel code, then I'd prefer opting for less code now as long as it addresses the requirements. Please let me know if currently there is a use case that can't be addressed using this simpler model. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
Hi Suman, On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote: 2. The of_hwspin_lock_simple_xlate() is a simple default translator function for hwspinlock provider implementations that use a single cell number for requesting a specific lock (relatively indexed) within a hwlock bank. Do we have a use case today that require the xlate() method? If not, let's remove it as we could always add it back if some new hardware shows up that needs it. As long as the dt data is unchanged, we should generally only add kernel code that we really need. 3. The of_hwspin_lock_request_specific() API can be used by hwspinlock clients to request a specific lock using the phandle + args specifier. This function relies on the implementation providing back a relative hwlock id within the bank from the args specifier. It seems to me we can just introduce a of_hwspin_lock_get_id() method which will provide the global lock id to dt users, with which they could just invoke the existing hwspin_lock_request_specific(). This way we will have more common code between dt users and users who get the lock id from a remote processor. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote:
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
struct hwspinlock_device *bank;
struct hwspinlock *hwlock;
struct resource *res;
void __iomem *io_base;
int num_locks, i, ret;
+ int base_id = 0;
We shouldn't implicitly assume base_id is zero: let's explicitly
protect against potential subsequent invocations of
omap_hwspinlock_probe.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
Hi Suman, On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote: The number of hwspinlocks are determined based on the value read from the IP block's SYSSTATUS register. However, the module may not be enabled and clocked, and the read may result in a bus error. This particular issue is seen rather easily on AM33XX, since the module wakeup is software controlled, and it is disabled out of reset. Make sure the module is enabled and clocked before reading the SYSSTATUS register. This seems like a valid fix that is independent of this patch series. Feel free to submit it separately if you want, so we can get it merged. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] arm: dts: add support for am437x sk
* Felipe Balbi ba...@ti.com [140630 09:47]: Hi, On Mon, Jun 23, 2014 at 01:20:57PM -0500, Felipe Balbi wrote: Hi, here's v3 of am437x sk support. Patches tested on top of next-20140617. Note that this series was tested with the following extra patches: http://marc.info/?l=linux-omapm=140299431732700w=2 http://marc.info/?l=linux-omapm=140300146503126w=2 http://marc.info/?l=linux-omapm=140299231232123 http://marc.info/?l=linux-omapm=140310472709968w=2 http://marc.info/?l=linux-omapm=140310471409959w=2 A branch is also available with all these patches at [1]. [1] http://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=am437x-starterkit Felipe Balbi (2): arm: dts: am4372: let boards access all nodes through phandles arm: dts: add support for AM437x StarterKit ping on this series, it has been tested by several folks and still no updates from anybody in the DT land. Thanks applying both into omap-for-v3.17/dt branch. 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: [PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx DRA7xx
Hi Suman, On Thu, May 1, 2014 at 3:34 AM, Suman Anna s-a...@ti.com wrote: HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC device families as well. The IPs are identical to that of OMAP4/OMAP5, except for the number of locks. Add a depends on to the above family of SoCs to enable the build support for OMAP hwspinlock driver for any of the above SoC configs. Signed-off-by: Suman Anna s-a...@ti.com This looks too like an independent change. If you want it merged without waiting for the entire series please submit it separately. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
am335x: linux 3.16-rc3: USB DMA issue
I have following system: USB0: host mode (USB hub is soldered internally) USB1: OTG mode with OTG connector My DTS: http://pastebin.com/KB3iTehQ If I enable DMA in the kernel, I get USB0 working, i.e. USB hub is detected and USB devices, that are connected to this hub are also detected and working. The USB thumb drive connected to USB1 won't be detected. # lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M |__ Port 3: Dev 3, If 0, Class=Communications, Driver=cdc_acm, 12M |__ Port 3: Dev 3, If 1, Class=CDC Data, Driver=cdc_acm, 12M of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401300[0]' 47401300.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.0.auto: Failed to request rx1. musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401b00[0]' 47401b00.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.1.auto: Failed to request rx1. musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517 platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral usbcore: registered new interface driver usbhid usbhid: USB HID core driver musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 1 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 3.16.0-rc3-6-g16874b2 musb-hcd usb usb1: SerialNumber: musb-hdrc.0.auto musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 2 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: MUSB HDRC host driver usb usb2: Manufacturer: Linux 3.16.0-rc3-6-g16874b2 musb-hcd usb usb2: SerialNumber: musb-hdrc.1.auto usb 1-1: new high-speed USB device number 2 using musb-hdrc usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub usb 1-1.3: new full-speed USB device number 3 using musb-hdrc usb 1-1.3: New USB device found, idVendor=1546, idProduct=01a7 usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.3: Product: u-blox 7 - GPS/GNSS Receiver usb 1-1.3: Manufacturer: u-blox AG - www.u-blox.com usb 1-1.2: new high-speed USB device number 4 using musb-hdrc usb 1-1.2: New USB device found, idVendor=1307, idProduct=0165 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.2: Product: USB Mass Storage Device usb 1-1.2: Manufacturer: USBest Technology usb 1-1.2: SerialNumber: 000504 usb-storage 1-1.2:1.0: USB Mass Storage device detected scsi0 : usb-storage 1-1.2:1.0 If I disable DMA in the kernel, I have reverse behavior: USB1 is working, USB0 doesn't see the hub. # lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401300[0]' 47401300.usb-phy supply vcc not found, using dummy regulator musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 1 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 3.16.0-rc3-6-g16874b2 musb-hcd usb usb1: SerialNumber: musb-hdrc.0.auto of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401b00[0]' 47401b00.usb-phy supply vcc not found, using dummy regulator musb-hdrc: ConfigData=0xde
Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
* Roger Quadros rog...@ti.com [140701 03:13]: On 06/13/2014 03:08 PM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140613 04:43]: OK. I agree about using some kind of abstraction instead of direct access. Yes and like we chatted on irc, adding a syscon mapping for for the NAND specific registers might do the trick here. After looking at the syscon driver, which relies on regmap, it seems that regmap was designed for slow control busses like I2C/SPI and using it for NAND controller register access will have a significant negative impact on performance. In the NAND case the register writes are used for each NAND command cycle and the reads for ECC checks (every page). See how much code regmap_read and regmap_mmio_read() translates to for a simple register read i.e. readl(). http://lxr.free-electrons.com/source/drivers/base/regmap/regmap.c#L1944 http://lxr.free-electrons.com/source/drivers/base/regmap/regmap-mmio.c#L129 So I'm not so sure of using regmap/syscon for NAND controller register access. OK yes I agree, it's not a good solution for a constant register access that's needed for the ECC registers. Could there be any other abstraction method of sharing the register space between GPMC and NAND driver? I've also added Ivan to the thread, the author of memory/ti-aemif.c driver, to check if he faced any issues with shared register access of the AEMIF/NAND registers. If there's no common framework available for GPMC to implement, it's best to just export few functions from gpmc.c for the ECC calculations. 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Gupta, Pekon pe...@ti.com [140701 02:09]:
From: Tony Lindgren [mailto:t...@atomide.com]
* Gupta, Pekon pe...@ti.com [140627 14:08]:
From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
On Tue, Jun 24, 2014 at 05:54:24PM +0530, Pekon Gupta wrote:
[...]
+gpmc {
+ ranges = 0 0 0 0x0100;/* address range = 16MB
(minimum GPMC partition) */
+ nand@0,0 {
+ status = disabled;
+ reg = 0 0 4; /* device IO registers */
+ pinctrl-names = default;
+ pinctrl-0 = bbcape_nand_flash_pins;
This doesn't seem to work as pinctrl properties are not parsed for
childs of the gpmc node. Did this work for you?
Putting this in the gpmc node makes it work, but how will we control
pins for the nand and nor independently? I believe there is currently no
support for muxing individual gpmc devices. If we want to add both
devices to the DT and enable them as needed we'd need to add support for
this, right?
Yes, And that should be the case, because different devices would be
connected to different chip-selects, so there should be support of
providing individual pin-mux for different GPMC devices.
Currently both NAND and NOR cape share GPMC_CS0, so both NAND and NOR
capes will not work simultaneously. But I'm planning to modify NOR cape
hardware at my end to use GPMC_CS1 instead of GPMC_CS0.
- NAND on GPMC_CS0
- NOR on GPMC_CS1
Hmm but we should have these working with both using CS0 without
any need to modify the hardware though?
Yes, but one at a time. That mean either of 'NAND cape' or 'NOR cape'.
If you need both working simultaneously as 2 separate devices attached
to GPMC, then you need 2 separate chip-selects, which is what I'm trying
to test with [1].
Right only one enabled at a time, not both enabled at the same time :)
In that case we should make sure we always set large enough GPMC
partition
Yes, this is taken care with introduction of NOR cape in
[PATCH v1 2/3] ARM: dts: am335x-bone: add support for beaglebone NOR cape
gpmc {
- ranges = 0 0 0 0x0100;/* address range = 16MB (minimum GPMC
partition) */
+ ranges = 0 0 0x0800 0x0100; /* address offset=128MB,
range=128Mb=16MB */
This GPMC partition suffices for both NAND and NOR requirements.
OK
and that the pins are muxed for the connected GPMC
devices only.
Pin mux is something I need to re-work, because currently
I've tested either NAND or NOR individually, not together.
Also as mentioned above by Guido, pin-ctrl property is not parsed individually
for GPMC children, Instead pin-ctrl is set once for GPMC as a whole.
Yes, drivers/base/pinctrl.c should already take care of that though?
Do you have any suggestions on how pin-ctrl should be set if we have
multiple devices connected to GPMC like;
All these devices will share:
- control lines (gpmc_wait, gpmc_ben_cle, gpmc_advn_ale, gpmc_we, gpmc_oe_ren)
- *some* data lines (gpmc_ad[])
- *some* address lines (gpmc_a[])
- but chip-selects will be different:
gpmc_cs0: NAND
gpmc_cs1: NOR
gpmc_cs2: SMSC91xx
gpmc_cs3: Camera
Well the pinctrl settings should be done a the child driver level
when it probes so drivers/base/pinctrl.c does what it's supposed
to do.
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: linux 3.16-rc3: USB DMA issue
On Tue, Jul 1, 2014 at 3:03 PM, Yegor Yefremov yegorsli...@googlemail.com wrote: I have following system: USB0: host mode (USB hub is soldered internally) USB1: OTG mode with OTG connector My DTS: http://pastebin.com/KB3iTehQ If I enable DMA in the kernel, I get USB0 working, i.e. USB hub is detected and USB devices, that are connected to this hub are also detected and working. The USB thumb drive connected to USB1 won't be detected. # lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M |__ Port 3: Dev 3, If 0, Class=Communications, Driver=cdc_acm, 12M |__ Port 3: Dev 3, If 1, Class=CDC Data, Driver=cdc_acm, 12M of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401300[0]' 47401300.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.0.auto: Failed to request rx1. musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401b00[0]' 47401b00.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.1.auto: Failed to request rx1. musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517 platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral usbcore: registered new interface driver usbhid usbhid: USB HID core driver musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 1 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 3.16.0-rc3-6-g16874b2 musb-hcd usb usb1: SerialNumber: musb-hdrc.0.auto musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 2 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: MUSB HDRC host driver usb usb2: Manufacturer: Linux 3.16.0-rc3-6-g16874b2 musb-hcd usb usb2: SerialNumber: musb-hdrc.1.auto usb 1-1: new high-speed USB device number 2 using musb-hdrc usb 1-1: New USB device found, idVendor=05e3, idProduct=0608 usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 1-1: Product: USB2.0 Hub usb 1-1.3: new full-speed USB device number 3 using musb-hdrc usb 1-1.3: New USB device found, idVendor=1546, idProduct=01a7 usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.3: Product: u-blox 7 - GPS/GNSS Receiver usb 1-1.3: Manufacturer: u-blox AG - www.u-blox.com usb 1-1.2: new high-speed USB device number 4 using musb-hdrc usb 1-1.2: New USB device found, idVendor=1307, idProduct=0165 usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.2: Product: USB Mass Storage Device usb 1-1.2: Manufacturer: USBest Technology usb 1-1.2: SerialNumber: 000504 usb-storage 1-1.2:1.0: USB Mass Storage device detected scsi0 : usb-storage 1-1.2:1.0 If I disable DMA in the kernel, I have reverse behavior: USB1 is working, USB0 doesn't see the hub. # lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401300[0]' 47401300.usb-phy supply vcc not found, using dummy regulator musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver musb-hdrc musb-hdrc.0.auto: new USB bus registered, assigned bus number 1 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: MUSB HDRC host driver usb usb1: Manufacturer: Linux 3.16.0-rc3-6-g16874b2 musb-hcd usb usb1: SerialNumber: musb-hdrc.0.auto
Re: am335x: linux 3.16-rc3: USB DMA issue
On 1 July 2014 12:07, Yegor Yefremov yegorsli...@googlemail.com wrote: [..] What can be done with these error messages: of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401300[0]' 47401300.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.0.auto: Failed to request rx1. musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401b00[0]' 47401b00.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.1.auto: Failed to request rx1. musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517 platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral couldn't find an available UDC The above are typical deferal messages. Have you tried building everything as a module or moving the DMA devicetree node so it's probed earlier? But I'm not sure it's related to the problem you are seeing. -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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: linux 3.16-rc3: USB DMA issue
On Tue, Jul 1, 2014 at 10:37 AM, Ezequiel García ezequ...@vanguardiasur.com.ar wrote: On 1 July 2014 12:07, Yegor Yefremov yegorsli...@googlemail.com wrote: [..] What can be done with these error messages: of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401300[0]' 47401300.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.0.auto: Failed to request rx1. musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral of_get_named_gpiod_flags: can't parse gpios property of node '/ocp/usb@4740/usb-phy@47401b00[0]' 47401b00.usb-phy supply vcc not found, using dummy regulator musb-hdrc musb-hdrc.1.auto: Failed to request rx1. musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517 platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral couldn't find an available UDC The above are typical deferal messages. Have you tried building everything as a module or moving the DMA devicetree node so it's probed earlier? But I'm not sure it's related to the problem you are seeing. It might be ZLP related. Daniel's patch dma: cppi41: handle 0-length packets might solve it. -Bin. -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: atmel_mxt_ts: defaulting irqflags to IRQF_TRIGGER_FALLING
Sekhar Nori wrote at Tuesday, July 01, 2014 3:52 AM: Nick, I have been using your for-next branch to base my development of touchscreen support on TI's DRA7x EVM. With the recent updates, it has worked out great and once I got the configuration right, it was just a question of adding DT data for the platform. Now, there is one problem with Stephen's patch defaulting the irqflags to IRQF_TRIGGER_FALLING. The interrupt controller I am using (ARM GIC) does not seem to support that and the device fails to probe: On the Tegra systems I have, IRQF_TRIGGER_FALLING is the correct (or at least a valid) choice. That's probably because the Atmel IRQ signal is routed to our GPIO controller, which is also an IRQ controller, and then forwarded up the chain to the GIC, with the polarity the GIC expects. If IRQ_TRIGGER_FALLING doesn't work everywhere, then we'll need to add some kind of DT property to configure the polarity of the IRQ output. [1.932798] genirq: Setting trigger mode 2 for irq 151 failed (gic_set_type+0x0/0xf0) [1.941340] atmel_mxt_ts 0-004a: Failed to register interrupt [1.947452] atmel_mxt_ts: probe of 0-004a failed with error -22 Attached patch does the trick for me: diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c index 71154c2..f2d3f72 100644 --- a/drivers/input/touchscreen/atmel_mxt_ts.c +++ b/drivers/input/touchscreen/atmel_mxt_ts.c @@ -3155,9 +3155,6 @@ static struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client) pdata-gpio_reset = of_get_named_gpio_flags(dev-of_node, atmel,reset-gpio, 0, NULL); - /* Default to this. Properties can be added to configure it later */ - pdata-irqflags = IRQF_TRIGGER_FALLING; - of_property_read_string(dev-of_node, atmel,cfg_name, pdata-cfg_name); Can you switch to leaving the platform to specify flags (at least for the DT case)? Thanks, Sekhar -- nvpublic -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part2)
--- a/arch/arm/mm/proc-arm926.S +++ b/arch/arm/mm/proc-arm926.S @@ -55,7 +55,7 @@ * cpu_arm926_proc_init() */ ENTRY(cpu_arm926_proc_init) - mov pc, lr + ret lr /* * cpu_arm926_proc_fin() @@ -65,7 +65,7 @@ ENTRY(cpu_arm926_proc_fin) bic r0, r0, #0x1000 @ ...i bic r0, r0, #0x000e @ wca. mcr p15, 0, r0, c1, c0, 0 @ disable caches - mov pc, lr + ret lr /* * cpu_arm926_reset(loc) @@ -89,7 +89,7 @@ ENTRY(cpu_arm926_reset) bic ip, ip, #0x000f @ wcam bic ip, ip, #0x1100 @ ...i...s mcr p15, 0, ip, c1, c0, 0 @ ctrl register - mov pc, r0 + ret r0 ENDPROC(cpu_arm926_reset) .popsection @@ -111,7 +111,7 @@ ENTRY(cpu_arm926_do_idle) mcr p15, 0, r0, c7, c0, 4 @ Wait for interrupt mcr p15, 0, r1, c1, c0, 0 @ Restore ICache enable msr cpsr_c, r3 @ Restore FIQ state - mov pc, lr + ret lr /* * flush_icache_all() @@ -121,7 +121,7 @@ ENTRY(cpu_arm926_do_idle) ENTRY(arm926_flush_icache_all) mov r0, #0 mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache - mov pc, lr + ret lr ENDPROC(arm926_flush_icache_all) /* @@ -151,7 +151,7 @@ __flush_whole_cache: tst r2, #VM_EXEC mcrne p15, 0, ip, c7, c5, 0 @ invalidate I cache mcrne p15, 0, ip, c7, c10, 4 @ drain WB - mov pc, lr + ret lr /* * flush_user_cache_range(start, end, flags) @@ -188,7 +188,7 @@ ENTRY(arm926_flush_user_cache_range) blo 1b tst r2, #VM_EXEC mcrne p15, 0, ip, c7, c10, 4 @ drain WB - mov pc, lr + ret lr /* * coherent_kern_range(start, end) @@ -222,7 +222,7 @@ ENTRY(arm926_coherent_user_range) blo 1b mcr p15, 0, r0, c7, c10, 4 @ drain WB mov r0, #0 - mov pc, lr + ret lr /* * flush_kern_dcache_area(void *addr, size_t size) @@ -242,7 +242,7 @@ ENTRY(arm926_flush_kern_dcache_area) mov r0, #0 mcr p15, 0, r0, c7, c5, 0 @ invalidate I cache mcr p15, 0, r0, c7, c10, 4 @ drain WB - mov pc, lr + ret lr /* * dma_inv_range(start, end) @@ -270,7 +270,7 @@ arm926_dma_inv_range: cmp r0, r1 blo 1b mcr p15, 0, r0, c7, c10, 4 @ drain WB - mov pc, lr + ret lr /* * dma_clean_range(start, end) @@ -291,7 +291,7 @@ arm926_dma_clean_range: blo 1b #endif mcr p15, 0, r0, c7, c10, 4 @ drain WB - mov pc, lr + ret lr /* * dma_flush_range(start, end) @@ -313,7 +313,7 @@ ENTRY(arm926_dma_flush_range) cmp r0, r1 blo 1b mcr p15, 0, r0, c7, c10, 4 @ drain WB - mov pc, lr + ret lr /* * dma_map_area(start, size, dir) @@ -336,7 +336,7 @@ ENDPROC(arm926_dma_map_area) * - dir - DMA direction */ ENTRY(arm926_dma_unmap_area) - mov pc, lr + ret lr ENDPROC(arm926_dma_unmap_area) .globl arm926_flush_kern_cache_louis @@ -353,7 +353,7 @@ ENTRY(cpu_arm926_dcache_clean_area) bhi 1b #endif mcr p15, 0, r0, c7, c10, 4 @ drain WB - mov pc, lr + ret lr /* === PageTable == */ @@ -380,7 +380,7 @@ ENTRY(cpu_arm926_switch_mm) mcr p15, 0, r0, c2, c0, 0 @ load page table pointer mcr p15, 0, ip, c8, c7, 0 @ invalidate I D TLBs #endif - mov pc, lr + ret lr /* * cpu_arm926_set_pte_ext(ptep, pte, ext) @@ -397,7 +397,7 @@ ENTRY(cpu_arm926_set_pte_ext) #endif mcr p15, 0, r0, c7, c10, 4 @ drain WB #endif - mov pc, lr + ret lr /* Suspend/resume support: taken from arch/arm/plat-s3c24xx/sleep.S */ .globl cpu_arm926_suspend_size @@ -448,7 +448,7 @@ __arm926_setup: #ifdef CONFIG_CPU_CACHE_ROUND_ROBIN orr r0, r0, #0x4000 @ .1.. #endif - mov pc, lr + ret lr .size __arm926_setup, . - __arm926_setup /* diff --git a/arch/arm/mm/proc-arm940.S b/arch/arm/mm/proc-arm940.S index 1c39a704ff6e..e5212d489377 100644 --- a/arch/arm/mm/proc-arm940.S +++ b/arch/arm/mm/proc-arm940.S @@ -31,7 +31,7 @@ */ ENTRY(cpu_arm940_proc_init) ENTRY(cpu_arm940_switch_mm) - mov pc, lr + ret lr /* * cpu_arm940_proc_fin() @@ -41,7 +41,7 @@ ENTRY(cpu_arm940_proc_fin) bic r0, r0, #0x1000 @ i-cache bic
Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Russell King rmk+ker...@arm.linux.org.uk writes: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than the mov pc, lr instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro ret with all its variants for the condition code which will resolve to the appropriate instruction. When the source register is not lr the name ret is a misnomer since only the bx lr instruction is predicted as a function return. The bx instruction with other source registers uses the normal prediction mechanisms, leaving the return stack alone, and should not be used for function returns. Any code currently using another register to return from a function should probably be modified to use lr instead, unless there are special reasons for doing otherwise. If code jumping to an address in a non-lr register is not a return, using the ret name will make for some rather confusing reading. I would suggest either using a more neutral name than ret or adding an alias to be used for non-return jumps so as to make the intent clearer. -- Måns Rullgård m...@mansr.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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote: Russell King rmk+ker...@arm.linux.org.uk writes: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than the mov pc, lr instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro ret with all its variants for the condition code which will resolve to the appropriate instruction. When the source register is not lr the name ret is a misnomer since only the bx lr instruction is predicted as a function return. The bx instruction with other source registers uses the normal prediction mechanisms, leaving the return stack alone, and should not be used for function returns. Any code currently using another register to return from a function should probably be modified to use lr instead, unless there are special reasons for doing otherwise. If code jumping to an address in a non-lr register is not a return, using the ret name will make for some rather confusing reading. I would suggest either using a more neutral name than ret or adding an alias to be used for non-return jumps so as to make the intent clearer. If you read the patch, the branches which are changed are those which do indeed return in some way. There are those which do this having moved lr to a different register. As you point out, bx lr /may/ be treated specially (I've actually been discussing this with Will Deacon over the last couple of days, who has also been talking to the hardware people in ARM, and Will is happy with this patch as in its current form.) This is why I've changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. I have thought about introducing a call macro for those other sites, but as there are soo few of them, I've left them as-is for the time being (this patch is already large enough.) If there are any in the patch which you have specific concerns about, please specifically point them out those which give you a concern. Thanks. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Russell King - ARM Linux li...@arm.linux.org.uk writes: On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote: Russell King rmk+ker...@arm.linux.org.uk writes: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than the mov pc, lr instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro ret with all its variants for the condition code which will resolve to the appropriate instruction. When the source register is not lr the name ret is a misnomer since only the bx lr instruction is predicted as a function return. The bx instruction with other source registers uses the normal prediction mechanisms, leaving the return stack alone, and should not be used for function returns. Any code currently using another register to return from a function should probably be modified to use lr instead, unless there are special reasons for doing otherwise. If code jumping to an address in a non-lr register is not a return, using the ret name will make for some rather confusing reading. I would suggest either using a more neutral name than ret or adding an alias to be used for non-return jumps so as to make the intent clearer. If you read the patch, the branches which are changed are those which do indeed return in some way. There are those which do this having moved lr to a different register. The patch is huge, and it wasn't obvious (to me) from the diff context what the non-lr jumps were doing. As you point out, bx lr /may/ be treated specially (I've actually been Most, if not all, Cortex-A cores do this according the public TRMs. They also do the same thing for mov pc, lr so there will probably be no performance gain from this change. It's still a good idea though, since we don't know what future cores will do. discussing this with Will Deacon over the last couple of days, who has also been talking to the hardware people in ARM, and Will is happy with this patch as in its current form.) This is why I've changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. In that case the patch should be fine. Your patch description didn't make it clear that only actual returns were being changed. -- Måns Rullgård m...@mansr.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] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Hi Mans, On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: As you point out, bx lr /may/ be treated specially (I've actually been Most, if not all, Cortex-A cores do this according the public TRMs. They also do the same thing for mov pc, lr so there will probably be no performance gain from this change. It's still a good idea though, since we don't know what future cores will do. Funnily enough, that's not actually true (and is more or less what prompted this patch after discussion with Russell). There are cores out there that don't predict mov pc, lr at all (let alone do anything with the return stack). discussing this with Will Deacon over the last couple of days, who has also been talking to the hardware people in ARM, and Will is happy with this patch as in its current form.) This is why I've changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. In that case the patch should be fine. Your patch description didn't make it clear that only actual returns were being changed. I'm led to believe that some predictors require lr in order to update the return stack, whilst others don't. That part is all horribly micro-architectural, so the current patch is doing the right thing by sticking to the ARM ARM but enabling us to hook into other registers later on if we choose. Cheers, Will -- 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: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
On 07/01/2014 10:19 AM, Russell King wrote: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than the mov pc, lr instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro ret with all its variants for the condition code which will resolve to the appropriate instruction. Rather than doing this piecemeal, and miss some instances, change all the mov pc instances to use the new macro, with the exception of the movs instruction and the kprobes code. This allows us to detect the mov pc, lr case and fix it up - and also gives us the possibility of deploying this for other registers depending on the CPU selection. Tested-by: Stephen Warren swar...@nvidia.com (On an NVIDIA Tegra Jetson TK1 board, both CPU hotplug and system sleep were tested, which are the use-cases that actually use the edited assembly files) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: l2c: squelch warning dump on power control setting
On Tue, Jun 17, 2014 at 08:19:35AM -0500, Felipe Balbi wrote: On Tue, Jun 17, 2014 at 04:04:51PM +0530, Sekhar Nori wrote: ROM code on AM437x does not support writing to L2C-310 power control register. The L2C driver, however, tries writing to this register for all revisions = r3p0. This leads to a warning dump on boot which leads most users to believe that L2 cache is non-functional. Since the problem is understood, and cannot be addressed through software, replace the warning with a pr_info() while maintaining the WARN_ON() for other truly unexpected scenarios. Reported-by: Nishanth Menon n...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Tested with today's linux-next (5f295cdf5c5dbbb0c40f10f2ddae02ff46bbf773) with am437x-sk, I can see that the WARNING goes away. Tested-by: Felipe Balbi ba...@ti.com ping here, I can't see this patch onl linus/master or next/master yet. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
Hi,
On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous default, and causes problems on AM43x when
using display and ethernet. There are multiple ways to select the clock
muxes on AM43x, and some of those clock paths have the same source
clocks for display and ethernet. When changing the clock rate for the
display subsystem, the clock framework decides to change the display mux
from the dedicated display PLL to a shared PLL which is used by the
ethernet, and then changes the rate of the shared PLL, breaking the
ethernet.
As I don't think there ever is a case where we want the clock framework
to automatically change the parent clock of a clock mux, this patch sets
the CLK_SET_RATE_NO_REPARENT for all ti,mux-clocks.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index 0197a478720c..e9d650e51287 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -160,7 +160,7 @@ static void of_mux_clk_setup(struct device_node *node)
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
-u32 flags = 0;
+u32 flags = CLK_SET_RATE_NO_REPARENT;
num_parents = of_clk_get_parent_count(node);
if (num_parents 2) {
Thanks, queued for 3.16-rc fixes.
did you skip a few -rcs by any chance? Looks like this could've been
merged on v3.16-rc3... Just checking.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Will Deacon will.dea...@arm.com writes: Hi Mans, On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: As you point out, bx lr /may/ be treated specially (I've actually been Most, if not all, Cortex-A cores do this according the public TRMs. They also do the same thing for mov pc, lr so there will probably be no performance gain from this change. It's still a good idea though, since we don't know what future cores will do. Funnily enough, that's not actually true (and is more or less what prompted this patch after discussion with Russell). There are cores out there that don't predict mov pc, lr at all (let alone do anything with the return stack). Even ones where the TRM says they do? I suppose the only way to know for sure is to measure it. discussing this with Will Deacon over the last couple of days, who has also been talking to the hardware people in ARM, and Will is happy with this patch as in its current form.) This is why I've changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. In that case the patch should be fine. Your patch description didn't make it clear that only actual returns were being changed. I'm led to believe that some predictors require lr in order to update the return stack, whilst others don't. That part is all horribly micro-architectural, so the current patch is doing the right thing by sticking to the ARM ARM but enabling us to hook into other registers later on if we choose. Agreed. -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] ARM: dts: am335x-evmsk: enable display and lcd panel support
Add the necessary nodes to enable the LCD controller and the
LCD panel that is attached to the Texas Instruments AM335x
EVMSK platform. Also setup the necessary pin mux within the
DT file to drive the LCD connector and add the correct
pinmux settings for the lcd pins to be configured to when
the SoC goes into sleep state for the minimum power
consumption.
For the sleep mode LCD pin settings, MUX_MODE7 is chosen as
this corresponds to switching the pins into input GPIO's with
an internal pulldown. Which has been determined to offer the
lowest power solution vs leaving the pins configured in LCD
mode.
Signed-off-by: Darren Etheridge detheri...@ti.com
Acked-by: Wolfram Sang w...@sang-engineering.com
---
Tony, Benoit,
I didn't see this patch get applied anywhere, so I updated it and I am
resending it. Please let me know if you need any more info before you will
apply it.
Thanks, Darren
v3:
Updated subject to match classification style of subsystem
Rebased against 3.16-rc3
v2:
Fixed up the incorrect label ordering in the pinmux comments for LCD pins
16 through 23 as reported by Wolfram Sang w...@sang-engineering.com
arch/arm/boot/dts/am335x-evmsk.dts | 105 +
1 file changed, 105 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ab9a34c..59766e2 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -149,12 +149,113 @@
Headphone Jack, HPLOUT,
Headphone Jack, HPROUT;
};
+
+ panel {
+ compatible = ti,tilcdc,panel;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = lcd_pins_default;
+ pinctrl-1 = lcd_pins_sleep;
+ status = okay;
+ panel-info {
+ ac-bias = 255;
+ ac-bias-intrpt= 0;
+ dma-burst-sz = 16;
+ bpp = 32;
+ fdd = 0x80;
+ sync-edge = 0;
+ sync-ctrl = 1;
+ raster-order = 0;
+ fifo-th = 0;
+ };
+ display-timings {
+ 480x272 {
+ hactive = 480;
+ vactive = 272;
+ hback-porch = 43;
+ hfront-porch= 8;
+ hsync-len = 4;
+ vback-porch = 12;
+ vfront-porch= 4;
+ vsync-len = 10;
+ clock-frequency = 900;
+ hsync-active= 0;
+ vsync-active= 0;
+ };
+ };
+ };
};
am33xx_pinmux {
pinctrl-names = default;
pinctrl-0 = gpio_keys_s0 clkout2_pin;
+ lcd_pins_default: lcd_pins_default {
+ pinctrl-single,pins =
+ 0x20 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad8.lcd_data23
*/
+ 0x24 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad9.lcd_data22
*/
+ 0x28 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad10.lcd_data21
*/
+ 0x2c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad11.lcd_data20
*/
+ 0x30 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad12.lcd_data19
*/
+ 0x34 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad13.lcd_data18
*/
+ 0x38 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad14.lcd_data17
*/
+ 0x3c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad15.lcd_data16
*/
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0
*/
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1
*/
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2
*/
+ 0xac (PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3
*/
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4
*/
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5
*/
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6
*/
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7
*/
+ 0xc0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8
*/
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9
*/
+ 0xc8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data10.lcd_data10 */
+ 0xcc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data11.lcd_data11 */
+ 0xd0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data12.lcd_data12 */
+ 0xd4
Re: [PATCH v3] ARM: dts: am335x-evmsk: enable display and lcd panel support
Hi,
On Tue, Jul 01, 2014 at 04:00:20PM -0500, Darren Etheridge wrote:
Add the necessary nodes to enable the LCD controller and the
LCD panel that is attached to the Texas Instruments AM335x
EVMSK platform. Also setup the necessary pin mux within the
DT file to drive the LCD connector and add the correct
pinmux settings for the lcd pins to be configured to when
the SoC goes into sleep state for the minimum power
consumption.
For the sleep mode LCD pin settings, MUX_MODE7 is chosen as
this corresponds to switching the pins into input GPIO's with
an internal pulldown. Which has been determined to offer the
lowest power solution vs leaving the pins configured in LCD
mode.
Signed-off-by: Darren Etheridge detheri...@ti.com
Acked-by: Wolfram Sang w...@sang-engineering.com
Tested-by: Felipe Balbi ba...@ti.com
serial console capture: http://slexy.org/view/s200thiMb3
note that v2 has been pending since May 9th:
http://marc.info/?l=linux-omapm=139966159102339w=2
---
Tony, Benoit,
I didn't see this patch get applied anywhere, so I updated it and I am
resending it. Please let me know if you need any more info before you will
apply it.
Thanks, Darren
v3:
Updated subject to match classification style of subsystem
Rebased against 3.16-rc3
v2:
Fixed up the incorrect label ordering in the pinmux comments for LCD pins
16 through 23 as reported by Wolfram Sang w...@sang-engineering.com
arch/arm/boot/dts/am335x-evmsk.dts | 105
+
1 file changed, 105 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index ab9a34c..59766e2 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -149,12 +149,113 @@
Headphone Jack, HPLOUT,
Headphone Jack, HPROUT;
};
+
+ panel {
+ compatible = ti,tilcdc,panel;
+ pinctrl-names = default, sleep;
+ pinctrl-0 = lcd_pins_default;
+ pinctrl-1 = lcd_pins_sleep;
+ status = okay;
+ panel-info {
+ ac-bias = 255;
+ ac-bias-intrpt= 0;
+ dma-burst-sz = 16;
+ bpp = 32;
+ fdd = 0x80;
+ sync-edge = 0;
+ sync-ctrl = 1;
+ raster-order = 0;
+ fifo-th = 0;
+ };
+ display-timings {
+ 480x272 {
+ hactive = 480;
+ vactive = 272;
+ hback-porch = 43;
+ hfront-porch= 8;
+ hsync-len = 4;
+ vback-porch = 12;
+ vfront-porch= 4;
+ vsync-len = 10;
+ clock-frequency = 900;
+ hsync-active= 0;
+ vsync-active= 0;
+ };
+ };
+ };
};
am33xx_pinmux {
pinctrl-names = default;
pinctrl-0 = gpio_keys_s0 clkout2_pin;
+ lcd_pins_default: lcd_pins_default {
+ pinctrl-single,pins =
+ 0x20 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad8.lcd_data23
*/
+ 0x24 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad9.lcd_data22
*/
+ 0x28 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad10.lcd_data21
*/
+ 0x2c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad11.lcd_data20
*/
+ 0x30 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad12.lcd_data19
*/
+ 0x34 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad13.lcd_data18
*/
+ 0x38 (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad14.lcd_data17
*/
+ 0x3c (PIN_OUTPUT | MUX_MODE1) /* gpmc_ad15.lcd_data16
*/
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0
*/
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1
*/
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2
*/
+ 0xac (PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3
*/
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4
*/
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5
*/
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6
*/
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7
*/
+ 0xc0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8
*/
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9
*/
+
Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
Quoting Paul Walmsley (2014-06-13 12:53:06) Furthermore, as a general interface principle, allowing clk_set_rate() to silently round rates could lead to unexpected behavior, since the set of rates that clk_set_rate() can round to may change between the call to clk_round_rate() and the call to clk_set_rate(). Rounding the rate will always happen in a call to clk_set_rate. We need to know what rate that clock node can actually support. The real question is what do we do with that rounded rate. There are two options: 1) abort and return an error code if the rounded rate does not exactly match the requested rate 2) use the rounded rate even if it does not match the requested rate #2 has some variations worth considering: a) allow a rounded rate within a specified tolerance (e.g. 10% of the requested rate) b) allow a rounded rate so long as it is rounded down from the requested rate c) same as #b, but rounded up, etc. So again I think that the right way to deal with this is to: 1. avoid silently rounding rates in clk_set_rate() and to return an error if calling clk_set_rate() would result in a rate other than the one desired; and to Let's get consensus on my above question before we solidify the API. It's worth noting that the current behavior of rounding the rate within clk_set_rate is actually what Russell had in mind back in 2010. See this thread[1] for details. Also note that this opens up a can of worms regarding *intended rates*. For example, if you always abort clk_set_rate if the rounded rate does not match the requested rate, then what does that mean for a child clock that will be changed by some parent clock higher up the tree? If that child gets put to a rate that would never be returned by clk_round_rate then is the framework responsible for walking down the tree, checking every child and aborting when the first one is off by a few hertz? That's going to be messy. 2. modify clk_round_rate() such that it returns the closest lowest-or-equal rate match to the target rate requested. I agree that the behavior of clk_round_rate needs to be defined once and for all. I also think that clk_round_ceil, clk_round_floor and clk_round_exact aren't terrible ideas either. I'll kick off a thread on this topic shortly, and we can hopefully gain some consensus. Regards, Mike [1] https://lkml.org/lkml/2010/7/14/330 - Paul -- 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/3] clk: ti: add 'ti,round-rate' flag
On Tue, Jul 01, 2014 at 02:40:17PM -0700, Mike Turquette wrote:
Let's get consensus on my above question before we solidify the API.
It's worth noting that the current behavior of rounding the rate within
clk_set_rate is actually what Russell had in mind back in 2010. See this
thread[1] for details.
Yes, because the problem is that doing anything else is racy.
Consider the sequence (which some folk who don't understand this point
have coded all over the place):
rate = clk_round_rate(clk, my_rate);
clk_set_rate(clk, rate);
The problem here is that between the two calls, it is possible that (as
you say) the parent clocks could be reconfigured - there are no locks
held at any point to protect against that happening.
So, what the above sequence means is that:
rate = clk_round_rate(clk, my_rate);
would return the rounded rate that the clock could provide for my_rate.
Then the clk's parent changes.
We now do the clk_set_rate(). This re-rounds the rate, and we get a
different rate to the one which was passed. This could well be end
result from the rate you would get if you simply did:
clk_set_rate(clk, my_rate);
Let's say that we did augment the interface with a load of clk_round_xxx()
method functions, and made clk_set_rate() error out of the passed rate
is not possible. On the face of it, this looks like a sensible way
forward - but wait! What if we re-read the above with these new
conditions and that race occurs:
rate = clk_round_nearest(clk, my_rate);
/* clk is reparented */
err = clk_set_rate(clk, rate);
Now, err indicates an error. So now we need to audit every driver using
this that they do something like this:
for (try = 0; try 10; try++) {
rate = clk_round_nearest(clk, my_rate);
err = clk_set_rate(clk, rate);
if (!err)
continue;
}
if (err)
dev_err(dev, failed to set clock rate to %lu: %d\n,
my_rate, err);
and this is still racy and unreliable (who says ten loops is enough?)
You could introduce a per-clock lock around this, but that also gets
messy, and makes the API harder to use (and more error-prone for the
driver author to use.)
What /may/ be a better idea is to pass a function pointer to a new
clk_round_rate() or clk_set_rate() pair of functions - both accept
the same function pointer. This function pointer points at the
rounding method that is desired, which would be called by the
underlying implementation with the appropriate locks.
Yes, it still doesn't guarantee that this sequence:
rate = clk_round_new_rate(clk, my_rate, clk_round_nearest);
clk_set_new_rate(clk, my_rate, clk_round_nearest);
will end up with the same clock, but it will help ensure that there
is a consistent manner in which both of these functions operate, and
that there won't be any doubling up of rounding errors caused by
serially calling clk_round_rate followed by clk_set_rate.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
Russell King rmk+ker...@arm.linux.org.uk writes: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than the mov pc, lr instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). For ARMv5 - XScale, and more specificaly the mioa701_bootresume.S path (suspend to RAM) : Tested-by: Robert Jarzmik robert.jarz...@free.fr Cheers. -- 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
FIX ME in function ocpi_enable in file arch/arm/mach-omap1/opci.c
Hey Tony and Russel , There is a FIX ME message in this function of the file stated in my subject line. I was wondering what locking is needed here due to not having experience with omap subsystem(s). Cheers Nick -- 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/RESEND 0/9] drm: tilcdc driver fixes
On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: [snip] Otherwise I think this is a good and useful patch series. It that a Tested-by tag? :) Thanks! Guido Darren The first 7 patches are bug fixes which and should probably be applied in the stable trees. The last two are clean-ups. Resending this since I got no replies. Guido Martínez (9): drm/i2c: tda998x: move drm_i2c_encoder_destroy call drm/tilcdc: panel: fix dangling sysfs connector node drm/tilcdc: slave: fix dangling sysfs connector node drm/tilcdc: tfp410: fix dangling sysfs connector node drm/tilcdc: panel: fix leak when unloading the module drm/tilcdc: fix release order on exit drm/tilcdc: fix double kfree drm/tilcdc: remove submodule destroy calls drm/tilcdc: replace late_initcall with module_init drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/tilcdc/Module.symvers | 0 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 + drivers/gpu/drm/tilcdc/tilcdc_drv.h| 1 - drivers/gpu/drm/tilcdc/tilcdc_panel.c | 39 +- drivers/gpu/drm/tilcdc/tilcdc_slave.c | 27 +-- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++--- 7 files changed, 59 insertions(+), 60 deletions(-) create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers -- Guido Martínez, VanguardiaSur www.vanguardiasur.com.ar -- 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 v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi Pekon,
On Tue, Jul 01, 2014 at 07:01:03AM +, Gupta, Pekon wrote:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
I don't think we need above patch.
Helper macro for_each_available_child_of_node internally takes care
of skipping nodes with status=disabled.
$KERNEL/include/linux/of.h
#define for_each_available_child_of_node(parent, child) \
for (child = of_get_next_available_child(parent, NULL); child != NULL; \
child = of_get_next_available_child(parent, child))
$KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
...
if (!__of_device_is_available(next))
continue;
...
Yes, that's why I suggest using that macro. It's not currently used
in gpmc.c and my patch changes the 'for_each_child_of_node' to a
'for_each_available_child_of_node'. Or am I missing something?
Regards,
--
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
--
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/RESEND 0/9] drm: tilcdc driver fixes
Hi Dave, did you take a look at this patchset? I foolishly missed adding you on the To: header, so apologies for that in advance. Thanks, On Tue, Jun 17, 2014 at 11:17:02AM -0300, Guido Martínez wrote: The tilcdc driver could be compiled as a module, but was severely broken and could not be used as such. This patchset attempts to fix the issues preventing a proper load/unload of the module. Issues included dangling sysfs nodes, dangling devices, memory leaks and a double kfree. It now seems to be working ok. We have tested this by loading and unloading the driver repeteadly, with both panel and slave connectors and found no flaws. There is still one warning left on tilcdc_crtc_destroy, caused by destroying the connector while still in an ON status. We don't know why this happens or why it's an issue, so we did not fix it. The first 7 patches are bug fixes which and should probably be applied in the stable trees. The last two are clean-ups. Resending this since I got no replies. Guido Martínez (9): drm/i2c: tda998x: move drm_i2c_encoder_destroy call drm/tilcdc: panel: fix dangling sysfs connector node drm/tilcdc: slave: fix dangling sysfs connector node drm/tilcdc: tfp410: fix dangling sysfs connector node drm/tilcdc: panel: fix leak when unloading the module drm/tilcdc: fix release order on exit drm/tilcdc: fix double kfree drm/tilcdc: remove submodule destroy calls drm/tilcdc: replace late_initcall with module_init drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/tilcdc/Module.symvers | 0 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 + drivers/gpu/drm/tilcdc/tilcdc_drv.h| 1 - drivers/gpu/drm/tilcdc/tilcdc_panel.c | 39 +- drivers/gpu/drm/tilcdc/tilcdc_slave.c | 27 +-- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++--- 7 files changed, 59 insertions(+), 60 deletions(-) create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers -- 2.0.0 -- Guido Martínez, VanguardiaSur www.vanguardiasur.com.ar -- 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/RESEND 0/9] drm: tilcdc driver fixes
On 07/01/2014 06:39 PM, Guido Martínez wrote: On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: [snip] Otherwise I think this is a good and useful patch series. It that a Tested-by tag? :) Sure - I would prefer that the WARN_ON was silenced when the tilcdc module is removed, but the series adds improvements over what is there now. I have tested it across a few variants of AM335x boards and attached display hardware in both module form and built-in to the kernel, therefore: Tested-by: Darren Etheridge detheri...@ti.com Thanks! Guido Darren The first 7 patches are bug fixes which and should probably be applied in the stable trees. The last two are clean-ups. Resending this since I got no replies. Guido Martínez (9): drm/i2c: tda998x: move drm_i2c_encoder_destroy call drm/tilcdc: panel: fix dangling sysfs connector node drm/tilcdc: slave: fix dangling sysfs connector node drm/tilcdc: tfp410: fix dangling sysfs connector node drm/tilcdc: panel: fix leak when unloading the module drm/tilcdc: fix release order on exit drm/tilcdc: fix double kfree drm/tilcdc: remove submodule destroy calls drm/tilcdc: replace late_initcall with module_init drivers/gpu/drm/i2c/tda998x_drv.c | 2 +- drivers/gpu/drm/tilcdc/Module.symvers | 0 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 + drivers/gpu/drm/tilcdc/tilcdc_drv.h| 1 - drivers/gpu/drm/tilcdc/tilcdc_panel.c | 39 +- drivers/gpu/drm/tilcdc/tilcdc_slave.c | 27 +-- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++--- 7 files changed, 59 insertions(+), 60 deletions(-) create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers -- 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: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
On Tue, 1 Jul 2014, Will Deacon wrote: Hi Mans, On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: As you point out, bx lr /may/ be treated specially (I've actually been Most, if not all, Cortex-A cores do this according the public TRMs. They also do the same thing for mov pc, lr so there will probably be no performance gain from this change. It's still a good idea though, since we don't know what future cores will do. Funnily enough, that's not actually true (and is more or less what prompted this patch after discussion with Russell). There are cores out there that don't predict mov pc, lr at all (let alone do anything with the return stack). discussing this with Will Deacon over the last couple of days, who has also been talking to the hardware people in ARM, and Will is happy with this patch as in its current form.) This is why I've changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. In that case the patch should be fine. Your patch description didn't make it clear that only actual returns were being changed. I'm led to believe that some predictors require lr in order to update the return stack, whilst others don't. That part is all horribly micro-architectural, so the current patch is doing the right thing by sticking to the ARM ARM but enabling us to hook into other registers later on if we choose. May I suggest to have a patch with only the macro definition in it and all this discussion in the commit log please? The usage sites should be done in a separate patch to make it clearer. Nicolas
Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data
Hi, On Fri, Jun 13, 2014 at 07:11:58PM +, Paul Walmsley wrote: Hi Felipe, Tomi, On Fri, 13 Jun 2014, Felipe Balbi wrote: On Fri, Jun 13, 2014 at 11:15:46AM -0500, Felipe Balbi wrote: From: Sathya Prakash M R sath...@ti.com Add DSS hwmod data for AM43xx. Cc: Andrew Morton a...@linux-foundation.org Acked-by: Rajendra Nayak rna...@ti.com Signed-off-by: Sathya Prakash M R sath...@ti.com Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- Note that this patch was originally send on May 9th [1], changes were requested and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged maintainer again and go no response. Without this patch, we cannot get display working on any AM437x devices. [1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2 [2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2 [3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++ arch/arm/mach-omap2/prcm43xx.h | 1 + 2 files changed, 99 insertions(+) Sorry for the delay on this. Have been corresponding with TI management to figure out what to do about patches for AM43xx. I don't have boards or public documentation for these devices, so it's impossible for me to documentation is now available publicly http://www.ti.com/product/AM4379 -- balbi signature.asc Description: Digital signature
[PATCH] spi: omap2-mcspi: Configure hardware when slave driver changes mode
Commit id 2bd16e3e23d9df41592c6b257c59b6860a9cc3ea
(spi: omap2-mcspi: Do not configure the controller
on each transfer unless needed) does its job too
well so omap2_mcspi_setup_transfer() isn't called
even when an SPI slave driver changes 'spi-mode'.
The result is that the mode requested by the SPI
slave driver never takes effect.
Fix this by adding the 'mode' member to the
omap2_mcspi_cs structure which holds the mode
value that the hardware is configured for.
When the SPI slave driver changes 'spi-mode'
it will be different than the value of this new
member and the SPI master driver will know that
the hardware must be reconfigured (by calling
omap2_mcspi_setup_transfer()).
CC: Stefan Sørensen stefan.soren...@spectralink.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/spi/spi-omap2-mcspi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 4dc77df..68441fa 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -149,6 +149,7 @@ struct omap2_mcspi_cs {
void __iomem*base;
unsigned long phys;
int word_len;
+ u16 mode;
struct list_headnode;
/* Context save and restore shadow register */
u32 chconf0, chctrl0;
@@ -926,6 +927,8 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
mcspi_write_chconf0(spi, l);
+ cs-mode = spi-mode;
+
dev_dbg(spi-dev, setup: speed %d, sample %s edge, clk %s\n,
speed_hz,
(spi-mode SPI_CPHA) ? trailing : leading,
@@ -998,6 +1001,7 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return -ENOMEM;
cs-base = mcspi-base + spi-chip_select * 0x14;
cs-phys = mcspi-phys + spi-chip_select * 0x14;
+ cs-mode = 0;
cs-chconf0 = 0;
cs-chctrl0 = 0;
spi-controller_state = cs;
@@ -1079,6 +1083,16 @@ static void omap2_mcspi_work(struct omap2_mcspi *mcspi,
struct spi_message *m)
cs = spi-controller_state;
cd = spi-controller_data;
+ /*
+* The slave driver could have changed spi-mode in which case
+* it will be different from cs-mode (the current hardware setup).
+* If so, set par_override (even though its not a parity issue) so
+* omap2_mcspi_setup_transfer will be called to configure the hardware
+* with the correct mode on the first iteration of the loop below.
+*/
+ if (spi-mode != cs-mode)
+ par_override = 1;
+
omap2_mcspi_set_enable(spi, 0);
list_for_each_entry(t, m-transfers, transfer_list) {
if (t-tx_buf == NULL t-rx_buf == NULL t-len) {
--
1.9.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/RESEND 0/9] drm: tilcdc driver fixes
On 2 July 2014 12:31, Darren Etheridge detheri...@ti.com wrote: On 07/01/2014 06:39 PM, Guido Martínez wrote: On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: [snip] Otherwise I think this is a good and useful patch series. It that a Tested-by tag? :) Sure - I would prefer that the WARN_ON was silenced when the tilcdc module is removed, but the series adds improvements over what is there now. I have tested it across a few variants of AM335x boards and attached display hardware in both module form and built-in to the kernel, therefore: Tested-by: Darren Etheridge detheri...@ti.com Has someone gathered that tags and put these in a git tree by any chance? Dave. -- 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: [RESEND 2/2] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Quoting Peter Ujfalusi (2014-06-29 22:56:55)
Hi Javier,
On 06/27/2014 09:23 PM, Javier Martinez Canillas wrote:
Hello Peter,
On Fri, Jun 27, 2014 at 8:01 AM, Peter Ujfalusi peter.ujfal...@ti.com
wrote:
Palmas class of devices can provide 32K clock(s) to be used by other
devices
on the board. Depending on the actual device the provided clocks can be:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
ti,palmas-clk32kg for clk32kg clock
ti,palmas-clk32kgaudio for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
See the documentation for more details.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Nishanth Menon n...@ti.com
+static unsigned long palmas_clks_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ return 32768;
+}
I see that other clock drivers using a constant rate return 0 if the
clock has not been enabled.
and there are examples when similar fixed clock drivers returns only the clock
value, like clk-max77686. I can not find clear guidelines neither in the
documentation or around the header/c files for this.
Mike, what is the appropriate way of handling the recalc_rate?
You are right that there are no guidelines stating, don't do that, but
please, don't do that ;-)
clk_enable and clk_set_rate are entirely unrelated operations from the
perspective of the Linux clock framework, and mixing these two classes
of operations is a recipe for pain.
So maybe is more correct to have something
like the following?
if (__clk_is_enabled(hw-clk))
return 32768;
else
return 0;
So what happens here if this is gateable clock and later on we call
clk_enable on it? The clocks rate will still be zero since
clk_enable/clk_disable do not touch the rate at all.
Regards,
Mike
Best regards,
Javier
--
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: [RESEND 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
Quoting Peter Ujfalusi (2014-06-26 23:01:09) Hi Mike, This is a resend of the v2 version of the palmas clock driver which seamingly missed the 3.16 merge window. I have added Nishanth's Reviewed-by tag to the patches. Thanks for the resend. Applied to clk-next. Regards, Mike Changes since v1: - binding documentation and driver has been separated based on Nishanth Menon's comment v2 of the series: https://lkml.org/lkml/2014/5/6/323 v1 of the driver can be found: https://lkml.org/lkml/2014/4/3/104 Palmas class of devices can provide 32K clock(s) to be used by other devices on the board. Depending on the actual device the provided clocks can be: CLK32K_KG and CLK32K_KGAUDIO or only one: CLK32K_KG (TPS659039 for example) Use separate compatible flags for the two 32K clock. A system which needs or have only one of the 32k clock from Palmas will need to add node(s) for each clock as separate section in the dts file. The two compatible property is: ti,palmas-clk32kg for clk32kg clock ti,palmas-clk32kgaudio for clk32kgaudio clock Apart from the register control of the clocks - which is done via the clock API there is a posibility to enable the external sleep control. In this way the clock can be enabled/disabled on demand by the user of the clock. Regards, Peter --- Peter Ujfalusi (2): dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks clk: Add driver for Palmas clk32kg and clk32kgaudio clocks .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ drivers/clk/Kconfig| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-palmas.c | 307 + include/dt-bindings/mfd/palmas.h | 18 ++ 5 files changed, 368 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt create mode 100644 drivers/clk/clk-palmas.c create mode 100644 include/dt-bindings/mfd/palmas.h -- 2.0.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 V2 0/6] regulator: palmas: cleanup and fixes
On Monday 30 June 2014 09:27 PM, Nishanth Menon wrote: Hi, Original thread (v1): http://marc.info/?t=14038076654r=1w=2 This series is based on: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git branch: topic/palmas (4c0c9ca Merge remote-tracking branch 'regulator/fix/palmas' into regulator-palmas) This series does a few cleanups to help ensure we dont make typo mistakes and finally provides a fix as attempted by (v1). Basic cpufreq tests performed on OMAP5uEVM, DRA7-evm, DRA72-evm all of which are palmas variants. The patches are also available here: https://github.com/nmenon/linux-2.6-playground/commits/broonie-topic-palmas-fixes For the series: Acked-by: Keerthy j-keer...@ti.com Nishanth Menon (6): regulator: palmas: Squelch sparse warnings regulator: palmas: Rename reg_info to palmas_reg_info regulator: palmas: Simplify code by using pointer to palmas_reg_info regulator: palmas: Rename palmas_regs_info to palmas_generic_regs_info regulator: palmas: Simplify code by not indexing regulator_desc unnecessarily regulator: palmas: Fix SMPS enable/disable/is_enable for tps65917 drivers/regulator/palmas-regulator.c | 344 -- include/linux/mfd/palmas.h |4 +- 2 files changed, 166 insertions(+), 182 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
RE: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape
From: Guido Martínez [mailto:gu...@vanguardiasur.com.ar]
On Tue, Jul 01, 2014 at 07:01:03AM +, Gupta, Pekon wrote:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266966.html
I don't think we need above patch.
Helper macro for_each_available_child_of_node internally takes care
of skipping nodes with status=disabled.
$KERNEL/include/linux/of.h
#define for_each_available_child_of_node(parent, child) \
for (child = of_get_next_available_child(parent, NULL); child != NULL; \
child = of_get_next_available_child(parent, child))
$KERNEL/drivers/of/base.c @@ of_get_next_available_child(...) {
...
if (!__of_device_is_available(next))
continue;
...
Yes, that's why I suggest using that macro. It's not currently used
in gpmc.c and my patch changes the 'for_each_child_of_node' to a
'for_each_available_child_of_node'. Or am I missing something?
Oops my bad. I was probably dreaming, I already had your patch in my tree
before reviewing the code. So please ignore my previous email.
with regards, pekon
--
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: mach-omap2: gpmc: ignore non-available nodes
From: Ezequiel García [mailto:ezequ...@vanguardiasur.com.ar] On 26 Jun 12:02 PM, Guido Martínez wrote: Currently, child nodes of the gpmc node are iterated and probed regardless of their 'status' property. This means adding 'status = disabled;' has no effect. This patch changes the iteration to only probe nodes marked as available. Signed-off-by: Guido Martínez gu...@vanguardiasur.com.ar Just a nit: the commit title doesn't match the recent commits. If you run git log on this file, you'll find the pattern should be something like: ARM: OMAP2+: GPMC should only probe enabled devices Other than this, the patch looks correct. Yes, plz keep patch title consistent as in other gpmc.c patches. And thanks for this fix. Tested-by: Pekon Gupta pe...@ti.com with regards, pekon -- 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
