diff mbox

ARM: EXYNOS: Update defconfig for Arndale and Origen board

Message ID 1368168599-28507-1-git-send-email-tushar.behera@linaro.org
State New
Headers show

Commit Message

Tushar Behera May 10, 2013, 6:49 a.m. UTC
It updates following drivers for EXYNOS based DT platform.

* S5M8767 driver
* MAX8997 driver
* MMC SDHCI driver

Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
---

This patch is based on Olof's following patch.
"[PATCH] ARM: exynos: defconfig update"
https://lkml.org/lkml/2013/5/9/455

 arch/arm/configs/exynos_defconfig |    6 ++++++
 1 file changed, 6 insertions(+)

Comments

Doug Anderson May 10, 2013, 3:31 p.m. UTC | #1
Tushar,

On Thu, May 9, 2013 at 11:49 PM, Tushar Behera <tushar.behera@linaro.org> wrote:
> It updates following drivers for EXYNOS based DT platform.
>
> * S5M8767 driver
> * MAX8997 driver
> * MMC SDHCI driver
>
> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> ---
>
> This patch is based on Olof's following patch.
> "[PATCH] ARM: exynos: defconfig update"
> https://lkml.org/lkml/2013/5/9/455
>
>  arch/arm/configs/exynos_defconfig |    6 ++++++
>  1 file changed, 6 insertions(+)

Your changes also look good to me.

Reviewed-by: Doug Anderson <dianders@chromium.org>
Kevin Hilman May 14, 2013, 12:06 a.m. UTC | #2
Tushar Behera <tushar.behera@linaro.org> writes:

> It updates following drivers for EXYNOS based DT platform.
>
> * S5M8767 driver
> * MAX8997 driver
> * MMC SDHCI driver
>
> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>

I tested this using v3.10-rc1 on Arndale, but still don't get any
support for the wired network.  Do you know if this is a Kconfig issue,
or a missing driver?

I suspect it may be related to the various "unable to find transceiver
of type USB2 PHY" messages I'm seeing?

Thanks,

Kevin
Tushar Behera May 14, 2013, 3:07 a.m. UTC | #3
On 05/14/2013 05:36 AM, Kevin Hilman wrote:
> Tushar Behera <tushar.behera@linaro.org> writes:
> 
>> It updates following drivers for EXYNOS based DT platform.
>>
>> * S5M8767 driver
>> * MAX8997 driver
>> * MMC SDHCI driver
>>
>> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> 
> I tested this using v3.10-rc1 on Arndale, but still don't get any
> support for the wired network.  Do you know if this is a Kconfig issue,
> or a missing driver?
> 
> I suspect it may be related to the various "unable to find transceiver
> of type USB2 PHY" messages I'm seeing?
> 

Yes, right. The missing USB-PHY components are one of the issues (they
were there in linux-next when I last tested).

Also, on Arndale board, we need to reset the USB hub during EHCI
initialization (a couple of those patches are required, which I am not
sure if we would be able to upstream).

I am collecting a minimal set of patches that would enable USB and wired
network on Arndale with 3.10-rc1 kernel. Once done, I will let you know.

> Thanks,
> 
> Kevin
> 

Thanks for testing.
Olof Johansson May 28, 2013, 11:17 p.m. UTC | #4
On Tue, May 14, 2013 at 08:37:53AM +0530, Tushar Behera wrote:
> On 05/14/2013 05:36 AM, Kevin Hilman wrote:
> > Tushar Behera <tushar.behera@linaro.org> writes:
> > 
> >> It updates following drivers for EXYNOS based DT platform.
> >>
> >> * S5M8767 driver
> >> * MAX8997 driver
> >> * MMC SDHCI driver
> >>
> >> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> > 
> > I tested this using v3.10-rc1 on Arndale, but still don't get any
> > support for the wired network.  Do you know if this is a Kconfig issue,
> > or a missing driver?
> > 
> > I suspect it may be related to the various "unable to find transceiver
> > of type USB2 PHY" messages I'm seeing?
> > 
> 
> Yes, right. The missing USB-PHY components are one of the issues (they
> were there in linux-next when I last tested).
> 
> Also, on Arndale board, we need to reset the USB hub during EHCI
> initialization (a couple of those patches are required, which I am not
> sure if we would be able to upstream).
> 
> I am collecting a minimal set of patches that would enable USB and wired
> network on Arndale with 3.10-rc1 kernel. Once done, I will let you know.

Hi Tushar,

Got an update on what these patches are yet?


-Olof
Olof Johansson May 28, 2013, 11:24 p.m. UTC | #5
Hi,

On Thu, May 9, 2013 at 11:49 PM, Tushar Behera <tushar.behera@linaro.org> wrote:
> It updates following drivers for EXYNOS based DT platform.
>
> * S5M8767 driver
> * MAX8997 driver
> * MMC SDHCI driver
>
> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>

I didn't see any movement from Kukjin on this, so I have (tentatively)
applied this together with my base defconfig update to the fixes
branch of arm-soc. I'll take it out in case he protests, but it's very
useful since the simplefb driver has landed in 3.10-rc3.


-Olof
Kukjin Kim May 29, 2013, 12:07 a.m. UTC | #6
Olof Johansson wrote:
> 
> Hi,
> 
> On Thu, May 9, 2013 at 11:49 PM, Tushar Behera <tushar.behera@linaro.org>
> wrote:
> > It updates following drivers for EXYNOS based DT platform.
> >
> > * S5M8767 driver
> > * MAX8997 driver
> > * MMC SDHCI driver
> >
> > Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> 
> I didn't see any movement from Kukjin on this, so I have (tentatively)
> applied this together with my base defconfig update to the fixes
> branch of arm-soc. I'll take it out in case he protests, but it's very
> useful since the simplefb driver has landed in 3.10-rc3.
> 
I'm fine on this, so please go ahead with my ack if you want,

Acked-by: Kukjin Kim <kgene.kim@samsung.com>

Thanks for your gentle reminder :-)

- Kukjin
Tushar Behera May 29, 2013, 3:59 a.m. UTC | #7
On 05/29/2013 04:47 AM, Olof Johansson wrote:
> On Tue, May 14, 2013 at 08:37:53AM +0530, Tushar Behera wrote:
>> On 05/14/2013 05:36 AM, Kevin Hilman wrote:
>>> Tushar Behera <tushar.behera@linaro.org> writes:
>>>
>>>> It updates following drivers for EXYNOS based DT platform.
>>>>
>>>> * S5M8767 driver
>>>> * MAX8997 driver
>>>> * MMC SDHCI driver
>>>>
>>>> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
>>>
>>> I tested this using v3.10-rc1 on Arndale, but still don't get any
>>> support for the wired network.  Do you know if this is a Kconfig issue,
>>> or a missing driver?
>>>
>>> I suspect it may be related to the various "unable to find transceiver
>>> of type USB2 PHY" messages I'm seeing?
>>>
>>
>> Yes, right. The missing USB-PHY components are one of the issues (they
>> were there in linux-next when I last tested).
>>
>> Also, on Arndale board, we need to reset the USB hub during EHCI
>> initialization (a couple of those patches are required, which I am not
>> sure if we would be able to upstream).
>>
>> I am collecting a minimal set of patches that would enable USB and wired
>> network on Arndale with 3.10-rc1 kernel. Once done, I will let you know.
> 
> Hi Tushar,
> 
> Got an update on what these patches are yet?
> 
> 
> -Olof
> 

The patches are at [1]. There are a total of 6 patches on top of
v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch
(c) is just a defconfig hack to get Arndale booting. Remaining 2 patches
(e, f) are required to reset the hub during EHCI initialization.

a. ARM: exynos: defconfig update
b. ARM: EXYNOS: Update defconfig for Arndale and Origen board
c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2
d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250
e. usb: ehci-s5p: add the HSIC port initialization
f. ARM: dts: Add USB gpio entries for Arndale board

I am not sure whether such kind of board-specific patches (e, f) are
appreciated in the drivers. But that is all we need to get USB and
Ethernet to work on v3.10-rc3 kernel.

[1] git://git.linaro.org/landing-teams/working/samsung/kernel.git
(upstream/arndale-usb)
Olof Johansson May 29, 2013, 5:31 a.m. UTC | #8
On Tue, May 28, 2013 at 8:59 PM, Tushar Behera <tushar.behera@linaro.org> wrote:

> The patches are at [1].

FWIW, a cgit/gitweb link is easier to follow when you're reading an
email. Anyway, found the patches.

> There are a total of 6 patches on top of
> v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch
> (c) is just a defconfig hack to get Arndale booting. Remaining 2 patches
> (e, f) are required to reset the hub during EHCI initialization.

Huh, I thought you said that (c) wasn't needed when I posted the
defconfig update. It'd be nice to see the code fixed to handle this
case instead of Linaro carrying a patch like this though. I.e. make it
able to deselect the uart, or make it tied to DEBUG_LL like on other
platforms instead of having a separate config for this.

> a. ARM: exynos: defconfig update
> b. ARM: EXYNOS: Update defconfig for Arndale and Origen board
> c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2
> d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250
> e. usb: ehci-s5p: add the HSIC port initialization
> f. ARM: dts: Add USB gpio entries for Arndale board
>
> I am not sure whether such kind of board-specific patches (e, f) are
> appreciated in the drivers. But that is all we need to get USB and
> Ethernet to work on v3.10-rc3 kernel.

I've come across a similar situation with wifi reset sequence on the
chromebook. On the product kernel we added some code to the board file
to deal with it, but if we keep doing that things will grow out of
hand.

I don't know if it'll be unpopular, but I think it's time to start a
drivers/platform/arm for these kind of things, and have those drivers
probe on the system compatible value, similar to how x86 does it (with
DMI tables). At least that's my plan for approaching the wifi
reset/power-on sequence on the Chromebook. I hope to have patches in
not all that long...

Likewise, the hub reset/enable code doesn't have to go with the USB
driver, right? I.e. if you cycle reset/enable on the hub after the
host and phy is configured, you'll still have a working setup?


-Olof
Tushar Behera May 29, 2013, 8:50 a.m. UTC | #9
On 05/29/2013 11:01 AM, Olof Johansson wrote:
> On Tue, May 28, 2013 at 8:59 PM, Tushar Behera <tushar.behera@linaro.org> wrote:
> 
>> The patches are at [1].
> 
> FWIW, a cgit/gitweb link is easier to follow when you're reading an
> email. Anyway, found the patches.
> 
>> There are a total of 6 patches on top of
>> v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch
>> (c) is just a defconfig hack to get Arndale booting. Remaining 2 patches
>> (e, f) are required to reset the hub during EHCI initialization.
> 
> Huh, I thought you said that (c) wasn't needed when I posted the
> defconfig update. It'd be nice to see the code fixed to handle this
> case instead of Linaro carrying a patch like this though. I.e. make it
> able to deselect the uart, or make it tied to DEBUG_LL like on other
> platforms instead of having a separate config for this.
> 

It would be good to free up the dependency on the correct UART port for
the board to boot. Without that, there would always be boards that don't
boot with default mainline defconfig file even though all other
components are in place.

>> a. ARM: exynos: defconfig update
>> b. ARM: EXYNOS: Update defconfig for Arndale and Origen board
>> c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2
>> d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250
>> e. usb: ehci-s5p: add the HSIC port initialization
>> f. ARM: dts: Add USB gpio entries for Arndale board
>>
>> I am not sure whether such kind of board-specific patches (e, f) are
>> appreciated in the drivers. But that is all we need to get USB and
>> Ethernet to work on v3.10-rc3 kernel.
> 
> I've come across a similar situation with wifi reset sequence on the
> chromebook. On the product kernel we added some code to the board file
> to deal with it, but if we keep doing that things will grow out of
> hand.
> 
> I don't know if it'll be unpopular, but I think it's time to start a
> drivers/platform/arm for these kind of things, and have those drivers
> probe on the system compatible value, similar to how x86 does it (with
> DMI tables). At least that's my plan for approaching the wifi
> reset/power-on sequence on the Chromebook. I hope to have patches in
> not all that long...
> 
> Likewise, the hub reset/enable code doesn't have to go with the USB
> driver, right? I.e. if you cycle reset/enable on the hub after the
> host and phy is configured, you'll still have a working setup?
> 

Right, hub reset/enable code need not be tied up with USB driver. As per
your suggestion regarding drivers/platform/arm, I implemented an Arndale
specific driver [2] in drivers/platform/arm and verified USB and
ethernet to be working.

[2]
https://git.linaro.org/gitweb?p=landing-teams/working/samsung/kernel.git;a=shortlog;h=refs/heads/upstream/arndale-usb-2

> 
> -Olof
>
Jingoo Han May 29, 2013, 9:33 a.m. UTC | #10
On Wednesday, May 29, 2013 5:51 PM, Tushar Behera:
> On 05/29/2013 11:01 AM, Olof Johansson wrote:
> > On Tue, May 28, 2013 at 8:59 PM, Tushar Behera <tushar.behera@linaro.org> wrote:
> >
> >> The patches are at [1].
> >
> > FWIW, a cgit/gitweb link is easier to follow when you're reading an
> > email. Anyway, found the patches.
> >
> >> There are a total of 6 patches on top of
> >> v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch
> >> (c) is just a defconfig hack to get Arndale booting. Remaining 2 patches
> >> (e, f) are required to reset the hub during EHCI initialization.
> >
> > Huh, I thought you said that (c) wasn't needed when I posted the
> > defconfig update. It'd be nice to see the code fixed to handle this
> > case instead of Linaro carrying a patch like this though. I.e. make it
> > able to deselect the uart, or make it tied to DEBUG_LL like on other
> > platforms instead of having a separate config for this.
> >
> 
> It would be good to free up the dependency on the correct UART port for
> the board to boot. Without that, there would always be boards that don't
> boot with default mainline defconfig file even though all other
> components are in place.
> 
> >> a. ARM: exynos: defconfig update
> >> b. ARM: EXYNOS: Update defconfig for Arndale and Origen board
> >> c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2
> >> d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250
> >> e. usb: ehci-s5p: add the HSIC port initialization
> >> f. ARM: dts: Add USB gpio entries for Arndale board
> >>
> >> I am not sure whether such kind of board-specific patches (e, f) are
> >> appreciated in the drivers. But that is all we need to get USB and
> >> Ethernet to work on v3.10-rc3 kernel.
> >
> > I've come across a similar situation with wifi reset sequence on the
> > chromebook. On the product kernel we added some code to the board file
> > to deal with it, but if we keep doing that things will grow out of
> > hand.
> >
> > I don't know if it'll be unpopular, but I think it's time to start a
> > drivers/platform/arm for these kind of things, and have those drivers
> > probe on the system compatible value, similar to how x86 does it (with
> > DMI tables). At least that's my plan for approaching the wifi
> > reset/power-on sequence on the Chromebook. I hope to have patches in
> > not all that long...
> >
> > Likewise, the hub reset/enable code doesn't have to go with the USB
> > driver, right? I.e. if you cycle reset/enable on the hub after the
> > host and phy is configured, you'll still have a working setup?
> >
> 
> Right, hub reset/enable code need not be tied up with USB driver. As per
> your suggestion regarding drivers/platform/arm, I implemented an Arndale
> specific driver [2] in drivers/platform/arm and verified USB and
> ethernet to be working.

CC'ed Thomas Abraham, Vivek Gautam

I think so.

I looked at Arndale board Schematics.
'Hub chip' on Arndale board needs hub reset/enable code.
'HUB_RESET' and 'HUB_CONNECT' pins are used to reset 'Hub chip'
on Arndale board, not Exynos EHCI controller. So, Exynos EHCI driver
does not need to consider this hub reset/enable code.

If there is a driver for this 'Hub chip', 'Hub chip' driver maybe
consider this.

However, Olof Johansson mentioned, 'drivers/platform/arm/board_arndale.c'
would be a good alternative.

> 
> [2]
> https://git.linaro.org/gitweb?p=landing-
> teams/working/samsung/kernel.git;a=shortlog;h=refs/heads/upstream/arndale-usb-2

It looks good.

Best regards,
Jingoo Han

> 
> >
> > -Olof
> >
> 
> 
> --
> Tushar Behera
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tushar Behera May 29, 2013, 12:03 p.m. UTC | #11
On 05/29/2013 11:01 AM, Olof Johansson wrote:
>> There are a total of 6 patches on top of
>> v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch
>> (c) is just a defconfig hack to get Arndale booting. Remaining 2 patches
>> (e, f) are required to reset the hub during EHCI initialization.
> 
> Huh, I thought you said that (c) wasn't needed when I posted the
> defconfig update. It'd be nice to see the code fixed to handle this
> case instead of Linaro carrying a patch like this though. I.e. make it
> able to deselect the uart, or make it tied to DEBUG_LL like on other
> platforms instead of having a separate config for this.
> 

I am working on this approach so that we can consolidate both the UART
port macros together and tie them to DEBUG_LL. I would post the patch
tomorrow.

>> a. ARM: exynos: defconfig update
>> b. ARM: EXYNOS: Update defconfig for Arndale and Origen board
>> c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2
>> d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250
>> e. usb: ehci-s5p: add the HSIC port initialization
>> f. ARM: dts: Add USB gpio entries for Arndale board
Kevin Hilman May 29, 2013, 6:23 p.m. UTC | #12
Olof Johansson <olof@lixom.net> writes:

> On Tue, May 28, 2013 at 8:59 PM, Tushar Behera <tushar.behera@linaro.org> wrote:
>
>> The patches are at [1].
>
> FWIW, a cgit/gitweb link is easier to follow when you're reading an
> email. Anyway, found the patches.
>
>> There are a total of 6 patches on top of
>> v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch
>> (c) is just a defconfig hack to get Arndale booting. Remaining 2 patches
>> (e, f) are required to reset the hub during EHCI initialization.
>
> Huh, I thought you said that (c) wasn't needed when I posted the
> defconfig update. It'd be nice to see the code fixed to handle this
> case instead of Linaro carrying a patch like this though. I.e. make it
> able to deselect the uart, or make it tied to DEBUG_LL like on other
> platforms instead of having a separate config for this.

I agree, that defconfig hack is awful to have to carry.

I also noticed that correct setting of CONFIG_S3C_LOWLEVEL_UART_PORT is
needed even without DEBUG_LL which seems broken.

Kevin
Kevin Hilman May 29, 2013, 6:34 p.m. UTC | #13
Tushar Behera <tushar.behera@linaro.org> writes:

[...]

> The patches are at [1]. There are a total of 6 patches on top of
> v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch
> (c) is just a defconfig hack to get Arndale booting. Remaining 2 patches
> (e, f) are required to reset the hub during EHCI initialization.
>
> a. ARM: exynos: defconfig update
> b. ARM: EXYNOS: Update defconfig for Arndale and Origen board
> c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2
> d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250
> e. usb: ehci-s5p: add the HSIC port initialization
> f. ARM: dts: Add USB gpio entries for Arndale board
>
> I am not sure whether such kind of board-specific patches (e, f) are
> appreciated in the drivers. But that is all we need to get USB and
> Ethernet to work on v3.10-rc3 kernel.

I confirm that using v3.10-rc3 + these patches, the wired network is
working on Arndale.

Thanks,

Kevin
Olof Johansson May 29, 2013, 6:46 p.m. UTC | #14
On Wed, May 29, 2013 at 2:33 AM, Jingoo Han <jg1.han@samsung.com> wrote:

> However, Olof Johansson mentioned, 'drivers/platform/arm/board_arndale.c'
> would be a good alternative.


Whoa. I didn't quite realize what I proposed, or rather, how what I
proposed could be perceived. I take it back. :)

We must _not_ introduce something that will be abused as a new home
for board file junk. If we do introduce a platform glue directory it
would need to be very limited in scope. Compare to what's in
drivers/platform/x86 today.


-Olof
Tushar Behera May 30, 2013, 3:37 a.m. UTC | #15
On 05/30/2013 12:16 AM, Olof Johansson wrote:
> On Wed, May 29, 2013 at 2:33 AM, Jingoo Han <jg1.han@samsung.com> wrote:
> 
>> However, Olof Johansson mentioned, 'drivers/platform/arm/board_arndale.c'
>> would be a good alternative.
> 
> 
> Whoa. I didn't quite realize what I proposed, or rather, how what I
> proposed could be perceived. I take it back. :)
> 
> We must _not_ introduce something that will be abused as a new home
> for board file junk. If we do introduce a platform glue directory it
> would need to be very limited in scope. Compare to what's in
> drivers/platform/x86 today.
> 
> 
> -Olof
> 

This was my proof-of-concept for moving USB hub reset code out of USB
driver. Verified that it works.

I would wait for your patches for wifi-reset sequence and then will add
hub-reset code for Arndale.
Jingoo Han May 30, 2013, 7:05 a.m. UTC | #16
On Thursday, May 30, 2013 12:38 PM, Tushar Behera wrote:
>On 05/30/2013 12:16 AM, Olof Johansson wrote:
>> On Wed, May 29, 2013 at 2:33 AM, Jingoo Han <jg1.han@samsung.com> wrote:
>>
>>> However, Olof Johansson mentioned, 'drivers/platform/arm/board_arndale.c'
>>> would be a good alternative.
>>
>>
>> Whoa. I didn't quite realize what I proposed, or rather, how what I
>> proposed could be perceived. I take it back. :)

My original message is as below.

"However, as Olof Johansson mentioned, 'drivers/platform/arm/'
would be a good alternative."

Also, 'board_arndale.c' should not be mentioned.
Sorry for making confusion. :)

>>
>> We must _not_ introduce something that will be abused as a new home
>> for board file junk. If we do introduce a platform glue directory it
>> would need to be very limited in scope. Compare to what's in
>> drivers/platform/x86 today.
>>
>>
>> -Olof
>>
>
>This was my proof-of-concept for moving USB hub reset code out of USB
>driver. Verified that it works.

Thank you for your additional comment.

>
>I would wait for your patches for wifi-reset sequence and then will add
>hub-reset code for Arndale.

Yes, this way looks good.

Best regards,
Jingoo Han

>
>
>--
>Tushar Behera
Vivek Gautam May 30, 2013, 1:10 p.m. UTC | #17
Hi,

> On Wednesday, May 29, 2013 5:51 PM, Tushar Behera:
>> On 05/29/2013 11:01 AM, Olof Johansson wrote:
>> > On Tue, May 28, 2013 at 8:59 PM, Tushar Behera 
>> > <tushar.behera@linaro.org> wrote:
>> >
>> >> The patches are at [1].
>> >
>> > FWIW, a cgit/gitweb link is easier to follow when you're reading an
>> > email. Anyway, found the patches.
>> >
>> >> There are a total of 6 patches on top of
>> >> v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another 
>> >> patch
>> >> (c) is just a defconfig hack to get Arndale booting. Remaining 2 
>> >> patches
>> >> (e, f) are required to reset the hub during EHCI initialization.
>> >
>> > Huh, I thought you said that (c) wasn't needed when I posted the
>> > defconfig update. It'd be nice to see the code fixed to handle this
>> > case instead of Linaro carrying a patch like this though. I.e. make it
>> > able to deselect the uart, or make it tied to DEBUG_LL like on other
>> > platforms instead of having a separate config for this.
>> >
>>
>> It would be good to free up the dependency on the correct UART port for
>> the board to boot. Without that, there would always be boards that don't
>> boot with default mainline defconfig file even though all other
>> components are in place.
>>
>> >> a. ARM: exynos: defconfig update
>> >> b. ARM: EXYNOS: Update defconfig for Arndale and Origen board
>> >> c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2
>> >> d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250
>> >> e. usb: ehci-s5p: add the HSIC port initialization
>> >> f. ARM: dts: Add USB gpio entries for Arndale board
>> >>
>> >> I am not sure whether such kind of board-specific patches (e, f) are
>> >> appreciated in the drivers. But that is all we need to get USB and
>> >> Ethernet to work on v3.10-rc3 kernel.
>> >
>> > I've come across a similar situation with wifi reset sequence on the
>> > chromebook. On the product kernel we added some code to the board file
>> > to deal with it, but if we keep doing that things will grow out of
>> > hand.
>> >
>> > I don't know if it'll be unpopular, but I think it's time to start a
>> > drivers/platform/arm for these kind of things, and have those drivers
>> > probe on the system compatible value, similar to how x86 does it (with
>> > DMI tables). At least that's my plan for approaching the wifi
>> > reset/power-on sequence on the Chromebook. I hope to have patches in
>> > not all that long...
>> >
>> > Likewise, the hub reset/enable code doesn't have to go with the USB
>> > driver, right? I.e. if you cycle reset/enable on the hub after the
>> > host and phy is configured, you'll still have a working setup?
>> >
>>
>> Right, hub reset/enable code need not be tied up with USB driver. As per
>> your suggestion regarding drivers/platform/arm, I implemented an Arndale
>> specific driver [2] in drivers/platform/arm and verified USB and
>> ethernet to be working.
>
> CC'ed Thomas Abraham, Vivek Gautam
>
> I think so.
>
> I looked at Arndale board Schematics.
> 'Hub chip' on Arndale board needs hub reset/enable code.
> 'HUB_RESET' and 'HUB_CONNECT' pins are used to reset 'Hub chip'
> on Arndale board, not Exynos EHCI controller. So, Exynos EHCI driver
> does not need to consider this hub reset/enable code.
>
> If there is a driver for this 'Hub chip', 'Hub chip' driver maybe
> consider this.
>
> However, Olof Johansson mentioned, 'drivers/platform/arm/board_arndale.c'
> would be a good alternative.

We do have a driver for USB3503 in upstream now, which has enough 
infrastructure for us to use.
We just want to handle states of HUB_CONNECT line or RESET_N line, which 
should just be fine with this driver.

Am I missing something ?

>
>>
>> [2]
>> https://git.linaro.org/gitweb?p=landing-
>> teams/working/samsung/kernel.git;a=shortlog;h=refs/heads/upstream/arndale-usb-2
>
> It looks good.


Regards
Vivek
Tushar Behera May 30, 2013, 3:26 p.m. UTC | #18
>
>
>> We do have a driver for USB3503 in upstream now, which has enough
> infrastructure for us to use.
> We just want to handle states of HUB_CONNECT line or RESET_N line, which
> should just be fine with this driver.
>
> Am I missing something ?
>
>
The USB3503 driver is an I2C client driver. In case of Arndale, the SDA and
SCL lines for SMSC3503 chip are sorted, hence there are no I2C channels
that the driver can register to. So effectively we can't use that driver
for Arndale.
Tushar Behera May 30, 2013, 3:28 p.m. UTC | #19
Resending in plain-text mode.

On 30 May 2013 20:56, Tushar Behera <tushar.behera@linaro.org> wrote:
>>>
>> We do have a driver for USB3503 in upstream now, which has enough
>> infrastructure for us to use.
>> We just want to handle states of HUB_CONNECT line or RESET_N line, which
>> should just be fine with this driver.
>>
>> Am I missing something ?
>>

The USB3503 driver is an I2C client driver. In case of Arndale, the SDA and
SCL lines for SMSC3503 chip are sorted, hence there are no I2C channels that
the driver can register to. So effectively we can't use that driver for
Arndale.
Mark Brown June 4, 2013, 12:13 p.m. UTC | #20
On Tue, May 28, 2013 at 10:31:41PM -0700, Olof Johansson wrote:
> On Tue, May 28, 2013 at 8:59 PM, Tushar Behera <tushar.behera@linaro.org> wrote:

> > e. usb: ehci-s5p: add the HSIC port initialization
> > f. ARM: dts: Add USB gpio entries for Arndale board

> > I am not sure whether such kind of board-specific patches (e, f) are
> > appreciated in the drivers. But that is all we need to get USB and
> > Ethernet to work on v3.10-rc3 kernel.

> I've come across a similar situation with wifi reset sequence on the
> chromebook. On the product kernel we added some code to the board file
> to deal with it, but if we keep doing that things will grow out of
> hand.

> I don't know if it'll be unpopular, but I think it's time to start a
> drivers/platform/arm for these kind of things, and have those drivers
> probe on the system compatible value, similar to how x86 does it (with
> DMI tables). At least that's my plan for approaching the wifi
> reset/power-on sequence on the Chromebook. I hope to have patches in
> not all that long...

This does seem to be a fairly general problem for embedded systems with
devices on enumerable buses - it's even worse for things like Slimbus
where the expectation is that many devices will spend almost all of
their time powered down.  We probably need to come up with
infrastructure to enable the drivers for the individual devices to
handle this, or at least roll out such infrastructure more widely, IIRC
there's some DT stuff for PCI.
diff mbox

Patch

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 469b5cc..eeae7bb 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -70,11 +70,15 @@  CONFIG_DEBUG_GPIO=y
 CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_I2C=y
 CONFIG_MFD_MAX77686=y
+CONFIG_MFD_MAX8997=y
+CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_TPS65090=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
+CONFIG_REGULATOR_MAX8997=y
 CONFIG_REGULATOR_MAX77686=y
+CONFIG_REGULATOR_S5M8767=y
 CONFIG_REGULATOR_TPS65090=y
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
@@ -96,6 +100,8 @@  CONFIG_USB_PHY=y
 CONFIG_SAMSUNG_USB2PHY=y
 CONFIG_SAMSUNG_USB3PHY=y
 CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_S3C=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_EXYNOS=y