| Message ID | 1368168599-28507-1-git-send-email-tushar.behera@linaro.org |
|---|---|
| State | New |
| Headers | show |
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>
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
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.
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
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
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
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)
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
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 >
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
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
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
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
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
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.
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
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
> > >> 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.
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.
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 --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
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(+)