[PATCH 0/2] Remove some dead code for omaps

[PATCH 0/2] Remove some dead code for omaps

[Tony Lindgren]

Hi all,

I noticed we have some dead code left over after we made omap4
to boot in device tree only mode, so let's just remove it.

Regards,

Tony


Tony Lindgren (2):
  ARM: OMAP2+: Remove legacy mux code for display.c
  ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init

 arch/arm/mach-omap2/common.h       |  1 -
 arch/arm/mach-omap2/display.c      | 78 --------------------------------------
 arch/arm/mach-omap2/omap4-common.c | 57 ----------------------------
 3 files changed, 136 deletions(-)

-- 
1.8.1.1

[PATCH 1/2] ARM: OMAP2+: Remove legacy mux code for display.c

[Tony Lindgren]

This is all omap4 specific, which is device tree based
nowadays and should use pinctrl-single instead.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/display.c | 78 -------------------------------------------
 1 file changed, 78 deletions(-)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a4e536b..58347bb 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -32,7 +32,6 @@
 
 #include "soc.h"
 #include "iomap.h"
-#include "mux.h"
 #include "control.h"
 #include "display.h"
 #include "prm.h"
@@ -102,90 +101,13 @@ static const struct omap_dss_hwmod_data omap4_dss_hwmod_data[] __initconst = {
 	{ "dss_hdmi", "omapdss_hdmi", -1 },
 };
 
-static void __init omap4_tpd12s015_mux_pads(void)
-{
-	omap_mux_init_signal("hdmi_cec",
-			OMAP_PIN_INPUT_PULLUP);
-	omap_mux_init_signal("hdmi_ddc_scl",
-			OMAP_PIN_INPUT_PULLUP);
-	omap_mux_init_signal("hdmi_ddc_sda",
-			OMAP_PIN_INPUT_PULLUP);
-}
-
-static void __init omap4_hdmi_mux_pads(enum omap_hdmi_flags flags)
-{
-	u32 reg;
-	u16 control_i2c_1;
-
-	/*
-	 * CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
-	 * HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
-	 * internal pull up resistor.
-	 */
-	if (flags & OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP) {
-		control_i2c_1 = OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_1;
-		reg = omap4_ctrl_pad_readl(control_i2c_1);
-		reg |= (OMAP4_HDMI_DDC_SDA_PULLUPRESX_MASK |
-			OMAP4_HDMI_DDC_SCL_PULLUPRESX_MASK);
-			omap4_ctrl_pad_writel(reg, control_i2c_1);
-	}
-}
-
-static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
-{
-	u32 enable_mask, enable_shift;
-	u32 pipd_mask, pipd_shift;
-	u32 reg;
-
-	if (dsi_id == 0) {
-		enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
-		enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
-		pipd_mask = OMAP4_DSI1_PIPD_MASK;
-		pipd_shift = OMAP4_DSI1_PIPD_SHIFT;
-	} else if (dsi_id == 1) {
-		enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
-		enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
-		pipd_mask = OMAP4_DSI2_PIPD_MASK;
-		pipd_shift = OMAP4_DSI2_PIPD_SHIFT;
-	} else {
-		return -ENODEV;
-	}
-
-	reg = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
-
-	reg &= ~enable_mask;
-	reg &= ~pipd_mask;
-
-	reg |= (lanes << enable_shift) & enable_mask;
-	reg |= (lanes << pipd_shift) & pipd_mask;
-
-	omap4_ctrl_pad_writel(reg, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
-
-	return 0;
-}
-
-int __init omap_hdmi_init(enum omap_hdmi_flags flags)
-{
-	if (cpu_is_omap44xx()) {
-		omap4_hdmi_mux_pads(flags);
-		omap4_tpd12s015_mux_pads();
-	}
-
-	return 0;
-}
-
 static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
 {
-	if (cpu_is_omap44xx())
-		return omap4_dsi_mux_pads(dsi_id, lane_mask);
-
 	return 0;
 }
 
 static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
 {
-	if (cpu_is_omap44xx())
-		omap4_dsi_mux_pads(dsi_id, 0);
 }
 
 static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
-- 
1.8.1.1

[PATCH 2/2] ARM: OMAP2+: Remove legacy omap4_twl6030_hsmmc_init

[Tony Lindgren]

This is no longer used, omap4 is device tree based now.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/common.h       |  1 -
 arch/arm/mach-omap2/omap4-common.c | 57 --------------------------------------
 2 files changed, 58 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f7644fe..e30ef67 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -299,7 +299,6 @@ struct omap_sdrc_params;
 extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
 				      struct omap_sdrc_params *sdrc_cs1);
 struct omap2_hsmmc_info;
-extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
 extern void omap_reserve(void);
 
 struct omap_hwmod;
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 5791143..b39efd4 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -35,7 +35,6 @@
 #include "iomap.h"
 #include "common.h"
 #include "mmc.h"
-#include "hsmmc.h"
 #include "prminst44xx.h"
 #include "prcm_mpu44xx.h"
 #include "omap4-sar-layout.h"
@@ -284,59 +283,3 @@ skip_errata_init:
 	omap_wakeupgen_init();
 	irqchip_init();
 }
-
-#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
-static int omap4_twl6030_hsmmc_late_init(struct device *dev)
-{
-	int irq = 0;
-	struct platform_device *pdev = container_of(dev,
-				struct platform_device, dev);
-	struct omap_mmc_platform_data *pdata = dev->platform_data;
-
-	/* Setting MMC1 Card detect Irq */
-	if (pdev->id == 0) {
-		irq = twl6030_mmc_card_detect_config();
-		if (irq < 0) {
-			dev_err(dev, "%s: Error card detect config(%d)\n",
-				__func__, irq);
-			return irq;
-		}
-		pdata->slots[0].card_detect_irq = irq;
-		pdata->slots[0].card_detect = twl6030_mmc_card_detect;
-	}
-	return 0;
-}
-
-static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
-{
-	struct omap_mmc_platform_data *pdata;
-
-	/* dev can be null if CONFIG_MMC_OMAP_HS is not set */
-	if (!dev) {
-		pr_err("Failed %s\n", __func__);
-		return;
-	}
-	pdata = dev->platform_data;
-	pdata->init =	omap4_twl6030_hsmmc_late_init;
-}
-
-int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
-{
-	struct omap2_hsmmc_info *c;
-
-	omap_hsmmc_init(controllers);
-	for (c = controllers; c->mmc; c++) {
-		/* pdev can be null if CONFIG_MMC_OMAP_HS is not set */
-		if (!c->pdev)
-			continue;
-		omap4_twl6030_hsmmc_set_late_init(&c->pdev->dev);
-	}
-
-	return 0;
-}
-#else
-int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
-{
-	return 0;
-}
-#endif
-- 
1.8.1.1

[alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Richard Genoud]

2013/11/19 Zhong Li <zql@glomationinc.com>:
> When playing stereo sound on the Atmel at91sam9x5-ek board the left and
> right channel would get swapped about 1 in 6 tries.

Can you give a little more background ? :
- What kernel ?
- Command line to reproduce ?

Richard.

[alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Zhong Li]

> Can you give a little more background ? :
> - What kernel ?
> - Command line to reproduce ?
> 
> Richard.

One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board).  We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc.  The command to test the sound is just the simple aplay <sound-test-file>.  The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing.

Thanks

[alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Richard Genoud]

[added Nicolas Ferre and Bo Shen ]

2013/11/19 Zhong Li <zql@glomationinc.com>:
>> Can you give a little more background ? :
>> - What kernel ?
>> - Command line to reproduce ?
>>
>> Richard.
>
> One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board).  We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc.  The command to test the sound is just the simple aplay <sound-test-file>.  The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing.
>
> Thanks

Ok, I reproduce the bug on g35-ek with a v3.11.7+(sam9x5 sound patches) kernel

So, *sometimes*,  the left and right channel are swapped. ( I found
also the ratio 1 out of 6 (but once it has happened, it seems to be
more often))
I tested that with the file given by Zhong Li, and with a file I
created with audacity (440Hz only on right channel).
I could see at the scope that the channels are swapped before the
w8731 codec (the data on the TD line are sometime on the low edge of
TF, instead of always being on the high edge (I2S mode)).
There's, in both cases, a clock period (TK) between the rising/falling
edge of TF and the 1st data bit on TD, so the mode is always I2S, and
the channel data are swapped.

I'll try to have a look (but I don't have much time right now)

If someone could test that on a sam9g20 or a WM8904 based board, since
they share the same DAI format, they may have the same problem.

Thanks !
Richard

-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?

[alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Richard Genoud]

2013/11/20 Richard Genoud <richard.genoud@gmail.com>:
> [added Nicolas Ferre and Bo Shen ]
>
> 2013/11/19 Zhong Li <zql@glomationinc.com>:
>>
>> One of the testing hardware is the Atmel at91sam9g25-ek (the CPU module and the carrier board).  We tried both the 2.6.39 patched with the Atmel patches and the mainline 3.12-rc.  The command to test the sound is just the simple aplay <sound-test-file>.  The wav file is available here, https://drive.google.com/file/d/0B3TSFX4Mq9PoeTdJOGVaZk5rTWM/edit?usp=sharing.
>>
>> Thanks
>
> Ok, I reproduce the bug on g35-ek with a v3.11.7+(sam9x5 sound patches) kernel
>
> So, *sometimes*,  the left and right channel are swapped. ( I found
> also the ratio 1 out of 6 (but once it has happened, it seems to be
> more often))
> I tested that with the file given by Zhong Li, and with a file I
> created with audacity (440Hz only on right channel).
> I could see at the scope that the channels are swapped before the
> w8731 codec (the data on the TD line are sometime on the low edge of
> TF, instead of always being on the high edge (I2S mode)).
> There's, in both cases, a clock period (TK) between the rising/falling
> edge of TF and the 1st data bit on TD, so the mode is always I2S, and
> the channel data are swapped.
>
> I'll try to have a look (but I don't have much time right now)
>
> If someone could test that on a sam9g20 or a WM8904 based board, since
> they share the same DAI format, they may have the same problem.

After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I
don't understand how the right and left channel are synchronized.
(which one will be on TF rising edge, and which one on TF falling edge
?)
In the SSC_TCMR register, the start event is TF_FALLING when there
only one channel (i.e. mono source always on left channel)
With a stereo source, it's TF_EDGE (Detection of any edge on TF
signal) ; so the samples are transferred on rising and falling edge.
I didn't see anything in the SSC what could synchronize the first
sample with a TF falling edge.
Or I missed something ?

Nicolas, Bo, any idea ?

Richard.

[alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Zhong Li]

> 
> After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I
> don't understand how the right and left channel are synchronized.
> (which one will be on TF rising edge, and which one on TF falling edge
> ?)
> In the SSC_TCMR register, the start event is TF_FALLING when there only
> one channel (i.e. mono source always on left channel) With a stereo
> source, it's TF_EDGE (Detection of any edge on TF
> signal) ; so the samples are transferred on rising and falling edge.
> I didn't see anything in the SSC what could synchronize the first
> sample with a TF falling edge.
> Or I missed something ?
> 


The codec seems to be set to I2S mode based on the parameter name.  And the FSOS field in the TFMR is set to be negative pulse.  So it matches the I2S mode diagram (Figure 27 of WM8731 datasheet).  The high to low on DACLRC (TF line aka PA25 pin) indicate start of the left channel data.  Looks like the TF signal is automatically generated by the SSC controller according to the TFMR settings.

[alsa-devel] Bug? Sound support for at91sam9x5-wm8731 based boards

[Richard Genoud]

2013/11/20 Zhong Li <zql@glomationinc.com>:
>>
>> After reading the sources (mainly sound/soc/atmel/atmel_ssc_dai.c), I
>> don't understand how the right and left channel are synchronized.
>> (which one will be on TF rising edge, and which one on TF falling edge
>> ?)
>> In the SSC_TCMR register, the start event is TF_FALLING when there only
>> one channel (i.e. mono source always on left channel) With a stereo
>> source, it's TF_EDGE (Detection of any edge on TF
>> signal) ; so the samples are transferred on rising and falling edge.
>> I didn't see anything in the SSC what could synchronize the first
>> sample with a TF falling edge.
>> Or I missed something ?
>>
>
>
> The codec seems to be set to I2S mode based on the parameter name.  And the FSOS field in the TFMR is set to be negative pulse.  So it matches the I2S mode diagram (Figure 27 of WM8731 datasheet).  The high to low on DACLRC (TF line aka PA25 pin) indicate start of the left channel data.  Looks like the TF signal is automatically generated by the SSC controller according to the TFMR settings.

Yes, we use the I2S mode as in wm8731-figure27.
But the WM8731 is in master mode (wm8731-figure3). So it provides BCLK
(TK) and frame clock (DACLRC (TF)).
That's set in sam9x5_wm8731.c :
dai->dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBM_CFM;
DAIFMT_I2S : I2S mode obviously (wm8731 reg 7 bit 0:1 = 2)
DAIFMT_NB_NF : clock frames phasing (wm8731 reg7 bit4=0, bit7=0 : Left
channel when DAC is low and BCKL not inverted)
DAIFMT_CBM_CFM : master mode (wm8731 reg7 bit6=1 )

And I think you read the wrong value for the FSOS field of TFMR
register : in the I2S + CBM_CFM case, it's set to 0 because TF pin is
an input for the SSC.

So yes, the wm8731 generates the TK and TF signals and the SSC is
configured to send 16bits data on every TF edge (SSC_START_EDGE_RF).
The SSC_FSEDGE_POSITIVE flag will trigger the TXSYN interrupt on a TF
positive edge.
That's a way to get the sync between right/left channel I think :
If we set SSC_FSEDGE_POSITIVE, and enable the TXSYN interrupt, at the
first interrupt received we could start the DMA transfer (and disable
the interrupt).
The SSC will then send the 1st data (left data) on the next TF edge
which will be a negative edge (left channel).

Richard