Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
Hi, On Thursday 13 November 2014 04:59 PM, Roger Quadros wrote: [...] What about performance impact? OMAP3 doesn't have ELM module. So error location for BCH8 has to be done in software. Performance impact happens only when there are bit-flips in an page. - For BCH8_HW ECC schemes ELM comes in the picture only when during reads there is an ECC mis-match, if there is no ECC mis-match GPMC engine alone handles all the decoding part. - For BCH8_SW ECC schemes Same-way, lib/bch.8: decode_bch() path is taken only when ECC mismatch is detected on the read path, for normal read/write GPMC engine handles everything. Yes, you may argue that with aging of the NAND the occurrence of bit-flips is common. That's true, but for new devices especially for SLC NAND the occurrence is usually rare on fresh parts. Also considering that most SLC are now manufactured in matured technologies. Also, if you are using UBIFS on top of NAND, then it will scrub the data on first detection of bit-flips, thereby reducing the accumulation of bit-flips and thereby conserving read performance. [...] Right no objections to using BCH8 for rootfs, except it stopped working over past year or so. This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine. So it seems nobody has used/tested BCH8-sw. I have tested BCH8_SW on both AM335x and later SoC, and checked its compatibility with various combinations of u-boot. [1] should give you some indications of various combinations users can try .. with regards, pekon [1] http://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide#ECC_schemes_support Powered by BigRock.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 v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
Hi Jyri,
On 14.11.2014 16:37, Vladimir Zapolskiy wrote:
Hi Jyri,
On 12.11.2014 16:41, Jyri Sarha wrote:
Signed-off-by: Jyri Sarha jsa...@ti.com
---
drivers/video/fbdev/omap2/dss/hdmi.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index a6e08ff..6d129f2 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
struct hdmi_audio_format *aud_fmt);
void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
struct hdmi_audio_dma *aud_dma);
-static inline bool hdmi_mode_has_audio(int mode)
+static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
{
-return mode == HDMI_HDMI ? true : false;
+return cfg-hdmi_dvi_mode == HDMI_HDMI ? true : false;
}
/* HDMI DRV data */
would it be possible for you to rearrange the changes preserving the
following sequence?
1) 13/19
2) 15/19
3) 11/19
4) 14/19
5) 16/19
Otherwise I'm worried that someone's git rebase may fail.
sorry, git bisect of course.
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
On Fri, Nov 14, 2014 at 10:37:27AM +0530, Vignesh R wrote: From: Brad Griffis bgrif...@ti.com TSC interrupt handler had udelay to avoid reporting of false pen-up interrupt to user space. This patch implements workaround suggesting in Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay and touchscreen lag. This also improves performance of touchscreen and eliminates sudden jump of cursor at touch release. I back ported this series onto v3.15.1 in order to try this out on a custom, beaglebone-like board. With this series, the touch is really broken. (I had fixed the pen up problem in a totally different way for a customer, and so I wanted to try out your solution.) I will try to port the board code to a more recent kernel to try your series again. With which kernel version did you test your patches? And which board? Thanks, Richard -- 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 v12 11/15] arm: omap1: Migrate debug_ll macros to use 8250.S
Hi, On Fri, Oct 24, 2014 at 11:54:32AM +0100, Daniel Thompson wrote: + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. [...] + on OMAP1 based platforms (expect OMAP730) on the UART2. [...] + on OMAP1 based platforms (expect OMAP730) on the UART3. ^^ Spelling again wrong. I think it was already corrected in v11? A. -- 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 v8 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
Arnd Bergmann wrote: On Friday 14 November 2014 15:11:58 Marek Szyprowski wrote: I assume that after all comments from previous versions, no more changes are needed to this patchset and I would really like to have it queued to v3.19. Arnd, Olof: could you take this patchset thought arm-soc tree? It already contains all dependencies. Kukjin: could you ack this patchset? I'd rather see this merged through Russell's tree, as most of the patches are for core code, and only three are for the platform. For the exynos patches: Acked-by: Arnd Bergmann a...@arndb.de I'm also fine on this series for the exynos stuff: Acked-by: Kukjin Kim kgene@samsung.com And agree with Arnd's suggestion to handle in rmk tree. (I think seems this has no dependency with samsung tree) Thanks, Kukjin -- 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
