[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

Doug Anderson dianders at google.com
Wed Jul 9 10:52:30 PDT 2014


Javier,

On Wed, Jul 9, 2014 at 10:46 AM, Javier Martinez Canillas
<javier at dowhile0.org> wrote:
> Hello Doug,
>
> On Wed, Jul 9, 2014 at 6:01 PM, Doug Anderson <dianders at google.com> wrote:
>> Javier,
>>
>> On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
>> <javier at dowhile0.org> wrote:
>>> Hello Tushar,
>>>
>>> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux at gmail.com> wrote:
>>>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>>>> Hello Tushar,
>>>>>
>>>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux at gmail.com> wrote:
>>>>>>>>
>>>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>>>
>>>>>>>> Peach # version
>>>>>>>>
>>>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>>>
>>>>>>>
>>>>>
>>>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>>>> with 2/3 to fix the issue.
>>>>>
>>>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>>>
>>>>>>> - Kukjin
>>>>>>
>>>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>>>> different patchset.
>>>>>>
>>>>>
>>>>> I'm sending as an attachment my complete boot log when booting today's
>>>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>>>> helps.
>>>>>
>>>>
>>>> Would you please check the behaviour after enabling following config
>>>> options?
>>>>
>>>> diff --git a/arch/arm/configs/exynos_defconfig
>>>> b/arch/arm/configs/exynos_defconfig
>>>> index e07a227..d6056ab 100644
>>>> --- a/arch/arm/configs/exynos_defconfig
>>>> +++ b/arch/arm/configs/exynos_defconfig
>>>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>>>  CONFIG_FONTS=y
>>>>  CONFIG_FONT_7x14=y
>>>>  CONFIG_LOGO=y
>>>> +CONFIG_SOUND=y
>>>> +CONFIG_SND=y
>>>> +CONFIG_SND_SOC=y
>>>> +CONFIG_SND_SOC_SAMSUNG=y
>>>> +CONFIG_SND_SOC_SNOW=y
>>>>  CONFIG_USB=y
>>>>  CONFIG_USB_EHCI_HCD=y
>>>>  CONFIG_USB_EHCI_EXYNOS=y
>>>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>>>  CONFIG_MMC_DW_EXYNOS=y
>>>>  CONFIG_RTC_CLASS=y
>>>>  CONFIG_RTC_DRV_S3C=y
>>>> +CONFIG_DMADEVICES=y
>>>> +CONFIG_PL330_DMA=y
>>>>  CONFIG_COMMON_CLK_MAX77686=y
>>>>  CONFIG_EXT2_FS=y
>>>>  CONFIG_EXT3_FS=y
>>>>
>>>>
>>>
>>> With those Kconfig options enabled the kernel does not hang anymore so
>>> patch 1/3 is not needed in that case.
>>
>> Just checking: did you happen to confirm whether it's the PL330 /
>> DMADEVICES that fixes things or do you actually need the sound stuff?
>
> Sorry I should had mentioned this before. The DMADEVICES and PL330
> Kconfig are enough to avoid the kernel to hang, the sound config
> options are not actually required.

OK, makes sense.  Possibly the correct fix is just a Kconfig change
that somehow enforces that we have these two configs on.

-Doug



More information about the linux-arm-kernel mailing list