[PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks

[PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks

[Javier Martinez Canillas]

Hello arm-soc maintainers,

This series is an attempt to reduce the delta between exynos_defconfig
and multi_v7_defconfig. Primarily to enable the needed Kconfig symbols
to make all Exynos Chromebooks peripherals to be working when building
an image using the ARMv7 multi-platform default config.

Since the policy is now to now enable as much as possible, I did build
as a module all the Kconfig symbols that were tristate and only enable
as built-in those that can't be a module because are boolean options.

A nice side effect of this series is that I found that many drivers
were not working properly when built as a module because the modalias
information was not filled properly or at all. I've posted patches to
fix the issues I found when testing this series.

The patches have been tested on an Exynos5250 Snow, Exynos5420 Peach
Pit and Exynos5800 Peach Pi Chromebooks but most config options will
be useful for others Exynos5 or other Samsung SoCs.

The series is composed of the following patches that can be applied on
top of your next/defconfig branch [0].

Javier Martinez Canillas (9):
  ARM: multi_v7_defconfig: Enable support for Samsung S3C64XX SPI
  ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock
    drivers
  ARM: multi_v7_defconfig: Enable Exynos USB PHY drivers support
  ARM: multi_v7_defconfig: Enable support for missing ChromeOS EC
    drivers
  ARM: multi_v7_defconfig: Enable Samsung PWM support
  ARM: multi_v7_defconfig: Enable Samsung S3C SoC RTC
  ARM: multi_v7_defconfig: Enable options for Exynos display support
  ARM: multi_v7_defconfig: Enable GPIO-based I2C arbitration support
  ARM: multi_v7_defconfig: Enable Cypress APA I2C Trackpad support

 arch/arm/configs/multi_v7_defconfig | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

Best regards,
Javier

[0]: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git next/defconfig

[PATCH 1/9] ARM: multi_v7_defconfig: Enable support for Samsung S3C64XX SPI

[Javier Martinez Canillas]

Build the spi-s3c64xx driver as a module to have support for
the SPI controller in several Samsung SoCs.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 492f6289a29e..2349584b6e08 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -293,6 +293,7 @@ CONFIG_SPI_OMAP24XX=y
 CONFIG_SPI_ORION=y
 CONFIG_SPI_PL022=y
 CONFIG_SPI_RSPI=y
+CONFIG_SPI_S3C64XX=m
 CONFIG_SPI_SH_MSIOF=m
 CONFIG_SPI_SH_HSPI=y
 CONFIG_SPI_SIRF=y
-- 
2.1.4

[PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Javier Martinez Canillas]

The Maxim max77802 Power Management IC is used on many Exynos machines.
Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
and 2-channel 32kHz clock outputs.

Enable the kernel config options to have the drivers for these devices
built as a module.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2349584b6e08..080120fe5580 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
 CONFIG_REGULATOR_MAX8907=y
 CONFIG_REGULATOR_MAX8973=y
 CONFIG_REGULATOR_MAX77686=y
+CONFIG_REGULATOR_MAX77802=m
 CONFIG_REGULATOR_PALMAS=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_S5M8767=y
@@ -507,6 +508,7 @@ CONFIG_RTC_DRV_AS3722=y
 CONFIG_RTC_DRV_DS1307=y
 CONFIG_RTC_DRV_MAX8907=y
 CONFIG_RTC_DRV_MAX77686=y
+CONFIG_RTC_DRV_MAX77802=m
 CONFIG_RTC_DRV_RS5C372=m
 CONFIG_RTC_DRV_PALMAS=y
 CONFIG_RTC_DRV_ST_LPC=y
@@ -548,6 +550,7 @@ CONFIG_NVEC_PAZ00=y
 CONFIG_QCOM_GSBI=y
 CONFIG_COMMON_CLK_QCOM=y
 CONFIG_COMMON_CLK_MAX77686=y
+CONFIG_COMMON_CLK_MAX77802=m
 CONFIG_APQ_MMCC_8084=y
 CONFIG_MSM_GCC_8660=y
 CONFIG_MSM_MMCC_8960=y
-- 
2.1.4

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Javier Martinez Canillas]

Hello,

On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> The Maxim max77802 Power Management IC is used on many Exynos machines.
> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
> and 2-channel 32kHz clock outputs.
>
> Enable the kernel config options to have the drivers for these devices
> built as a module.
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  arch/arm/configs/multi_v7_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 2349584b6e08..080120fe5580 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>  CONFIG_REGULATOR_MAX8907=y
>  CONFIG_REGULATOR_MAX8973=y
>  CONFIG_REGULATOR_MAX77686=y
> +CONFIG_REGULATOR_MAX77802=m

I noticed that the version that landed in 4.2-rc1 as commit
f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
and clock drivers") doesn't include this symbol. I guess it was caused
by a wrong resolved conflict? I'll post a patch to enable the
regulator again.

Best regards,
Javier

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Javier Martinez Canillas]

Hello,

On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> The Maxim max77802 Power Management IC is used on many Exynos machines.
> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
> and 2-channel 32kHz clock outputs.
>
> Enable the kernel config options to have the drivers for these devices
> built as a module.
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  arch/arm/configs/multi_v7_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 2349584b6e08..080120fe5580 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>  CONFIG_REGULATOR_MAX8907=y
>  CONFIG_REGULATOR_MAX8973=y
>  CONFIG_REGULATOR_MAX77686=y
> +CONFIG_REGULATOR_MAX77802=m

I noticed that the version that landed in 4.2-rc1 as commit
f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
and clock drivers") doesn't include this symbol. I guess it was caused
by a wrong resolved conflict? I'll post a patch to enable the
regulator again.

Best regards,
Javier

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Krzysztof Kozlowski]

On 16.07.2015 00:38, Javier Martinez Canillas wrote:
> Hello,
> 
> On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> The Maxim max77802 Power Management IC is used on many Exynos machines.
>> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
>> and 2-channel 32kHz clock outputs.
>>
>> Enable the kernel config options to have the drivers for these devices
>> built as a module.
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>  arch/arm/configs/multi_v7_defconfig | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index 2349584b6e08..080120fe5580 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>>  CONFIG_REGULATOR_MAX8907=y
>>  CONFIG_REGULATOR_MAX8973=y
>>  CONFIG_REGULATOR_MAX77686=y
>> +CONFIG_REGULATOR_MAX77802=m
> 
> I noticed that the version that landed in 4.2-rc1 as commit
> f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
> and clock drivers") doesn't include this symbol. I guess it was caused
> by a wrong resolved conflict? I'll post a patch to enable the
> regulator again.

As you can see in mentioned mainline commit Kukjin removed it manually:
[kgene@kernel.org: removing useless REGULATOR_MAX77802 config]

I wonder why?

Best regards,
Krzysztof

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Krzysztof Kozlowski]

On 16.07.2015 00:38, Javier Martinez Canillas wrote:
> Hello,
> 
> On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>> The Maxim max77802 Power Management IC is used on many Exynos machines.
>> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
>> and 2-channel 32kHz clock outputs.
>>
>> Enable the kernel config options to have the drivers for these devices
>> built as a module.
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> ---
>>  arch/arm/configs/multi_v7_defconfig | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> index 2349584b6e08..080120fe5580 100644
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>>  CONFIG_REGULATOR_MAX8907=y
>>  CONFIG_REGULATOR_MAX8973=y
>>  CONFIG_REGULATOR_MAX77686=y
>> +CONFIG_REGULATOR_MAX77802=m
> 
> I noticed that the version that landed in 4.2-rc1 as commit
> f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
> and clock drivers") doesn't include this symbol. I guess it was caused
> by a wrong resolved conflict? I'll post a patch to enable the
> regulator again.

As you can see in mentioned mainline commit Kukjin removed it manually:
[kgene@kernel.org: removing useless REGULATOR_MAX77802 config]

I wonder why?

Best regards,
Krzysztof

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Javier Martinez Canillas]

Hello Krzysztof,

On 07/16/2015 02:42 AM, Krzysztof Kozlowski wrote:
> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
>> Hello,
>>
>> On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk> wrote:
>>> The Maxim max77802 Power Management IC is used on many Exynos machines.
>>> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
>>> and 2-channel 32kHz clock outputs.
>>>
>>> Enable the kernel config options to have the drivers for these devices
>>> built as a module.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> ---
>>>  arch/arm/configs/multi_v7_defconfig | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>>> index 2349584b6e08..080120fe5580 100644
>>> --- a/arch/arm/configs/multi_v7_defconfig
>>> +++ b/arch/arm/configs/multi_v7_defconfig
>>> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>>>  CONFIG_REGULATOR_MAX8907=y
>>>  CONFIG_REGULATOR_MAX8973=y
>>>  CONFIG_REGULATOR_MAX77686=y
>>> +CONFIG_REGULATOR_MAX77802=m
>>
>> I noticed that the version that landed in 4.2-rc1 as commit
>> f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
>> and clock drivers") doesn't include this symbol. I guess it was caused
>> by a wrong resolved conflict? I'll post a patch to enable the
>> regulator again.
> 
> As you can see in mentioned mainline commit Kukjin removed it manually:
> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
>

Oh, I missed that in the commit message. I thought it was a merge / conflict
error, not something done on purpose.
 
> I wonder why?
>

Me too.

> Best regards,
> Krzysztof
> --

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Javier Martinez Canillas]

Hello Krzysztof,

On 07/16/2015 02:42 AM, Krzysztof Kozlowski wrote:
> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
>> Hello,
>>
>> On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk> wrote:
>>> The Maxim max77802 Power Management IC is used on many Exynos machines.
>>> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
>>> and 2-channel 32kHz clock outputs.
>>>
>>> Enable the kernel config options to have the drivers for these devices
>>> built as a module.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> ---
>>>  arch/arm/configs/multi_v7_defconfig | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>>> index 2349584b6e08..080120fe5580 100644
>>> --- a/arch/arm/configs/multi_v7_defconfig
>>> +++ b/arch/arm/configs/multi_v7_defconfig
>>> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>>>  CONFIG_REGULATOR_MAX8907=y
>>>  CONFIG_REGULATOR_MAX8973=y
>>>  CONFIG_REGULATOR_MAX77686=y
>>> +CONFIG_REGULATOR_MAX77802=m
>>
>> I noticed that the version that landed in 4.2-rc1 as commit
>> f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
>> and clock drivers") doesn't include this symbol. I guess it was caused
>> by a wrong resolved conflict? I'll post a patch to enable the
>> regulator again.
> 
> As you can see in mentioned mainline commit Kukjin removed it manually:
> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
>

Oh, I missed that in the commit message. I thought it was a merge / conflict
error, not something done on purpose.
 
> I wonder why?
>

Me too.

> Best regards,
> Krzysztof
> --

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Olof Johansson]

On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
> > Hello,
> > 
> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
> > <javier.martinez@collabora.co.uk> wrote:
> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
> >> and 2-channel 32kHz clock outputs.
> >>
> >> Enable the kernel config options to have the drivers for these devices
> >> built as a module.
> >>
> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> >> ---
> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> >> index 2349584b6e08..080120fe5580 100644
> >> --- a/arch/arm/configs/multi_v7_defconfig
> >> +++ b/arch/arm/configs/multi_v7_defconfig
> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
> >>  CONFIG_REGULATOR_MAX8907=y
> >>  CONFIG_REGULATOR_MAX8973=y
> >>  CONFIG_REGULATOR_MAX77686=y
> >> +CONFIG_REGULATOR_MAX77802=m
> > 
> > I noticed that the version that landed in 4.2-rc1 as commit
> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
> > and clock drivers") doesn't include this symbol. I guess it was caused
> > by a wrong resolved conflict? I'll post a patch to enable the
> > regulator again.
> 
> As you can see in mentioned mainline commit Kukjin removed it manually:
> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
> 
> I wonder why?

Seems odd. exynos_defconfig still enables it.

Javier or Krzysztof, please send an incremental fix to enable and I'll pick
it up as a fix.


-Olof

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Olof Johansson]

On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
> > Hello,
> > 
> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
> > <javier.martinez@collabora.co.uk> wrote:
> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
> >> and 2-channel 32kHz clock outputs.
> >>
> >> Enable the kernel config options to have the drivers for these devices
> >> built as a module.
> >>
> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> >> ---
> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> >> index 2349584b6e08..080120fe5580 100644
> >> --- a/arch/arm/configs/multi_v7_defconfig
> >> +++ b/arch/arm/configs/multi_v7_defconfig
> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
> >>  CONFIG_REGULATOR_MAX8907=y
> >>  CONFIG_REGULATOR_MAX8973=y
> >>  CONFIG_REGULATOR_MAX77686=y
> >> +CONFIG_REGULATOR_MAX77802=m
> > 
> > I noticed that the version that landed in 4.2-rc1 as commit
> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
> > and clock drivers") doesn't include this symbol. I guess it was caused
> > by a wrong resolved conflict? I'll post a patch to enable the
> > regulator again.
> 
> As you can see in mentioned mainline commit Kukjin removed it manually:
> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
> 
> I wonder why?

Seems odd. exynos_defconfig still enables it.

Javier or Krzysztof, please send an incremental fix to enable and I'll pick
it up as a fix.


-Olof

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Javier Martinez Canillas]

Hello Olof,

On Fri, Jul 17, 2015 at 6:49 PM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
>> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
>> > Hello,
>> >
>> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
>> > <javier.martinez@collabora.co.uk> wrote:
>> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
>> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
>> >> and 2-channel 32kHz clock outputs.
>> >>
>> >> Enable the kernel config options to have the drivers for these devices
>> >> built as a module.
>> >>
>> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> >> ---
>> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> >> index 2349584b6e08..080120fe5580 100644
>> >> --- a/arch/arm/configs/multi_v7_defconfig
>> >> +++ b/arch/arm/configs/multi_v7_defconfig
>> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>> >>  CONFIG_REGULATOR_MAX8907=y
>> >>  CONFIG_REGULATOR_MAX8973=y
>> >>  CONFIG_REGULATOR_MAX77686=y
>> >> +CONFIG_REGULATOR_MAX77802=m
>> >
>> > I noticed that the version that landed in 4.2-rc1 as commit
>> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
>> > and clock drivers") doesn't include this symbol. I guess it was caused
>> > by a wrong resolved conflict? I'll post a patch to enable the
>> > regulator again.
>>
>> As you can see in mentioned mainline commit Kukjin removed it manually:
>> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
>>
>> I wonder why?
>
> Seems odd. exynos_defconfig still enables it.
>

Yeah since it is needed for at least the Exynos5420 Peach Pit and
Exynos5800 Peach Pi Chromebooks that use this PMIC.

> Javier or Krzysztof, please send an incremental fix to enable and I'll pick
> it up as a fix.
>

I already posted an incremental patch [0] and Krzysztof is pushing it
through Kukjin for 4.3 [1].

I guess that's OK and there is no need to add it as a fix for the 4.2
-rc cycle since this is not really a regression. I mean, the max77802
regulator driver was never enabled for multi_v7_defconfig before.

>
> -Olof

[0]: https://lkml.org/lkml/2015/7/16/60
[1]: https://lkml.org/lkml/2015/7/17/93

Best regards,
Javier

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Javier Martinez Canillas]

Hello Olof,

On Fri, Jul 17, 2015 at 6:49 PM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
>> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
>> > Hello,
>> >
>> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
>> > <javier.martinez@collabora.co.uk> wrote:
>> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
>> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
>> >> and 2-channel 32kHz clock outputs.
>> >>
>> >> Enable the kernel config options to have the drivers for these devices
>> >> built as a module.
>> >>
>> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> >> ---
>> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
>> >>  1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>> >> index 2349584b6e08..080120fe5580 100644
>> >> --- a/arch/arm/configs/multi_v7_defconfig
>> >> +++ b/arch/arm/configs/multi_v7_defconfig
>> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>> >>  CONFIG_REGULATOR_MAX8907=y
>> >>  CONFIG_REGULATOR_MAX8973=y
>> >>  CONFIG_REGULATOR_MAX77686=y
>> >> +CONFIG_REGULATOR_MAX77802=m
>> >
>> > I noticed that the version that landed in 4.2-rc1 as commit
>> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
>> > and clock drivers") doesn't include this symbol. I guess it was caused
>> > by a wrong resolved conflict? I'll post a patch to enable the
>> > regulator again.
>>
>> As you can see in mentioned mainline commit Kukjin removed it manually:
>> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
>>
>> I wonder why?
>
> Seems odd. exynos_defconfig still enables it.
>

Yeah since it is needed for at least the Exynos5420 Peach Pit and
Exynos5800 Peach Pi Chromebooks that use this PMIC.

> Javier or Krzysztof, please send an incremental fix to enable and I'll pick
> it up as a fix.
>

I already posted an incremental patch [0] and Krzysztof is pushing it
through Kukjin for 4.3 [1].

I guess that's OK and there is no need to add it as a fix for the 4.2
-rc cycle since this is not really a regression. I mean, the max77802
regulator driver was never enabled for multi_v7_defconfig before.

>
> -Olof

[0]: https://lkml.org/lkml/2015/7/16/60
[1]: https://lkml.org/lkml/2015/7/17/93

Best regards,
Javier

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Olof Johansson]

Hi,


On Fri, Jul 17, 2015 at 11:47 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Olof,
>
> On Fri, Jul 17, 2015 at 6:49 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
>>> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
>>> > Hello,
>>> >
>>> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
>>> > <javier.martinez@collabora.co.uk> wrote:
>>> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
>>> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
>>> >> and 2-channel 32kHz clock outputs.
>>> >>
>>> >> Enable the kernel config options to have the drivers for these devices
>>> >> built as a module.
>>> >>
>>> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> >> ---
>>> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
>>> >>  1 file changed, 3 insertions(+)
>>> >>
>>> >> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>>> >> index 2349584b6e08..080120fe5580 100644
>>> >> --- a/arch/arm/configs/multi_v7_defconfig
>>> >> +++ b/arch/arm/configs/multi_v7_defconfig
>>> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>>> >>  CONFIG_REGULATOR_MAX8907=y
>>> >>  CONFIG_REGULATOR_MAX8973=y
>>> >>  CONFIG_REGULATOR_MAX77686=y
>>> >> +CONFIG_REGULATOR_MAX77802=m
>>> >
>>> > I noticed that the version that landed in 4.2-rc1 as commit
>>> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
>>> > and clock drivers") doesn't include this symbol. I guess it was caused
>>> > by a wrong resolved conflict? I'll post a patch to enable the
>>> > regulator again.
>>>
>>> As you can see in mentioned mainline commit Kukjin removed it manually:
>>> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
>>>
>>> I wonder why?
>>
>> Seems odd. exynos_defconfig still enables it.
>>
>
> Yeah since it is needed for at least the Exynos5420 Peach Pit and
> Exynos5800 Peach Pi Chromebooks that use this PMIC.
>
>> Javier or Krzysztof, please send an incremental fix to enable and I'll pick
>> it up as a fix.
>>
>
> I already posted an incremental patch [0] and Krzysztof is pushing it
> through Kukjin for 4.3 [1].
>
> I guess that's OK and there is no need to add it as a fix for the 4.2
> -rc cycle since this is not really a regression. I mean, the max77802
> regulator driver was never enabled for multi_v7_defconfig before.

Yeah, I came across those emails a little further down. :-) It's all
good, we'll see it come in later.


-Olof

Re: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Olof Johansson]

Hi,


On Fri, Jul 17, 2015 at 11:47 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Olof,
>
> On Fri, Jul 17, 2015 at 6:49 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
>>> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
>>> > Hello,
>>> >
>>> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
>>> > <javier.martinez@collabora.co.uk> wrote:
>>> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
>>> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
>>> >> and 2-channel 32kHz clock outputs.
>>> >>
>>> >> Enable the kernel config options to have the drivers for these devices
>>> >> built as a module.
>>> >>
>>> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>> >> ---
>>> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
>>> >>  1 file changed, 3 insertions(+)
>>> >>
>>> >> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
>>> >> index 2349584b6e08..080120fe5580 100644
>>> >> --- a/arch/arm/configs/multi_v7_defconfig
>>> >> +++ b/arch/arm/configs/multi_v7_defconfig
>>> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
>>> >>  CONFIG_REGULATOR_MAX8907=y
>>> >>  CONFIG_REGULATOR_MAX8973=y
>>> >>  CONFIG_REGULATOR_MAX77686=y
>>> >> +CONFIG_REGULATOR_MAX77802=m
>>> >
>>> > I noticed that the version that landed in 4.2-rc1 as commit
>>> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
>>> > and clock drivers") doesn't include this symbol. I guess it was caused
>>> > by a wrong resolved conflict? I'll post a patch to enable the
>>> > regulator again.
>>>
>>> As you can see in mentioned mainline commit Kukjin removed it manually:
>>> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
>>>
>>> I wonder why?
>>
>> Seems odd. exynos_defconfig still enables it.
>>
>
> Yeah since it is needed for at least the Exynos5420 Peach Pit and
> Exynos5800 Peach Pi Chromebooks that use this PMIC.
>
>> Javier or Krzysztof, please send an incremental fix to enable and I'll pick
>> it up as a fix.
>>
>
> I already posted an incremental patch [0] and Krzysztof is pushing it
> through Kukjin for 4.3 [1].
>
> I guess that's OK and there is no need to add it as a fix for the 4.2
> -rc cycle since this is not really a regression. I mean, the max77802
> regulator driver was never enabled for multi_v7_defconfig before.

Yeah, I came across those emails a little further down. :-) It's all
good, we'll see it come in later.


-Olof

RE: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Kukjin Kim]

Olof Johansson wrote:
> 
> Hi,
> 
Hi,

> On Fri, Jul 17, 2015 at 11:47 AM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
> > Hello Olof,
> >
> > On Fri, Jul 17, 2015 at 6:49 PM, Olof Johansson <olof@lixom.net> wrote:
> >> On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
> >>> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
> >>> > Hello,
> >>> >
> >>> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
> >>> > <javier.martinez@collabora.co.uk> wrote:
> >>> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
> >>> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
> >>> >> and 2-channel 32kHz clock outputs.
> >>> >>
> >>> >> Enable the kernel config options to have the drivers for these devices
> >>> >> built as a module.
> >>> >>
> >>> >> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> >>> >> ---
> >>> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
> >>> >>  1 file changed, 3 insertions(+)
> >>> >>
> >>> >> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> >>> >> index 2349584b6e08..080120fe5580 100644
> >>> >> --- a/arch/arm/configs/multi_v7_defconfig
> >>> >> +++ b/arch/arm/configs/multi_v7_defconfig
> >>> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
> >>> >>  CONFIG_REGULATOR_MAX8907=y
> >>> >>  CONFIG_REGULATOR_MAX8973=y
> >>> >>  CONFIG_REGULATOR_MAX77686=y
> >>> >> +CONFIG_REGULATOR_MAX77802=m
> >>> >
> >>> > I noticed that the version that landed in 4.2-rc1 as commit
> >>> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
> >>> > and clock drivers") doesn't include this symbol. I guess it was caused
> >>> > by a wrong resolved conflict? I'll post a patch to enable the
> >>> > regulator again.
> >>>
> >>> As you can see in mentioned mainline commit Kukjin removed it manually:
> >>> [kgene@kernel.org: removing useless REGULATOR_MAX77802 config]
> >>>
> >>> I wonder why?
> >>
> >> Seems odd. exynos_defconfig still enables it.
> >>
It has been removed when I did 'make savedefconfig' at that time maybe because
of dependency with other configs...

> > Yeah since it is needed for at least the Exynos5420 Peach Pit and
> > Exynos5800 Peach Pi Chromebooks that use this PMIC.
> >
> >> Javier or Krzysztof, please send an incremental fix to enable and I'll pick
> >> it up as a fix.
> >>
> >
> > I already posted an incremental patch [0] and Krzysztof is pushing it
> > through Kukjin for 4.3 [1].
> >
Yes. I'll send it out to arm-soc in this weekend.

> > I guess that's OK and there is no need to add it as a fix for the 4.2
> > -rc cycle since this is not really a regression. I mean, the max77802
> > regulator driver was never enabled for multi_v7_defconfig before.
> 
> Yeah, I came across those emails a little further down. :-) It's all
> good, we'll see it come in later.
> 
Thanks,
Kukjin

[PATCH 3/9] ARM: multi_v7_defconfig: Enable Exynos USB PHY drivers support

[Javier Martinez Canillas]

Enable the needed kconfig options to have support for Samsung USB 2.0
and USB 3.0 PHY drivers to support the USB PHYs found on Exynos SoCs.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 080120fe5580..e81125364ae2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -578,6 +578,11 @@ CONFIG_PHY_STIH41X_USB=y
 CONFIG_PHY_STIH407_USB=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_SUN9I_USB=y
+CONFIG_PHY_SAMSUNG_USB2=m
+CONFIG_PHY_EXYNOS4210_USB2=y
+CONFIG_PHY_EXYNOS4X12_USB2=y
+CONFIG_PHY_EXYNOS5250_USB2=y
+CONFIG_PHY_EXYNOS5_USBDRD=y
 CONFIG_EXT4_FS=y
 CONFIG_AUTOFS4_FS=y
 CONFIG_MSDOS_FS=y
-- 
2.1.4

[PATCH 4/9] ARM: multi_v7_defconfig: Enable support for missing ChromeOS EC drivers

[Javier Martinez Canillas]

Enable the needed Kconfig options to have support for the ChromeOS EC
I2C transport, I2C tunnel and chardev user-space interface.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index e81125364ae2..fcaa82448be3 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -286,6 +286,7 @@ CONFIG_I2C_ST=y
 CONFIG_I2C_TEGRA=y
 CONFIG_I2C_XILINX=y
 CONFIG_I2C_RCAR=y
+CONFIG_I2C_CROS_EC_TUNNEL=m
 CONFIG_SPI=y
 CONFIG_SPI_CADENCE=y
 CONFIG_SPI_DAVINCI=y
@@ -352,6 +353,7 @@ CONFIG_MFD_AS3722=y
 CONFIG_MFD_BCM590XX=y
 CONFIG_MFD_AXP20X=y
 CONFIG_MFD_CROS_EC=y
+CONFIG_MFD_CROS_EC_I2C=m
 CONFIG_MFD_CROS_EC_SPI=y
 CONFIG_MFD_MAX77686=y
 CONFIG_MFD_MAX8907=y
@@ -547,6 +549,8 @@ CONFIG_KEYBOARD_NVEC=y
 CONFIG_SERIO_NVEC_PS2=y
 CONFIG_NVEC_POWER=y
 CONFIG_NVEC_PAZ00=y
+CONFIG_CHROME_PLATFORMS=y
+CONFIG_CROS_EC_CHARDEV=m
 CONFIG_QCOM_GSBI=y
 CONFIG_COMMON_CLK_QCOM=y
 CONFIG_COMMON_CLK_MAX77686=y
-- 
2.1.4

[PATCH 5/9] ARM: multi_v7_defconfig: Enable Samsung PWM support

[Javier Martinez Canillas]

Build the Generic PWM Samsung driver as a module to support PWM
devices used in platforms with a Samsung SoC.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index fcaa82448be3..bc7da5659e5d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -570,6 +570,7 @@ CONFIG_XILINX_XADC=y
 CONFIG_AK8975=y
 CONFIG_PWM=y
 CONFIG_PWM_RENESAS_TPU=y
+CONFIG_PWM_SAMSUNG=m
 CONFIG_PWM_TEGRA=y
 CONFIG_PWM_VT8500=y
 CONFIG_PHY_HIX5HD2_SATA=y
-- 
2.1.4

[PATCH 6/9] ARM: multi_v7_defconfig: Enable Samsung S3C SoC RTC

[Javier Martinez Canillas]

The rtc-s3c driver supports a range of S3C series Real-Time-Clocks found
on many Samsung SoCs. Build the driver as a module to support these RTC.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bc7da5659e5d..f587f2214202 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -520,6 +520,7 @@ CONFIG_RTC_DRV_TPS65910=y
 CONFIG_RTC_DRV_S35390A=m
 CONFIG_RTC_DRV_EM3027=y
 CONFIG_RTC_DRV_DIGICOLOR=m
+CONFIG_RTC_DRV_S3C=m
 CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_VT8500=y
 CONFIG_RTC_DRV_SUN6I=y
-- 
2.1.4

[PATCH 7/9] ARM: multi_v7_defconfig: Enable options for Exynos display support

[Javier Martinez Canillas]

Many Exynos devices have devices attached to their display ports.
This patch enables the needed Kconfig options to support different
configuration such as simple panel, embedded DisplayPort (eDP) to
LVDS bridges and HDMI displays.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index f587f2214202..e89bd6999aa3 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -402,6 +402,12 @@ CONFIG_VIDEO_RENESAS_VSP1=m
 # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
 CONFIG_VIDEO_ADV7180=m
 CONFIG_DRM=y
+CONFIG_DRM_PTN3460=m
+CONFIG_DRM_PS8622=m
+CONFIG_DRM_EXYNOS=m
+CONFIG_DRM_EXYNOS_FIMD=y
+CONFIG_DRM_EXYNOS_DP=y
+CONFIG_DRM_EXYNOS_HDMI=y
 CONFIG_DRM_RCAR_DU=m
 CONFIG_DRM_TEGRA=y
 CONFIG_DRM_PANEL_SIMPLE=y
@@ -411,6 +417,7 @@ CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SIMPLE=y
 CONFIG_FB_SH_MOBILE_MERAM=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_PLATFORM=m
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
 CONFIG_BACKLIGHT_AS3711=y
-- 
2.1.4

Re: [PATCH 7/9] ARM: multi_v7_defconfig: Enable options for Exynos display support

[Krzysztof Kozlowski]

2015-05-15 0:40 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> Many Exynos devices have devices attached to their display ports.
> This patch enables the needed Kconfig options to support different
> configuration such as simple panel, embedded DisplayPort (eDP) to
> LVDS bridges and HDMI displays.

Enabling the display would be nice but for some quite long time we had
issues with DRM on Exynos. exynos_defconfig has it enabled and most of
boards boot fine with it. Exception is Arndale 5250:
http://storage.kernelci.org/next/next-20150514/arm-exynos_defconfig/lab-khilman/boot-exynos5250-arndale.html
[    1.630290] [drm:exynos_dp_bind] *ERROR* failed: of_get_videomode() : -22
[    1.637071] exynos-drm exynos-drm: failed to bind
145b0000.dp-controller (ops exynos_dp_ops): -22
[    1.646504] exynos-drm exynos-drm: master bind failed: -22
[    1.651391] exynos-drm: probe of exynos-drm failed with error -22

Anyway it is not like I am against it... just wondering. On the other
hand enabling it could help in early detection of errors.

Best regards,
Krzysztof

Re: [PATCH 7/9] ARM: multi_v7_defconfig: Enable options for Exynos display support

[Javier Martinez Canillas]

Hello Krzysztof,

On Fri, May 15, 2015 at 2:36 AM, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> 2015-05-15 0:40 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> Many Exynos devices have devices attached to their display ports.
>> This patch enables the needed Kconfig options to support different
>> configuration such as simple panel, embedded DisplayPort (eDP) to
>> LVDS bridges and HDMI displays.
>
> Enabling the display would be nice but for some quite long time we had
> issues with DRM on Exynos. exynos_defconfig has it enabled and most of
> boards boot fine with it. Exception is Arndale 5250:

Yes, like I said in the other thread, the fact that Exynos DRM is
working fine now on most boards is mostly because the bugs were
exposed when the Exynos DRM options were enabled.

> http://storage.kernelci.org/next/next-20150514/arm-exynos_defconfig/lab-khilman/boot-exynos5250-arndale.html
> [    1.630290] [drm:exynos_dp_bind] *ERROR* failed: of_get_videomode() : -22
> [    1.637071] exynos-drm exynos-drm: failed to bind
> 145b0000.dp-controller (ops exynos_dp_ops): -22
> [    1.646504] exynos-drm exynos-drm: master bind failed: -22
> [    1.651391] exynos-drm: probe of exynos-drm failed with error -22
>

Ajay Kumar changed the DT bindings for the Exynos DRM Display Panel
driver some time ago but it seems that the Arndale 5250 DTS was never
updated. Something along the lines of commit [0] is needed.

> Anyway it is not like I am against it... just wondering. On the other
> hand enabling it could help in early detection of errors.
>

I think that not enabling these options will just make latent bugs to
not be exposed. As an example I found that module auto-loading was
broken for the driver of the PTN3460 eDP to LVDS bridge used in the
Exynos5250 Snow Chromebook and already posted a fix [1].

I would had never found that bug if wouldn't had tried enabling these
options in multi_v7 as a module. Also remember that the consumer
version of these machines don't have a serial console so for users
building images with multi_v7, not having display support means that
the machine is pretty useless.

> Best regards,
> Krzysztof

Best regards,
Javier

[0]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0a0752c6ee58f28a29e78f1a8c38f2f1b11cba9f
[1]: https://lkml.org/lkml/2015/5/14/363

Re: [PATCH 7/9] ARM: multi_v7_defconfig: Enable options for Exynos display support

[Javier Martinez Canillas]

Hello Krzysztof,

On Fri, May 15, 2015 at 2:36 AM, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> 2015-05-15 0:40 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> Many Exynos devices have devices attached to their display ports.
>> This patch enables the needed Kconfig options to support different
>> configuration such as simple panel, embedded DisplayPort (eDP) to
>> LVDS bridges and HDMI displays.
>
> Enabling the display would be nice but for some quite long time we had
> issues with DRM on Exynos. exynos_defconfig has it enabled and most of
> boards boot fine with it. Exception is Arndale 5250:

Yes, like I said in the other thread, the fact that Exynos DRM is
working fine now on most boards is mostly because the bugs were
exposed when the Exynos DRM options were enabled.

> http://storage.kernelci.org/next/next-20150514/arm-exynos_defconfig/lab-khilman/boot-exynos5250-arndale.html
> [    1.630290] [drm:exynos_dp_bind] *ERROR* failed: of_get_videomode() : -22
> [    1.637071] exynos-drm exynos-drm: failed to bind
> 145b0000.dp-controller (ops exynos_dp_ops): -22
> [    1.646504] exynos-drm exynos-drm: master bind failed: -22
> [    1.651391] exynos-drm: probe of exynos-drm failed with error -22
>

Ajay Kumar changed the DT bindings for the Exynos DRM Display Panel
driver some time ago but it seems that the Arndale 5250 DTS was never
updated. Something along the lines of commit [0] is needed.

> Anyway it is not like I am against it... just wondering. On the other
> hand enabling it could help in early detection of errors.
>

I think that not enabling these options will just make latent bugs to
not be exposed. As an example I found that module auto-loading was
broken for the driver of the PTN3460 eDP to LVDS bridge used in the
Exynos5250 Snow Chromebook and already posted a fix [1].

I would had never found that bug if wouldn't had tried enabling these
options in multi_v7 as a module. Also remember that the consumer
version of these machines don't have a serial console so for users
building images with multi_v7, not having display support means that
the machine is pretty useless.

> Best regards,
> Krzysztof

Best regards,
Javier

[0]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0a0752c6ee58f28a29e78f1a8c38f2f1b11cba9f
[1]: https://lkml.org/lkml/2015/5/14/363

Re: [PATCH 7/9] ARM: multi_v7_defconfig: Enable options for Exynos display support

[Krzysztof Kozlowski]

2015-05-15 9:58 GMT+09:00 Javier Martinez Canillas <javier@dowhile0.org>:
> Hello Krzysztof,
>
> On Fri, May 15, 2015 at 2:36 AM, Krzysztof Kozlowski
> <k.kozlowski@samsung.com> wrote:
>> 2015-05-15 0:40 GMT+09:00 Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk>:
>>> Many Exynos devices have devices attached to their display ports.
>>> This patch enables the needed Kconfig options to support different
>>> configuration such as simple panel, embedded DisplayPort (eDP) to
>>> LVDS bridges and HDMI displays.
>>
>> Enabling the display would be nice but for some quite long time we had
>> issues with DRM on Exynos. exynos_defconfig has it enabled and most of
>> boards boot fine with it. Exception is Arndale 5250:
>
> Yes, like I said in the other thread, the fact that Exynos DRM is
> working fine now on most boards is mostly because the bugs were
> exposed when the Exynos DRM options were enabled.

I saw your response in email 0/9 but let us stick to one thread.
So these are my only concerns - instability in the past.

>> http://storage.kernelci.org/next/next-20150514/arm-exynos_defconfig/lab-khilman/boot-exynos5250-arndale.html
>> [    1.630290] [drm:exynos_dp_bind] *ERROR* failed: of_get_videomode() : -22
>> [    1.637071] exynos-drm exynos-drm: failed to bind
>> 145b0000.dp-controller (ops exynos_dp_ops): -22
>> [    1.646504] exynos-drm exynos-drm: master bind failed: -22
>> [    1.651391] exynos-drm: probe of exynos-drm failed with error -22
>>
>
> Ajay Kumar changed the DT bindings for the Exynos DRM Display Panel
> driver some time ago but it seems that the Arndale 5250 DTS was never
> updated. Something along the lines of commit [0] is needed.

Thanks,

>
>> Anyway it is not like I am against it... just wondering. On the other
>> hand enabling it could help in early detection of errors.
>>
>
> I think that not enabling these options will just make latent bugs to
> not be exposed. As an example I found that module auto-loading was
> broken for the driver of the PTN3460 eDP to LVDS bridge used in the
> Exynos5250 Snow Chromebook and already posted a fix [1].

Right, enabling the options helps in exposing problems so they could
be spotted and fixed.


> I would had never found that bug if wouldn't had tried enabling these
> options in multi_v7 as a module. Also remember that the consumer
> version of these machines don't have a serial console so for users
> building images with multi_v7, not having display support means that
> the machine is pretty useless.

That is indeed good reason.

FWIW, I tested multi_v7 with your patches on Exynos4412 Trats2 board
and it worked fine.

Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

Re: [PATCH 7/9] ARM: multi_v7_defconfig: Enable options for Exynos display support

[Krzysztof Kozlowski]

2015-05-15 9:58 GMT+09:00 Javier Martinez Canillas <javier@dowhile0.org>:
> Hello Krzysztof,
>
> On Fri, May 15, 2015 at 2:36 AM, Krzysztof Kozlowski
> <k.kozlowski@samsung.com> wrote:
>> 2015-05-15 0:40 GMT+09:00 Javier Martinez Canillas
>> <javier.martinez@collabora.co.uk>:
>>> Many Exynos devices have devices attached to their display ports.
>>> This patch enables the needed Kconfig options to support different
>>> configuration such as simple panel, embedded DisplayPort (eDP) to
>>> LVDS bridges and HDMI displays.
>>
>> Enabling the display would be nice but for some quite long time we had
>> issues with DRM on Exynos. exynos_defconfig has it enabled and most of
>> boards boot fine with it. Exception is Arndale 5250:
>
> Yes, like I said in the other thread, the fact that Exynos DRM is
> working fine now on most boards is mostly because the bugs were
> exposed when the Exynos DRM options were enabled.

I saw your response in email 0/9 but let us stick to one thread.
So these are my only concerns - instability in the past.

>> http://storage.kernelci.org/next/next-20150514/arm-exynos_defconfig/lab-khilman/boot-exynos5250-arndale.html
>> [    1.630290] [drm:exynos_dp_bind] *ERROR* failed: of_get_videomode() : -22
>> [    1.637071] exynos-drm exynos-drm: failed to bind
>> 145b0000.dp-controller (ops exynos_dp_ops): -22
>> [    1.646504] exynos-drm exynos-drm: master bind failed: -22
>> [    1.651391] exynos-drm: probe of exynos-drm failed with error -22
>>
>
> Ajay Kumar changed the DT bindings for the Exynos DRM Display Panel
> driver some time ago but it seems that the Arndale 5250 DTS was never
> updated. Something along the lines of commit [0] is needed.

Thanks,

>
>> Anyway it is not like I am against it... just wondering. On the other
>> hand enabling it could help in early detection of errors.
>>
>
> I think that not enabling these options will just make latent bugs to
> not be exposed. As an example I found that module auto-loading was
> broken for the driver of the PTN3460 eDP to LVDS bridge used in the
> Exynos5250 Snow Chromebook and already posted a fix [1].

Right, enabling the options helps in exposing problems so they could
be spotted and fixed.


> I would had never found that bug if wouldn't had tried enabling these
> options in multi_v7 as a module. Also remember that the consumer
> version of these machines don't have a serial console so for users
> building images with multi_v7, not having display support means that
> the machine is pretty useless.

That is indeed good reason.

FWIW, I tested multi_v7 with your patches on Exynos4412 Trats2 board
and it worked fine.

Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

[PATCH 8/9] ARM: multi_v7_defconfig: Enable GPIO-based I2C arbitration support

[Javier Martinez Canillas]

The I2C GPIO arbitration driver is used on the Exynos5250 Snow Chromebook
to arbitrate the access to a I2C bus by the Application Processor or a EC.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index e89bd6999aa3..ca011472a5d3 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -270,6 +270,7 @@ CONFIG_SERIAL_ST_ASC_CONSOLE=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_DAVINCI=y
 CONFIG_I2C_MUX=y
+CONFIG_I2C_ARB_GPIO_CHALLENGE=m
 CONFIG_I2C_MUX_PCA954x=y
 CONFIG_I2C_MUX_PINCTRL=y
 CONFIG_I2C_CADENCE=y
-- 
2.1.4

[PATCH 9/9] ARM: multi_v7_defconfig: Enable Cypress APA I2C Trackpad support

[Javier Martinez Canillas]

The Cypress All Points Addressable (APA) I2C Trackpad is used in the
Samsung Exynos 5250 Snow Chromebook. Build the driver as a module so
the device is supported.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index ca011472a5d3..78d3b0365070 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -222,6 +222,7 @@ CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_ST_KEYSCAN=y
 CONFIG_KEYBOARD_CROS_EC=y
 CONFIG_MOUSE_PS2_ELANTECH=y
+CONFIG_MOUSE_CYAPA=m
 CONFIG_MOUSE_ELAN_I2C=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ATMEL_MXT=y
-- 
2.1.4

Re: [PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks

[Krzysztof Kozlowski]

2015-05-15 0:40 GMT+09:00 Javier Martinez Canillas
<javier.martinez@collabora.co.uk>:
> Hello arm-soc maintainers,
>
> This series is an attempt to reduce the delta between exynos_defconfig
> and multi_v7_defconfig. Primarily to enable the needed Kconfig symbols
> to make all Exynos Chromebooks peripherals to be working when building
> an image using the ARMv7 multi-platform default config.
>
> Since the policy is now to now enable as much as possible, I did build
> as a module all the Kconfig symbols that were tristate and only enable
> as built-in those that can't be a module because are boolean options.
>
> A nice side effect of this series is that I found that many drivers
> were not working properly when built as a module because the modalias
> information was not filled properly or at all. I've posted patches to
> fix the issues I found when testing this series.
>
> The patches have been tested on an Exynos5250 Snow, Exynos5420 Peach
> Pit and Exynos5800 Peach Pi Chromebooks but most config options will
> be useful for others Exynos5 or other Samsung SoCs.

I think enabling these config options would help using the multi_v7 on
Exynos boards. I have doubts only for patch 7 (DRM), so for rest of
them:
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

Re: [PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks

[Javier Martinez Canillas]

Hello Krzysztof,

On Fri, May 15, 2015 at 2:18 AM, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> 2015-05-15 0:40 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> Hello arm-soc maintainers,
>>
>> This series is an attempt to reduce the delta between exynos_defconfig
>> and multi_v7_defconfig. Primarily to enable the needed Kconfig symbols
>> to make all Exynos Chromebooks peripherals to be working when building
>> an image using the ARMv7 multi-platform default config.
>>
>> Since the policy is now to now enable as much as possible, I did build
>> as a module all the Kconfig symbols that were tristate and only enable
>> as built-in those that can't be a module because are boolean options.
>>
>> A nice side effect of this series is that I found that many drivers
>> were not working properly when built as a module because the modalias
>> information was not filled properly or at all. I've posted patches to
>> fix the issues I found when testing this series.
>>
>> The patches have been tested on an Exynos5250 Snow, Exynos5420 Peach
>> Pit and Exynos5800 Peach Pi Chromebooks but most config options will
>> be useful for others Exynos5 or other Samsung SoCs.
>
> I think enabling these config options would help using the multi_v7 on
> Exynos boards. I have doubts only for patch 7 (DRM), so for rest of
> them:
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>

Thanks a lot for your review. Do you think that there is something
wrong with patch 7 (DRM) or your doubt is given that the Exynos DRM
driver has been so unstable in the past, enabling could cause more
harm than good?

IMHO enabling the Exynos DRM options in exynos_defconfig was worth the
trouble since a lot of bugs were exposed (and fixed!) while before we
had unnoticed broken code laying around.

> Best regards,
> Krzysztof
> --

Best regards,
Javier

Re: [PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks

[Javier Martinez Canillas]

Hello Krzysztof,

On Fri, May 15, 2015 at 2:18 AM, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> 2015-05-15 0:40 GMT+09:00 Javier Martinez Canillas
> <javier.martinez@collabora.co.uk>:
>> Hello arm-soc maintainers,
>>
>> This series is an attempt to reduce the delta between exynos_defconfig
>> and multi_v7_defconfig. Primarily to enable the needed Kconfig symbols
>> to make all Exynos Chromebooks peripherals to be working when building
>> an image using the ARMv7 multi-platform default config.
>>
>> Since the policy is now to now enable as much as possible, I did build
>> as a module all the Kconfig symbols that were tristate and only enable
>> as built-in those that can't be a module because are boolean options.
>>
>> A nice side effect of this series is that I found that many drivers
>> were not working properly when built as a module because the modalias
>> information was not filled properly or at all. I've posted patches to
>> fix the issues I found when testing this series.
>>
>> The patches have been tested on an Exynos5250 Snow, Exynos5420 Peach
>> Pit and Exynos5800 Peach Pi Chromebooks but most config options will
>> be useful for others Exynos5 or other Samsung SoCs.
>
> I think enabling these config options would help using the multi_v7 on
> Exynos boards. I have doubts only for patch 7 (DRM), so for rest of
> them:
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>

Thanks a lot for your review. Do you think that there is something
wrong with patch 7 (DRM) or your doubt is given that the Exynos DRM
driver has been so unstable in the past, enabling could cause more
harm than good?

IMHO enabling the Exynos DRM options in exynos_defconfig was worth the
trouble since a lot of bugs were exposed (and fixed!) while before we
had unnoticed broken code laying around.

> Best regards,
> Krzysztof
> --

Best regards,
Javier

Re: [PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks

[Arnd Bergmann]

On Thursday 14 May 2015 17:40:07 Javier Martinez Canillas wrote:
> Hello arm-soc maintainers,
> 
> This series is an attempt to reduce the delta between exynos_defconfig
> and multi_v7_defconfig. Primarily to enable the needed Kconfig symbols
> to make all Exynos Chromebooks peripherals to be working when building
> an image using the ARMv7 multi-platform default config.
> 
> Since the policy is now to now enable as much as possible, I did build
> as a module all the Kconfig symbols that were tristate and only enable
> as built-in those that can't be a module because are boolean options.
> 
> A nice side effect of this series is that I found that many drivers
> were not working properly when built as a module because the modalias
> information was not filled properly or at all. I've posted patches to
> fix the issues I found when testing this series.
> 
> The patches have been tested on an Exynos5250 Snow, Exynos5420 Peach
> Pit and Exynos5800 Peach Pi Chromebooks but most config options will
> be useful for others Exynos5 or other Samsung SoCs.
> 
> The series is composed of the following patches that can be applied on
> top of your next/defconfig branch [0].

Looks good to me. My preferred approach for merging would be to have
Kukjin pick up these patches and send a pull request, along with other
defconfig changes he might have for exynos.

If there are any problems with that, we can also pick them up directly.

	Arnd

Re: [PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks

[Krzysztof Kozlowski]

2015-05-15 20:37 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 14 May 2015 17:40:07 Javier Martinez Canillas wrote:
>> Hello arm-soc maintainers,
>>
>> This series is an attempt to reduce the delta between exynos_defconfig
>> and multi_v7_defconfig. Primarily to enable the needed Kconfig symbols
>> to make all Exynos Chromebooks peripherals to be working when building
>> an image using the ARMv7 multi-platform default config.
>>
>> Since the policy is now to now enable as much as possible, I did build
>> as a module all the Kconfig symbols that were tristate and only enable
>> as built-in those that can't be a module because are boolean options.
>>
>> A nice side effect of this series is that I found that many drivers
>> were not working properly when built as a module because the modalias
>> information was not filled properly or at all. I've posted patches to
>> fix the issues I found when testing this series.
>>
>> The patches have been tested on an Exynos5250 Snow, Exynos5420 Peach
>> Pit and Exynos5800 Peach Pi Chromebooks but most config options will
>> be useful for others Exynos5 or other Samsung SoCs.
>>
>> The series is composed of the following patches that can be applied on
>> top of your next/defconfig branch [0].
>
> Looks good to me. My preferred approach for merging would be to have
> Kukjin pick up these patches and send a pull request, along with other
> defconfig changes he might have for exynos.

I have some other old patches in the same topic - related to important
stuff for Exynos boards. I'll rebase them and ask Kukjin for picking.

Best regards,
Krzysztof

Re: [PATCH 0/9] multi_v7_defconfig: Enable options for Exynos Chromebooks

[Kukjin Kim]

On 05/15/15 21:00, Krzysztof Kozlowski wrote:
> 2015-05-15 20:37 GMT+09:00 Arnd Bergmann <arnd@arndb.de>:
>> On Thursday 14 May 2015 17:40:07 Javier Martinez Canillas wrote:
>>> Hello arm-soc maintainers,
>>>
>>> This series is an attempt to reduce the delta between exynos_defconfig
>>> and multi_v7_defconfig. Primarily to enable the needed Kconfig symbols
>>> to make all Exynos Chromebooks peripherals to be working when building
>>> an image using the ARMv7 multi-platform default config.
>>>
>>> Since the policy is now to now enable as much as possible, I did build
>>> as a module all the Kconfig symbols that were tristate and only enable
>>> as built-in those that can't be a module because are boolean options.
>>>
>>> A nice side effect of this series is that I found that many drivers
>>> were not working properly when built as a module because the modalias
>>> information was not filled properly or at all. I've posted patches to
>>> fix the issues I found when testing this series.
>>>
>>> The patches have been tested on an Exynos5250 Snow, Exynos5420 Peach
>>> Pit and Exynos5800 Peach Pi Chromebooks but most config options will
>>> be useful for others Exynos5 or other Samsung SoCs.
>>>
>>> The series is composed of the following patches that can be applied on
>>> top of your next/defconfig branch [0].
>>
>> Looks good to me. My preferred approach for merging would be to have
>> Kukjin pick up these patches and send a pull request, along with other
>> defconfig changes he might have for exynos.
> 
OK, I'll in this weekend.

> I have some other old patches in the same topic - related to important
> stuff for Exynos boards. I'll rebase them and ask Kukjin for picking.
> 
Yeah, OK.

Thanks,
Kukjin