Re: [PATCH 00/17] Add memory mapped support for ti qspi, m25p80 serial flash.
Hi Brian, On Tuesday 26 November 2013 01:04 PM, Sourav Poddar wrote: The patch series aims to add memory mapped support for TI qspi contoller and also add support for the same in serial flash driver(m25p80). These feature was added as a part of the series[1]: The series[1] add support for quad and memory mapped feature in spi and flash driver. Based on Brian Norris suggestion on splitting the quad and memory mapped feature, I had sent a seperate series for quad support which has beed accepted by Brian. The $subject patch series takes care of the memory mapped part. Overview of memory mapped support in qspi: TI qspi controller supports memory mapped read support, switching to which requires register modifications(qspi registers, control module register for DRA, qspi register for am43x). Once switched, the flash data can be available at a soc specific memory mapped address. For operations in normal mode, we need to keep memory mapped disable. Flow of the patch is to keep the memory mapped enable by default in the driver. Whenever Normal spi mode operations are desired, we switch to configuration mode and at the end of it memory mapped is again enabled. There are few function pointers added to fecilitate easy communication between the flash and spi controllers. Major changes in the $subject patch based on discussion in [1]: - Feature has been broken down into small meaningfl patches. - memcpy is done in flash driver and spi framework is bypassed. - configuration of memory mapped spi controller regsiters is done through function calls from flash side. [1]: http://lists.infradead.org/pipermail/linux-mtd/2013-October/049058.html Tested on DRA7 board with spansion S25FL256S flash along with some internal irq crossbar patches. Tested on AM437x epos evm with macronix MX66l51235l flash. Testing done: -Erase the whole flash. -write to the flash -read back the flash - compare the data Sourav Poddar (17): spi/spi.h: Add get_buf/put_buf support in spi master.. spi/spi.h: Add configure from slave support. spi/qspi: parse register by name. spi/qspi: parse control module register. spi/qspi: parse memory map register. spi/qspi: Add support to switc to memory mapped operation. spi/qspi: configure set up register for memory map.. spi/qspi: Add api for get_buf/put_buf. spi/spi.h: Add mem variable in spi master. spi/spi.h: Add mmap flag in spi master. spi/qspi: set mmap flag to true. spi/qspi: convert driver to enable/disable memory mapped.. drivers: mtd: m25p80: Add api to configure master register . drivers: mtd: m25p80: Adapt driver to support memory mapped read. arm: dts: dra7: Add qspi device. arm: dts: am43x-epos: Add qspi device. Documentation: bindings: ti-qspi: update binding information. Documentation/devicetree/bindings/spi/ti_qspi.txt |2 + arch/arm/boot/dts/am4372.dtsi | 12 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 28 + arch/arm/boot/dts/dra7-evm.dts| 32 ++ arch/arm/boot/dts/dra7.dtsi | 13 +++ drivers/mtd/devices/m25p80.c | 30 ++ drivers/spi/spi-ti-qspi.c | 115 - include/linux/spi/spi.h | 16 +++ 8 files changed, 246 insertions(+), 2 deletions(-) Gentle ping on this series on mtd side... -- 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
OMAP3 NAND ECC selection
Hello, on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme (hw) than the rootfs (sw) is there a way to tell the kernel which ECC scheme to use on a per-partition basis? I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) -- 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/1] gpio: twl4030: Fix regression for twl gpio LED output
On 12/04/2013 07:37 PM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [131204 03:35]:
Commit 0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.
This causes USB host probe failures for Beagleboard C4.
[2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv
requests probe deferral
[2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22
[2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to
register regulator: -22
[2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed
with error -22
direction_out/direction_in must return 0 if the operation succeeded.
Uh, OK, sorry that was an unexpected side effect. We still should keep the
return values though instead of just ignoring them.
OK.
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..0999ed1 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -294,13 +294,13 @@ out:
static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
-int ret;
+int ret = 0;
mutex_lock(priv-mutex);
if (offset TWL4030_GPIO_MAX)
-ret = twl4030_set_gpio_direction(offset, 1);
+twl4030_set_gpio_direction(offset, 1);
else
-ret = -EINVAL;
+ret = -EINVAL; /* LED outputs can't be set as input */
if (!ret)
priv-direction = ~BIT(offset);
This looks OK to me.
@@ -354,18 +354,21 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
-int ret = -EINVAL;
Can't you just have:
int ret = 0;
Yes, i'll add that.
mutex_lock(priv-mutex);
if (offset TWL4030_GPIO_MAX)
-ret = twl4030_set_gpio_direction(offset, 0);
+twl4030_set_gpio_direction(offset, 0);
+
+/*
+ * LED gpio's i.e. offset = TWL4030_GPIO_MAX are always output
+ */
priv-direction |= BIT(offset);
mutex_unlock(priv-mutex);
twl_set(chip, offset, value);
-return ret;
+return 0;
}
Then the rest of this change is not needed and we check the return value for
twl4030_set_gpio_direction. Makes sense to keep the comment there though.
OK. Will post v2.
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
[PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output
Commit 0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.
This causes USB host probe failures for Beagleboard C4.
[2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests
probe deferral
[2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22
[2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register
regulator: -22
[2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed with
error -22
direction_out/direction_in must return 0 if the operation succeeded.
Also, don't update direction flag and output data if
twl4030_set_gpio_direction()
failed inside twl_direction_out();
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/gpio/gpio-twl4030.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..f999689 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -300,7 +300,7 @@ static int twl_direction_in(struct gpio_chip *chip,
unsigned offset)
if (offset TWL4030_GPIO_MAX)
ret = twl4030_set_gpio_direction(offset, 1);
else
- ret = -EINVAL;
+ ret = -EINVAL; /* LED outputs can't be set as input */
if (!ret)
priv-direction = ~BIT(offset);
@@ -354,11 +354,20 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
- int ret = -EINVAL;
+ int ret = 0;
mutex_lock(priv-mutex);
- if (offset TWL4030_GPIO_MAX)
+ if (offset TWL4030_GPIO_MAX) {
ret = twl4030_set_gpio_direction(offset, 0);
+ if (ret) {
+ mutex_unlock(priv-mutex);
+ return ret;
+ }
+ }
+
+ /*
+* LED gpios i.e. offset = TWL4030_GPIO_MAX are always output
+*/
priv-direction |= BIT(offset);
mutex_unlock(priv-mutex);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected
On 12/04/2013 07:07 PM, Nishanth Menon wrote:
On 18:14-20131204, Joel Fernandes wrote:
On 12/04/2013 05:03 PM, Nishanth Menon wrote:
On 12/04/2013 02:08 AM, Joel Fernandes wrote:
On 12/04/2013 07:09 AM, Nishanth Menon wrote:
Due to the cross dependencies between hwmod for automanaged device
information for OMAP and dts node definitions, we can run into scenarios
where the dts node is defined, however it's hwmod entry is yet to be
added. In these cases:
a) omap_device does not register a pm_domain (since it cannot find
hwmod entry).
b) driver does not know about (a), does a pm_runtime_get_sync which
never fails
c) It then tries to do some operation on the device (such as read the
revision register (as part of probe) without clock or adequate OMAP
generic PM operation performed for enabling the module.
This causes a crash such as that reported in:
https://bugzilla.kernel.org/show_bug.cgi?id=66441
When 'ti,hwmod' is provided in dt node, it is expected that the device
will not function without the OMAP's power automanagement. Hence, when
we hit a fail condition (due to hwmod entries not present or other
similar scenario), fail at pm_domain level due to lack of data, provide
enough information for it to be fixed, however, it allows for the driver
to take appropriate measures to prevent crash.
Reported-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap_device.c | 24
arch/arm/mach-omap2/omap_device.h |1 +
2 files changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 53f0735..e0a398c 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -183,6 +183,10 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
odbfd_exit1:
kfree(hwmods);
odbfd_exit:
+/* if data/we are at fault.. load up a fail handler */
+if (ret)
+pdev-dev.pm_domain = omap_device_fail_pm_domain;
+
return ret;
}
Just wondering, can't we just print the warning here instead of
registering new
pm_domain callbacks?
I suggest you might want to read the commit message again.. but lets try
once
again:
I know what your patch does and what the problem you're trying to solve is..
Was
just trying to see if there's a better way of doing what you're trying to
do..
Thanks for clarifying.
b) driver does not know about (a), does a pm_runtime_get_sync which
never fails
A device node stated it will have hwmod to adequately control it, but in
reality, as in this case, it does not. how does printing a warning alone
help
the driver which is not aware of these? The driver's attempt at
pm_runtime_sync
should fail, as that is what ti,hwmod property controls.
Why not do the following?
Assign pm_domain as omap_device_pm_domain always regardless of error or not.
Then in the _od_runtime_resume, check if the od or hwmods exists. If not,
print
the warning. That way you don't need to register additional special callbacks
just to print a warning and will prolly be fewer LoC fwiw.
That may be harder to do and may require additional checks in
omap_device_enable
etc, not sure. In that case, your approach is certainly the next best way.
Just
thought its worth looking into :)
fair enough, The moment we use the generic omap_device_pm_domain, the
remaining code which assumes od will be valid will need checking.. (so,
we got to do that for all functions where usage is present - fine, that
can be done too)[1] - and yes, it will take care of the pm_runtime handling
However, lets look at the side effect, omap_device_pm_domain also
registers generic suspend_noirq and resume_noirq, and _od_suspend_noirq will
also fail - as a result device will fail to even attempt to suspend.
That IMHO, is a wrong behavior, So, that explains why we'd need a
omap_device_fail_pm_domain. Keeps the error handling completely
seperated from regular code.
Sorry for the late reply due to travel. Ok, in that case then your patch is OK
method to fix it.
If required for FWIW,
Acked-by: Joel Fernandes jo...@ti.com
regards,
-Joel
[1]
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 53f0735..029f076 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -173,7 +173,6 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
r-name = dev_name(pdev-dev);
}
- pdev-dev.pm_domain = omap_device_pm_domain;
if (device_active) {
omap_device_enable(pdev);
@@ -183,6 +182,7 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
odbfd_exit1:
kfree(hwmods);
odbfd_exit:
+ pdev-dev.pm_domain = omap_device_pm_domain;
return ret;
}
@@ -267,6 +267,10 @@
Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
On 2013-12-04 18:01, Sebastian Reichel wrote: Hi, On Wed, Dec 04, 2013 at 02:28:27PM +0200, Tomi Valkeinen wrote: Here's a new version for DT support to OMAP Display Subsystem. See http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the previous version, which contains thoughts about the related problems. The major change in this version is the use of V4L2 and CDF style port/endpoint style in the DT data. However, note that even if the DT data contains proper port endpoint data, the drivers only use the first endpoint. This is to simplify the patches, as adding full support for the ports and endpoints to the drivers will be a big task. This approach still works with more or less all the boards, as the only cases where the simpler model is an issue are the boards with multiple display devices connected to a single output. Laurent, I'd appreciate if you could have a look at the .dts changes, to see if there's anything that's clearly not CDF compatible. The patches can also be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt Will this be ready for 3.14? Depending on that I would handle That is my hope. We have been missing DSS DT bindings for too long, and maintaining and adding new mixed DT/non-DT panels, as done for omap4 now, is just a big headache. The bindings in my series are probably not perfect, but I believe they should be fine enough. I didn't get any NACKs for the previous versions of this series, and the only reason I haven't been pushing these to mainline is that I haven't been satisfied with the bindings. Laurent promised to have a look at the bindings to see if he notices anything that would conflict with Common Display Framework bindings. If he's ok with the bindings, I think we can decide next week if these will be merged for 3.14. omapdss support for the N900 differently. If this code gets merged into 3.14 I will update the N900 patches [0] accordingly. Otherwise I would suggest to take the N900 patches as is for 3.14 and I will take care of adding the omapdss DT support to the panel (and the N900.dts) separately. I really would not like to add any more hacks for DSS. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP3 NAND ECC selection
Hi Peter, 2013/12/5 Peter Meerwald pme...@pmeerw.net: Hello, on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme (hw) than the rootfs (sw) There is some discussion around this, please take a look at this thread, http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html is there a way to tell the kernel which ECC scheme to use on a per-partition basis? At this moment this is not possible. I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary Hope it helps you. Regards, Enric thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Add more device nodes for am43x-epos-evm
On Wednesday 27 November 2013 01:00 PM, Sourav Poddar wrote: The patch series adds support for enabling pwm backlight, i2c2, spi and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) [1]: https://patchwork.kernel.org/patch/3009541/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this temporary patch[2]. [2]: http://www.spinics.net/lists/arm-kernel/msg288215.html Darren Etheridge (1): pinctrl: am43xx: dt-bindings: add MUX_MODE8 Sourav Poddar (4): arm: dts: am4372: Add pwm-cellsproperty for ecap device. arm: dts: am43x-epos-evm: Add I2C data. arm: dts: am43x-epos-evm: Add SPI data. ARM: dts: am43x-epos-evm: Add pwm backlight support. arch/arm/boot/dts/am4372.dtsi|9 + arch/arm/boot/dts/am43x-epos-evm.dts | 67 ++ include/dt-bindings/pinctrl/am43xx.h |1 + 3 files changed, 77 insertions(+), 0 deletions(-) gentle ping on this.. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Add more device nodes for am43x gp evm.
Hi Benoit, On Wednesday 27 November 2013 01:01 PM, Sourav Poddar wrote: The patch series adds support for enabling gpio, pwm backlight and matrix gpio keys on am43x-gp-evm. Done on top of 3.13-rc1 + tero clock series(1) + Afzal's basic gp support(2). [1]: https://patchwork.kernel.org/patch/3009541/ [2]: https://patchwork.kernel.org/patch/3171761/ Tested on am43x-gp-evm. There is a some bug while using regulators through backlight driver on 3.13-rc1. So, tested pwm part with this patch[3]. [3]: http://www.spinics.net/lists/arm-kernel/msg288215.html Sourav Poddar (3): arm: dts: am437x-gp-evm: Enable gpio. ARM: dts: am43x-gp-evm: Add matrix gpio keys. ARM: dts: am437x-gp-evm: Add pwm backlight support. arch/arm/boot/dts/am437x-gp-evm.dts | 53 +++ 1 files changed, 53 insertions(+), 0 deletions(-) Gentle pIng on this. -- 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: OMAP3 NAND ECC selection
Hi Peter, On 12/05/2013 10:47 AM, Enric Balletbo Serra wrote: 2013/12/5 Peter Meerwald pme...@pmeerw.net: snip I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 Best regards Andreas Bießmann signature.asc Description: OpenPGP digital signature
[Bug] am33xx: Basic suspend resume support: Doesn't resume
Hi, I'm having here a custom am335x board with DDR3 equipped trying to setup suspend/resume support. I have tested this with the ancient TI-PSP-3.2 Kernel and current 3.13-rc plus some pm patches. Problem: After suspending the device, it doesn't resume (freeze): echo mem /sys/power/state [ 103.020845] PM: Syncing filesystems ... done. [ 103.055549] Freezing user space processes ... (elapsed 0.003 seconds) done. [ 103.066696] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 103.077506] PM: Sending message for entering DeepSleep mode [ 103.099896] PM: suspend of devices complete after 11.951 msecs [ 103.110894] PM: late suspend of devices complete after 4.659 msecs [ 103.122599] PM: noirq suspend of devices complete after 5.032 msecs As a wakeup source I'm currently using gpio0_12. Triggering the reset button (am335x-pin: WARMRSTn) in suspend-mode has no effect, which is fine. But after changing the signal on the wakeup source (here gpio0_12), triggering a reset works fine again. So it seems to me that somewhere in the wakeup-process is a bug. Could this be related to DDR3? Apart from that, this custom board here is pretty similar to the ti-evm board wich works fine. In oder to test, I've shrunken the kernel to minimal driver support to sort out as much as possible segfaults in resume functions. With a view to be able to debug this further, I just ordered an openocd jtag adapter. Any comments, ideas, tips, ..? Thanks -- Christoph -- 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] crypto: omap-sham - Only release DMA channel if successfully requested
On Tue, Nov 12, 2013 at 01:12:27PM -0700, Mark A. Greer wrote: In omap_sham_probe() and omap_sham_remove(), 'dd-dma_lch' is released without checking to see if it was successfully requested or not. This is a bug and was identified and reported by Dan Carpenter here: http://www.spinics.net/lists/devicetree/msg11023.html Add code to only release 'dd-dma_lch' when its not NULL (that is, when it was successfully requested). Reported-by: Dan Carpenter dan.carpen...@oracle.com CC: Joel Fernandes jo...@ti.com Signed-off-by: Mark A. Greer mgr...@animalcreek.com Patch applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] crypto: omap-aes: add error check for pm_runtime_get_sync
On Tue, Dec 03, 2013 at 07:43:13PM -0600, Nishanth Menon wrote: The AES driver currently assumes that pm_runtime_get_sync will always succeed, which may not always be true, so add error handling for the same. This scenario was reported in the following bug: place. https://bugzilla.kernel.org/show_bug.cgi?id=66441 Reported-by: Tobias Jakobi tjak...@math.uni-bielefeld.de Signed-off-by: Nishanth Menon n...@ti.com Patch applied. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 6/8] ARM: dts: add pbias-supply
On Thursday 21 November 2013 10:33 PM, Tony Lindgren wrote:
* Balaji T K balaj...@ti.com [131121 06:21]:
Add pbias-supply to mmc1/sd card.
...
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -261,6 +261,7 @@
mmc1 {
status = okay;
vmmc-supply = ldo1_reg;
+ pbias-supply = pbias_regulator;
bus-width = 4;
};
You may not need to patch this in at all. I think the PBIAS is there
only for the first slot and it's hardwired so it's always there. If
that's the case, then you can just always request it. Or use the
compatible flag if needed.
pbias is not applicable for mmc1 on am33xx and is applicable for
only for OMAP2-OMAP5, so I can add pbias-supply to omapx.dtsi files
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: [RFC PATCH v3 1/8] mmc: omap_hsmmc: use devm_regulator API
On Thursday 21 November 2013 08:38 PM, Ulf Hansson wrote:
On 21 November 2013 15:20, Balaji T K balaj...@ti.com wrote:
Use devm_regulator API, while at it use
devm_regulator_get_optional for optional vmmc_aux supply
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index dbd32ad..1eb4350 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -316,7 +316,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
struct regulator *reg;
int ocr_value = 0;
- reg = regulator_get(host-dev, vmmc);
+ reg = devm_regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_err(host-dev, vmmc regulator missing\n);
return PTR_ERR(reg);
@@ -336,7 +336,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
}
/* Allow an aux regulator */
- reg = regulator_get(host-dev, vmmc_aux);
+ reg = devm_regulator_get_optional(host-dev, vmmc_aux);
host-vcc_aux = IS_ERR(reg) ? NULL : reg;
/* For eMMC do not power off when not in sleep state */
@@ -366,8 +366,6 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
static void omap_hsmmc_reg_put(struct omap_hsmmc_host *host)
{
- regulator_put(host-vcc);
- regulator_put(host-vcc_aux);
mmc_slot(host).set_power = NULL;
}
While you are touching this code I would suggest to convert to
mmc_regulator_get_supply instead. That mean the vmmc_aux change name
to vqmmc though, so you need to adapt for this as well then.
Hi Ulf,
Thanks for the comments, I will address it on separate series.
Thanks and Regards,
Balaji T K
--
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: OMAP3 NAND ECC selection
I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 pretty much what I have been looking for, thanks! p. -- Peter Meerwald +43-664-218 (mobile) -- 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 1/1] gpio: twl4030: Fix regression for twl gpio LED output
* Roger Quadros rog...@ti.com [131205 01:24]:
Commit 0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.
This causes USB host probe failures for Beagleboard C4.
[2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv
requests probe deferral
[2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22
[2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register
regulator: -22
[2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed
with error -22
direction_out/direction_in must return 0 if the operation succeeded.
Also, don't update direction flag and output data if
twl4030_set_gpio_direction()
failed inside twl_direction_out();
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Linus, commit 0b2aa8be is in mainline now, so feel free to pick this one
up if it looks OK to you. This should be also Cc stable as 0b2aa8be has
that.
Regards,
Tony
---
drivers/gpio/gpio-twl4030.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..f999689 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -300,7 +300,7 @@ static int twl_direction_in(struct gpio_chip *chip,
unsigned offset)
if (offset TWL4030_GPIO_MAX)
ret = twl4030_set_gpio_direction(offset, 1);
else
- ret = -EINVAL;
+ ret = -EINVAL; /* LED outputs can't be set as input */
if (!ret)
priv-direction = ~BIT(offset);
@@ -354,11 +354,20 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
- int ret = -EINVAL;
+ int ret = 0;
mutex_lock(priv-mutex);
- if (offset TWL4030_GPIO_MAX)
+ if (offset TWL4030_GPIO_MAX) {
ret = twl4030_set_gpio_direction(offset, 0);
+ if (ret) {
+ mutex_unlock(priv-mutex);
+ return ret;
+ }
+ }
+
+ /*
+ * LED gpios i.e. offset = TWL4030_GPIO_MAX are always output
+ */
priv-direction |= BIT(offset);
mutex_unlock(priv-mutex);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
* Tomi Valkeinen tomi.valkei...@ti.com [131204 04:31]:
Description missing.. But other than that can you please check that
the latest patch I posted in thread [PATCH] ARM: OMAP2+: Fix populating
the hwmod data from device works with this?
The test to do is to remove the related reg, interrupt and dma entries
from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
from DT properly.
I don't know if it makes sense to have them as children of dss_core, they
really all seem to be completely independent devices?
BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
property and do the lookup based on the compatible property instead ;)
So from that point of view we need to get the device mapping right in
the .dtsi files, and don't want to start mixing up separate devices into
single .dtsi entry.
Regards,
Tony
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f3a0c26ed0c2..6fc163201cbd 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -588,5 +588,48 @@
num-eps = 16;
ram-bits = 12;
};
+
+ dss@4805 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4805 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@48050400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x48050400 0x400;
+ interrupts = 25;
+ ti,hwmods = dss_dispc;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap3-dpi;
+ };
+
+ sdi: encoder@1 {
+ compatible = ti,omap3-sdi;
+ };
+
+ dsi: encoder@4804fc00 {
+ compatible = ti,omap3-dsi;
+ reg = 0x4804fc00 0x400;
+ interrupts = 25;
+ ti,hwmods = dss_dsi1;
+ };
+
+ rfbi: encoder@48050800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x48050800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ venc: encoder@48050c00 {
+ compatible = ti,omap3-venc;
+ reg = 0x48050c00 0x100;
+ ti,hwmods = dss_venc;
+ };
+ };
};
};
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: enable EHCI by default
* Thomas Pedersen tho...@cozybit.com [131204 17:09]: This is needed for the pandaboard (ES) kernel to detect the ethernet device during boot. Useful for NFS root etc. Thanks for the patch, just to clarify why we have not been able to apply this is EHCI blocks deeper PM states for at least omap3 currently. And this means the PM related tests won't run properly out of the box.. Roger has been working to get EHCI working properly with PM, and the recent interrupts-extended binding and the addition of wake-up interrupts to pinctrl-single.c should allow us to do that soon. Maybe Roger can summarize what else might still be missing? Regards, Tony Signed-off-by: Thomas Pedersen tho...@cozybit.com --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index bfa80a1..a236a2b 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -212,6 +212,7 @@ CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_MON=y -- 1.8.4.3 -- 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: OMAP3 NAND ECC selection
* Peter Meerwald pme...@pmeerw.net [131205 08:13]: I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 pretty much what I have been looking for, thanks! Hmm well both methods should work, but is there anything stopping us merging the module param patch to the mainline tree? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix populating the hwmod data from device tree
* Tony Lindgren t...@atomide.com [131121 12:49]:
* Tony Lindgren t...@atomide.com [131120 17:46]:
* Tony Lindgren t...@atomide.com [131120 16:06]:
They at least had interrupts listed looking at commit 3b9b10. Probably
the thing to do for now is to revert those changes, and see if we can
just remove the L3 entries from the .dtsi files.
Actually the patch I posted should be able to handle also the
ti,hwmods = l3_main_1, l3_main_2, l3_main_3 property in omap4.dtsi,
but we're not currently parsing that as we only look at the children
and not the properties of the OCP bus. Should be fixable, will take a look
tomorrow if this approach makes sense to you.
OK this one seems to do the right thing for me.
No comments? I'll queue the patch below to the fixes, please yell
if you see any issues with that.
Tony
From: Tony Lindgren t...@atomide.com
Date: Wed, 20 Nov 2013 15:46:51 -0800
Subject: [PATCH] ARM: OMAP2+: Fix overwriting hwmod data with data from
device tree
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We have some device tree properties where the ti,hwmod have multiple
values:
am33xx.dtsi: ti,hwmods = tpcc, tptc0, tptc1, tptc2;
am4372.dtsi: ti,hwmods = tpcc, tptc0, tptc1, tptc2;
dra7.dtsi:ti,hwmods = l3_main_1, l3_main_2;
omap3.dtsi: ti,hwmods = mcbsp2, mcbsp2_sidetone;
omap3.dtsi: ti,hwmods = mcbsp3, mcbsp3_sidetone;
omap4.dtsi: ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
omap5.dtsi: ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
That's not correct way of doing things in this case because these are
separate devices with their own address space, interrupts, SYSCONFIG
registers and can set their PM states independently.
So they should all be fixed up to be separate devices in the .dts files.
We also have the related data removed for at least omap4 in commit
3b9b10151c68 (ARM: OMAP4: hwmod data: Clean up the data file), so
that data is wrongly initialized as null data.
So we need to fix two bugs:
1. We are only checking the first entry of the ti,hwmods property
This means that we're only initializing the first hwmods entry
instead of the ones listed in the ti,hwmods property.
2. We are only checking the child nodes, not the nodes themselves
This means that anything listed at OCP level is currently just
ignored and unitialized and at least the omap4 case, with the
legacy data missing from the hwmod.
Fix both of the issues by using an index to the ti,hwmods property
and changing the hwmod lookup function to also check the current node
for ti,hwmods property instead of just the children.
While at it, let's also add some warnings for the bad data so it's
easier to fix.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index e3f0eca..ee655da 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2326,38 +2326,80 @@ static int _shutdown(struct omap_hwmod *oh)
return 0;
}
+static int of_dev_find_hwmod(struct device_node *np,
+ struct omap_hwmod *oh)
+{
+ int count, i, res;
+ const char *p;
+
+ count = of_property_count_strings(np, ti,hwmods);
+ if (count 1)
+ return -ENODEV;
+
+ for (i = 0; i count; i++) {
+ res = of_property_read_string_index(np, ti,hwmods,
+ i, p);
+ if (res)
+ continue;
+ if (!strcmp(p, oh-name)) {
+ pr_debug(omap_hwmod: dt %s[%i] uses hwmod %s\n,
+ np-name, i, oh-name);
+ return i;
+ }
+ }
+
+ return -ENODEV;
+}
+
/**
* of_dev_hwmod_lookup - look up needed hwmod from dt blob
* @np: struct device_node *
* @oh: struct omap_hwmod *
+ * @index: index of the entry found
+ * @found: struct device_node * found or NULL
*
* Parse the dt blob and find out needed hwmod. Recursive function is
* implemented to take care hierarchical dt blob parsing.
- * Return: The device node on success or NULL on failure.
+ * Return: Returns 0 on success, -ENODEV when not found.
*/
-static struct device_node *of_dev_hwmod_lookup(struct device_node *np,
- struct omap_hwmod *oh)
+static int of_dev_hwmod_lookup(struct device_node *np,
+struct omap_hwmod *oh,
+int *index,
+struct device_node **found)
{
- struct device_node *np0 = NULL, *np1 = NULL;
- const char *p;
+ struct device_node *np0 = NULL;
+ int res;
+
+ res = of_dev_find_hwmod(np, oh);
+ if (res = 0) {
+ *found = np;
Re: OMAP3 NAND ECC selection
[adding Pekon and Thomas as cc] On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren t...@atomide.com wrote: * Peter Meerwald pme...@pmeerw.net [131205 08:13]: I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 pretty much what I have been looking for, thanks! Hmm well both methods should work, but is there anything stopping us merging the module param patch to the mainline tree? Hi Tony, In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. In fact the data-sheet for the NAND device used on the IGEPv2 board says: Minimum required ECC 4-bit ECC per 528 bytes || Minimum required ECC for block 0 1-bit ECC per 528 byte so I don't think we should impose a software limitation by having a global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the ti,nand-ecc-opt. I'll see if I can get some free time to try to implement that. Pekon does not agree with this solution though [2] Thanks a lot and best regards, Javier [0]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99008.html [2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136 -- 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
[HACK] remotely powering on a OMAP5 uEVM over the debug port
Here's a tiny hack I came up with to remote-power on an OMAP5 uEVM. I
have mine in an unattended setup where I can cycle power, but it still
needs a power button press to start.
Luckily two GPIO lines on the secondary FTDI channel are routed to the same
buttons, so it can be done via software. It requires your board to have U37
populated though, so make sure you have it (mine did already).
The below little hack uses libmpsse, available at
https://code.google.com/p/libmpsse/.
To use it, give it the path of the FTDI device. I.e. on my system the uEVM is
at 3-1.3.3. Check dmesg and lsusb (it's bus number + path).
Anyway, I figured this could be useful for others as well, so I'm posting just
for that purpose. No warranties, don't come to me if you break your board with
this, etc, etc.
This pulses the power button for 1 second (GPIOH5). If you want to pulse
the reset instead, use GPIOH6.
#include stdlib.h
#include stdio.h
#include unistd.h
#include usb.h
#include mpsse.h
void usage(char *p)
{
printf(Usage: %s busnr-devpath\n, p);
}
void fill_busdev(char *usbpath, int *bus, int *dev)
{
char udir[PATH_MAX+1];
FILE *fp;
sprintf(udir, /sys/bus/usb/devices/%s/busnum, usbpath);
fp = fopen(udir, r);
if (!fp) {
printf(can't open %s to find usb info\n, udir);
exit(1);
}
fscanf(fp, %d, bus);
fclose(fp);
sprintf(udir, /sys/bus/usb/devices/%s/devnum, usbpath);
fp = fopen(udir, r);
if (!fp) {
printf(can't open %s to find usb info\n, udir);
exit(1);
}
fscanf(fp, %d, dev);
fclose(fp);
}
int main(int argc, char **argv)
{
struct mpsse_context *io = NULL;
int i = 0;
int bus, dev;
if (argc 1) {
usage(argv[0]);
exit(1);
}
fill_busdev(argv[1], bus, dev);
while (1) {
struct usb_device *ud;
io = OpenIndex(0x0403, 0x6010, GPIO, 0, 0, 2, NULL, NULL, i++);
if (!io || !io-open) {
printf(Failed to open device %s\n, argv[1]);
exit(1);
}
ud = usb_device(io-ftdi.usb_dev);
if (ud-devnum == dev ud-bus-location == bus) {
printf(found: %s/%s %d\n, ud-bus-dirname,
ud-filename, ud-bus-location);
break;
} else {
printf(skipped: %s/%s %d\n, ud-bus-dirname,
ud-filename, ud-bus-location);
}
Close(io);
}
/* Default is high */
PinHigh(io, GPIOH5);
PinHigh(io, GPIOH6);
sleep(1);
/* Pulse power */
PinLow(io, GPIOH5);
sleep(1);
PinHigh(io, GPIOH5);
Close(io);
exit(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: [HACK] remotely powering on a OMAP5 uEVM over the debug port
* Olof Johansson o...@lixom.net [131205 10:00]: Here's a tiny hack I came up with to remote-power on an OMAP5 uEVM. I have mine in an unattended setup where I can cycle power, but it still needs a power button press to start. Great, thanks a lot, just what I need :) 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 0/7] mmc: omap: Fixes, cleanup and add ERASE capability
* Jarkko Nikula jarkko.nik...@bitmer.com [131204 11:15]: Hi I've sent these patches earlier to linux-mmc list. This time set is one patch smaller since commit 31ee9181eb92 (mmc: omap: Fix DMA configuration to not rely on device id) does practically same what one of my patch did. Patch 1 is an obvious fix. 2-4 are preparing for 5 which also should fix the error introduced by 31ee9181eb92: http://www.spinics.net/lists/linux-omap/msg100790.html Patch 6 continue cleanup and 7 adds the ERASE capability to the driver so one could utilize discards with mkfs, mount option or with the fstrim. Set goes on top of v3.13-rc2-208-g8ecffd791448. Great they look good to me: Acked-by: Tony Lindgren t...@atomide.com Jarkko Nikula (7): mmc: omap: Fix NULL pointer dereference due uninitialized cover_tasklet mmc: omap: Convert to devm_kzalloc mmc: omap: Remove duplicate host-irq assignment mmc: omap: Remove mem_res field from struct mmc_omap_host mmc: omap: Convert to devm_ioremap_resource mmc: omap: Remove always set use_dma flag from struct mmc_omap_host mmc: omap: Add erase capability drivers/mmc/host/omap.c | 93 +++-- 1 file changed, 36 insertions(+), 57 deletions(-) -- 1.8.4.3 -- 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: OMAP3 NAND ECC selection
Hi Javier, (CCing Brian: What do you think about this?) On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote: On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren t...@atomide.com wrote: In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. [..] global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the ti,nand-ecc-opt. I'll see if I can get some free time to try to implement that. AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. While there are some per MTD device (which model each partition), the ECC mode is present in the, nand_chip structure. My understanding is that the NAND core hasn't been designed for this use case, and thus some major re-work is needed to accomplish it. Therefore, it's a much short-term solution to implement the OMAP module parameter to fix the issue. Of course, feel free to prove me wrong :-) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.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: DTS: omap4-sdp: Add regulator for LCD backlight (pwm-backlight)
* Sourav Poddar sourav.pod...@ti.com [131128 02:10]: On Thursday 28 November 2013 02:58 PM, Peter Ujfalusi wrote: Since in DT booted kernel dummy regulators are no longer supported we need to provide valid phandle for the regulator needed by the backlight. On the board VBAT is used to power the LCD backlight(s). Signed-off-by: Peter Ujfalusipeter.ujfal...@ti.com --- Hi, This patch is needed for 3.13 to get the LCD backlight to work again. Is this usage of power supply a mandatory requirement? There is a thread which discusses this issue[1]: http://www.spinics.net/lists/arm-kernel/msg288215.html According to the above, regulator framework have support in 3.13-rc1 to returns a dummy regulator if there is none specified in the dts data. Thierry told that there seems to be a bug in regulator in handling these case. Though, I also posted a patch on pwm a couple of days ago[2] [2]: https://patchwork.kernel.org/patch/3246711/ I posted it without power-supply by testing it with the solution proposed in [1]. If I dont use the solution[1], it fails for me also. Hmm so if this is not needed, I'll mark this thread as read in my inbox. If you guys need it please repost. 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] omap: twl-common: Fix musb-hdrc device name.
* Belisko Marek marek.beli...@gmail.com [131203 01:21]: On Tue, Dec 3, 2013 at 10:08 AM, Belisko Marek marek.beli...@gmail.com wrote: Hi, On Tue, Dec 3, 2013 at 9:58 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Tuesday 03 December 2013 02:03 PM, Marek Belisko wrote: Without this change when booting omap3 device (gta04) with board file leads to follwing errors: [1.203308] musb-hdrc musb-hdrc.0.auto: unable to find phy [1.209075] HS USB OTG: no transceiver configured [1.214019] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 and usb isn't working. This is probably regression caused by commit: 6c27f939 I think a better fix would be to have this merged.. https://lkml.org/lkml/2013/7/26/91 Yes I see but how this could help with current situation? Ho you then specify device number? I was too fast with reply sorry. I can see whole series and it is of course correct solution. But as I said can we except to be merged to 3.13. If not Tony can you pick my patch. If it's a regression, then let's get it merged for the -rc cycle. So please try to follow up on getting the proper fix merged, meanwhile I'll mark this thread as read. If you need this one merged for some reason, then please report to get it back to my radar. 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: [pandaboard] audio initialization fails due to TWL6040
* Tobias Jakobi tjak...@math.uni-bielefeld.de [131203 14:45]: And another one! https://bugzilla.kernel.org/show_bug.cgi?id=66451 Maybe Peter can take a look at this one? FYI, Peter, only slightly related to this, but can you also please unravel the mcbsp and sidetone .dtsi entries to be separate devices? I'm hoping to deprecate ti,hwmods for v3.15 and use the compatible property instead, so we need to have 1-to-1 mapping of devices defined in the .dtsi files compared to the real hardware devices mapped in the omap_hwmod_*_data.c files. There's some more info regarding that in thread: http://www.spinics.net/lists/arm-kernel/msg288036.html 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: OMAP3 NAND ECC selection
Hi Ezequiel, On Thu, Dec 5, 2013 at 7:26 PM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: Hi Javier, (CCing Brian: What do you think about this?) On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote: On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren t...@atomide.com wrote: In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. [..] global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the ti,nand-ecc-opt. I'll see if I can get some free time to try to implement that. AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. Agreed, in fact if you look at what I shared from the Micron NAND datasheet used on IGEPv2 it says that different ECC schemes could be used for block 0 and the rest of the NAND so definitely this is a software limitation. While there are some per MTD device (which model each partition), the ECC mode is present in the, nand_chip structure. My understanding is that the NAND core hasn't been designed for this use case, and thus some major re-work is needed to accomplish it. I see thanks for the clarification. I'm not familiar with the MTD subsystem to be honest so I somehow misunderstood that other nand drivers did this already and thought that it was just a matter of adding support to the OMAP NAND driver. Therefore, it's a much short-term solution to implement the OMAP module parameter to fix the issue. Of course, feel free to prove me wrong :-) Agreed. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com Thanks a lot and best regards, Javier -- 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: OMAP3 NAND ECC selection
Hi Ezequiel, From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] [...] AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. I had some reservations in doing so.. (as mentioned in previous email also [2]) I would rather like to understand long term benefits of such implementation. Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. [2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136 [a]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99025.html [b]: http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary with regards, pekon
Re: [PATCH] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected
* Nishanth Menon n...@ti.com [131203 17:40]:
Due to the cross dependencies between hwmod for automanaged device
information for OMAP and dts node definitions, we can run into scenarios
where the dts node is defined, however it's hwmod entry is yet to be
added. In these cases:
a) omap_device does not register a pm_domain (since it cannot find
hwmod entry).
b) driver does not know about (a), does a pm_runtime_get_sync which
never fails
c) It then tries to do some operation on the device (such as read the
revision register (as part of probe) without clock or adequate OMAP
generic PM operation performed for enabling the module.
This causes a crash such as that reported in:
https://bugzilla.kernel.org/show_bug.cgi?id=66441
When 'ti,hwmod' is provided in dt node, it is expected that the device
will not function without the OMAP's power automanagement. Hence, when
we hit a fail condition (due to hwmod entries not present or other
similar scenario), fail at pm_domain level due to lack of data, provide
enough information for it to be fixed, however, it allows for the driver
to take appropriate measures to prevent crash.
Kevin, any comments on this one?
Regards,
Tony
Reported-by: Tobias Jakobi tjak...@math.uni-bielefeld.de
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap_device.c | 24
arch/arm/mach-omap2/omap_device.h |1 +
2 files changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 53f0735..e0a398c 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -183,6 +183,10 @@ static int omap_device_build_from_dt(struct
platform_device *pdev)
odbfd_exit1:
kfree(hwmods);
odbfd_exit:
+ /* if data/we are at fault.. load up a fail handler */
+ if (ret)
+ pdev-dev.pm_domain = omap_device_fail_pm_domain;
+
return ret;
}
@@ -604,6 +608,19 @@ static int _od_runtime_resume(struct device *dev)
return pm_generic_runtime_resume(dev);
}
+
+static int _od_fail_runtime_suspend(struct device *dev)
+{
+ dev_warn(dev, %s: FIXME: missing hwmod/omap_dev info\n, __func__);
+ return -ENODEV;
+}
+
+static int _od_fail_runtime_resume(struct device *dev)
+{
+ dev_warn(dev, %s: FIXME: missing hwmod/omap_dev info\n, __func__);
+ return -ENODEV;
+}
+
#endif
#ifdef CONFIG_SUSPEND
@@ -657,6 +674,13 @@ static int _od_resume_noirq(struct device *dev)
#define _od_resume_noirq NULL
#endif
+struct dev_pm_domain omap_device_fail_pm_domain = {
+ .ops = {
+ SET_RUNTIME_PM_OPS(_od_fail_runtime_suspend,
+_od_fail_runtime_resume, NULL)
+ }
+};
+
struct dev_pm_domain omap_device_pm_domain = {
.ops = {
SET_RUNTIME_PM_OPS(_od_runtime_suspend, _od_runtime_resume,
diff --git a/arch/arm/mach-omap2/omap_device.h
b/arch/arm/mach-omap2/omap_device.h
index 17ca1ae..78c02b3 100644
--- a/arch/arm/mach-omap2/omap_device.h
+++ b/arch/arm/mach-omap2/omap_device.h
@@ -29,6 +29,7 @@
#include omap_hwmod.h
extern struct dev_pm_domain omap_device_pm_domain;
+extern struct dev_pm_domain omap_device_fail_pm_domain;
/* omap_device._state values */
#define OMAP_DEVICE_STATE_UNKNOWN0
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Dear Gupta, Pekon, On Thu, 5 Dec 2013 19:02:22 +, Gupta, Pekon wrote: From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] [...] AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. I had some reservations in doing so.. (as mentioned in previous email also [2]) I would rather like to understand long term benefits of such implementation. The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Isn't handling hardware constraints properly not a sufficient motivation for doing something? Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. And you're not realizing that these solutions are ugly and impractical? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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 v2 0/3] ARM: OMAP2+: USB Host bug fixes for 3.13 rc
* Tomi Valkeinen tomi.valkei...@ti.com [131204 02:01]: On 2013-12-03 16:25, Roger Quadros wrote: Hi, This is a follow up solution to the original series in [1] The first patch fixes the OMAP4 Panda USB detection problems on 3.13-rc1 with u-boot v2013.10. The remaining 2 patches are required if SOFTRESET needs to be done for the USB Host module on OMAP3 platforms. Patch 2 fixes the hwmod RESET logic to prevent multiple SOFTRESETs being issued to the modules. This multiple SOFTRESET was causing problems with OMAP3 USB Host module. On Beagleboard C4 this is seen as failure to mount NFS root over external USB to Ethernet device. This might be the reason why HWMOD_INIT_NO_RESET was used for the OMAP USB host module in OMAP3 hwmod data and just carried forward in OMAP4 and OMAP5 hwmod data as well. cheers, -roger Tested on Panda and Beagle xM. Works fine for me. Looks like we should merge these as regression fixes during the -rc cycle. Paul should take a look at these first though. 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: OMAP3 NAND ECC selection
On Thu, Dec 5, 2013 at 10:26 AM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: (CCing Brian: What do you think about this?) On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote: On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren t...@atomide.com wrote: In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. [..] global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the ti,nand-ecc-opt. I'll see if I can get some free time to try to implement that. AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. While there are some per MTD device (which model each partition), the ECC mode is present in the, nand_chip structure. My understanding is that the NAND core hasn't been designed for this use case, and thus some major re-work is needed to accomplish it. Yes, it looks like a lot of work for little benefit. IMO, the *right* thing to do is have the bootloader use a sufficiently strong ECC for the flash part, so you don't have to configure different strengths for different partitions. But I'll concede that it may be *nice* to have flexibility in some cases. Part of the difficulty is in making this generic for all types of NAND drivers. On some, you can simply change some high-level software parameters to use a different ECC mode, while others may require hooks for controlling hardware parameters. And switching this at runtime can end up being a lot of work, since a sequence of reads/writes alternating between two differently-configured partitions would rapid reconfiguration of the ECC controller, which previously only needed configured at module initialization time. It may be doable, but to commit to this approach, you must do a lot of work. Also, this requires major changes to the MTD framework. Right now, I believe MTD partitions are a very small shim layer, where the bulk of the MTD transactions are filtered through to the parent master MTD. Therefore, it's a much short-term solution to implement the OMAP module parameter to fix the issue. That's possible, but even there, I don't see what the real benefit is. If you only need special-case solutions (which it seems like this use case is) for updating bootloader data, can't a simple 1-bit ECC user-space tool (like the one you linked earlier) suffice? It seems like it's only a small convenience to place this flexibility in a module parameter, but it is much *less* generic; what if someone builds omap2 into the kernel (not as a module)? So the user-space tool seems superior in many cases. Brian -- 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: OMAP3 NAND ECC selection
On Thu, Dec 5, 2013 at 11:06 AM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: On Thu, 5 Dec 2013 19:02:22 +, Gupta, Pekon wrote: From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] [...] AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. I had some reservations in doing so.. (as mentioned in previous email also [2]) I would rather like to understand long term benefits of such implementation. The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. Isn't handling hardware constraints properly not a sufficient motivation for doing something? I'm not convinced your hardware constraints are reasonable or generally useful. But I could be convinced otherwise. Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. And you're not realizing that these solutions are ugly and impractical? Solution [a] is both ugly and impractical. Solution [b] is only a little ugly but quite practical (you could flesh out a better user-space ECC library, then combine it with nanddump/nandwrite --noecc). Rewriting both the MTD and NAND layers is not exactly practical and may still yield something ugly. Brian -- 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: OMAP3 NAND ECC selection
Dear Brian Norris, On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Isn't handling hardware constraints properly not a sufficient motivation for doing something? I'm not convinced your hardware constraints are reasonable or generally useful. But I could be convinced otherwise. They may not be reasonable, but they exist :) Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. And you're not realizing that these solutions are ugly and impractical? Solution [a] is both ugly and impractical. Solution [b] is only a little ugly but quite practical (you could flesh out a better user-space ECC library, then combine it with nanddump/nandwrite --noecc). Rewriting both the MTD and NAND layers is not exactly practical and may still yield something ugly. It's not practical because it wasn't thought like this originally, but technically speaking, being able to use a different ECC scheme for different areas of the NAND makes a lot of sense. That being said, it is true that having a good and reusable userspace tool to write data with arbitrary ECC schemes would be useful to workaround this situation. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.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: OMAP3 NAND ECC selection
* Thomas Petazzoni thomas.petazz...@free-electrons.com [131205 11:33]: Dear Brian Norris, On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Yeah and it seems that for the bootloader partition we need to be able to specify the ECC scheme in the .dts file to avoid having people trash their system unless they really want to do it. /me at least has rebooted and reflashed way too many times unnecessarily while trying to update MLO or u-boot from the kernel. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Documentation: dt: Document TSC2005 DT binding
Add devicetree binding documentation for TSC2005 touchscreen.
Signed-off-by: Sebastian Reichel s...@debian.org
---
.../bindings/input/touchscreen/tsc2005.txt | 49 ++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
new file mode 100644
index 000..4e7df0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -0,0 +1,49 @@
+* TSC2005 Touchscreen
+
+Required properties:
+ - compatible: ti,tsc2005
+ - reg : SPI device address
+ - spi-max-frequency : Maximal SPI speed
+ - interrupts: IRQ specifier
+ - reset-gpio: GPIO specifier
+
+Optional properties:
+ - ti,fuzz-x : integer, X noise value of the touchscreen
+ (defaults to 4)
+ - ti,fuzz-y : integer, Y noise value of the touchscreen
+ (defaults to 8)
+ - ti,fuzz-pressure : integer, pressure noise value of the touchscreen
+ (defaults to 2)
+ - ti,max-x : integer, maximum reported x value
+ (defaults to 4096)
+ - ti,max-y : integer, maximum reported y value
+ (defaults to 4096)
+ - ti,max-pressure : integer, maximum reported pressure
+ (defaults to 4096)
+ - ti,x-plate-resistance : integer, resistance of the touchscreen's X
plates
+ in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond
after
+ the configured time (in milli seconds), the
driver
+ will reset it. This is disabled by default.
+
+Example:
+
+mcspi1 {
+ tsc2005@0 {
+ compatible = ti,tsc2005;
+ spi-max-frequency = 600;
+ reg = 0;
+ reset-gpio = gpio4 8 GPIO_ACTIVE_HIGH; /* 104 */
+ interrupt-parent = gpio4;
+ interrupts = 4 IRQ_TYPE_NONE; /* gpio line 100 */
+
+ ti,fuzz-x = 4;
+ ti,fuzz-y = 7;
+ ti,fuzz-pressure = 2;
+ ti,max-x = 4096;
+ ti,max-y = 4096;
+ ti,max-pressure = 2048;
+ ti,x-plate-resistance = 280;
+ ti,esd-recovery-timeout-ms = 8000;
+ };
+}
--
1.8.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Input: tsc2005: add DT support
This adds DT support to the tsc2005 touchscreen
driver.
Signed-off-by: Sebastian Reichel s...@debian.org
---
drivers/input/touchscreen/tsc2005.c | 95 ++---
1 file changed, 78 insertions(+), 17 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 7a6ff52..b50986b 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -28,6 +28,8 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/pm.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/spi/spi.h
#include linux/spi/tsc2005.h
@@ -100,6 +102,11 @@
TSC2005_CFR2_AVG_7)
#define MAX_12BIT 0xfff
+#define TSC2005_DEF_X_FUZZ 4
+#define TSC2005_DEF_Y_FUZZ 8
+#define TSC2005_DEF_P_FUZZ 2
+#define TSC2005_DEF_RESISTOR 280
+
#define TSC2005_SPI_MAX_SPEED_HZ 1000
#define TSC2005_PENUP_TIME_MS 40
@@ -143,6 +150,7 @@ struct tsc2005 {
boolpen_down;
+ int reset_gpio;
void(*set_reset)(bool enable);
};
@@ -337,6 +345,14 @@ static void tsc2005_stop_scan(struct tsc2005 *ts)
tsc2005_cmd(ts, TSC2005_CMD_STOP);
}
+static void tsc2005_set_reset(struct tsc2005 *ts, bool enable)
+{
+ if (ts-reset_gpio = 0)
+ gpio_set_value(ts-reset_gpio, enable);
+ else if (ts-set_reset)
+ ts-set_reset(enable);
+}
+
/* must be called with ts-mutex held */
static void __tsc2005_disable(struct tsc2005 *ts)
{
@@ -355,7 +371,7 @@ static void __tsc2005_enable(struct tsc2005 *ts)
{
tsc2005_start_scan(ts);
- if (ts-esd_timeout ts-set_reset) {
+ if (ts-esd_timeout (ts-set_reset || ts-reset_gpio)) {
ts-last_valid_interrupt = jiffies;
schedule_delayed_work(ts-esd_work,
round_jiffies_relative(
@@ -414,9 +430,9 @@ static ssize_t tsc2005_selftest_show(struct device *dev,
}
/* hardware reset */
- ts-set_reset(false);
+ tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
- ts-set_reset(true);
+ tsc2005_set_reset(ts, true);
if (!success)
goto out;
@@ -459,7 +475,7 @@ static umode_t tsc2005_attr_is_visible(struct kobject *kobj,
umode_t mode = attr-mode;
if (attr == dev_attr_selftest.attr) {
- if (!ts-set_reset)
+ if (!ts-set_reset !ts-reset_gpio)
mode = 0;
}
@@ -509,9 +525,9 @@ static void tsc2005_esd_work(struct work_struct *work)
tsc2005_update_pen_state(ts, 0, 0, 0);
- ts-set_reset(false);
+ tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
- ts-set_reset(true);
+ tsc2005_set_reset(ts, true);
enable_irq(ts-spi-irq);
tsc2005_start_scan(ts);
@@ -572,29 +588,53 @@ static void tsc2005_setup_spi_xfer(struct tsc2005 *ts)
static int tsc2005_probe(struct spi_device *spi)
{
const struct tsc2005_platform_data *pdata = spi-dev.platform_data;
+ struct device_node *np = spi-dev.of_node;
struct tsc2005 *ts;
struct input_dev *input_dev;
unsigned int max_x, max_y, max_p;
unsigned int fudge_x, fudge_y, fudge_p;
+ unsigned int esd_timeout, x_plate_ohm;
int error;
- if (!pdata) {
+ if (!np !pdata) {
dev_err(spi-dev, no platform data\n);
return -ENODEV;
}
- fudge_x = pdata-ts_x_fudge? : 4;
- fudge_y = pdata-ts_y_fudge? : 8;
- fudge_p = pdata-ts_pressure_fudge ? : 2;
- max_x = pdata-ts_x_max ? : MAX_12BIT;
- max_y = pdata-ts_y_max ? : MAX_12BIT;
- max_p = pdata-ts_pressure_max ? : MAX_12BIT;
-
if (spi-irq = 0) {
dev_err(spi-dev, no irq\n);
return -ENODEV;
}
+ if (pdata) {
+ fudge_x = pdata-ts_x_fudge ? : TSC2005_DEF_X_FUZZ;
+ fudge_y = pdata-ts_y_fudge ? : TSC2005_DEF_Y_FUZZ;
+ fudge_p = pdata-ts_pressure_fudge ? : TSC2005_DEF_P_FUZZ;
+ max_x = pdata-ts_x_max ? : MAX_12BIT;
+ max_y = pdata-ts_y_max ? : MAX_12BIT;
+ max_p = pdata-ts_pressure_max? : MAX_12BIT;
+ x_plate_ohm = pdata-ts_x_plate_ohm ? : TSC2005_DEF_RESISTOR;
+ esd_timeout = pdata-esd_timeout_ms;
+ } else {
+ fudge_x = TSC2005_DEF_X_FUZZ;
+ of_property_read_u32(np, ti,fuzz-x, fudge_x);
+ fudge_y = TSC2005_DEF_Y_FUZZ;
+ of_property_read_u32(np, ti,fuzz-y, fudge_y);
+ fudge_p = TSC2005_DEF_P_FUZZ;
+
[PATCH 0/2] tsc2005 DT binding
Hi, This adds device tree support for the tsc2005 touchscreen controller, which is currently only used by the Nokia N900 board. The patch does not update the reset pin handling for platform data based probe to avoid merge conflicts (Tony will remove the Nokia N900 boardcode in 3.14). The platform data based probe can be removed once the N900 boardcode is gone. -- Sebastian Sebastian Reichel (2): Input: tsc2005: add DT support Documentation: dt: Document TSC2005 DT binding .../bindings/input/touchscreen/tsc2005.txt | 49 +++ drivers/input/touchscreen/tsc2005.c| 95 ++ 2 files changed, 127 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt -- 1.8.4.3 -- 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: [Bug] am33xx: Basic suspend resume support: Doesn't resume
On Thu, 2013-12-05 at 14:42 +0100, Christoph Fritz wrote: Hi, I'm having here a custom am335x board with DDR3 equipped trying to setup suspend/resume support. I have tested this with the ancient TI-PSP-3.2 Kernel and current 3.13-rc plus some pm patches. Problem: After suspending the device, it doesn't resume (freeze): echo mem /sys/power/state [ 103.020845] PM: Syncing filesystems ... done. [ 103.055549] Freezing user space processes ... (elapsed 0.003 seconds) done. [ 103.066696] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 103.077506] PM: Sending message for entering DeepSleep mode [ 103.099896] PM: suspend of devices complete after 11.951 msecs [ 103.110894] PM: late suspend of devices complete after 4.659 msecs [ 103.122599] PM: noirq suspend of devices complete after 5.032 msecs As a wakeup source I'm currently using gpio0_12. Triggering the reset button (am335x-pin: WARMRSTn) in suspend-mode has no effect, which is fine. But after changing the signal on the wakeup source (here gpio0_12), triggering a reset works fine again. So it seems to me that somewhere in the wakeup-process is a bug. Could this be related to DDR3? Apart from that, this custom board here is pretty similar to the ti-evm board wich works fine. In oder to test, I've shrunken the kernel to minimal driver support to sort out as much as possible segfaults in resume functions. With a view to be able to debug this further, I just ordered an openocd jtag adapter. Any comments, ideas, tips, ..? Update: It has definitely something to do with DDR3. I'll investigate this further. By the way, is there a TI-Board with DDR3 and working suspend-resume? Thanks -- Christoph -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix populating the hwmod data from device tree
On Thu, 5 Dec 2013, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [131121 12:49]: * Tony Lindgren t...@atomide.com [131120 17:46]: * Tony Lindgren t...@atomide.com [131120 16:06]: They at least had interrupts listed looking at commit 3b9b10. Probably the thing to do for now is to revert those changes, and see if we can just remove the L3 entries from the .dtsi files. Actually the patch I posted should be able to handle also the ti,hwmods = l3_main_1, l3_main_2, l3_main_3 property in omap4.dtsi, but we're not currently parsing that as we only look at the children and not the properties of the OCP bus. Should be fixable, will take a look tomorrow if this approach makes sense to you. OK this one seems to do the right thing for me. No comments? I'll queue the patch below to the fixes, please yell if you see any issues with that. Looks reasonable to me based on a quick glance: Acked-by: Paul Walmsley p...@pwsan.com Have not tested it though. I like the warning message for the bad data. - 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
[PATCHv2 4/5] wl1251: spi: add device tree support
Add device tree support for the spi variant of wl1251.
Signed-off-by: Sebastian Reichel s...@debian.org
---
drivers/net/wireless/ti/wl1251/spi.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/spi.c
b/drivers/net/wireless/ti/wl1251/spi.c
index 0a8aacc..b06d36d 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -27,6 +27,8 @@
#include linux/spi/spi.h
#include linux/wl12xx.h
#include linux/gpio.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/regulator/consumer.h
#include wl1251.h
@@ -240,13 +242,13 @@ static const struct wl1251_if_operations wl1251_spi_ops =
{
static int wl1251_spi_probe(struct spi_device *spi)
{
- struct wl1251_platform_data *pdata;
+ struct wl1251_platform_data *pdata = dev_get_platdata(spi-dev);
+ struct device_node *np = spi-dev.of_node;
struct ieee80211_hw *hw;
struct wl1251 *wl;
int ret;
- pdata = dev_get_platdata(spi-dev);
- if (!pdata) {
+ if (!np !pdata) {
wl1251_error(no platform data);
return -ENODEV;
}
@@ -273,7 +275,18 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
- wl-power_gpio = pdata-power_gpio;
+ if (np) {
+ wl-use_eeprom = of_property_read_bool(np,
ti,wl1251-has-eeprom);
+ wl-power_gpio = of_get_named_gpio(np, ti,power-gpio, 0);
+ } else if (pdata) {
+ wl-power_gpio = pdata-power_gpio;
+ wl-use_eeprom = pdata-use_eeprom;
+ }
+
+ if (wl-power_gpio == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto out_free;
+ }
if (gpio_is_valid(wl-power_gpio)) {
ret = devm_gpio_request_one(spi-dev, wl-power_gpio,
@@ -295,8 +308,6 @@ static int wl1251_spi_probe(struct spi_device *spi)
goto out_free;
}
- wl-use_eeprom = pdata-use_eeprom;
-
irq_set_status_flags(wl-irq, IRQ_NOAUTOEN);
ret = devm_request_irq(spi-dev, wl-irq, wl1251_irq, 0,
DRIVER_NAME, wl);
--
1.8.4.3
--
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
[PATCHv2 0/5] wl1251 device tree support
Hi, The following patchset adds device tree support to the spi variant of the wl1251 driver. Changes since v1 [0]: * Added some Reviewed-By: Pavel Machek * Splitted DT binding documentation into its own patch * Added ti, prefix to power-gpio * Renamed ti,use-eeprom to ti,wl1251-has-eeprom * Updated description for ti,wl1251-has-eeprom * Removed boardcode update from regulator patch to avoid useless merge conflicts (all relevant boardcode will be removed in 3.14). [0] https://lkml.org/lkml/2013/10/27/112 -- Sebastian Luciano Coelho (1): wl1251: split wl251 platform data to a separate structure Sebastian Reichel (4): wl1251: move power GPIO handling into the driver wl1251: spi: add vio regulator support wl1251: spi: add device tree support Documentation: dt: wireless: Add wl1251 .../devicetree/bindings/net/wireless/ti,wl1251.txt | 39 arch/arm/mach-omap2/board-omap3pandora.c | 6 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 13 +--- drivers/net/wireless/ti/wilink_platform_data.c | 37 +-- drivers/net/wireless/ti/wl1251/sdio.c | 31 +++--- drivers/net/wireless/ti/wl1251/spi.c | 71 -- drivers/net/wireless/ti/wl1251/wl1251.h| 4 +- include/linux/wl12xx.h | 24 +++- 8 files changed, 176 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt -- 1.8.4.3 -- 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
[PATCHv2 3/5] wl1251: spi: add vio regulator support
This patch adds support for requesting the regulator powering
the vio pin.
Signed-off-by: Sebastian Reichel s...@debian.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
drivers/net/wireless/ti/wl1251/spi.c| 19 +--
drivers/net/wireless/ti/wl1251/wl1251.h | 2 ++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/spi.c
b/drivers/net/wireless/ti/wl1251/spi.c
index 6abcbc3..0a8aacc 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -27,6 +27,7 @@
#include linux/spi/spi.h
#include linux/wl12xx.h
#include linux/gpio.h
+#include linux/regulator/consumer.h
#include wl1251.h
#include reg.h
@@ -306,13 +307,26 @@ static int wl1251_spi_probe(struct spi_device *spi)
irq_set_irq_type(wl-irq, IRQ_TYPE_EDGE_RISING);
- ret = wl1251_init_ieee80211(wl);
+ wl-vio = devm_regulator_get(spi-dev, vio);
+ if (IS_ERR(wl-vio)) {
+ ret = PTR_ERR(wl-vio);
+ wl1251_error(vio regulator missing: %d, ret);
+ goto out_free;
+ }
+
+ ret = regulator_enable(wl-vio);
if (ret)
goto out_free;
+ ret = wl1251_init_ieee80211(wl);
+ if (ret)
+ goto disable_regulator;
+
return 0;
- out_free:
+disable_regulator:
+ regulator_disable(wl-vio);
+out_free:
ieee80211_free_hw(hw);
return ret;
@@ -324,6 +338,7 @@ static int wl1251_spi_remove(struct spi_device *spi)
free_irq(wl-irq, wl);
wl1251_free_hw(wl);
+ regulator_disable(wl-vio);
return 0;
}
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h
b/drivers/net/wireless/ti/wl1251/wl1251.h
index f396a95..b0bfdf5 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -279,6 +279,8 @@ struct wl1251 {
int irq;
bool use_eeprom;
+ struct regulator *vio;
+
spinlock_t wl_lock;
enum wl1251_state state;
--
1.8.4.3
--
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
[PATCHv2 1/5] wl1251: split wl251 platform data to a separate structure
From: Luciano Coelho coe...@ti.com
Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251. Change the platform data built-in
block and board files accordingly.
Signed-off-by: Luciano Coelho coe...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Reviewed-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sebastian Reichel s...@debian.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
arch/arm/mach-omap2/board-omap3pandora.c | 4 +--
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
drivers/net/wireless/ti/wilink_platform_data.c | 37 +-
drivers/net/wireless/ti/wl1251/sdio.c | 12 -
drivers/net/wireless/ti/wl1251/spi.c | 2 +-
include/linux/wl12xx.h | 22 ++-
6 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index de1bc6b..24f3c1b 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -536,7 +536,7 @@ static struct spi_board_info omap3pandora_spi_board_info[]
__initdata = {
static void __init pandora_wl1251_init(void)
{
- struct wl12xx_platform_data pandora_wl1251_pdata;
+ struct wl1251_platform_data pandora_wl1251_pdata;
int ret;
memset(pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -550,7 +550,7 @@ static void __init pandora_wl1251_init(void)
goto fail_irq;
pandora_wl1251_pdata.use_eeprom = true;
- ret = wl12xx_set_platform_data(pandora_wl1251_pdata);
+ ret = wl1251_set_platform_data(pandora_wl1251_pdata);
if (ret 0)
goto fail_irq;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index dbf3ae5..01e8bef 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -84,7 +84,7 @@ enum {
RX51_SPI_MIPID, /* LCD panel */
};
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
static struct tsc2005_platform_data tsc2005_pdata;
#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c
b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
#include linux/err.h
#include linux/wl12xx.h
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
- if (platform_data)
+ if (wl12xx_platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
- platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!platform_data)
+ wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl12xx_platform_data)
return -ENOMEM;
return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct
wl12xx_platform_data *data)
struct wl12xx_platform_data *wl12xx_get_platform_data(void)
{
- if (!platform_data)
+ if (!wl12xx_platform_data)
return ERR_PTR(-ENODEV);
- return platform_data;
+ return wl12xx_platform_data;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+ if (wl1251_platform_data)
+ return -EBUSY;
+ if (!data)
+ return -EINVAL;
+
+ wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl1251_platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+ if (!wl1251_platform_data)
+ return ERR_PTR(-ENODEV);
+
+ return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c
b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
struct wl1251 *wl;
struct ieee80211_hw *hw;
struct wl1251_sdio *wl_sdio;
- const struct wl12xx_platform_data *wl12xx_board_data;
+ const struct wl1251_platform_data *wl1251_board_data;
hw = wl1251_alloc_hw();
if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl-if_priv = wl_sdio;
wl-if_ops = wl1251_sdio_ops;
- wl12xx_board_data =
[PATCHv2 2/5] wl1251: move power GPIO handling into the driver
Move the power GPIO handling from the board code into
the driver. This is a dependency for device tree support.
Signed-off-by: Sebastian Reichel s...@debian.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
arch/arm/mach-omap2/board-omap3pandora.c | 2 ++
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++
drivers/net/wireless/ti/wl1251/sdio.c| 21 +-
drivers/net/wireless/ti/wl1251/spi.c | 33 ++--
drivers/net/wireless/ti/wl1251/wl1251.h | 2 +-
include/linux/wl12xx.h | 2 +-
6 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 24f3c1b..cf18340 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -541,6 +541,8 @@ static void __init pandora_wl1251_init(void)
memset(pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
+ pandora_wl1251_pdata.power_gpio = -1;
+
ret = gpio_request_one(PANDORA_WIFI_IRQ_GPIO, GPIOF_IN, wl1251 irq);
if (ret 0)
goto fail;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 01e8bef..6538184 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -1166,13 +1166,7 @@ static inline void board_smc91x_init(void)
#endif
-static void rx51_wl1251_set_power(bool enable)
-{
- gpio_set_value(RX51_WL1251_POWER_GPIO, enable);
-}
-
static struct gpio rx51_wl1251_gpios[] __initdata = {
- { RX51_WL1251_POWER_GPIO, GPIOF_OUT_INIT_LOW, wl1251 power },
{ RX51_WL1251_IRQ_GPIO, GPIOF_IN, wl1251 irq},
};
@@ -1189,17 +1183,16 @@ static void __init rx51_init_wl1251(void)
if (irq 0)
goto err_irq;
- wl1251_pdata.set_power = rx51_wl1251_set_power;
+ wl1251_pdata.power_gpio = RX51_WL1251_POWER_GPIO;
rx51_peripherals_spi_board_info[RX51_SPI_WL1251].irq = irq;
return;
err_irq:
gpio_free(RX51_WL1251_IRQ_GPIO);
- gpio_free(RX51_WL1251_POWER_GPIO);
error:
printk(KERN_ERR wl1251 board initialisation failed\n);
- wl1251_pdata.set_power = NULL;
+ wl1251_pdata.power_gpio = -1;
/*
* Now rx51_peripherals_spi_board_info[1].irq is zero and
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c
b/drivers/net/wireless/ti/wl1251/sdio.c
index b75a37a..b661f89 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -28,6 +28,7 @@
#include linux/wl12xx.h
#include linux/irq.h
#include linux/pm_runtime.h
+#include linux/gpio.h
#include wl1251.h
@@ -182,8 +183,9 @@ static int wl1251_sdio_set_power(struct wl1251 *wl, bool
enable)
* callback in case it wants to do any additional setup,
* for example enabling clock buffer for the module.
*/
- if (wl-set_power)
- wl-set_power(true);
+ if (gpio_is_valid(wl-power_gpio))
+ gpio_set_value(wl-power_gpio, true);
+
ret = pm_runtime_get_sync(func-dev);
if (ret 0) {
@@ -203,8 +205,8 @@ static int wl1251_sdio_set_power(struct wl1251 *wl, bool
enable)
if (ret 0)
goto out;
- if (wl-set_power)
- wl-set_power(false);
+ if (gpio_is_valid(wl-power_gpio))
+ gpio_set_value(wl-power_gpio, false);
}
out:
@@ -256,11 +258,20 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl1251_board_data = wl1251_get_platform_data();
if (!IS_ERR(wl1251_board_data)) {
- wl-set_power = wl1251_board_data-set_power;
+ wl-power_gpio = wl1251_board_data-power_gpio;
wl-irq = wl1251_board_data-irq;
wl-use_eeprom = wl1251_board_data-use_eeprom;
}
+ if (gpio_is_valid(wl-power_gpio)) {
+ ret = devm_gpio_request(func-dev, wl-power_gpio,
+ wl1251 power);
+ if (ret) {
+ wl1251_error(Failed to request gpio: %d\n, ret);
+ goto disable;
+ }
+ }
+
if (wl-irq) {
irq_set_status_flags(wl-irq, IRQ_NOAUTOEN);
ret = request_irq(wl-irq, wl1251_line_irq, 0, wl1251, wl);
diff --git a/drivers/net/wireless/ti/wl1251/spi.c
b/drivers/net/wireless/ti/wl1251/spi.c
index 62403a1..6abcbc3 100644
--- a/drivers/net/wireless/ti/wl1251/spi.c
+++ b/drivers/net/wireless/ti/wl1251/spi.c
@@ -26,6 +26,7 @@
#include linux/crc7.h
#include linux/spi/spi.h
#include linux/wl12xx.h
+#include linux/gpio.h
#include wl1251.h
#include reg.h
@@ -221,8 +222,8 @@ static void
[PATCHv2 5/5] Documentation: dt: wireless: Add wl1251
Add device tree binding documentation for Texas Instrument's wl1251
wireless lan chip. For now only the SPI binding is documented.
Signed-off-by: Sebastian Reichel s...@debian.org
---
.../devicetree/bindings/net/wireless/ti,wl1251.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
new file mode 100644
index 000..189ae5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
@@ -0,0 +1,39 @@
+* Texas Instruments wl1251 wireless lan controller
+
+The wl1251 chip can be connected via SPI or via SDIO. This
+document describes the binding for the SPI connected chip.
+
+Required properties:
+- compatible :Should be ti,wl1251
+- reg : Chip select address of device
+- spi-max-frequency : Maximum SPI clocking speed of device in Hz
+- interrupts :Should contain interrupt line
+- interrupt-parent : Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- vio-supply :phandle to regulator providing VIO
+- ti,power-gpio : GPIO connected to chip's PMEN pin
+
+Optional properties:
+- ti,wl1251-has-eeprom : boolean, the wl1251 has an eeprom connected, which
+ provides configuration data (calibration, MAC, ...)
+- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
+ for optional SPI connection related properties,
+
+Examples:
+
+spi1 {
+ wl1251@0 {
+ compatible = ti,wl1251;
+
+ reg = 0;
+ spi-max-frequency = 4800;
+ spi-cpol;
+ spi-cpha;
+
+ interrupt-parent = gpio2;
+ interrupts = 10 IRQ_TYPE_NONE; /* gpio line 42 */
+
+ vio-supply = vio;
+ ti,power-gpio = gpio3 23 GPIO_ACTIVE_HIGH; /* 87 */
+ };
+};
--
1.8.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix populating the hwmod data from device tree
* Paul Walmsley p...@pwsan.com [131205 16:09]: On Thu, 5 Dec 2013, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [131121 12:49]: * Tony Lindgren t...@atomide.com [131120 17:46]: * Tony Lindgren t...@atomide.com [131120 16:06]: They at least had interrupts listed looking at commit 3b9b10. Probably the thing to do for now is to revert those changes, and see if we can just remove the L3 entries from the .dtsi files. Actually the patch I posted should be able to handle also the ti,hwmods = l3_main_1, l3_main_2, l3_main_3 property in omap4.dtsi, but we're not currently parsing that as we only look at the children and not the properties of the OCP bus. Should be fixable, will take a look tomorrow if this approach makes sense to you. OK this one seems to do the right thing for me. No comments? I'll queue the patch below to the fixes, please yell if you see any issues with that. Looks reasonable to me based on a quick glance: Acked-by: Paul Walmsley p...@pwsan.com Have not tested it though. OK thanks for looking. I've used it with my mach-omap2 DT patches for past few weeks on various boards without issues. I like the warning message for the bad data. :) 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
[GIT PULL] one regression fix and two more omap dt fixes against v3.13-rc2
The following changes since commit dc1ccc48159d63eca5089e507c82c7d22ef60839: Linux 3.13-rc2 (2013-11-29 12:57:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.13/yet-more-dt-regressions for you to fetch changes up to 341ba42e76723f2c39da7e288703896ae3d85620: ARM: OMAP2+: Fix the machine entry for am3517 (2013-12-05 16:25:30 -0800) A rather big fix for a regression where we have dropped omap4 hwmod data earlier but are not initializing it from device tree. In addition to this fix we eventually also be fix the issues in the .dts files and drivers, but that's too intrusive for the -rc cycle and must be done later on. Also two more legacy booting vs device tree based booting fixes for am3517 that I did not notice earlier until Nishant Menon reported these to me few days ago. With these we're good to go having v3.13 working both for legacy booting and device tree based booting, and we can then go ahed and drop the legacy booting for mach-omap2 for v3.14. Nishanth Menon (1): ARM: OMAP2+: Fix the machine entry for am3517 Tony Lindgren (2): ARM: OMAP2+: Fix overwriting hwmod data with data from device tree ARM: dts: Fix missing entries for am3517 arch/arm/boot/dts/am3517-evm.dts| 6 +-- arch/arm/boot/dts/am3517.dtsi | 63 arch/arm/mach-omap2/board-generic.c | 18 +++ arch/arm/mach-omap2/omap_hwmod.c| 98 + 4 files changed, 162 insertions(+), 23 deletions(-) create mode 100644 arch/arm/boot/dts/am3517.dtsi -- 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] net: davinci_emac: Fix platform data handling and make usable for am3517
From: Tony Lindgren t...@atomide.com Date: Tue, 3 Dec 2013 15:13:02 -0800 When booted with device tree, we may still have platform data passed as auxdata. For am3517 this is needed for passing the interrupt_enable and interrupt_disable callbacks that access the omap system control module registers. These callback functions will eventually go away when we have a separate system control module driver. Some of the things that are currently passed as platform data we don't need to set up as device tree properties as they are always the same on am3517. So let's use a new compatible flag for those so we can get those from the device tree match data. Also note that we need to fix setting of phy_dev to NULL instead of an empty string as the code later on uses that to find the first phy on the mdio bus. This seems to have been caused by 5d69e0076a72 (net: davinci_emac: switch to new mdio). Signed-off-by: Tony Lindgren t...@atomide.com Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] drivers: net : cpsw: Use netdev_name while requesting irq
From: George Cherian george.cher...@ti.com
Use netdev_name while requesting irq so that eth* name is shown
in /proc/interrupts. Previously it was showing device name as (null)
for cpsw interrupts. For using netdev_name register_netdev and then
call devm_request_irq.
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a91f0c9..61ae17f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2090,19 +2090,6 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
}
- while ((res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k))) {
- for (i = res-start; i = res-end; i++) {
- if (devm_request_irq(pdev-dev, i, cpsw_interrupt, 0,
-dev_name(priv-dev), priv)) {
- dev_err(priv-dev, error attaching irq\n);
- goto clean_ale_ret;
- }
- priv-irqs_table[k] = i;
- priv-num_irqs = k + 1;
- }
- k++;
- }
-
ndev-features |= NETIF_F_HW_VLAN_CTAG_FILTER;
ndev-netdev_ops = cpsw_netdev_ops;
@@ -2118,6 +2105,19 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ale_ret;
}
+ while ((res = platform_get_resource(priv-pdev, IORESOURCE_IRQ, k))) {
+ for (i = res-start; i = res-end; i++) {
+ if (devm_request_irq(pdev-dev, i, cpsw_interrupt, 0,
+netdev_name(ndev), priv)) {
+ dev_err(priv-dev, error attaching irq\n);
+ goto clean_ale_ret;
+ }
+ priv-irqs_table[k] = i;
+ priv-num_irqs = k + 1;
+ }
+ k++;
+ }
+
if (cpts_register(pdev-dev, priv-cpts,
data-cpts_clock_mult, data-cpts_clock_shift))
dev_err(priv-dev, error registering cpts device\n);
--
1.8.5.rc3.2.gc302941
--
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
