Re: [PATCH] usb: dwc3: exynos: remove usb_phy_generic support
On Fri, Aug 29, 2014 at 11:02:52AM +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday, August 28, 2014 12:29:52 PM Greg Kroah-Hartman wrote:
> > On Thu, Aug 28, 2014 at 08:11:04PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > [ added Alan and Greg to cc: ]
> > >
> > > Hi,
> > >
> > > On Wednesday, August 27, 2014 11:42:25 PM Vivek Gautam wrote:
> > > > Hi Baltlomiej,
> > > >
> > > >
> > > > On Wed, Aug 27, 2014 at 1:22 PM, Bartlomiej Zolnierkiewicz
> > > > wrote:
> > > > > dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver
> > > > > (PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by
> > > > > looking at the following commits:
> > > > >
> > > > > 7a4cf0fde054 ("ARM: dts: Update DWC3 usb controller to use new
> > > > > phy driver for exynos5250")
> > > > >
> > > > > f070267b5fc1 ("ARM: dts: Enable support for DWC3 controller for
> > > > > exynos5420")
> > > > >
> > > > > Thus remove unused usb_phy_generic support from dwc3 Exynos glue
> > > > > layer.
> > > > >
> > > > > [ The code that is being removed is harmful in the context of
> > > > > multi_v7_defconfig and enabling "EHCI support for Samsung
> > > > > S5P/EXYNOS SoC Series" (USB_EHCI_EXYNOS) + "OHCI support for
> > > > > Samsung S5P/EXYNOS SoC Series" (USB_OHCI_EXYNOS) because "EHCI
> > > > > support for OMAP3 and later chips" (USB_EHCI_HCD_OMAP) selects
> > > > > "NOP USB Transceiver Driver" (NOP_USB_XCEIV). NOP USB driver
> > > > > attaches itself to usb_phy_generic platform devices created by
> > > > > dwc3 Exynos glue layer and later causes Exynos EHCI driver to
> > > > > fail probe and Exynos OHCI driver to hang on probe (as observed
> > > > > on Exynos5250 Arndale board). ]
> > > >
> > > > The issue with EHCI and OHCI on exynos platforms is that until now
> > > > they also request
> > > > usb-phy and only later if they don't find one, they go ahead and get a
> > > > 'phy' generic.
> > > >
> > > > Fortunately we missed this issue with exynos_defconfig, and as you
> > > > rightly
> > > > mentioned with multi_v7_defconfig, the NOP_USB_XCEIV gets enabled and
> > > > EHCI and OHCI exynos get no-op usb-phy, which actually blocks EHCI/OHCI
> > > > from
> > > > initializing the real PHYs.
> > > >
> > > > This issue is resolved with patches:
> > > > [PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy
> > > > support
> > > > [PATCH v2 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy
> > > > support
> > > > wherein we are completely removing the usb-phy support from
> > > > ehci/ohci-exynos.
> > > > So with these patches we should not see the issue mentioned by you.
> > >
> > > Indeed, your patches fix the issue.
> > >
> > > Greg, could these two patches ([1] & [2]) get merged quickly, pretty
> > > please
> > > (they were already acked by Alan)? They are not a mere cleanups because
> > > they fix the actual problem with using multi_v7_defconfig which in turn
> > > has
> > > been blocking Olof's defconfig update patch [3] for quite some time now.
> > > Moreover these patches are limited to Exynos host drivers so they should
> > > be
> > > pretty safe when it comes to potential regressions.
> > >
> > > [1] http://www.spinics.net/lists/linux-usb/msg112294.html
> > > [2] http://www.spinics.net/lists/linux-usb/msg112293.html
> > > [3] http://www.spinics.net/lists/arm-kernel/msg349654.html
> >
> > merged for 3.18-rc1, or do you "need" them for 3.17-final?
>
> If it is not too much trouble please push them to 3.17-final.
They don't meet the "regression or bugfix" rule at all, so I can't do
this, sorry. I'll queue them up for 3.18.
> > I already reverted one patch for exynos for 3.17-final that is sitting
> > in my tree to go to Linus soon as you all didn't seem to want it
> > anymore, so I'm getting really confused here...
>
> These two patches are a replacement for the one reverted and
> they just remove the old code instead of keeping it as fallback.
> This means that the reverted patch was not breaking anything and
> these two new patches could have been also done as incremental
> ones. Sorry for the confusion.
As they came in too late for 3.17-rc1, they will have to wait for
3.18-rc1.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Thomas, On Fri, Aug 29, 2014 at 5:52 AM, Thomas Abraham wrote: > Hi Kevin, > > On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman wrote: >> On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman wrote: >>> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap >>> wrote: >> >> [...] >> > > Can you clarify how you're setting the voltages to ensure stability? below is the diff : wip/exynos/integ >>> >>> Thanks. >>> >>> I've applied your patch, and bootup shows vdd_arm and vdd_kfc at >>> 1500mV, but still when booting with cpuidle enabled (bL switcher >>> disabled), I'm seeing lockups with no kernel output. With CPUidle >>> disabled, things are pretty stable. >>> >>> What tree are you using to test this out on 5420? I'm using mainline >>> v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my >>> wip/exynos/integ branch at >>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. >> >> I mis-stated this. Actually my tree is based on the v3.17-rc1 branch >> of the exynos-reference tree[1] + the above mentioned patches for >> cpuidle and cpufreq. >> >> Also, I've narrowed down the instability a bit, and it's not related >> to CPUidle. I can now trigger a boot hang even without CPUidle >> enabled. Here's a quick way to cause a boot lockup. With the switcher >> disabled, I enable CPUfreq and set the default governor to >> performance. As soon as cpufreq driver loads, it tries to use the top >> frequences for both clusters, and it hangs. >> >> Selectively disabling frequencies, I narrowed it down to the 1.3GHz >> and 1.2GHz frequencies of the little cluster. With these commented >> out in the DT, it will fully boot with the performance governor >> enabled. >> >> So that leads to the question. Are all of the operating points in >> exynos5420.dtsi valid for exynos5800, and have they been validated? > > I tried to recreate the boot lockup issue using the same steps you > listed above for the Exynos5800 peach-pi platform (Chromebook2), but I > do not see any issues. I can see both clusters with max clock speed > after boot (1.8GHz and 1.3GHz). > > I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support > patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 > voltage to 1.3V. Can you share your branch and temp hack(s) as well as your defconfig? I'm using the v3.17-rc1 branch from the exynos tree (which includes the max77802 series) but also has a bunch of other stuff which may be causing the issue. It would be good if I can reproduce your exact tree/branch and see if I still have the same problem. Thanks for looking into this, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 4/6] ARM: Exynos: switch to using generic cpufreq driver for Exynos4210/5250/5420
Hi Kevin, On Wed, Aug 27, 2014 at 3:55 AM, Kevin Hilman wrote: > On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman wrote: >> On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap >> wrote: > > [...] > Can you clarify how you're setting the voltages to ensure stability? >>> >>> below is the diff : wip/exynos/integ >> >> Thanks. >> >> I've applied your patch, and bootup shows vdd_arm and vdd_kfc at >> 1500mV, but still when booting with cpuidle enabled (bL switcher >> disabled), I'm seeing lockups with no kernel output. With CPUidle >> disabled, things are pretty stable. >> >> What tree are you using to test this out on 5420? I'm using mainline >> v3.17-rc1 + DT patch for CPUidle and this cpufreq series. See my >> wip/exynos/integ branch at >> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git. > > I mis-stated this. Actually my tree is based on the v3.17-rc1 branch > of the exynos-reference tree[1] + the above mentioned patches for > cpuidle and cpufreq. > > Also, I've narrowed down the instability a bit, and it's not related > to CPUidle. I can now trigger a boot hang even without CPUidle > enabled. Here's a quick way to cause a boot lockup. With the switcher > disabled, I enable CPUfreq and set the default governor to > performance. As soon as cpufreq driver loads, it tries to use the top > frequences for both clusters, and it hangs. > > Selectively disabling frequencies, I narrowed it down to the 1.3GHz > and 1.2GHz frequencies of the little cluster. With these commented > out in the DT, it will fully boot with the performance governor > enabled. > > So that leads to the question. Are all of the operating points in > exynos5420.dtsi valid for exynos5800, and have they been validated? I tried to recreate the boot lockup issue using the same steps you listed above for the Exynos5800 peach-pi platform (Chromebook2), but I do not see any issues. I can see both clusters with max clock speed after boot (1.8GHz and 1.3GHz). I am using v3.17-rc2 + CPUFreq Patches + max77802 regulator support patches for Chromebook2 + temp hack to set A15 voltage to 1.35V and A7 voltage to 1.3V. Sorry for the delaying in following up. Thanks, Thomas. > > Kevin > > [1]https://github.com/exynos-reference/kernel.git > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] pinctrl: samsung: use CONFIG_PINCTRL_SAMSUNG symbol in makefile
On Wed, Aug 27, 2014 at 11:48 AM, Naveen Krishna Chatradhi wrote: > Samsung Exynos7 is a ARM64bit processor. Which does not select > the CONFIG_PLAT_SAMSUNG symbol. CONFIG_PINCTRL_SAMSUNG is being > selected for both PLAT_SAMSUNG and ARCH_EXYNOS7 symbols. > > This patch modifes the pinctrl/Makefile to use > CONFIG_PINCTRL_SAMSUNG symbol to compile the pinctrl/samsung/*.c > > Signed-off-by: Naveen Krishna Chatradhi > Cc: Tomasz Figa > Cc: linus.wall...@linaro.org > Cc: Thomas Abraham Excellent catch, thanks, patch applied! I should use this pattern on more places in the Makefile, I was confused by logically thinking that Kconfig symbols used in Makefile cannot be from a Kconfig one level below. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: Tomasz has moved
On Tue, Aug 26, 2014 at 4:30 PM, Tomasz Figa wrote: > I am leaving Samsung, so my current e-mail address is not going to work > any longer. Replace it with my private one. In addition, Sylwester > Nawrocki is being added as co-maintainer for Samsung clock drivers to > take some of the responsibilities, as I will be doing my part in my spare > time. > > Signed-off-by: Tomasz Figa OK I'm taking this patch through pinctrl fixes. Not much controversy here, Mike you need not worry about it. Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes
On 25 August 2014 22:59, Doug Anderson wrote:
> Ulf,
>
> On Mon, Aug 25, 2014 at 1:31 AM, Ulf Hansson wrote:
>> On 22 August 2014 22:38, Doug Anderson wrote:
>>> Ulf,
>>>
>>> On Fri, Aug 22, 2014 at 8:35 AM, Ulf Hansson wrote:
On 22 August 2014 15:47, Yuvaraj Kumar C D wrote:
> From: Doug Anderson
>
> For UHS cards we need the ability to switch voltages from 3.3V to
> 1.8V. Add support to the dw_mmc driver to handle this. Note that
> dw_mmc needs a little bit of extra code since the interface needs a
> special bit programmed to the CMD register while CMD11 is progressing.
> This means adding a few extra states to the state machine to track.
>
> Signed-off-by: Doug Anderson
> Signed-off-by: Yuvaraj Kumar C D
> ---
> changes since v1:
> 1. Added error message and return error in case of
> regulator_set_voltage() fail.
> 2. changed dw_mci_cmd_interrupt(host,pending |
> SDMMC_INT_CMD_DONE)
>to dw_mci_cmd_interrupt(host,pending).
> 3. Removed unnecessary comments.
>
> drivers/mmc/host/dw_mmc.c | 134
> +---
> drivers/mmc/host/dw_mmc.h |5 +-
> include/linux/mmc/dw_mmc.h |2 +
> 3 files changed, 131 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index aadb0d6..f20b4b8 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -234,10 +235,13 @@ err:
> }
> #endif /* defined(CONFIG_DEBUG_FS) */
>
> +static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg);
> +
> static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct
> mmc_command *cmd)
> {
> struct mmc_data *data;
> struct dw_mci_slot *slot = mmc_priv(mmc);
> + struct dw_mci *host = slot->host;
> const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
> u32 cmdr;
> cmd->error = -EINPROGRESS;
> @@ -253,6 +257,31 @@ static u32 dw_mci_prepare_command(struct mmc_host
> *mmc, struct mmc_command *cmd)
> else if (cmd->opcode != MMC_SEND_STATUS && cmd->data)
> cmdr |= SDMMC_CMD_PRV_DAT_WAIT;
>
> + if (cmd->opcode == SD_SWITCH_VOLTAGE) {
> + u32 clk_en_a;
> +
> + /* Special bit makes CMD11 not die */
> + cmdr |= SDMMC_CMD_VOLT_SWITCH;
> +
> + /* Change state to continue to handle CMD11 weirdness */
> + WARN_ON(slot->host->state != STATE_SENDING_CMD);
> + slot->host->state = STATE_SENDING_CMD11;
> +
> + /*
> +* We need to disable clock stop while doing voltage
> switch
> +* according to Voltage Switch Normal Scenario.
> +* It's assumed that by the next time the CLKENA is
> updated
> +* (when we set the clock next) that the voltage change
> will
> +* be over, so we don't bother setting any bits to
> synchronize
> +* with dw_mci_setup_bus().
> +*/
I don't know the details about the dw_mmc controller, but normally a
host driver is expected to gate the clock from it's ->set_ios
callback, when the clk frequency are set to 0.
Could you elaborate on why dw_mmc can't do that, but need to handle
this from here?
>>>
>>> Let's see, it's been a while since I wrote this...
>>>
>>>
>>> So dw_mmc has a special feature where the controller itself will
>>> automatically stop the MMC Card clock when nothing is going on. This
>>> is called "low power" mode. I'm not super familiar with other MMC
>>> drivers, I get the impression that this is a special dw_mmc feature
>>> and not common to other controllers. I think other drivers have
>>> aggressive runtime PM to get similar power savings.
>>
>> I see.
>>
>> I am familiar with such "low power" mode features, there are certainly
>> other controllers supporting such as well. My experience tells me,
>> it's hard to get things right for all corner cases. The voltage switch
>> behaviour is just one of these, then you have SDIO irq etc.
>>
>> Instead of using the controller HW, yes you may implement clock gating
>> through runtime PM in the host driver.
>>
>>>
>>> The dw_mmc auto clock gating can wreck total havoc on the voltage
>>> change procedure, since part of the way that the host and card
>>> communicate is that the host is supposed to stop its clock when it
>>> gets to a certain phase of the voltage switch sequence. If the
>>> controller is stopping the clock for us then it can confuse the
Re: [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
On 22 August 2014 15:47, Yuvaraj Kumar C D wrote:
> This patch makes use of mmc_regulator_get_supply() to handle
> the vmmc and vqmmc regulators.Also it moves the code handling
> the these regulators to dw_mci_set_ios().It turned on the vmmc
> and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
> during MMC_POWER_OFF.
>
> Signed-off-by: Yuvaraj Kumar C D
Thanks! Applied for next.
Kind regards
Uffe
> ---
> changes from v1:
> 1.Used mmc_regulator_set_ocr() instead of regulator_enable() for vmmc.
> 2.Turned on vmmc and vqmmc during MMC_POWER_UP.
> 3. Removed the flags DW_MMC_CARD_POWERED and DW_MMC_IO_POWERED which
>added during the initial version of this patch.
> 4. Added error message, if it failed to turn on regulator's.
>
> drivers/mmc/host/dw_mmc.c | 72
> +---
> include/linux/mmc/dw_mmc.h |2 +-
> 2 files changed, 36 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 7f227e9..aadb0d6 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -936,6 +936,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
> struct dw_mci_slot *slot = mmc_priv(mmc);
> const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
> u32 regs;
> + int ret;
>
> switch (ios->bus_width) {
> case MMC_BUS_WIDTH_4:
> @@ -974,12 +975,38 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
>
> switch (ios->power_mode) {
> case MMC_POWER_UP:
> + if (!IS_ERR(mmc->supply.vmmc)) {
> + ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
> + ios->vdd);
> + if (ret) {
> + dev_err(slot->host->dev,
> + "failed to enable vmmc regulator\n");
> + /*return, if failed turn on vmmc*/
> + return;
> + }
> + }
> + if (!IS_ERR(mmc->supply.vqmmc) && !slot->host->vqmmc_enabled)
> {
> + ret = regulator_enable(mmc->supply.vqmmc);
> + if (ret < 0)
> + dev_err(slot->host->dev,
> + "failed to enable vqmmc regulator\n");
> + else
> + slot->host->vqmmc_enabled = true;
> + }
> set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
> regs = mci_readl(slot->host, PWREN);
> regs |= (1 << slot->id);
> mci_writel(slot->host, PWREN, regs);
> break;
> case MMC_POWER_OFF:
> + if (!IS_ERR(mmc->supply.vmmc))
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> +
> + if (!IS_ERR(mmc->supply.vqmmc) && slot->host->vqmmc_enabled) {
> + regulator_disable(mmc->supply.vqmmc);
> + slot->host->vqmmc_enabled = false;
> + }
> +
> regs = mci_readl(slot->host, PWREN);
> regs &= ~(1 << slot->id);
> mci_writel(slot->host, PWREN, regs);
> @@ -2110,7 +2137,13 @@ static int dw_mci_init_slot(struct dw_mci *host,
> unsigned int id)
> mmc->f_max = freq[1];
> }
>
> - mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
> + /*if there are external regulators, get them*/
> + ret = mmc_regulator_get_supply(mmc);
> + if (ret == -EPROBE_DEFER)
> + goto err_setup_bus;
> +
> + if (!mmc->ocr_avail)
> + mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
>
> if (host->pdata->caps)
> mmc->caps = host->pdata->caps;
> @@ -2176,7 +2209,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
> unsigned int id)
>
> err_setup_bus:
> mmc_free_host(mmc);
> - return -EINVAL;
> + return ret;
> }
>
> static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
> @@ -2469,24 +2502,6 @@ int dw_mci_probe(struct dw_mci *host)
> }
> }
>
> - host->vmmc = devm_regulator_get_optional(host->dev, "vmmc");
> - if (IS_ERR(host->vmmc)) {
> - ret = PTR_ERR(host->vmmc);
> - if (ret == -EPROBE_DEFER)
> - goto err_clk_ciu;
> -
> - dev_info(host->dev, "no vmmc regulator found: %d\n", ret);
> - host->vmmc = NULL;
> - } else {
> - ret = regulator_enable(host->vmmc);
> - if (ret) {
> - if (ret != -EPROBE_DEFER)
> - dev_err(host->dev,
> - "regulator_enable fail: %d\n", ret);
> -
Re: [PATCH] mmc: dw_mmc: exynos: Add support for exynos7
Hi, Abhilash.
On 08/28/2014 10:18 PM, Yuvaraj Kumar C D wrote:
> From: Abhilash Kesavan
>
> The Exynos7 has a DWMMC controller (v2.70a) which is different from
> prior versions. This patch adds new compatible strings for exynos7.
> This patch also fixes the CLKSEL register offset on exynos7.
If support the 64bit, dw-mmc.c need to modify.(according to v2.70, some offset
is changed for 64-bit address)
But i didn't see any patches at mailing.
Do you have the plan which send patch of dw-mmc.c?
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Yuvaraj Kumar C D
> ---
> .../devicetree/bindings/mmc/exynos-dw-mshc.txt |4 +
> drivers/mmc/host/dw_mmc-exynos.c | 91
> +---
> 2 files changed, 82 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> index 6cd3525..ee4fc05 100644
> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> @@ -18,6 +18,10 @@ Required Properties:
> specific extensions.
> - "samsung,exynos5420-dw-mshc": for controllers with Samsung Exynos5420
> specific extensions.
> + - "samsung,exynos7-dw-mshc": for controllers with Samsung Exynos7
> + specific extensions.
> + - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
> + specific extensions having an SMU.
>
> * samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
>unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
> b/drivers/mmc/host/dw_mmc-exynos.c
> index 0fbc53a..509365c 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -25,6 +25,7 @@
> #define NUM_PINS(x) (x + 2)
>
> #define SDMMC_CLKSEL 0x09C
> +#define SDMMC_CLKSEL64 0x0A8
> #define SDMMC_CLKSEL_CCLK_SAMPLE(x) (((x) & 7) << 0)
> #define SDMMC_CLKSEL_CCLK_DRIVE(x) (((x) & 7) << 16)
> #define SDMMC_CLKSEL_CCLK_DIVIDER(x) (((x) & 7) << 24)
> @@ -65,6 +66,8 @@ enum dw_mci_exynos_type {
> DW_MCI_TYPE_EXYNOS5250,
> DW_MCI_TYPE_EXYNOS5420,
> DW_MCI_TYPE_EXYNOS5420_SMU,
> + DW_MCI_TYPE_EXYNOS7,
> + DW_MCI_TYPE_EXYNOS7_SMU,
> };
>
> /* Exynos implementation specific driver private data */
> @@ -95,6 +98,12 @@ static struct dw_mci_exynos_compatible {
> }, {
> .compatible = "samsung,exynos5420-dw-mshc-smu",
> .ctrl_type = DW_MCI_TYPE_EXYNOS5420_SMU,
> + }, {
> + .compatible = "samsung,exynos7-dw-mshc",
> + .ctrl_type = DW_MCI_TYPE_EXYNOS7,
> + }, {
> + .compatible = "samsung,exynos7-dw-mshc-smu",
> + .ctrl_type = DW_MCI_TYPE_EXYNOS7_SMU,
> },
> };
>
> @@ -102,7 +111,8 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
> {
> struct dw_mci_exynos_priv_data *priv = host->priv;
>
> - if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS5420_SMU) {
> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS5420_SMU ||
> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU) {
> mci_writel(host, MPSBEGIN0, 0);
> mci_writel(host, MPSEND0, DWMCI_BLOCK_NUM);
> mci_writel(host, MPSCTRL0, DWMCI_MPSCTRL_SECURE_WRITE_BIT |
> @@ -153,11 +163,22 @@ static int dw_mci_exynos_resume(struct device *dev)
> static int dw_mci_exynos_resume_noirq(struct device *dev)
> {
> struct dw_mci *host = dev_get_drvdata(dev);
> + struct dw_mci_exynos_priv_data *priv = host->priv;
> u32 clksel;
>
> - clksel = mci_readl(host, CLKSEL);
> - if (clksel & SDMMC_CLKSEL_WAKEUP_INT)
> - mci_writel(host, CLKSEL, clksel);
> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
> + clksel = mci_readl(host, CLKSEL64);
> + else
> + clksel = mci_readl(host, CLKSEL);
> +
> + if (clksel & SDMMC_CLKSEL_WAKEUP_INT) {
> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
> + mci_writel(host, CLKSEL64, clksel);
> + else
> + mci_writel(host, CLKSEL, clksel);
> + }
>
> return 0;
> }
> @@ -169,6 +190,7 @@ static int dw_mci_exynos_resume_noirq(struct device *dev)
>
> static void dw_mci_exynos_prepare_command(struct dw_mci *host, u32 *cmdr)
> {
> + struct dw_mci_exynos_priv_data *priv = host->priv;
> /*
>* Exynos4412 and Exynos5250 extends the use of CMD register with the
>* use of bit 29 (which is reserved on standard MSHC controllers) for
> @@ -176,8 +198,14 @@ static void dw_mci_exynos_prepare_command(struct dw_mci
> *host, u
Re: [PATCH] usb: dwc3: exynos: remove usb_phy_generic support
On Thursday, August 28, 2014 12:29:52 PM Greg Kroah-Hartman wrote:
> On Thu, Aug 28, 2014 at 08:11:04PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > [ added Alan and Greg to cc: ]
> >
> > Hi,
> >
> > On Wednesday, August 27, 2014 11:42:25 PM Vivek Gautam wrote:
> > > Hi Baltlomiej,
> > >
> > >
> > > On Wed, Aug 27, 2014 at 1:22 PM, Bartlomiej Zolnierkiewicz
> > > wrote:
> > > > dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver
> > > > (PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by
> > > > looking at the following commits:
> > > >
> > > > 7a4cf0fde054 ("ARM: dts: Update DWC3 usb controller to use new
> > > > phy driver for exynos5250")
> > > >
> > > > f070267b5fc1 ("ARM: dts: Enable support for DWC3 controller for
> > > > exynos5420")
> > > >
> > > > Thus remove unused usb_phy_generic support from dwc3 Exynos glue
> > > > layer.
> > > >
> > > > [ The code that is being removed is harmful in the context of
> > > > multi_v7_defconfig and enabling "EHCI support for Samsung
> > > > S5P/EXYNOS SoC Series" (USB_EHCI_EXYNOS) + "OHCI support for
> > > > Samsung S5P/EXYNOS SoC Series" (USB_OHCI_EXYNOS) because "EHCI
> > > > support for OMAP3 and later chips" (USB_EHCI_HCD_OMAP) selects
> > > > "NOP USB Transceiver Driver" (NOP_USB_XCEIV). NOP USB driver
> > > > attaches itself to usb_phy_generic platform devices created by
> > > > dwc3 Exynos glue layer and later causes Exynos EHCI driver to
> > > > fail probe and Exynos OHCI driver to hang on probe (as observed
> > > > on Exynos5250 Arndale board). ]
> > >
> > > The issue with EHCI and OHCI on exynos platforms is that until now
> > > they also request
> > > usb-phy and only later if they don't find one, they go ahead and get a
> > > 'phy' generic.
> > >
> > > Fortunately we missed this issue with exynos_defconfig, and as you rightly
> > > mentioned with multi_v7_defconfig, the NOP_USB_XCEIV gets enabled and
> > > EHCI and OHCI exynos get no-op usb-phy, which actually blocks EHCI/OHCI
> > > from
> > > initializing the real PHYs.
> > >
> > > This issue is resolved with patches:
> > > [PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
> > > [PATCH v2 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support
> > > wherein we are completely removing the usb-phy support from
> > > ehci/ohci-exynos.
> > > So with these patches we should not see the issue mentioned by you.
> >
> > Indeed, your patches fix the issue.
> >
> > Greg, could these two patches ([1] & [2]) get merged quickly, pretty please
> > (they were already acked by Alan)? They are not a mere cleanups because
> > they fix the actual problem with using multi_v7_defconfig which in turn has
> > been blocking Olof's defconfig update patch [3] for quite some time now.
> > Moreover these patches are limited to Exynos host drivers so they should be
> > pretty safe when it comes to potential regressions.
> >
> > [1] http://www.spinics.net/lists/linux-usb/msg112294.html
> > [2] http://www.spinics.net/lists/linux-usb/msg112293.html
> > [3] http://www.spinics.net/lists/arm-kernel/msg349654.html
>
> merged for 3.18-rc1, or do you "need" them for 3.17-final?
If it is not too much trouble please push them to 3.17-final.
> I already reverted one patch for exynos for 3.17-final that is sitting
> in my tree to go to Linus soon as you all didn't seem to want it
> anymore, so I'm getting really confused here...
These two patches are a replacement for the one reverted and
they just remove the old code instead of keeping it as fallback.
This means that the reverted patch was not breaking anything and
these two new patches could have been also done as incremental
ones. Sorry for the confusion.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 17/17] drm/exynos/ipp: add file checks for ioctls
Hi Andrzej,
On 08/28/2014 06:07 PM, Andrzej Hajda wrote:
> Process should not have access to ipp nodes created by another
> process. The patch adds necessary checks.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index fc8bb67..d233cfc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -318,7 +318,8 @@ static void ipp_print_property(struct
> drm_exynos_ipp_property *property,
> sz->hsize, sz->vsize, config->flip, config->degree);
> }
>
> -static int ipp_find_and_set_property(struct drm_exynos_ipp_property
> *property)
> +static int ipp_find_and_set_property(struct drm_exynos_ipp_property
> *property,
> + struct drm_file *file)
This is ok, but i think ipp_find_and_set_property function is some
duplicated. If we add function to get c_node from struct
exynos_drm_ippdrv, it's easy to remove ipp_find_and_set_property.
Thanks.
> {
> struct exynos_drm_ippdrv *ippdrv;
> struct drm_exynos_ipp_cmd_node *c_node;
> @@ -339,8 +340,12 @@ static int ipp_find_and_set_property(struct
> drm_exynos_ipp_property *property)
>*/
> mutex_lock(&ippdrv->cmd_lock);
> list_for_each_entry(c_node, &ippdrv->cmd_list, list) {
> - if ((c_node->property.prop_id == prop_id) &&
> - (c_node->state == IPP_STATE_STOP)) {
> + if (c_node->property.prop_id == prop_id) {
> + if (c_node->filp != file)
> + break;
> + if (c_node->state != IPP_STATE_STOP)
> + break;
> +
> mutex_unlock(&ippdrv->cmd_lock);
> DRM_DEBUG_KMS("found cmd[%d]ippdrv[0x%x]\n",
> property->cmd, (int)ippdrv);
> @@ -418,7 +423,7 @@ int exynos_drm_ipp_set_property(struct drm_device
> *drm_dev, void *data,
>*/
> if (property->prop_id) {
> DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id);
> - return ipp_find_and_set_property(property);
> + return ipp_find_and_set_property(property, file);
> }
>
> /* find ipp driver using ipp id */
> @@ -1032,7 +1037,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev,
> void *data,
>
> c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock,
> cmd_ctrl->prop_id);
> - if (!c_node) {
> + if (!c_node || c_node->filp != file) {
> DRM_ERROR("invalid command node list.\n");
> return -ENODEV;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 16/17] drm/exynos/ipp: remove file argument from node related functions
Hi Andrzej,
On 08/28/2014 06:07 PM, Andrzej Hajda wrote:
> Since file pointer is preserved in c_node passing it
> as argument in node functions is redundant.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 05f0f4e..fc8bb67 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
>
> static struct drm_exynos_ipp_mem_node
> *ipp_get_mem_node(struct drm_device *drm_dev,
> - struct drm_file *file,
> struct drm_exynos_ipp_cmd_node *c_node,
> struct drm_exynos_ipp_queue_buf *qbuf)
> {
> @@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
> dma_addr_t *addr;
>
> addr = exynos_drm_gem_get_dma_addr(drm_dev,
> - qbuf->handle[i], file);
> + qbuf->handle[i], c_node->filp);
> if (IS_ERR(addr)) {
> DRM_ERROR("failed to get addr.\n");
> ipp_put_mem_node(drm_dev, c_node, m_node);
> @@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event
> *event)
> }
>
> static int ipp_get_event(struct drm_device *drm_dev,
> - struct drm_file *file,
> struct drm_exynos_ipp_cmd_node *c_node,
> struct drm_exynos_ipp_queue_buf *qbuf)
> {
> @@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
> e = kzalloc(sizeof(*e), GFP_KERNEL);
> if (!e) {
> spin_lock_irqsave(&drm_dev->event_lock, flags);
> - file->event_space += sizeof(e->event);
> + c_node->filp->event_space += sizeof(e->event);
> spin_unlock_irqrestore(&drm_dev->event_lock, flags);
> return -ENOMEM;
> }
> @@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
> e->event.prop_id = qbuf->prop_id;
> e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
> e->base.event = &e->event.base;
> - e->base.file_priv = file;
> + e->base.file_priv = c_node->filp;
> e->base.destroy = ipp_free_event;
> mutex_lock(&c_node->event_lock);
> list_add_tail(&e->base.link, &c_node->event_list);
> @@ -899,7 +897,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
> void *data,
> /* find command node */
> c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock,
> qbuf->prop_id);
> - if (!c_node) {
> + if (!c_node || c_node->filp != file) {
I think this should go to patch 17.
Thanks.
> DRM_ERROR("failed to get command node.\n");
> return -ENODEV;
> }
> @@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
> void *data,
> switch (qbuf->buf_type) {
> case IPP_BUF_ENQUEUE:
> /* get memory node */
> - m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
> + m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
> if (IS_ERR(m_node)) {
> DRM_ERROR("failed to get m_node.\n");
> return PTR_ERR(m_node);
> @@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
> void *data,
>*/
> if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) {
> /* get event for destination buffer */
> - ret = ipp_get_event(drm_dev, file, c_node, qbuf);
> + ret = ipp_get_event(drm_dev, c_node, qbuf);
> if (ret) {
> DRM_ERROR("failed to get event.\n");
> goto err_clean_node;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
