RE: [PATCH] da8xx: Allow use by am33xx based devices
Hi Tomi, On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote: Hi, On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote: This driver can be used for AM33xx devices, like the popular beaglebone. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/video/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9791d10..e7868d8 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2202,7 +2202,7 @@ config FB_SH7760 config FB_DA8XX tristate DA8xx/OMAP-L1xx Framebuffer support - depends on FB ARCH_DAVINCI_DA8XX + depends on FB (ARCH_DAVINCI_DA8XX || SOC_AM33XX) Agreed this is present on da8xx and am33xx, but moving forward for supporting DT, we should be avoiding these dependencies. So instead change this to remove machine dependencies. I could be wrong here, having dependency on platform seems to be right. Otherwise may lead to build errors for other platforms. Please ignore my comments and accept this patch. Thanks, Prakash -- To unsubscribe from this list: send the line unsubscribe 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] serial: omap: add the functionality of a 9-bit UART with userspaces CMSPAR
From: Enric Balletbo i Serra eballe...@iseebcn.com Some systems require the additional communication functionality of a 9-bit UART. For that we could use the stick (mark/space) parity bit supported on omap serial device. When is set, if PARODD is set the parity bit is always 1; if PARODD is not set, then the parity bit is always 0. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- drivers/tty/serial/omap-serial.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 6d3d26a..197fb71 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -756,6 +756,8 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, cval |= UART_LCR_PARITY; if (!(termios-c_cflag PARODD)) cval |= UART_LCR_EPAR; + if (termios-c_cflag CMSPAR) + cval |= UART_LCR_SPAR; /* * Ask the core to calculate the divisor for us. -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Wed, Dec 05, 2012 at 05:15:52AM +, Philip, Avinash wrote: (...) First a short reminder of pros and cons of the constant polynomial addition (let's just call it CPA) feature: pros: - it elegantly solves all problems related to reading an erased page (no clumsy hack needed) - better performance: when a bitflip appears on an erased page (often this is a sticky bitflip), there is no need to perform a full scan+cleanup of the page each time it is read No need for scan + cleanup on each read, as the chances of encountering bit flips in erased page is less. Also to find bit flips in erased page, compare ecc vector for read erased page against a standard ecc vector. Presence of bit flips can find by checking the compare results. In case of mismatch, should go for correction of bit flips in erased page with full scan. Hi Avinash, I explicitly mentioned the condition when a bitflip appears on an erased page, in which case you _do_ have to do a full scan upon each read, until you erase the block; and then, the bitflip may still be there (this is what I called a sticky bitflip). My experience with recent devices (4-bit/8-bit) is that erased pages with a single bitflip are not uncommon. For those pages, there is undeniably a performance penalty compared to CPA. Benchmarks would be needed to quantify the overall performance impact, but I suspect it is small. So with this approach, we can nullify the effect of CPA for erased page bit flip handling. Well, not completely. I would happily drop CPA is that were the case. cons: - the ecc vector is not compatible with RBL RBL compatibility is not necessary in my case, because I'm using the OMAP MLC ROM boot mode. Rather than completely removing the CPA feature, I'd like to keep it as an option; it could even be used with the ELM module. I agree RBL compatibility depends on the user. But with RBL compatibility, there is no sacrifice of any existing feature. Is it right? Also nand driver get simplified with removal of CPA, so that both HW SW error correction can go for same ecc calculation. Indeed that would be a simplification. I'm OK to submit a patch in this direction, but first I'd like to wait for the dust to settle on arch/arm/mach-omap2 and mtd/nand/omap2.c with Afzal patches and everything; things have become a bit complicated to follow recently :-) Afzal's changes are in are settled now. What about this set: http://lists.infradead.org/pipermail/linux-mtd/2012-October/044337.html I cannot see it in l2-mtd-2.6 ? Or did I miss something ? Thanks, -- Ivan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] gpio: twl4030: Correct status reporting for outputs
Hi, As Grant commneted on the first version: https://lkml.org/lkml/2012/12/5/53 Introduce bitfields to cache the directionand output status of the pins so we can report them correctly. To do this I did some cleanup within the driver to get rid of the global variables and moved them under a private structure, changed the locking as well to protect the bitfield operation. As a last patch I added a note that the PWMA/B handling should not be in this driver at all. Regards, Peter --- Peter Ujfalusi (3): gpio: twl4030: Introduce private structure to store variables needed runtime gpio: twl4030: Cache the direction and output states in private data gpio: twl4030: TODO comment to remove the PWMA/B (LEDA/B) handling drivers/gpio/gpio-twl4030.c | 177 1 file changed, 115 insertions(+), 62 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] gpio: twl4030: Introduce private structure to store variables needed runtime
Move most of the global variables inside a private structure and allocate
it dynamically.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/gpio/gpio-twl4030.c | 82 +++--
1 file changed, 50 insertions(+), 32 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 55b4fe4..c092739 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -49,11 +49,6 @@
* There are also two LED pins used sometimes as output-only GPIOs.
*/
-
-static struct gpio_chip twl_gpiochip;
-static int twl4030_gpio_base;
-static int twl4030_gpio_irq_base;
-
/* genirq interfaces are not available to modules */
#ifdef MODULE
#define is_module()true
@@ -72,11 +67,20 @@ static int twl4030_gpio_irq_base;
/* Data structures */
static DEFINE_MUTEX(gpio_lock);
-/* store usage of each GPIO. - each bit represents one GPIO */
-static unsigned int gpio_usage_count;
+struct gpio_twl4030_priv {
+ struct gpio_chip gpio_chip;
+ int irq_base;
+
+ unsigned int usage_count;
+};
/*--*/
+static inline struct gpio_twl4030_priv *to_gpio_twl4030(struct gpio_chip *chip)
+{
+ return container_of(chip, struct gpio_twl4030_priv, gpio_chip);
+}
+
/*
* To configure TWL4030 GPIO module registers
*/
@@ -193,10 +197,6 @@ static int twl4030_get_gpio_datain(int gpio)
u8 base = 0;
int ret = 0;
- if (unlikely((gpio = TWL4030_GPIO_MAX)
- || !(gpio_usage_count BIT(gpio
- return -EPERM;
-
base = REG_GPIODATAIN1 + d_bnk;
ret = gpio_twl4030_read(base);
if (ret 0)
@@ -209,6 +209,7 @@ static int twl4030_get_gpio_datain(int gpio)
static int twl_request(struct gpio_chip *chip, unsigned offset)
{
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
int status = 0;
mutex_lock(gpio_lock);
@@ -252,7 +253,7 @@ static int twl_request(struct gpio_chip *chip, unsigned
offset)
}
/* on first use, turn GPIO module on */
- if (!gpio_usage_count) {
+ if (!priv-usage_count) {
struct twl4030_gpio_platform_data *pdata;
u8 value = MASK_GPIO_CTRL_GPIO_ON;
@@ -266,16 +267,18 @@ static int twl_request(struct gpio_chip *chip, unsigned
offset)
status = gpio_twl4030_write(REG_GPIO_CTRL, value);
}
+done:
if (!status)
- gpio_usage_count |= (0x1 offset);
+ priv-usage_count |= BIT(offset);
-done:
mutex_unlock(gpio_lock);
return status;
}
static void twl_free(struct gpio_chip *chip, unsigned offset)
{
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+
if (offset = TWL4030_GPIO_MAX) {
twl4030_led_set_value(offset - TWL4030_GPIO_MAX, 1);
return;
@@ -283,10 +286,10 @@ static void twl_free(struct gpio_chip *chip, unsigned
offset)
mutex_lock(gpio_lock);
- gpio_usage_count = ~BIT(offset);
+ priv-usage_count = ~BIT(offset);
/* on last use, switch off GPIO module */
- if (!gpio_usage_count)
+ if (!priv-usage_count)
gpio_twl4030_write(REG_GPIO_CTRL, 0x0);
mutex_unlock(gpio_lock);
@@ -301,14 +304,19 @@ static int twl_direction_in(struct gpio_chip *chip,
unsigned offset)
static int twl_get(struct gpio_chip *chip, unsigned offset)
{
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
int status = 0;
+ if (!(priv-usage_count BIT(offset)))
+ return -EPERM;
+
if (offset TWL4030_GPIO_MAX)
status = twl4030_get_gpio_datain(offset);
else if (offset == TWL4030_GPIO_MAX)
status = cached_leden LEDEN_LEDAON;
else
status = cached_leden LEDEN_LEDBON;
+
return (status 0) ? 0 : status;
}
@@ -333,12 +341,14 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_to_irq(struct gpio_chip *chip, unsigned offset)
{
- return (twl4030_gpio_irq_base (offset TWL4030_GPIO_MAX))
- ? (twl4030_gpio_irq_base + offset)
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+
+ return (priv-irq_base (offset TWL4030_GPIO_MAX))
+ ? (priv-irq_base + offset)
: -EINVAL;
}
-static struct gpio_chip twl_gpiochip = {
+static struct gpio_chip template_chip = {
.label = twl4030,
.owner = THIS_MODULE,
.request= twl_request,
@@ -424,8 +434,14 @@ static int __devinit gpio_twl4030_probe(struct
platform_device *pdev)
{
struct twl4030_gpio_platform_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
+ struct gpio_twl4030_priv *priv;
int ret, irq_base;
+ priv =
[PATCH v2 2/3] gpio: twl4030: Cache the direction and output states in private data
Use more coherent locking in the driver. Use bitfield to store the GPIO
direction and if the pin is configured as output store the status also in a
bitfiled.
In this way we can just look at these bitfields when we need information
about the pin status and only reach out to the chip when it is needed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/gpio/gpio-twl4030.c | 99 ++---
1 file changed, 66 insertions(+), 33 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index c092739..a38e6e9c 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -64,14 +64,15 @@
/* Mask for GPIO registers when aggregated into a 32-bit integer */
#define GPIO_32_MASK 0x0003
-/* Data structures */
-static DEFINE_MUTEX(gpio_lock);
-
struct gpio_twl4030_priv {
struct gpio_chip gpio_chip;
+ struct mutex mutex;
int irq_base;
+ /* Bitfields for state caching */
unsigned int usage_count;
+ unsigned int direction;
+ unsigned int out_state;
};
/*--*/
@@ -130,7 +131,7 @@ static inline int gpio_twl4030_read(u8 address)
/*--*/
-static u8 cached_leden;/* protected by gpio_lock */
+static u8 cached_leden;
/* The LED lines are open drain outputs ... a FET pulls to GND, so an
* external pullup is needed. We could also expose the integrated PWM
@@ -144,14 +145,12 @@ static void twl4030_led_set_value(int led, int value)
if (led)
mask = 1;
- mutex_lock(gpio_lock);
if (value)
cached_leden = ~mask;
else
cached_leden |= mask;
status = twl_i2c_write_u8(TWL4030_MODULE_LED, cached_leden,
TWL4030_LED_LEDEN_REG);
- mutex_unlock(gpio_lock);
}
static int twl4030_set_gpio_direction(int gpio, int is_input)
@@ -162,7 +161,6 @@ static int twl4030_set_gpio_direction(int gpio, int
is_input)
u8 base = REG_GPIODATADIR1 + d_bnk;
int ret = 0;
- mutex_lock(gpio_lock);
ret = gpio_twl4030_read(base);
if (ret = 0) {
if (is_input)
@@ -172,7 +170,6 @@ static int twl4030_set_gpio_direction(int gpio, int
is_input)
ret = gpio_twl4030_write(base, reg);
}
- mutex_unlock(gpio_lock);
return ret;
}
@@ -212,7 +209,7 @@ static int twl_request(struct gpio_chip *chip, unsigned
offset)
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
int status = 0;
- mutex_lock(gpio_lock);
+ mutex_lock(priv-mutex);
/* Support the two LED outputs as output-only GPIOs. */
if (offset = TWL4030_GPIO_MAX) {
@@ -271,7 +268,7 @@ done:
if (!status)
priv-usage_count |= BIT(offset);
- mutex_unlock(gpio_lock);
+ mutex_unlock(priv-mutex);
return status;
}
@@ -279,64 +276,98 @@ static void twl_free(struct gpio_chip *chip, unsigned
offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ mutex_lock(priv-mutex);
if (offset = TWL4030_GPIO_MAX) {
twl4030_led_set_value(offset - TWL4030_GPIO_MAX, 1);
return;
}
- mutex_lock(gpio_lock);
-
priv-usage_count = ~BIT(offset);
/* on last use, switch off GPIO module */
if (!priv-usage_count)
gpio_twl4030_write(REG_GPIO_CTRL, 0x0);
- mutex_unlock(gpio_lock);
+ mutex_unlock(priv-mutex);
}
static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
{
- return (offset TWL4030_GPIO_MAX)
- ? twl4030_set_gpio_direction(offset, 1)
- : -EINVAL;
+ struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ int ret;
+
+ mutex_lock(priv-mutex);
+ if (offset TWL4030_GPIO_MAX)
+ ret = twl4030_set_gpio_direction(offset, 1);
+ else
+ ret = -EINVAL;
+
+ if (!ret)
+ priv-direction = ~BIT(offset);
+
+ mutex_unlock(priv-mutex);
+
+ return ret;
}
static int twl_get(struct gpio_chip *chip, unsigned offset)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
+ int ret;
int status = 0;
- if (!(priv-usage_count BIT(offset)))
- return -EPERM;
+ mutex_lock(priv-mutex);
+ if (!(priv-usage_count BIT(offset))) {
+ ret = -EPERM;
+ goto out;
+ }
- if (offset TWL4030_GPIO_MAX)
- status = twl4030_get_gpio_datain(offset);
- else if (offset == TWL4030_GPIO_MAX)
- status = cached_leden LEDEN_LEDAON;
+ if (priv-direction BIT(offset))
+ status = priv-out_state BIT(offset);
else
-
[PATCH v2 3/3] gpio: twl4030: TODO comment to remove the PWMA/B (LEDA/B) handling
This GPIO driver should not configure anything else then GPIOs. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/gpio/gpio-twl4030.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c index a38e6e9c..1e9f08c4 100644 --- a/drivers/gpio/gpio-twl4030.c +++ b/drivers/gpio/gpio-twl4030.c @@ -47,6 +47,7 @@ * intended to support multiple hosts. * * There are also two LED pins used sometimes as output-only GPIOs. + * TODO: Handling of PWMA/B (LEDA/B) should be removed from this GPIO driver! */ /* genirq interfaces are not available to modules */ @@ -131,6 +132,7 @@ static inline int gpio_twl4030_read(u8 address) /*--*/ +/* TODO: Handling of PWMA/B (LEDA/B) should be removed from this GPIO driver! */ static u8 cached_leden; /* The LED lines are open drain outputs ... a FET pulls to GND, so an -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: twl4030: Correct status reporting when the GPIO is used as output
On 12/05/2012 11:48 PM, Grant Likely wrote: -base = REG_GPIODATAIN1 + d_bnk; +direction = gpio_twl4030_read(REG_GPIODATADIR1 + d_bnk); +if (direction 0 (direction d_off) 0x1) +base = REG_SETGPIODATAOUT1 + d_bnk; +else +base = REG_GPIODATAIN1 + d_bnk; + This is probably quite expensive considering that reads need to go out the i2c bus. Things like the output state and the pin direction should be cached by the driver in its private data structure so that you don't add an additional i2c round trip. True. I have sent the v2, which grown a bit since I did not wanted to add more global variable to this driver. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: cm-t3517: add MMC support
cm-t3517 uses two MMC interfaces. Add support for both.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t3517.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index ebbc2ad..fb1f993 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -32,6 +32,7 @@
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
+#include linux/mmc/host.h
#include linux/can/platform/ti_hecc.h
#include asm/mach-types.h
@@ -46,6 +47,7 @@
#include mux.h
#include control.h
+#include hsmmc.h
#include common-board-devices.h
#include am35xx-emac.h
#include gpmc-nand.h
@@ -121,6 +123,24 @@ static void cm_t3517_init_hecc(void)
static inline void cm_t3517_init_hecc(void) {}
#endif
+#if defined(CONFIG_MMC) || defined(CONFIG_MMC_MODULE)
+static struct omap2_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ .caps = MMC_CAP_4_BIT_DATA,
+ .gpio_cd= 144,
+ .gpio_wp= 59,
+ },
+ {
+ .mmc= 2,
+ .caps = MMC_CAP_4_BIT_DATA,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ },
+ {} /* Terminator */
+};
+#endif
+
#if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
#define RTC_IO_GPIO(153)
#define RTC_WR_GPIO(154)
@@ -271,6 +291,10 @@ static struct omap_board_mux board_mux[] __initdata = {
/* CM-T3517 USB HUB nRESET */
OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* CD - GPIO144 and WP - GPIO59 for MMC1 - SB-T35 */
+ OMAP3_MUX(UART2_CTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(GPMC_CLK, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
@@ -286,6 +310,7 @@ static void __init cm_t3517_init(void)
cm_t3517_init_usbh();
cm_t3517_init_hecc();
am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
+ omap_hsmmc_init(mmc);
}
MACHINE_START(CM_T3517, Compulab CM-T3517)
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Thu, Dec 06, 2012 at 15:45:41, Ivan Djelic wrote: On Wed, Dec 05, 2012 at 05:15:52AM +, Philip, Avinash wrote: (...) First a short reminder of pros and cons of the constant polynomial addition (let's just call it CPA) feature: pros: - it elegantly solves all problems related to reading an erased page (no clumsy hack needed) - better performance: when a bitflip appears on an erased page (often this is a sticky bitflip), there is no need to perform a full scan+cleanup of the page each time it is read No need for scan + cleanup on each read, as the chances of encountering bit flips in erased page is less. Also to find bit flips in erased page, compare ecc vector for read erased page against a standard ecc vector. Presence of bit flips can find by checking the compare results. In case of mismatch, should go for correction of bit flips in erased page with full scan. Hi Avinash, I explicitly mentioned the condition when a bitflip appears on an erased page, in which case you _do_ have to do a full scan upon each read, until you erase the block; and then, the bitflip may still be there (this is what I called a sticky bitflip). Bit flips in erased page require full scan. My experience with recent devices (4-bit/8-bit) is that erased pages with a single bitflip are not uncommon. What about erased page without bit flips? If we take the probability of bit flips and non-bit flips in erased page, erased pages with bit flips will be very less. So probability of scanning erased page is less. For those pages, there is undeniably a performance penalty compared to CPA. Pages with bit flips would have better performance with CPA as no explicit scan present. Pages without bit flips, would have better performance if we compare against standard ecc vector than with present implementation of software BCH. The same can be achieved with software BCH also. Benchmarks would be needed to quantify the overall performance impact, but I suspect it is small. So overall performance would be better with checking with standard ecc vector for finding erased page and handling bit flip in erased page with full scan due to probability that bit flips in erased page is very less than pages without bit flips. But with performance improvement for bit flipped erased page with CPA, we have to sacrifice RBL compatibility. So a common layout across all components would be missing. So with this approach, we can nullify the effect of CPA for erased page bit flip handling. Well, not completely. I would happily drop CPA is that were the case. So the choices can be 1. Performance drop in case of bit flip in erased page with full scan of page if bit flip in erased page. But can achieve RBL compatibility, simplification of ecc calculation. 2. Sacrifice RBL compatibility with CPA, but still performance can be improved for erased pages without bit flips. But initial discussion in this direction told RBL compatibility would be a better option https://lkml.org/lkml/2012/10/11/240 cons: - the ecc vector is not compatible with RBL RBL compatibility is not necessary in my case, because I'm using the OMAP MLC ROM boot mode. Rather than completely removing the CPA feature, I'd like to keep it as an option; it could even be used with the ELM module. I agree RBL compatibility depends on the user. But with RBL compatibility, there is no sacrifice of any existing feature. Is it right? Also nand driver get simplified with removal of CPA, so that both HW SW error correction can go for same ecc calculation. Indeed that would be a simplification. I'm OK to submit a patch in this direction, but first I'd like to wait for the dust to settle on arch/arm/mach-omap2 and mtd/nand/omap2.c with Afzal patches and everything; things have become a bit complicated to follow recently :-) Afzal's changes are in are settled now. What about this set: http://lists.infradead.org/pipermail/linux-mtd/2012-October/044337.html I cannot see it in l2-mtd-2.6 ? Or did I miss something ? Yes, Afzal's changes are present in linux-next. I think it will get in next merge window. http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=drivers/mtd/nand/omap2.c;h=0002d5e94f0d0e3b84f36d2ccb505c95a30b4cdb;hb=cfc4410f5d3de0f68139ddffe065b9889a41d3c0 These changes not present in l2-mtd-2.6 Thanks Avinash Thanks, -- Ivan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] Device Power: introduce power controller
On Thu, Dec 6, 2012 at 11:46 AM, Jassi Brar jaswinder.si...@linaro.org wrote: The patch can make usb port deal with the 'power controller' only, and make it avoid to deal with regulators/clocks/... directly. I am curious too, except for clocks and voltage supplies (regulators), what other external resources does a chip need ? For example, one indicator LED which doesn't connect to the same power domain might need to be triggered after the power switch state is changed. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe 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 1/5] drivers : introduce device_path api
On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros rog...@ti.com wrote: Hi Jassi, On 12/01/2012 09:49 AM, Jassi Brar wrote: On Tue, Nov 27, 2012 at 10:32 PM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote: We should have a more generic solution in a more central location, like the device core. For example, each struct platform_device could have a list of resources to be enabled when the device is bound to a driver and disabled when the device is unbound. Such a list could include regulators, clocks, and whatever else people can invent. In this case, when it is created the ehci-omap.0 platform device could get an entry pointing to the LAN95xx's regulator. Then the regulator would automatically be turned on when the platform device is bound to the ehci-omap driver. How does this sound? That sounds much better, and it might come in handy for other types of devices than platform devices, so feel free to put this on the core 'struct device' instead if needed. Isn't enabling/disabling of clocks and regulators what dev.probe()/remove() of any driver already does? If we mean only board specific setup/teardown, still it would mean having the device core to do an extra 'probe' call when the current probe() is already meant to do whatever it takes to bring the device up. To my untrained eyes, it seem like messing with the probe()/remove()'s semantics. IMHO, if we really must implement something like that, may be we should employ some 'broadcast mechanism' so that anything anywhere in kernel knows which new device has been probed()/removed() successfully. I haven't thought exactly how because I am not sure even that would be the right way to approach PandaBoard's problem. Looking at Figure 15 – Panda USBB1 Interface Block Diagram of http://pandaboard.org/sites/default/files/board_reference/pandaboard-es-b/panda-es-b-manual.pdf gives me visions ... 1) OMAP doesn't provide the USB root-hub, but only ULPIPHY. It is USB3320C chip that employs OMAP's ULPIPHY to provide the root-hub. So we should have a platform device for USB3320C, the probe() of which should simply Actually the EHCI controller within OMAP provides the root hub with 3 ports but no PHY. One of them is connected to the USB3320 which is just a ULPI PHY. a) Enable REFCLK (FREF_CLK3_OUT) b) Reset itself by cycling RESETB (GPIO_62) c) Create one ehci-omap platform device c) is not appropriate. ehci-omap must be created before usb3320. (or in appropriate order if the above isn't) That way insmod/rmmod'ing the USB3320C driver would power-up/down the whole subsystem. Yes, this is where we can think of a generic PHY driver to make sure thy PHY has necessary resources enabled. In the Panda case it would be the PHY clock and RESET gpio. I wonder if ehci-omap should assume, besides regulator, a clock might also be need to setup for the transceiver chip. Maybe usbhs_bdata in board-omap4panda.c should have .reset_gpio_port[0] = GPIO_HUB_NRESET ? The LAN95xx chip still needs to be powered up and the PHY driver isn't the right place for that (though it could be done there as a hack). The closest we can get to emulating right USB behavior is to map the SET/CLEAR PORT_FEATURE of the root hub port to the regulator that powers the LAN95xx. This way, we still don't fall in the dynamically probed space, so we could still provide the regulator information to the ehci hub via platform data and handle the regulator in ehci_hub_control (Set/ClearPortFeature). I'm looking at this as a software workaround for all platforms not implementing the EHCI set port power feature correctly. The same could be repeated for other HCDs as well if required. IMHO it's not a matter of platforms not implementing EHCI set port power feature correctly, we should think about onboard devices connected to onboard non-root hubs. Setups like LAN9514 on Panda (HSIC too ?) that don't run on VBUS of USB, would like their local supply to be treated as if it came from the parent hub's port i.e, tie together the USB's set port power control with their OOB regulated power supply (U9 on PandaBoard). cheers. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] Device Power: introduce power controller
On 6 December 2012 18:48, Ming Lei tom.leim...@gmail.com wrote: On Thu, Dec 6, 2012 at 11:46 AM, Jassi Brar jaswinder.si...@linaro.org wrote: The patch can make usb port deal with the 'power controller' only, and make it avoid to deal with regulators/clocks/... directly. I am curious too, except for clocks and voltage supplies (regulators), what other external resources does a chip need ? For example, one indicator LED which doesn't connect to the same power domain might need to be triggered after the power switch state is changed. Hmm.. I am not sure if we could call an indicator LED a resource that a chip needs to be functional. Isn't how mmc core manages the indicator led, a better way? cheers. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/5] arm: omap2: support port power on lan95xx devices
On Thu, 6 Dec 2012, Andy Green wrote:
Right. The question is should it be done in this somewhat roundabout
way (you've got two separate assets for setting up this one thing), or
should the USB port code be responsible for explicitly checking if
there are any applicable assets when the port is created?
The advantange of the second approach is that it doesn't involve
checking all the ancestors every time a new device is added (and it
involves only one asset). The disadvantage is that it works only for
USB ports.
It's done in two steps to strongly filter candidate child devices
against being children of a known platform device. If you go around
that, you will be back to full device path matching with wildcards at
the USB child to determine if he is the one. So that's a feature not
an issue I think.
I don't follow. Suppose an asset is attached to ehci-omap.0 with its
string set to -0:1.0/port1 and the other members pointing to the
regulator, clock and so on. And suppose the USB port code, when
creating a new port, checks for a name match against all the assets
attached to its bus's host controller device structure. That should
do exactly what you want while using only one asset.
I can see doing it generically or not is equally a political issue as a
technical one, but I think if we bother to add this kind of support we
should prefer to do it generally. It's going to be about the same
amount of code.
Not quite. If you do it generally then you have to insert hooks at all
the places where a subsystem _might_ need it. If you do it
specifically then no hooks are needed at all -- just a match call at
the right place in the subsystem that needs it.
As Tony Lindgren said, even board-omap4panda.c itself is deprecated, to
project platform info into USB stack you either have to add DT code into
usb stack then to go find things directly, or provide a generic
methodology like assets which have the dt bindings done outside of any
subsystem and apply their operations outside the subsystem too.
Assuming DT can be extended to support assets, adding one asset will be
simpler than adding two.
To answer the question, we need to know how other subsystems might
want to use the asset-matching approach. My guess is that only a small
number of device types would care about assets (in the same way that
assets matter to USB ports but not to other USB device types). And it
might not be necessary to check against every ancestor; we might know
beforehand where to check (just as the USB port would know to look for
an asset attached to the host controller device).
Yes I think it boils down to buses in general can benefit from this.
They're the thing that dynamically - later - create child devices you
might need to target with what was ultimately platform information.
On Panda the other bus thing that can benefit is the WLAN module on
SDIO. In fact that's a very illuminating case for your question above.
Faced with exactly the same problem, that they needed to project
platform info on to SDIO-probed device instance to tell it what clock
rate it had been given, they invented an api which you can see today in
board-omap4panda.c and other boards there, wl12xx_set_platform_data().
This is from board-4430sdp:
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
.board_ref_clock = WL12XX_REFCLOCK_26,
.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
};
...
ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
You can find the other end of it here in
drivers/net/wireless/ti/wlcore/wl12xx_platform_data.c
static struct wl12xx_platform_data *platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
if (platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
if (!platform_data)
return -ENOMEM;
return 0;
}
when the driver for the device instance wants to get its platform data
it reads the static pointer via another api. Obviously if you want two
modules on your platform that's not so good.
Also it isn't type-safe, although that's probably not a big concern.
I doubt that's the only SDIO device that wants to know platform info.
So I think by providing a generic way we help other buses and devices.
I agree, assets look like a good way to improve this. In fact, to some
extent assets appear to be a generalization or extension of platform
data.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 12/05/2012 05:24 PM, Grant Likely wrote: On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: Hi Grant, On 12/05/2012 04:22 PM, Grant Likely wrote: On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote: This patch adds basic DT bindings for OMAP GPMC. The actual peripherals are instantiated from child nodes within the GPMC node, and the only type of device that is currently supported is NAND. Code was added to parse the generic GPMC timing parameters and some documentation with examples on how to use them. Successfully tested on an AM33xx board. Signed-off-by: Daniel Mack zon...@gmail.com --- Documentation/devicetree/bindings/bus/ti-gpmc.txt | 77 ++ .../devicetree/bindings/mtd/gpmc-nand.txt | 76 + arch/arm/mach-omap2/gpmc.c | 171 - 3 files changed, 323 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt new file mode 100644 index 000..7d2a645 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -0,0 +1,77 @@ +Device tree bindings for OMAP general purpose memory controllers (GPMC) + +The actual devices are instantiated from the child nodes of a GPMC node. + +Required properties: + + - compatible:Should be set to ti,gpmc Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? They are not 100% register compatible. There are a couple fields in the binding that are only applicable to OMAP3+ devices. The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. Ok, gotcha! I will do a register comparison and may be recommend to Daniel which compatible strings we will need. Thanks! Jon -- To unsubscribe from this list: send the line unsubscribe 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 12/05/2012 06:03 PM, Tony Lindgren wrote: * Grant Likely grant.lik...@secretlab.ca [121205 15:26]: On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: On 12/05/2012 04:22 PM, Grant Likely wrote: Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. The compatible property can also be used to figure out which ones need the workarounds in patch #4 of this series for the DT case. So we should be specific with the compatible. We should not merged patch #4. Daniel included this here because he is using this on the current mainline, however, this is not needed for linux-next and so we should drop it. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 06.12.2012 17:22, Jon Hunter wrote: On 12/05/2012 06:03 PM, Tony Lindgren wrote: * Grant Likely grant.lik...@secretlab.ca [121205 15:26]: On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: On 12/05/2012 04:22 PM, Grant Likely wrote: Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. The compatible property can also be used to figure out which ones need the workarounds in patch #4 of this series for the DT case. So we should be specific with the compatible. We should not merged patch #4. Daniel included this here because he is using this on the current mainline, however, this is not needed for linux-next and so we should drop it. I think we're talking about different things here since awhile. The patch I pointed you which is in mainline and which removes the reference to plat/gpmc.h from drivers/mtd/nand/omap2.c has nothing to do with my patch #4. It just solves Tony's concern that regarding the multi-arch zImages. My code in gpmc.c calls gpmc_nand_init() which in turn calls gpmc_hwecc_bch_capable(). Without path #4, gpmc_hwecc_bch_capable() will return 0, and the nand init will fail consequently, in mainline as well as in linux-next. I understood Tony that he wanted to remove the entiry function and do the check based on DT properties, which will then solve the problem on a different level. However, that change is planned for *after* the merge window. Daniel -- To unsubscribe from this list: send the line unsubscribe 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Hi Jon, On 06.12.2012 17:19, Jon Hunter wrote: On 12/05/2012 05:24 PM, Grant Likely wrote: On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: Hi Grant, On 12/05/2012 04:22 PM, Grant Likely wrote: On Wed, 5 Dec 2012 20:09:31 +0100, Daniel Mack zon...@gmail.com wrote: This patch adds basic DT bindings for OMAP GPMC. The actual peripherals are instantiated from child nodes within the GPMC node, and the only type of device that is currently supported is NAND. Code was added to parse the generic GPMC timing parameters and some documentation with examples on how to use them. Successfully tested on an AM33xx board. Signed-off-by: Daniel Mack zon...@gmail.com --- Documentation/devicetree/bindings/bus/ti-gpmc.txt | 77 ++ .../devicetree/bindings/mtd/gpmc-nand.txt | 76 + arch/arm/mach-omap2/gpmc.c | 171 - 3 files changed, 323 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt new file mode 100644 index 000..7d2a645 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -0,0 +1,77 @@ +Device tree bindings for OMAP general purpose memory controllers (GPMC) + +The actual devices are instantiated from the child nodes of a GPMC node. + +Required properties: + + - compatible: Should be set to ti,gpmc Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? They are not 100% register compatible. There are a couple fields in the binding that are only applicable to OMAP3+ devices. The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. Ok, gotcha! I will do a register comparison and may be recommend to Daniel which compatible strings we will need. Ok, thanks a lot! However, I don't know whether we should treat different models differently in the code yet, distiguished by their 'compatible' string. We should register the driver correctly so we can use the power of that feature once we get rid of the runtime-hacks (cpu_is_xxx() macros), but I think until we're there, we can well live with multiple compatible-entries that all map to the same driver, right? OTOH, we could also think about tieing num-waitpins and num-cs to a specific 'compatible' entry (by passing a struct along in .data members of of_device_id), but I'm not sure whether that's really better here. Daniel -- To unsubscribe from this list: send the line unsubscribe 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 v7 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On 12/06/2012 10:54 AM, Daniel Mack wrote: On 06.12.2012 17:22, Jon Hunter wrote: On 12/05/2012 06:03 PM, Tony Lindgren wrote: * Grant Likely grant.lik...@secretlab.ca [121205 15:26]: On Wed, 5 Dec 2012 16:33:48 -0600, Jon Hunter jon-hun...@ti.com wrote: On 12/05/2012 04:22 PM, Grant Likely wrote: Please, be specific. Use something like ti,am3340-gpmc or ti,omap3430-gpmc. The compatible property is a list so that new devices can claim compatibility with old. Compatible strings that are overly generic are a pet-peave of mine. We aim to use the binding for omap2,3,4,5 as well as the am33xx devices (which are omap based). Would it be sufficient to have ti,omap2-gpmc implying all omap2+ based devices or should we have a compatible string for each device supported? Are they each register-level compatible with one another? The general recommended approach here is to make subsequent silicon claim compatibility with the first compatible implementation. So, for an am3358 board: compatible = ti,am3358-gpmc, ti,omap2420-gpmc; Essentially, what this means is that ti,omap2420-gpmc is the generic value instead of omap2-gpmc. The reason for this is so that the value is anchored against a specific implementation, and not against something completely imaginary or idealized. If a newer version isn't quite compatible with the omap2420-gpmc, then it can drop the compatible claim and the driver really should be told about the new device. The compatible property can also be used to figure out which ones need the workarounds in patch #4 of this series for the DT case. So we should be specific with the compatible. We should not merged patch #4. Daniel included this here because he is using this on the current mainline, however, this is not needed for linux-next and so we should drop it. I think we're talking about different things here since awhile. The patch I pointed you which is in mainline and which removes the reference to plat/gpmc.h from drivers/mtd/nand/omap2.c has nothing to do with my patch #4. It just solves Tony's concern that regarding the multi-arch zImages. My code in gpmc.c calls gpmc_nand_init() which in turn calls gpmc_hwecc_bch_capable(). Without path #4, gpmc_hwecc_bch_capable() will return 0, and the nand init will fail consequently, in mainline as well as in linux-next. Ok, yes I see that now. I should have looked more closely at linux-next. I understood Tony that he wanted to remove the entiry function and do the check based on DT properties, which will then solve the problem on a different level. However, that change is planned for *after* the merge window. Well now that it is only being called from within the platform code and not from drivers, it is ok. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
