Re: [PATCH 1/3] mtd: nand: omap: Revert to using software ECC by default
On Wed, Aug 6, 2014 at 11:02 AM, Roger Quadros wrote: > Hi Gražvydas, > > On 08/05/2014 07:15 PM, Grazvydas Ignotas wrote: >> On Tue, Aug 5, 2014 at 1:11 PM, Roger Quadros wrote: >>> For v3.12 and prior, 1-bit Hamming code ECC via software was the >>> default choice. Commit c66d039197e4 in v3.13 changed the behaviour >>> to use 1-bit Hamming code via Hardware using a different ECC layout >>> i.e. (ROM code layout) than what is used by software ECC. >>> >>> This ECC layout change causes NAND filesystems created in v3.12 >>> and prior to be unusable in v3.13 and later. So revert back to >>> using software ECC by default if an ECC scheme is not explicitely >>> specified. >>> >>> This defect can be observed on the following boards during legacy boot >>> >>> -omap3beagle >>> -omap3touchbook >>> -overo >>> -am3517crane >>> -devkit8000 >>> -ldp >>> -3430sdp >> >> omap3pandora is also using sw ecc, with ubifs. Some time ago I tried >> booting mainline (I think it was 3.14) with rootfs on NAND, and while >> it did boot and reached a shell, there were lots of ubifs errors, fs >> got corrupted and I lost all my data. I used to be able to boot >> mainline this way fine sometime ~3.8 release. It's interesting that >> 3.14 was able to read the data, even with wrong ecc setup. > > This is due to another bug introduced in 3.7 by commit > 65b97cf6b8deca3ad7a3e00e8316bb89617190fb. > Because of that bug (i.e. inverted CS_MASK in omap_calculate_ecc), > omap_calculate_ecc() always fails with -EINVAL and calculated ECC bytes are > always 0. I'll be sending a patch to fix that as well. But that will only > affect the cases where OMAP_ECC_HAM1_CODE_HW is used which happened for > pandora from 3.13 onwards. > >> >> Do you think it's safe again to boot ubifs created on 3.2 after >> applying this series? >> > > Yes. If you boot pandora using legacy boot (non DT method), it passes 0 for > .ecc_opt in pandora_nand_data. This used to mean > OMAP_ECC_HAMMING_CODE_DEFAULT which is software ecc. i.e. NAND_ECC_SOFT with > default ECC layout. Until the above mentioned commits changed the meaning. We > now call that option OMAP_ECC_HAM1_CODE_SW. > > Please let me know if it works for you. Thanks. Yes it does, thank you. Tested-by: Grazvydas Ignotas Found something new in dmesg though: [1.542755] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xbc [1.549621] nand: Micron MT29F4G16ABBDA3W [1.553894] nand: 512MiB, SLC, page size: 2048, OOB size: 64 [1.560058] nand: WARNING: omap2-nand.0: the ECC used on your system is too weak compared to the one required by the NAND chip Do you think it's best to migrate to different ECC scheme? It would be better to avoid that so that users can freely change kernels and the bootloader wouldn't have to be changed.. -- Gražvydas -- 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: TSC2004 driver
On Wed, Aug 6, 2014 at 5:28 PM, Sebastian Reichel wrote: > Hi, > > On Wed, Aug 06, 2014 at 05:13:19PM -0500, Michael Welling wrote: >> The tsc2005 still needs devicetree conversion, so it is at least 2 >> patches away from where I can use it. > > TSC2005 DT support has been added in 3.16: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a38cfebb56898633687ab337fd53710e63a0aedd Sorry for the misinformation. If someone else is volunteering to do the regmap support let me know. > > -- Sebastian -- 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: TSC2004 driver
Hi, On Wed, Aug 06, 2014 at 05:13:19PM -0500, Michael Welling wrote: > The tsc2005 still needs devicetree conversion, so it is at least 2 > patches away from where I can use it. TSC2005 DT support has been added in 3.16: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a38cfebb56898633687ab337fd53710e63a0aedd -- Sebastian signature.asc Description: Digital signature
Re: TSC2004 driver
On Wed, Aug 6, 2014 at 4:16 PM, Dmitry Torokhov wrote: > On Wed, Aug 06, 2014 at 10:33:18PM +0200, Joachim Eastwood wrote: >> On 6 August 2014 21:37, Dmitry Torokhov wrote: >> > Hi Michael, >> > >> > On Tue, Aug 05, 2014 at 12:06:40PM -0500, Michael Welling wrote: >> >> The TSC2004 driver has yet to appear in the mainline kernel. We have >> >> been using the driver referenced here as provided by TI: >> >> >> >> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html >> >> >> >> Are there any plans of supporting this device in the mainline kernel? >> > >> > I still believe that support for TSC2004 should be added 5to tsc2007, they >> > are >> > too much alike to be separate drivers. >> >> I tried to add tsc2004 support to the tsc2007 driver but I didn't >> really get it to work properly because the tsc2007 interrupt handling >> differs from what tsc2004 needs. > > OK. > >> >> I think it would be better to add tsc2004 support to the tsc2005 >> driver. They only difference between those two chips is the interface >> (i2c vs spi). If regmap was added to tsc2005 I think it should be easy >> to support tsc2004. > > That would also be acceptable. The tsc2005 still needs devicetree conversion, so it is at least 2 patches away from where I can use it. I have missed the window for my companies OE release so I doubt I will have time to code in all or any of this. I am in the process of routing a AM335x SoM which obsoletes this AM3517 one so my resources will be elsewhere. > > Thanks. > > -- > Dmitry -- 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: TSC2004 driver
On Wed, Aug 06, 2014 at 10:33:18PM +0200, Joachim Eastwood wrote: > On 6 August 2014 21:37, Dmitry Torokhov wrote: > > Hi Michael, > > > > On Tue, Aug 05, 2014 at 12:06:40PM -0500, Michael Welling wrote: > >> The TSC2004 driver has yet to appear in the mainline kernel. We have > >> been using the driver referenced here as provided by TI: > >> > >> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html > >> > >> Are there any plans of supporting this device in the mainline kernel? > > > > I still believe that support for TSC2004 should be added 5to tsc2007, they > > are > > too much alike to be separate drivers. > > I tried to add tsc2004 support to the tsc2007 driver but I didn't > really get it to work properly because the tsc2007 interrupt handling > differs from what tsc2004 needs. OK. > > I think it would be better to add tsc2004 support to the tsc2005 > driver. They only difference between those two chips is the interface > (i2c vs spi). If regmap was added to tsc2005 I think it should be easy > to support tsc2004. That would also be acceptable. Thanks. -- Dmitry -- 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: TSC2004 driver
On 6 August 2014 21:37, Dmitry Torokhov wrote: > Hi Michael, > > On Tue, Aug 05, 2014 at 12:06:40PM -0500, Michael Welling wrote: >> The TSC2004 driver has yet to appear in the mainline kernel. We have >> been using the driver referenced here as provided by TI: >> >> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html >> >> Are there any plans of supporting this device in the mainline kernel? > > I still believe that support for TSC2004 should be added 5to tsc2007, they are > too much alike to be separate drivers. I tried to add tsc2004 support to the tsc2007 driver but I didn't really get it to work properly because the tsc2007 interrupt handling differs from what tsc2004 needs. I think it would be better to add tsc2004 support to the tsc2005 driver. They only difference between those two chips is the interface (i2c vs spi). If regmap was added to tsc2005 I think it should be easy to support tsc2004. >> >> Mysteriously a device tree entry was found in the following file: >> arch/arm/boot/dts/omap4-var-som-om44.dtsi >> >> This is obviously pointing to an out of tree driver that is not easily >> obtained. I have patches that add tsc2004 support to the tsc2007 driver, but I really can't recommend them. The interrupt handling is broken so for each touch event the chip needs to be software reset... The driver you posted a link to above also has flaw btw. regards Joachim Eastwood >> Suggestions? > > Thanks. > > -- > Dmitry > -- > 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 -- 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: TSC2004 driver
Hi Michael, On Tue, Aug 05, 2014 at 12:06:40PM -0500, Michael Welling wrote: > The TSC2004 driver has yet to appear in the mainline kernel. We have > been using the driver referenced here as provided by TI: > > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg22018.html > > Are there any plans of supporting this device in the mainline kernel? I still believe that support for TSC2004 should be added 5to tsc2007, they are too much alike to be separate drivers. > > Mysteriously a device tree entry was found in the following file: > arch/arm/boot/dts/omap4-var-som-om44.dtsi > > This is obviously pointing to an out of tree driver that is not easily > obtained. > > Suggestions? Thanks. -- Dmitry -- 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: Working in custom board - supporting and patches
Hi, On Wed, Aug 06, 2014 at 11:44:47PM +0700, Boris Vinogradov wrote: > Hello, > > I'm using another arm boards and know basics in linux kernel. > > I need a little help (sorry, my english it's so bad) - Now I'm writed > patches for AM335x(BeagleBone Black) and need to append it in mainline > kernel - because this code activity using in another distribution. But > usign with selfpatching. take a look at Documentation/SubmittingPatches, Documentation/CodingStyle and Documentation/SubmitChecklist. That'll help you. After that, just send a series os patches to the proper interested parties (use scripts/get_maintainer.pl to help figuring out who to add to Cc). good luck. -- balbi signature.asc Description: Digital signature
Working in custom board - supporting and patches
Hello, I'm using another arm boards and know basics in linux kernel. I need a little help (sorry, my english it's so bad) - Now I'm writed patches for AM335x(BeagleBone Black) and need to append it in mainline kernel - because this code activity using in another distribution. But usign with selfpatching. Thanks, Boris Vinoradov (emb developer, russia). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
Add machine driver support for BeagleBone-Black HDMI audio. BBB has
NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The
44100 Hz sample-rate and it's multiples can not be accurately produced
on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.
Signed-off-by: Jyri Sarha
---
.../bindings/sound/davinci-evm-audio.txt |4 +-
sound/soc/davinci/davinci-evm.c| 82 +++-
2 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 963e100..c137436 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -1,7 +1,9 @@
* Texas Instruments SoC audio setups with TLV320AIC3X Codec
Required properties:
-- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx
+- compatible : "ti,da830-evm-audio" : for DM365/DA8xx/OMAPL1x/AM33xx
+ "ti,am335x-beaglebone-black-audio" : for Beaglebone-black HDMI
+audio
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index a50010e..9b98667 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -83,12 +84,46 @@ static int evm_hw_params(struct snd_pcm_substream
*substream,
return 0;
}
+/* If changing sample format the tda998x configuration (REG_CTS_N) needs
+ to be changed. */
+#define TDA998X_SAMPLE_FORMAT SNDRV_PCM_FORMAT_S32_LE
+static int evm_tda998x_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_mask *fmt = constrs_mask(&runtime->hw_constraints,
+ SNDRV_PCM_HW_PARAM_FORMAT);
+ snd_mask_none(fmt);
+ snd_mask_set(fmt, TDA998X_SAMPLE_FORMAT);
+
+ return evm_startup(substream);
+}
+
+static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ struct snd_soc_card *soc_card = rtd->card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+
+ return snd_soc_dai_set_sysclk(cpu_dai, 0, drvdata->sysclk,
+ SND_SOC_CLOCK_IN);
+}
+
static struct snd_soc_ops evm_ops = {
.startup = evm_startup,
.shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
+
+static struct snd_soc_ops evm_tda998x_ops = {
+ .startup = evm_tda998x_startup,
+ .shutdown = evm_shutdown,
+ .hw_params = evm_tda998x_hw_params,
+};
+
/* davinci-evm machine dapm widgets */
static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = {
SND_SOC_DAPM_HP("Headphone Jack", NULL),
@@ -149,6 +184,35 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
return 0;
}
+static const struct snd_soc_dapm_widget tda998x_dapm_widgets[] = {
+ SND_SOC_DAPM_OUTPUT("HDMI Out"),
+};
+
+static int evm_tda998x_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ struct snd_soc_dapm_context *dapm = &rtd->codec->dapm;
+ struct snd_soc_card *soc_card = rtd->card;
+ int ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 1);
+ if (ret < 0)
+ return ret;
+
+ snd_soc_dapm_new_controls(dapm, tda998x_dapm_widgets,
+ ARRAY_SIZE(tda998x_dapm_widgets));
+
+ ret = snd_soc_of_parse_audio_routing(soc_card, "ti,audio-routing");
+
+ /* not connected */
+ snd_soc_dapm_disable_pin(dapm, "RX");
+
+ /* always connected */
+ snd_soc_dapm_enable_pin(dapm, "HDMI Out");
+
+ return 0;
+}
+
/* davinci-evm digital audio interface glue - connects codec <--> CPU */
static struct snd_soc_dai_link dm6446_evm_dai = {
.name = "TLV320AIC3X",
@@ -334,7 +398,7 @@ static struct snd_soc_card da850_snd_soc_card = {
#if defined(CONFIG_OF)
/*
- * The struct is used as place holder. It will be completely
+ * The structs are used as place holders. They will be completely
* filled with data from dt node.
*/
static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
@@ -347,10 +411,24 @@ static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
SND_SOC_DAIFMT_IB_NF,
};
+static struct snd_soc_dai_link evm_dai_tda998x_hdmi = {
+
[PATCH 2/9] clk: add gpio controlled clock
The added clk-gpio is a basic clock that can be enabled and disabled
trough a gpio output. The DT binding document for the clock is also
added. For EPROBE_DEFER handling the registering of the clock has to
be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/clock/gpio-clock.txt | 21 ++
drivers/clk/Makefile |1 +
drivers/clk/clk-gpio.c | 206
include/linux/clk-provider.h | 23 +++
4 files changed, 251 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt
create mode 100644 drivers/clk/clk-gpio.c
diff --git a/Documentation/devicetree/bindings/clock/gpio-clock.txt
b/Documentation/devicetree/bindings/clock/gpio-clock.txt
new file mode 100644
index 000..54fea39
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio controlled clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "gpio-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = "gpio-clock";
+ clocks = <&parentclk>;
+ #clock-cells = <0>;
+ enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 567f102..bde8fdf 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
obj-$(CONFIG_COMMON_CLK) += clk-fractional-divider.o
+obj-$(CONFIG_COMMON_CLK) += clk-gpio.o
# hardware specific clock types
# please keep this section sorted lexicographically by file/directory path name
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
new file mode 100644
index 000..1eff97c
--- /dev/null
+++ b/drivers/clk/clk-gpio.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (C) 2012 - 2014 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Jyri Sarha
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Gpio controlled clock implementation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * DOC: basic gpio controlled clock which can be enabled and disabled
+ * with gpio output
+ * Traits of this clock:
+ * prepare - clk_(un)prepare only ensures parent is (un)prepared
+ * enable - clk_enable and clk_disable are functional & control gpio
+ * rate - inherits rate from parent. No clk_set_rate support
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
+
+static int clk_gpio_enable(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ gpiod_set_value(clk->gpiod, 1);
+
+ return 0;
+}
+
+static void clk_gpio_disable(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ gpiod_set_value(clk->gpiod, 0);
+}
+
+static int clk_gpio_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gpio *clk = to_clk_gpio(hw);
+
+ return gpiod_get_value(clk->gpiod);
+}
+
+const struct clk_ops clk_gpio_ops = {
+ .enable = clk_gpio_enable,
+ .disable = clk_gpio_disable,
+ .is_enabled = clk_gpio_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_gpio_ops);
+
+/**
+ * clk_register_gpio - register a gpip clock with the clock framework
+ * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_name: name of this clock's parent
+ * @gpiod: gpio descriptor to control this clock
+ */
+struct clk *clk_register_gpio(struct device *dev, const char *name,
+ const char *parent_name, struct gpio_desc *gpiod,
+ unsigned long flags)
+{
+ struct clk_gpio *clk_gpio = NULL;
+ struct clk *clk = ERR_PTR(-EINVAL);
+ struct clk_init_data init = { NULL };
+ unsigned long gpio_flags;
+ int err;
+
+ if (gpiod_is_active_low(gpiod))
+ gpio_flags = GPIOF_OUT_INIT_HIGH;
+ else
+ gpio_flags = GPIOF_OUT_INIT_LOW;
+
+ if (dev)
+ err = devm_gpio_request_one(dev, desc_to_gpio(gpiod),
+ gpio_flags, name);
+ else
+ err = gpio_request_one(desc_to_gpio(gpiod), gpio_flags, name);
+
+ if (err) {
+ pr_err("%s: %s: Error requesting clock control gpio %u\n",
+ __func__, name, desc_t
[PATCH 3/9] drm/tilcdc: Add I2S HDMI audio config for tda998x
The configuration is needed for HDMI audio. The "swap" and "mirr"
parameters have to be correctly set in the configuration in order to
have proper colors in the HDMI picture.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 595068b..e43240a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "tilcdc_drv.h"
@@ -111,8 +112,29 @@ static const struct drm_encoder_helper_funcs
slave_encoder_helper_funcs = {
.restore= drm_i2c_encoder_restore,
};
+static struct tda998x_encoder_params tda998x_pdata = {
+ .swap_b = 0x3,
+ .mirr_b = 0x0,
+ .swap_a = 0x2,
+ .mirr_a = 0x0,
+ .swap_d = 0x1,
+ .mirr_d = 0x0,
+ .swap_c = 0x0,
+ .mirr_c = 0x0,
+ .swap_f = 0x5,
+ .mirr_f = 0x0,
+ .swap_e = 0x4,
+ .mirr_e = 0x0,
+ .audio_cfg = 0x3, /* I2S mode */
+ .audio_clk_cfg = 1, /* select clock pin */
+ .audio_frame[1] = 1,/* channels - 1 */
+ .audio_format = AFMT_I2S,
+ .audio_sample_rate = 48000,
+};
+
static const struct i2c_board_info info = {
- I2C_BOARD_INFO("tda998x", 0x70)
+ I2C_BOARD_INFO("tda998x", 0x70),
+ .platform_data = &tda998x_pdata,
};
static struct drm_encoder *slave_encoder_create(struct drm_device *dev,
--
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
[PATCH 6/9] ARM: dts: am33xx: Add external clock provider
Add external clock provaider for am33xx devices.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am33xx.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4a4e02d..5093c64 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -92,6 +92,16 @@
pinctrl-single,function-mask = <0x7f>;
};
+ ext_clocks {
+ compatible = "ti,external-clocks";
+
+ ext_clocks: clocks {
+ };
+
+ ext_clockdomains: clockdomains {
+ };
+ };
+
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex. Since
--
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
[PATCH 5/9] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
Adds configuration option for HDMI audio support for AM33XX based boards with NXP TDA998x HDMI transmitter. The audio is connected to NXP TDA998x trough McASP running in i2s mode. Signed-off-by: Jyri Sarha --- sound/soc/davinci/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index b310dd3..59c61a0 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -37,6 +37,18 @@ config SND_AM33XX_SOC_EVM AM335X-EVMSK, and BeagelBone with AudioCape boards have this setup. +config SND_AM335X_SOC_NXPTDA_EVM + tristate "HDMI Audio for the AM33XX chip based boards with TDA998x" + depends on SND_EDMA_SOC && SOC_AM33XX && DRM_I2C_NXP_TDA998X + select SND_SOC_HDMI_CODEC + select SND_DAVINCI_SOC_MCASP + select SND_DAVINCI_SOC_GENERIC_EVM + help + Say Y or M if you want to add support for HDMI SoC audio on + AM33XX boards with NXP TDA998x HDMI transmitter. For example + BeagleBoneBack. The audio is connected to NXP TDA998x trough + McASP running in i2s mode. + config SND_DAVINCI_SOC_EVM tristate "SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM" depends on SND_DAVINCI_SOC && I2C -- 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
[PATCH 7/9] ARM: dts: am335x-boneblack: Add HDMI audio support
Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio,
and sound nodes.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 54
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 305975d..c3c4618 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -59,12 +59,50 @@
0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
AM33XX_PIN_OUTPUT */
>;
};
+
+ mcasp0_pins: mcasp0_pins {
+ pinctrl-single,pins = <
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE0)/*
mcasp0_ahclkx.mcasp0_ahclkx */
+ 0x19c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mcasp0_ahclkr.mcasp0_axr2 */
+ 0x194 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
mcasp0_fsx.mcasp0_fsx */
+ 0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mcasp0_aclkx.mcasp0_aclkx */
+ 0x06c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a11.GPIO1_27 */
+ >;
+ };
};
&lcdc {
status = "okay";
};
+&mcasp0{
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcasp0_pins>;
+ status = "okay";
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 0
+ >;
+ tx-num-evt = <1>;
+ rx-num-evt = <1>;
+};
+
+&ext_clocks {
+ clk_mcasp0_fixed: clk_mcasp0_fixed {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24576000>;
+ };
+
+ clk_mcasp0: clk_mcasp0 {
+ #clock-cells = <0>;
+ compatible = "gpio-clock";
+ clocks = <&clk_mcasp0_fixed>;
+ enable-gpios = <&gpio1 27 0>; /* BeagleBone Black Clk enable on
GPIO1_27 */
+ };
+};
+
/ {
hdmi {
compatible = "ti,tilcdc,slave";
@@ -74,4 +112,20 @@
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
status = "okay";
};
+
+ hdmi_audio: hdmi_audio@0 {
+ compatible = "linux,hdmi-audio";
+ status = "okay";
+ };
+
+ sound {
+ compatible = "ti,am335x-beaglebone-black-audio";
+ ti,model = "TI BeagleBone Black";
+ ti,audio-codec = <&hdmi_audio>;
+ ti,mcasp-controller = <&mcasp0>;
+ ti,audio-routing =
+ "HDMI Out", "TX";
+ clocks = <&clk_mcasp0>;
+ clock-names = "mclk";
+ };
};
--
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
[PATCH 9/9] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support
Select CONFIG_SND_EDMA_SOC=m and CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m for BBB HDMI audio. Signed-off-by: Jyri Sarha --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 8b07fda..73dbfad 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -222,7 +222,9 @@ CONFIG_SND_DEBUG=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_SOC=m CONFIG_SND_OMAP_SOC=m +CONFIG_SND_EDMA_SOC=m CONFIG_SND_AM33XX_SOC_EVM=m +CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m CONFIG_SND_DAVINCI_SOC=m CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m -- 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
[PATCH 8/9] ARM: OMAP2+: omap2plus_defconfig: TDA998X HDMI trough tilcdc,slave
Select CONFIG_DRM=m, CONFIG_DRM_I2C_NXP_TDA998X=m, and CONFIG_DRM_TILCDC=m, for Beaglebone-Black HDMI video support. Signed-off-by: Jyri Sarha --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 536a137..8b07fda 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -191,6 +191,9 @@ CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_PBIAS=y +CONFIG_DRM=m +CONFIG_DRM_I2C_NXP_TDA998X=m +CONFIG_DRM_TILCDC=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 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
[PATCH 1/9] ASoC: mcasp: Fix implicit BLCK divider setting
The implicit BLCK divider setting was broken by "ASoC: mcasp: don't
override bclk divider if it was provided by the machine"-patch. After
the BCLK divider is implicitly set for the first time the
mcasp->bclk_div gets a non zero value and the implicit setting is
"turned off".
Signed-off-by: Jyri Sarha
---
sound/soc/davinci/davinci-mcasp.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index c28508d..6a6b2ff 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -403,7 +403,8 @@ out:
return ret;
}
-static int davinci_mcasp_set_clkdiv(struct snd_soc_dai *dai, int div_id, int
div)
+static int __davinci_mcasp_set_clkdiv(struct snd_soc_dai *dai, int div_id,
+ int div, bool explicit)
{
struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(dai);
@@ -420,7 +421,8 @@ static int davinci_mcasp_set_clkdiv(struct snd_soc_dai
*dai, int div_id, int div
ACLKXDIV(div - 1), ACLKXDIV_MASK);
mcasp_mod_bits(mcasp, DAVINCI_MCASP_ACLKRCTL_REG,
ACLKRDIV(div - 1), ACLKRDIV_MASK);
- mcasp->bclk_div = div;
+ if (explicit)
+ mcasp->bclk_div = div;
break;
case 2: /* BCLK/LRCLK ratio */
@@ -434,6 +436,12 @@ static int davinci_mcasp_set_clkdiv(struct snd_soc_dai
*dai, int div_id, int div
return 0;
}
+static int davinci_mcasp_set_clkdiv(struct snd_soc_dai *dai, int div_id,
+ int div)
+{
+ return __davinci_mcasp_set_clkdiv(dai, div_id, div, 1);
+}
+
static int davinci_mcasp_set_sysclk(struct snd_soc_dai *dai, int clk_id,
unsigned int freq, int dir)
{
@@ -738,7 +746,7 @@ static int davinci_mcasp_hw_params(struct snd_pcm_substream
*substream,
"Inaccurate BCLK: %u Hz / %u != %u Hz\n",
mcasp->sysclk_freq, div, bclk_freq);
}
- davinci_mcasp_set_clkdiv(cpu_dai, 1, div);
+ __davinci_mcasp_set_clkdiv(cpu_dai, 1, div, 0);
}
ret = mcasp_common_hw_param(mcasp, substream->stream,
--
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
[PATCH 0/9] Beaglebone-Black HDMI audio
The code has a functional dependency to: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg108199.html Without the above patch the audio card does not probe. The code has been rebased on top of Linux 3.16 merged with git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next with http://www.mail-archive.com/linux-omap@vger.kernel.org/msg108199.html cherry-picked on top. All patches have gone trough some cleaning up since the RFC version of these patches over half a year ago. Jyri Sarha (9): ASoC: mcasp: Fix implicit BLCK divider setting clk: add gpio controlled clock drm/tilcdc: Add I2S HDMI audio config for tda998x ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus ASoC: davinci: HDMI audio build for AM33XX and TDA998x ARM: dts: am33xx: Add external clock provider ARM: dts: am335x-boneblack: Add HDMI audio support ARM: OMAP2+: omap2plus_defconfig: TDA998X HDMI trough tilcdc,slave ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support .../devicetree/bindings/clock/gpio-clock.txt | 21 ++ .../bindings/sound/davinci-evm-audio.txt |4 +- arch/arm/boot/dts/am335x-boneblack.dts | 54 + arch/arm/boot/dts/am33xx.dtsi | 10 + arch/arm/configs/omap2plus_defconfig |5 + drivers/clk/Makefile |1 + drivers/clk/clk-gpio.c | 206 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- include/linux/clk-provider.h | 23 +++ sound/soc/davinci/Kconfig | 12 ++ sound/soc/davinci/davinci-evm.c| 82 +++- sound/soc/davinci/davinci-mcasp.c | 14 +- 12 files changed, 449 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt create mode 100644 drivers/clk/clk-gpio.c -- 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
Hi
Can I talk to you, I will be very glad if you permit me to talk to you for an important deal. Regards, KM. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd: nand: omap: Revert to using software ECC by default
Hi Pekon, On 08/05/2014 11:30 PM, pe...@pek-sem.com wrote: > Hi Roger, > > On Tuesday 05 August 2014 09:45 PM, Grazvydas Ignotas wrote: >> On Tue, Aug 5, 2014 at 1:11 PM, Roger Quadros wrote: >>> For v3.12 and prior, 1-bit Hamming code ECC via software was the >>> default choice. Commit c66d039197e4 in v3.13 changed the behavior >>> to use 1-bit Hamming code via Hardware using a different ECC layout >>> i.e. (ROM code layout) than what is used by software ECC. >>> > As per OMAP3 TRM [1], the NAND ECC layout required for > NAND boot is same as that of OMAP_ECC_HAM1_CODE_HW. So No. The layout is different. What I mean by OMAP_ECC_HAM1_CODE_SW is what earlier was OMAP_ECC_HAMMING_CODE_DEFAULT. It sets nand.ecc.mode to NAND_ECC_SOFT and doesn't use OMAP ROM code layout. > above mentioned 'commit c66d039197e4' does not break > backward compatibility as far as NAND boot is concerned. It does. Grazvydas has reported it and I have observed it on omap3beagle with legacy boot when switching from v3.12 to v3.13 and later. > > AFAIK, all users on OMAP3 used HAM1_HW which is same > as HAM1 today. So unless we have a real OMAP3 user who > (1) had created file-system using HAM1_SW && > (2) now wants to migrate to new kernel, I don't think > its wise to re-introduce HAM1_SW4 ECC schemes. many boards using legacy boot don't explicitly set ecc_opt parameter of nand_platform_data. So that is set to 0. commit c66d039197e4 changed the meaning from default ECC layout to OMAP ROM code layout and hence the regressions. > > Instead we are trying to push OMAP3 users to migrate to > BCH4_SW (supported by ROM) or BCH8_SW ECC schemes. > > Please understand > commit c66d039197e42af8867e5d0d9b904daf0fb9e6bc > was part of larger series to clean-up NAND driver and > remove obsolete or redundant code. So this was > intentional change. > > > >>> This ECC layout change causes NAND filesystems created in v3.12 >>> and prior to be unusable in v3.13 and later. So revert back to >>> using software ECC by default if an ECC scheme is not explicitely >>> specified. >>> >>> This defect can be observed on the following boards during legacy boot >>> >>> -omap3beagle >>> -omap3touchbook >>> -overo >>> -am3517crane >>> -devkit8000 >>> -ldp >>> -3430sdp >> >> omap3pandora is also using sw ecc, with ubifs. Some time ago I tried >> booting mainline (I think it was 3.14) with rootfs on NAND, and while >> it did boot and reached a shell, there were lots of ubifs errors, fs >> got corrupted and I lost all my data. I used to be able to boot >> mainline this way fine sometime ~3.8 release. It's interesting that >> 3.14 was able to read the data, even with wrong ecc setup. >> >> Do you think it's safe again to boot ubifs created on 3.2 after >> applying this series? >> > Are you sure you are using "sw" ECC scheme ? > Can you please share the ecc-layout of the NAND page, because ecc-layout for software scheme depends on oob size. http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_base.c#L53 > as per [1] you should not be able to Boot from NAND then. Bootpartition and filesystem partition are different. Boot partition needs to be compatible with OMAP ROM code layout but root filesystem doesn't need to be. I agree that it is best to use the same for but if boards have been using a different layout for filesystem then we need to maintain backward compatibility. > > IIRC.. > - ECC layout of HAM1_SW has ECC bytes towards end of OOB-section. > - ECC layout of HAM1_HW has ECC bytes towards staring of OOB section. The main difference between sw layout and ROM code layout is - sw layout always starts at offset 0 - rom layout starts at 1 for x8 device and 2 for x16 device. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd: nand: omap: Revert to using software ECC by default
Hi Gražvydas, On 08/05/2014 07:15 PM, Grazvydas Ignotas wrote: > On Tue, Aug 5, 2014 at 1:11 PM, Roger Quadros wrote: >> For v3.12 and prior, 1-bit Hamming code ECC via software was the >> default choice. Commit c66d039197e4 in v3.13 changed the behaviour >> to use 1-bit Hamming code via Hardware using a different ECC layout >> i.e. (ROM code layout) than what is used by software ECC. >> >> This ECC layout change causes NAND filesystems created in v3.12 >> and prior to be unusable in v3.13 and later. So revert back to >> using software ECC by default if an ECC scheme is not explicitely >> specified. >> >> This defect can be observed on the following boards during legacy boot >> >> -omap3beagle >> -omap3touchbook >> -overo >> -am3517crane >> -devkit8000 >> -ldp >> -3430sdp > > omap3pandora is also using sw ecc, with ubifs. Some time ago I tried > booting mainline (I think it was 3.14) with rootfs on NAND, and while > it did boot and reached a shell, there were lots of ubifs errors, fs > got corrupted and I lost all my data. I used to be able to boot > mainline this way fine sometime ~3.8 release. It's interesting that > 3.14 was able to read the data, even with wrong ecc setup. This is due to another bug introduced in 3.7 by commit 65b97cf6b8deca3ad7a3e00e8316bb89617190fb. Because of that bug (i.e. inverted CS_MASK in omap_calculate_ecc), omap_calculate_ecc() always fails with -EINVAL and calculated ECC bytes are always 0. I'll be sending a patch to fix that as well. But that will only affect the cases where OMAP_ECC_HAM1_CODE_HW is used which happened for pandora from 3.13 onwards. > > Do you think it's safe again to boot ubifs created on 3.2 after > applying this series? > Yes. If you boot pandora using legacy boot (non DT method), it passes 0 for .ecc_opt in pandora_nand_data. This used to mean OMAP_ECC_HAMMING_CODE_DEFAULT which is software ecc. i.e. NAND_ECC_SOFT with default ECC layout. Until the above mentioned commits changed the meaning. We now call that option OMAP_ECC_HAM1_CODE_SW. Please let me know if it works for you. Thanks. 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
