Re: [PATCH RESEND] usb: ehci/ohci-exynos: Fix PHY getting sequence
Hi Vivek, On Tue, Aug 5, 2014 at 4:09 PM, Vivek Gautam wrote: > Since we want to keep support for both older usb-phys as well as the > newer generic phys, lets first get the generic PHYs and fallback to > older USB-PHYs only when we fail to get the former. > This should fix the issue with ehci-exynos and ohci-exynos, wherein > in the absence of SAMSUNG_USB2PHY config symbol, we end up getting > the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs > are not configured properly. > > Reported-by: Sachin Kamat > Signed-off-by: Vivek Gautam > Cc: Alan Stern > Cc: Jingoo Han Tested this patch on Exynos5250 based Arndale and Snow boards. Fixes the said issue. Thanks. Tested-by: Sachin Kamat -- Regards, Sachin. -- 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] media: v4l2: make allocation algorithm more robust and flexible
Hi Zhaowei, On Wed, Jul 30, 2014 at 9:39 AM, Zhaowei Yuan wrote: > Current algorithm relies on the fact that caller will align the > size to PAGE_SIZE, otherwise order will be decreased to negative > when remain size is less than PAGE_SIZE, it makes the function > hard to be migrated. > This patch sloves the hidden problem. > > Signed-off-by: Zhaowei Yuan > --- > drivers/media/v4l2-core/videobuf2-dma-sg.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c > b/drivers/media/v4l2-core/videobuf2-dma-sg.c > index adefc31..40d18aa 100644 > --- a/drivers/media/v4l2-core/videobuf2-dma-sg.c > +++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c > @@ -58,7 +58,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf > *buf, > > order = get_order(size); > /* Dont over allocate*/ > - if ((PAGE_SIZE << order) > size) > + if (order > 0 && (PAGE_SIZE << order) > size) > order--; If size is not page aligned, then wouldn't decrementing the order under-allocate the memory? -- Regards, Sachin. -- 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: [RESEND][PATCH 2/2] ARM: EXYNOS: Add exynos5260 PMU compatible string to DT match table
Hi Vikas,
On Mon, Jul 28, 2014 at 6:08 PM, Vikas Sajjan wrote:
> Exynos initialisation code now relies on obtaining the PMU address via
> DT, so add the exynos5260 PMU compatible string to DT match table.
>
> Signed-off-by: Vikas Sajjan
> ---
> arch/arm/mach-exynos/exynos.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index df41bd1..e4f7270 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -253,6 +253,7 @@ static const struct of_device_id exynos_dt_pmu_match[] = {
> { .compatible = "samsung,exynos4412-pmu" },
> { .compatible = "samsung,exynos5250-pmu" },
> { .compatible = "samsung,exynos5420-pmu" },
> + { .compatible = "samsung,exynos5260-pmu" },
Same comment as previous patch regarding order.
--
Regards,
Sachin.
--
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: [RESEND][PATCH 1/2] ARM: DTS: Add PMU DT node for exynos5260 SoC
Hi Vikas, On Mon, Jul 28, 2014 at 6:07 PM, Vikas Sajjan wrote: > Adds PMU DT node for exynos5260 SoC. > > Signed-off-by: Vikas Sajjan > --- > .../devicetree/bindings/arm/samsung/pmu.txt|1 + > arch/arm/boot/dts/exynos5260.dtsi |5 + > 2 files changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt > b/Documentation/devicetree/bindings/arm/samsung/pmu.txt > index 2a4ab04..c038628 100644 > --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt > +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt > @@ -8,6 +8,7 @@ Properties: >- "samsung,exynos4412-pmu" - for Exynos4412 SoC, >- "samsung,exynos5250-pmu" - for Exynos5250 SoC, >- "samsung,exynos5420-pmu" - for Exynos5420 SoC. > + - "samsung,exynos5260-pmu" - for Exynos5260 SoC. nit: This line should come after 5250 entry to preserve the order. Otherwise, looks good. -- Regards, Sachin. -- 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 1/1] i2c: Kconfig: Enable HSI2C for Exynos5 platform
On Wed, Jul 16, 2014 at 11:10 PM, Wolfram Sang wrote: > On Wed, Jun 25, 2014 at 10:55:31AM -0700, Doug Anderson wrote: >> Sachin, >> >> On Wed, Jun 25, 2014 at 3:02 AM, Sachin Kamat >> wrote: >> > All Exynos5 platforms have HSI2C controllers and are needed by >> > various IPs connected to the boards based on these SoCs. Thus >> > select this by default for Exynos5 platforms. >> > >> > Signed-off-by: Sachin Kamat >> > Cc: Doug Anderson >> > --- >> > drivers/i2c/busses/Kconfig |4 ++-- >> > 1 file changed, 2 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> > index 9f7d5859cf65..c7918cffe790 100644 >> > --- a/drivers/i2c/busses/Kconfig >> > +++ b/drivers/i2c/busses/Kconfig >> > @@ -465,9 +465,9 @@ config I2C_EG20T >> > config I2C_EXYNOS5 >> > tristate "Exynos5 high-speed I2C driver" >> > depends on ARCH_EXYNOS5 && OF >> > + default y >> > help >> > - Say Y here to include support for high-speed I2C controller in >> > the >> > - Exynos5 based Samsung SoCs. >> > + High-speed I2C controller on Exynos5 based Samsung SoCs. >> > >> > config I2C_GPIO >> > tristate "GPIO-based bitbanging I2C" >> > -- >> > 1.7.9.5 >> >> This seems reasonable to me and I will also take the blame for >> suggesting this. It's hard to imagine running a real exynos5 system >> without I2C. One could argue that on an exynos5250 the high speed I2C >> controller is not mandatory (since all the ports can be muxed to use >> the old controller) but on newer exynos5 products you're expected to >> have the main PMIC on one of the i2c ports. An exynos system without >> access to its PMIC will just sorta limp by. >> >> ...but I've added Arnd to this thread as he expressed some >> reservations about this type of thing, so we'll see what he says. > > Ping. Arnd? I have no strong opinion and would take this patch... Wolfram, How do you want to proceed with this? > >> >> Reviewed-by: Doug Anderson -- Regards, Sachin. -- 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] cpufreq: tests: Providing cpufreq regression test
Hi Lukasz, On Fri, Jul 18, 2014 at 5:29 PM, Lukasz Majewski wrote: > Hi Sachin, > >> Hi Lukasz, >> >> I tested this script on 4210 based Origen board. >> This is the output: >> ./cpufreq_freq_test.sh >> CURRENT GOVERNOR: performance >> SET GOVERNOR: performance >> ## >> TEST AVAILABLE FREQS >> ## >> FREQ: 120 sleep: invalid number '0.1' >> [5.918347] random: gzip urandom read with 61 bits of entropy >> available OK >> FREQ: 100 sleep: invalid number '0.1' >> OK >> FREQ: 80 sleep: invalid number '0.1' >> OK >> FREQ: 50 sleep: invalid number '0.1' >> OK >> FREQ: 20 sleep: invalid number '0.1' >> OK >> ## >> TEST FREQS SWITCHING >> ## >> REFERENCE FREQ: 120 >> FREQ: 120 > FREQ: 120 sleep: invalid number '0.1' >> OK >> FREQ: 120 > FREQ: 100 sleep: invalid number '0.1' >> OK >> FREQ: 120 > FREQ: 80 sleep: invalid number '0.1' >> OK >> FREQ: 120 > FREQ: 50 sleep: invalid number '0.1' >> OK >> FREQ: 120 > FREQ: 20 sleep: invalid number '0.1' >> OK >> REFERENCE FREQ: 100 >> FREQ: 100 > FREQ: 120 sleep: invalid number '0.1' >> OK >> FREQ: 100 > FREQ: 100 sleep: invalid number '0.1' >> OK >> FREQ: 100 > FREQ: 80 sleep: invalid number '0.1' >> OK >> FREQ: 100 > FREQ: 50 sleep: invalid number '0.1' >> OK >> FREQ: 100 > FREQ: 20 sleep: invalid number '0.1' >> OK >> REFERENCE FREQ: 80 >> FREQ: 80 > FREQ: 120 sleep: invalid number '0.1' >> OK >> FREQ: 80 > FREQ: 100 sleep: invalid number '0.1' >> OK >> FREQ: 80 > FREQ: 80 sleep: invalid number '0.1' >> OK >> FREQ: 80 > FREQ: 50 sleep: invalid number '0.1' >> OK >> FREQ: 80 > FREQ: 20 sleep: invalid number '0.1' >> OK >> REFERENCE FREQ: 50 >> FREQ: 50 > FREQ: 120 sleep: invalid number '0.1' >> OK >> FREQ: 50 > FREQ: 100 sleep: invalid number '0.1' >> OK >> FREQ: 50 > FREQ: 80 sleep: invalid number '0.1' >> OK >> FREQ: 50 > FREQ: 50 sleep: invalid number '0.1' >> OK >> FREQ: 50 > FREQ: 20 sleep: invalid number '0.1' >> OK >> REFERENCE FREQ: 20 >> FREQ: 20 > FREQ: 120 sleep: invalid number '0.1' >> OK >> FREQ: 20 > FREQ: 100 sleep: invalid number '0.1' >> OK >> FREQ: 20 > FREQ: 80 sleep: invalid number '0.1' >> OK >> FREQ: 20 > FREQ: 50 sleep: invalid number '0.1' >> OK >> FREQ: 20 > FREQ: 20 sleep: invalid number '0.1' >> OK >> ## >> ERRORS: 0 >> ## >> >> Though it says 0 errors, what does the "invalid number..." signify? > > I guess that this message is caused by your default sleep > implementation. > > Could you type 'sleep 0.1' and then 'sleep 1' in your console on the > target system? > Is the "invalid number" not present with the second case? Only with first case (sleep 0.1) I get the "invalid number" message. sleep 1 seems to be OK. -- Regards, Sachin. -- 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] cpufreq: tests: Providing cpufreq regression test
Hi Lukasz, I tested this script on 4210 based Origen board. This is the output: ./cpufreq_freq_test.sh CURRENT GOVERNOR: performance SET GOVERNOR: performance ## TEST AVAILABLE FREQS ## FREQ: 120 sleep: invalid number '0.1' [5.918347] random: gzip urandom read with 61 bits of entropy available OK FREQ: 100 sleep: invalid number '0.1' OK FREQ: 80 sleep: invalid number '0.1' OK FREQ: 50 sleep: invalid number '0.1' OK FREQ: 20 sleep: invalid number '0.1' OK ## TEST FREQS SWITCHING ## REFERENCE FREQ: 120 FREQ: 120 > FREQ: 120 sleep: invalid number '0.1' OK FREQ: 120 > FREQ: 100 sleep: invalid number '0.1' OK FREQ: 120 > FREQ: 80 sleep: invalid number '0.1' OK FREQ: 120 > FREQ: 50 sleep: invalid number '0.1' OK FREQ: 120 > FREQ: 20 sleep: invalid number '0.1' OK REFERENCE FREQ: 100 FREQ: 100 > FREQ: 120 sleep: invalid number '0.1' OK FREQ: 100 > FREQ: 100 sleep: invalid number '0.1' OK FREQ: 100 > FREQ: 80 sleep: invalid number '0.1' OK FREQ: 100 > FREQ: 50 sleep: invalid number '0.1' OK FREQ: 100 > FREQ: 20 sleep: invalid number '0.1' OK REFERENCE FREQ: 80 FREQ: 80 > FREQ: 120 sleep: invalid number '0.1' OK FREQ: 80 > FREQ: 100 sleep: invalid number '0.1' OK FREQ: 80 > FREQ: 80 sleep: invalid number '0.1' OK FREQ: 80 > FREQ: 50 sleep: invalid number '0.1' OK FREQ: 80 > FREQ: 20 sleep: invalid number '0.1' OK REFERENCE FREQ: 50 FREQ: 50 > FREQ: 120 sleep: invalid number '0.1' OK FREQ: 50 > FREQ: 100 sleep: invalid number '0.1' OK FREQ: 50 > FREQ: 80 sleep: invalid number '0.1' OK FREQ: 50 > FREQ: 50 sleep: invalid number '0.1' OK FREQ: 50 > FREQ: 20 sleep: invalid number '0.1' OK REFERENCE FREQ: 20 FREQ: 20 > FREQ: 120 sleep: invalid number '0.1' OK FREQ: 20 > FREQ: 100 sleep: invalid number '0.1' OK FREQ: 20 > FREQ: 80 sleep: invalid number '0.1' OK FREQ: 20 > FREQ: 50 sleep: invalid number '0.1' OK FREQ: 20 > FREQ: 20 sleep: invalid number '0.1' OK ## ERRORS: 0 ## Though it says 0 errors, what does the "invalid number..." signify? On Fri, Jul 18, 2014 at 3:53 PM, Lukasz Majewski wrote: > This commit adds first regression test "cpufreq_freq_test.sh" for the > cpufreq subsystem. > > Signed-off-by: Lukasz Majewski > --- > drivers/cpufreq/tests/README | 23 + > drivers/cpufreq/tests/cpufreq_freq_test.sh | 149 > + > 2 files changed, 172 insertions(+) > create mode 100644 drivers/cpufreq/tests/README > create mode 100755 drivers/cpufreq/tests/cpufreq_freq_test.sh > > diff --git a/drivers/cpufreq/tests/README b/drivers/cpufreq/tests/README > new file mode 100644 > index 000..66638d2 > --- /dev/null > +++ b/drivers/cpufreq/tests/README > @@ -0,0 +1,23 @@ > +This file contains list of cpufreq's available regression tests with a short > +usage description. > + > +1. cpufreq_freq_test.sh > + > +Description: > + > +This test is supposed to test if cpufreq attributes exported by sysfs are s/test/script would be better > +exposing a correct values. s/ exposing a correct values / exposing correct values > + > +It can work with or without boost enabled and helps spotting errors related > to s/ helps spotting / helps in spotting > + > +set +x > + > +COLOUR_RED="\33[31m" > +COLOUR_BLUE="\33[34m" > +COLOUR_GREEN="\33[32m" > +COLOUR_DEFAULT="\33[0m" > + > +T_PATCH=/sys/devices/system/cpu/cpu0/cpufreq Shouldn't this be called PATH instead of PATCH? > +BOOST_PATCH=/sys/devices/system/cpu/cpufreq ditto and rest of the places in the document. -- Regards, Sachin. -- 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 1/4 v2] iio: exyno-adc: use syscon for PMU register access
Hi Naveen, On Thu, Jul 17, 2014 at 4:49 PM, Naveen Krishna Chatradhi wrote: > This patch updates the IIO based ADC driver to use syscon and regmap > APIs to access and use PMU registers instead of remapping the PMU > registers in the driver. > > Signed-off-by: Naveen Krishna Chatradhi > To: linux-...@vger.kernel.org With only this patch applied, I believe the ADC functionality would be broken. Perhaps the DT changes should be merged along with this patch? -- Regards, Sachin. -- 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] ARM: config: update multi_v7_defconfig
Hi Doug, On Tue, Jul 15, 2014 at 9:29 PM, Doug Anderson wrote: > Naveen, > > On Tue, Jul 15, 2014 at 1:02 AM, Naveen Krishna Chatradhi > wrote: >> Enabled S3C24XX I2C driver and MAX77686 PMIC MFD and Voltage >> regulator drivers used on Exynos5250 based Snow board. >> >> Signed-off-by: Naveen Krishna Chatradhi >> --- >> By enabling the symbols to compile S3C24XX I2C driver, MAX77686 PMIC >> under MFD and REGULATOR. >> >> http://arm-soc.lixom.net/bootlogs/next/next-20140711/snow-multi_v7_defconfig.html >> The warnings by cpufreq on Snow board are fixed. >> >> Booted and verified on on Exynos5420 based Snow board >> >> arch/arm/configs/multi_v7_defconfig |3 +++ >> 1 file changed, 3 insertions(+) > > Is there a reason not to add more of the max77686 configs? > > +CONFIG_RTC_DRV_MAX77686=y > +CONFIG_COMMON_CLK_MAX77686=y > > I also seems like it would be nice to reconcile this with Sacin's > latest patch. For starters I notice that you're missing: > CONFIG_EXYNOS5420_MCPM=y > > I'll leave it up to you to look for other things that might be > missing. If some of the things in exynos5_defconfig can't go into the > multi-config, please explain. multi_v7_defconfig update patch, inline with exynos_defconfig is already on my TODO list. I wanted to send this one along with the next update of exynos_defconfig (around -rc7) as Olof preferred to have a single patch updating most of the available things. By then I believe remaining drivers like 5420/5800 regulators, display and cpufreq drivers would have been merged. -- Regards, Sachin. -- 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 1/1] ARM: exynos_defconfig: Update exynos_defconfig
On Tue, Jul 15, 2014 at 12:20 AM, Olof Johansson wrote: > On Mon, Jul 14, 2014 at 9:47 AM, Doug Anderson wrote: >> Sachin, >> >> On Wed, Jul 9, 2014 at 3:22 AM, Sachin Kamat >> wrote: > Gave this a go on my board farm as well, it looks better than before > for sure. Boot logs are at: > http://arm-soc.lixom.net/bootlogs/misc/v3.16-rc4-360-g1501776 > > There are still some issues to resolve but this is an improvement so > let's pick it up and fix with new patches on top. Thanks for your review and testing. > > Some of the new warnings are: > > [WARN] [0.785066] usb@1200 supply vdd33 not found, using dummy > regulator > [WARN] [0.791071] usb@1200 supply vdd10 not found, using dummy > regulator > [WARN] [0.998658] usb@1240 supply vdd33 not found, using dummy > regulator > [WARN] [1.004049] usb@1240 supply vdd10 not found, using dummy > regulator Vivek had submitted patches for the same [1]. Vivek, any updates? [1] https://lkml.org/lkml/2014/6/25/363 > [WARN] [1.673277] 1006.tmu supply vtmu not found, using dummy > regulator > [WARN] [1.685873] 10064000.tmu supply vtmu not found, using dummy > regulator > [WARN] [1.706262] 10068000.tmu supply vtmu not found, using dummy > regulator > [WARN] [1.720076] 1006c000.tmu supply vtmu not found, using dummy > regulator > [WARN] [1.733957] 100a.tmu supply vtmu not found, using dummy > regulator I think similar patches as with USB are required here. Naveen, comments? -- Regards, Sachin. -- 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 1/1] ARM: exynos_defconfig: Update exynos_defconfig
Hi Doug, On Mon, Jul 14, 2014 at 10:17 PM, Doug Anderson wrote: > Sachin, > > On Wed, Jul 9, 2014 at 3:22 AM, Sachin Kamat wrote: >> Removed outdated configs. Enabled most of the configs used on latest >> Exynos based platforms. This will provide a reference for users trying >> to verify and test various features on Exynos based platforms and also >> help in detecting breakages by widening the build coverage. >> >> Signed-off-by: Sachin Kamat >> --- >> arch/arm/configs/exynos_defconfig | 56 >> +++-- >> 1 file changed, 48 insertions(+), 8 deletions(-) > > How about "CONFIG_CPU_FREQ=y" + related configs? I'm pretty sure that > CPU_FREQ works on exynos5250-snow and the config didn't hurt last time > I tried on exynos5420/5800. I have left them out for now in the hope that they would soon get obsoleted by the latest patchset migrating to generic CPUFreq driver. I will send a second round of update around rc-7 based on the drivers prevalent then. > > Once Javier's changes land we'll need to add max77802 in here, but > it's fine to leave it out until then. > > I'd also wonder about CONFIG_DRM eventually being set for graphics, > but I'll admit to very little knowledge there. That seems like it > could be in a followup patch. My plan was to include only basic things which are currently functional in the first round and then enable CPUFreq, DRM and PMIC (for 5420/5800) in the second round (based on the merge status). Display/panel/bridge related patches are not yet merged and enabling hdmi, etc. would give errors as regulator is not available. Again a second round material. > > I would strongly suggest PREMPT_VOLUNTARY=y for now (again in a > separate patch). OK. >With your config and 'slub_debug=FZPUA' I continue > to get constant errors reported. These errors are not your fault > (they also show up on tegra boards). I've already reported this and > it's pretty much gone nowhere. > > Another suggestion is to enable the WiFi that's on ARM Chromebooks: > CONFIG_MWIFIEX=m > CONFIG_MWIFIEX_SDIO=m OK. > > ...and that probably means some WiFi configs. I'm not an expert, but > possibly these. The first of these appears to be needed to keep shill > (present in the default ChromeOS rootfilesystem) from crashing wildly: > CONFIG_CFG80211=m > CONFIG_CFG80211_WEXT=y > CONFIG_MAC80211=m OK. I would need someone to test these though. > > > Possibly you should be enabling the battery eventually since > Chromebooks have these too: > CONFIG_BATTERY_SBS=m Sure. > > You're enabling the adc, but not what's hooked up to it: > CONFIG_SENSORS_NTC_THERMISTOR=m OK. > > The eMMC that ships on Chromebooks has more than 8 partitions, so you > probably should have this: > CONFIG_MMC_BLOCK_MINORS=16 OK. > > There's a light sensor on most ARM Chromebooks: > CONFIG_SENSORS_ISL29018=m OK. > > > > All of the above could be in followup patches, so: > > Tested-by: Doug Anderson > Reviewed-by: Doug Anderson Thanks for your review and testing. >> +CONFIG_COMMON_CLK_S2MPS11=y >> +CONFIG_EXYNOS_IOMMU=y >> +CONFIG_IIO=y > > optional: You could probably =m this (and the ADC). Better to test > the =m case I think and there's no strong need for this to be in the > kernel. OK. -- Regards, Sachin. -- 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
[PATCH v3 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
Since the USB 2.0 PHYs are required with EHCI/OHCI USB drivers and USB gadget controller supported by the DWC2 gadget driver, make it depend on them and default to ARCH_EXYNOS as they are meant for Exynos platforms. Also, make the sub-drivers silent options enabling them based on the SoC platforms that they are meant to work with. This will make life easier for end users who do not have any way knowing the dependencies. Signed-off-by: Sachin Kamat Reviewed-by: Jingoo Han --- Changes since v3: * Rebased the series on top of latest PHY tree [1]. [1] git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git --- drivers/phy/Kconfig | 35 +++ 1 file changed, 11 insertions(+), 24 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 5fceb33..c412ca4 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -132,43 +132,30 @@ config PHY_SUN4I_USB config PHY_SAMSUNG_USB2 tristate "Samsung USB 2.0 PHY driver" depends on HAS_IOMEM + depends on USB_EHCI_EXYNOS || USB_OHCI_EXYNOS || USB_DWC2 select GENERIC_PHY select MFD_SYSCON + default ARCH_EXYNOS help Enable this to support the Samsung USB 2.0 PHY driver for Samsung - SoCs. This driver provides the interface for USB 2.0 PHY. Support for - particular SoCs has to be enabled in addition to this driver. Number - and type of supported phys depends on the SoC. + SoCs. This driver provides the interface for USB 2.0 PHY. Support + for particular PHYs will be enabled based on the SoC type in addition + to this driver. config PHY_EXYNOS4210_USB2 - bool "Support for Exynos 4210" + bool depends on PHY_SAMSUNG_USB2 - depends on CPU_EXYNOS4210 - help - Enable USB PHY support for Exynos 4210. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4210 four - phys are available - device, host, HSIC0 and HSIC1. + default CPU_EXYNOS4210 config PHY_EXYNOS4X12_USB2 - bool "Support for Exynos 3250/4x12" + bool depends on PHY_SAMSUNG_USB2 - depends on (SOC_EXYNOS3250 || SOC_EXYNOS4212 || SOC_EXYNOS4412) - help - Enable USB PHY support for Exynos 3250/4x12. This option requires - that Samsung USB 2.0 PHY driver is enabled and means that support for - this particular SoC is compiled in the driver. In case of Exynos 4x12 - four phys are available - device, host, HSIC0 and HSIC1. + default SOC_EXYNOS3250 || SOC_EXYNOS4212 || SOC_EXYNOS4412 config PHY_EXYNOS5250_USB2 - bool "Support for Exynos 5250" + bool depends on PHY_SAMSUNG_USB2 - depends on SOC_EXYNOS5250 - help - Enable USB PHY support for Exynos 5250. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 5250 four - phys are available - device, host, HSIC0 and HSIC. + default SOC_EXYNOS5250 || SOC_EXYNOS5420 config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" -- 1.7.9.5 -- 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
[PATCH 2/2] phy: Kconfig: Update config for Exynos USB DRD
USB DWC3 driver on Exynos platform does not work without its corresponding phy driver. Hence make the PHY driver depend on Exynos DWC3 driver and default it to yes to make things easier for the end user. Signed-off-by: Sachin Kamat Reviewed-by: Jingoo Han --- drivers/phy/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index c412ca4..c730e85 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -161,8 +161,10 @@ config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" depends on ARCH_EXYNOS5 && OF depends on HAS_IOMEM + depends on USB_DWC3_EXYNOS select GENERIC_PHY select MFD_SYSCON + default y help Enable USB DRD PHY support for Exynos 5 SoC series. This driver provides PHY interface for USB 3.0 DRD controller -- 1.7.9.5 -- 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 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
On Mon, Jul 14, 2014 at 2:39 PM, Kishon Vijay Abraham I wrote: > > > On Monday 14 July 2014 02:36 PM, Sachin Kamat wrote: >> On Mon, Jul 14, 2014 at 2:32 PM, Kishon Vijay Abraham I >> wrote: >>> >>> >>> On Monday 14 July 2014 02:29 PM, Sachin Kamat wrote: >>>> Hi, >>>> >>>> On Mon, Jul 14, 2014 at 2:26 PM, Kishon Vijay Abraham I >>>> wrote: >>>>> Hi, >>>>> >>>>> On Wednesday 09 July 2014 05:19 PM, Sachin Kamat wrote: >>>>>> Since the USB 2.0 PHYs are required with EHCI/OHCI USB drivers and >>>>>> USB gadget controller supported by the DWC2 gadget driver, make it >>>>>> depend on them and default to ARCH_EXYNOS as they are meant for >>>>>> Exynos platforms. Also, make the sub-drivers silent options enabling >>>>>> them based on the SoC platforms that they are meant to work with. This >>>>>> will make life easier for end users who do not have any way knowing the >>>>>> dependencies. >>>>> >>>>> There is a new Exynos PHY in town, Exynos 3250. Can you rebase your patch >>>>> on >>>>> top of that? >>>> >>>> Sure. But I did not see it in linux-next yet. Is it merged somewhere? >>> >>> It's in the list. I can push it to my tree if that helps. >> >> That would be great to avoid any other conflicts. > > pushed to git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > next. You can use it to rebase your patch. Thanks. I will re-spin on top of it. -- Regards, Sachin. -- 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 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
On Mon, Jul 14, 2014 at 2:32 PM, Kishon Vijay Abraham I wrote: > > > On Monday 14 July 2014 02:29 PM, Sachin Kamat wrote: >> Hi, >> >> On Mon, Jul 14, 2014 at 2:26 PM, Kishon Vijay Abraham I >> wrote: >>> Hi, >>> >>> On Wednesday 09 July 2014 05:19 PM, Sachin Kamat wrote: >>>> Since the USB 2.0 PHYs are required with EHCI/OHCI USB drivers and >>>> USB gadget controller supported by the DWC2 gadget driver, make it >>>> depend on them and default to ARCH_EXYNOS as they are meant for >>>> Exynos platforms. Also, make the sub-drivers silent options enabling >>>> them based on the SoC platforms that they are meant to work with. This >>>> will make life easier for end users who do not have any way knowing the >>>> dependencies. >>> >>> There is a new Exynos PHY in town, Exynos 3250. Can you rebase your patch on >>> top of that? >> >> Sure. But I did not see it in linux-next yet. Is it merged somewhere? > > It's in the list. I can push it to my tree if that helps. That would be great to avoid any other conflicts. -- Regards, Sachin. -- 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 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
Hi, On Mon, Jul 14, 2014 at 2:26 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Wednesday 09 July 2014 05:19 PM, Sachin Kamat wrote: >> Since the USB 2.0 PHYs are required with EHCI/OHCI USB drivers and >> USB gadget controller supported by the DWC2 gadget driver, make it >> depend on them and default to ARCH_EXYNOS as they are meant for >> Exynos platforms. Also, make the sub-drivers silent options enabling >> them based on the SoC platforms that they are meant to work with. This >> will make life easier for end users who do not have any way knowing the >> dependencies. > > There is a new Exynos PHY in town, Exynos 3250. Can you rebase your patch on > top of that? Sure. But I did not see it in linux-next yet. Is it merged somewhere? -- Regards, Sachin. -- 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 2/4] Documentation: dt-bindings: move exynos-adc.txt to more iio/adc/
Hi Naveen, On Fri, Jul 11, 2014 at 2:36 PM, Naveen Krishna Chatradhi wrote: > The DT bindings in exynos-adc.txt applies to the ADC > driver (exynos-adc.c) developed based on IIO framework. > > The bindings are more appropriate to be under > Documentation/devicetree/bindings/iio/adc/ > > Signed-off-by: Naveen Krishna Chatradhi > To: devicet...@vger.kernel.org > --- > .../devicetree/bindings/arm/samsung/exynos-adc.txt | 82 > > .../devicetree/bindings/iio/adc/exynos-adc.txt | 82 > > 2 files changed, 82 insertions(+), 82 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt > create mode 100644 Documentation/devicetree/bindings/iio/adc/exynos-adc.txt > Tip: For only a file move or rename please use "-M" with git format-patch. That will make the patch concise. -- Regards, Sachin. -- 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 12/16] i2c: i2c-s3c2410: Drop class based scanning to improve bootup time
Hi Wolfram, On Thu, Jul 10, 2014 at 5:16 PM, Wolfram Sang wrote: > This driver has been flagged to drop class based instantiation. The removal > improves boot-up time and is unneeded for embedded controllers. Users have > been > warned to switch for some time now, so we can actually do the removal. Keep > the > DEPRECATED flag, so the core can inform users that the behaviour finally > changed now. After another transition period, this flag can go, too. > While we are here, remove the indentation for the array setup because > such things always break after some time. > > Signed-off-by: Wolfram Sang > --- > drivers/i2c/busses/i2c-s3c2410.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-s3c2410.c > b/drivers/i2c/busses/i2c-s3c2410.c > index e828a1dba0e5..6252c051525a 100644 > --- a/drivers/i2c/busses/i2c-s3c2410.c > +++ b/drivers/i2c/busses/i2c-s3c2410.c > @@ -1128,11 +1128,11 @@ static int s3c24xx_i2c_probe(struct platform_device > *pdev) > s3c24xx_i2c_parse_dt(pdev->dev.of_node, i2c); > > strlcpy(i2c->adap.name, "s3c2410-i2c", sizeof(i2c->adap.name)); > - i2c->adap.owner = THIS_MODULE; > - i2c->adap.algo= &s3c24xx_i2c_algorithm; > + i2c->adap.owner = THIS_MODULE; > + i2c->adap.algo = &s3c24xx_i2c_algorithm; > i2c->adap.retries = 2; > - i2c->adap.class = I2C_CLASS_HWMON | I2C_CLASS_SPD | > I2C_CLASS_DEPRECATED; > - i2c->tx_setup = 50; > + i2c->adap.class = I2C_CLASS_DEPRECATED; > + i2c->tx_setup = 50; > > init_waitqueue_head(&i2c->wait); > > -- Tested on Exynos 5250 boards. Tested-by: Sachin Kamat -- Regards, Sachin. -- 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
[PATCH 1/1] pinctrl: samsung: Group all drivers in a sub-dir
Group all pin control drivers of Samsung platform together in
a sub-directory for easy maintenance.
Signed-off-by: Sachin Kamat
---
This patch has been inspired by a similar patch [1] from Linus Walleij for
Qualcomm drivers. I have boot tested this patch on Exynos boards and
compile tested for other Samsung platforms.
[1] http://www.spinics.net/lists/arm-kernel/msg345924.html
---
drivers/pinctrl/Kconfig| 27 +--
drivers/pinctrl/Makefile |6 +
drivers/pinctrl/samsung/Kconfig| 28
drivers/pinctrl/samsung/Makefile |7 +
drivers/pinctrl/{ => samsung}/pinctrl-exynos.c |0
drivers/pinctrl/{ => samsung}/pinctrl-exynos.h |0
drivers/pinctrl/{ => samsung}/pinctrl-exynos5440.c |2 +-
drivers/pinctrl/{ => samsung}/pinctrl-s3c24xx.c|0
drivers/pinctrl/{ => samsung}/pinctrl-s3c64xx.c|0
drivers/pinctrl/{ => samsung}/pinctrl-samsung.c|2 +-
drivers/pinctrl/{ => samsung}/pinctrl-samsung.h|0
11 files changed, 39 insertions(+), 33 deletions(-)
create mode 100644 drivers/pinctrl/samsung/Kconfig
create mode 100644 drivers/pinctrl/samsung/Makefile
rename drivers/pinctrl/{ => samsung}/pinctrl-exynos.c (100%)
rename drivers/pinctrl/{ => samsung}/pinctrl-exynos.h (100%)
rename drivers/pinctrl/{ => samsung}/pinctrl-exynos5440.c (99%)
rename drivers/pinctrl/{ => samsung}/pinctrl-s3c24xx.c (100%)
rename drivers/pinctrl/{ => samsung}/pinctrl-s3c64xx.c (100%)
rename drivers/pinctrl/{ => samsung}/pinctrl-samsung.c (99%)
rename drivers/pinctrl/{ => samsung}/pinctrl-samsung.h (100%)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 2744fa2825e0..f8bf9d80fc1a 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -363,22 +363,6 @@ config PINCTRL_COH901
COH 901 335 and COH 901 571/3. They contain 3, 5 or 7
ports of 8 GPIO pins each.
-config PINCTRL_SAMSUNG
- bool
- select PINMUX
- select PINCONF
-
-config PINCTRL_EXYNOS
- bool "Pinctrl driver data for Samsung EXYNOS SoCs other than 5440"
- depends on OF && GPIOLIB && (ARCH_EXYNOS || ARCH_S5PV210)
- select PINCTRL_SAMSUNG
-
-config PINCTRL_EXYNOS5440
- bool "Samsung EXYNOS5440 SoC pinctrl driver"
- depends on SOC_EXYNOS5440
- select PINMUX
- select PINCONF
-
config PINCTRL_PALMAS
bool "Pinctrl driver for the PALMAS Series MFD devices"
depends on OF && MFD_PALMAS
@@ -390,18 +374,9 @@ config PINCTRL_PALMAS
open drain configuration for the Palmas series devices like
TPS65913, TPS80036 etc.
-config PINCTRL_S3C24XX
- bool "Samsung S3C24XX SoC pinctrl driver"
- depends on ARCH_S3C24XX
- select PINCTRL_SAMSUNG
-
-config PINCTRL_S3C64XX
- bool "Samsung S3C64XX SoC pinctrl driver"
- depends on ARCH_S3C64XX
- select PINCTRL_SAMSUNG
-
source "drivers/pinctrl/berlin/Kconfig"
source "drivers/pinctrl/mvebu/Kconfig"
+source "drivers/pinctrl/samsung/Kconfig"
source "drivers/pinctrl/sh-pfc/Kconfig"
source "drivers/pinctrl/spear/Kconfig"
source "drivers/pinctrl/sunxi/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index c7d8f1b7311f..2ee910dbfe36 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -60,11 +60,6 @@ obj-$(CONFIG_PINCTRL_TZ1090) += pinctrl-tz1090.o
obj-$(CONFIG_PINCTRL_TZ1090_PDC) += pinctrl-tz1090-pdc.o
obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
obj-$(CONFIG_PINCTRL_COH901) += pinctrl-coh901.o
-obj-$(CONFIG_PINCTRL_SAMSUNG) += pinctrl-samsung.o
-obj-$(CONFIG_PINCTRL_EXYNOS) += pinctrl-exynos.o
-obj-$(CONFIG_PINCTRL_EXYNOS5440) += pinctrl-exynos5440.o
-obj-$(CONFIG_PINCTRL_S3C24XX) += pinctrl-s3c24xx.o
-obj-$(CONFIG_PINCTRL_S3C64XX) += pinctrl-s3c64xx.o
obj-$(CONFIG_PINCTRL_XWAY) += pinctrl-xway.o
obj-$(CONFIG_PINCTRL_LANTIQ) += pinctrl-lantiq.o
obj-$(CONFIG_PINCTRL_TB10X)+= pinctrl-tb10x.o
@@ -78,3 +73,4 @@ obj-$(CONFIG_SUPERH) += sh-pfc/
obj-$(CONFIG_PLAT_SPEAR) += spear/
obj-$(CONFIG_ARCH_VT8500) += vt8500/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
+obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig
new file mode 100644
index ..d0461cd5d707
--- /dev/null
+++ b/drivers/pinctrl/samsung/Kconfig
@@ -0,0 +1,28 @@
+#
+# Samsung Pin control drivers
+#
+config PINCTRL_SAMSUNG
+ bool
+ select PINMUX
+ select PINCONF
+
+config PINCTRL_EXYNOS
+ bool "Pinctrl driver data for Samsung EXYNOS SoCs other than 5440"
+ depends on OF && GPIOLIB && (ARCH_EXYNOS || ARCH_S5PV210)
[PATCH v2 2/2] phy: Kconfig: Update config for Exynos USB DRD
USB DWC3 driver on Exynos platform does not work without its corresponding phy driver. Hence make the PHY driver depend on Exynos DWC3 driver and default it to yes to make things easier for the end user. Signed-off-by: Sachin Kamat --- No changes since v1. --- drivers/phy/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 128f8b92b55c..ee6c80a5392a 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -152,8 +152,10 @@ config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" depends on ARCH_EXYNOS5 && OF depends on HAS_IOMEM + depends on USB_DWC3_EXYNOS select GENERIC_PHY select MFD_SYSCON + default y help Enable USB DRD PHY support for Exynos 5 SoC series. This driver provides PHY interface for USB 3.0 DRD controller -- 1.7.9.5 -- 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
[PATCH v2 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
Since the USB 2.0 PHYs are required with EHCI/OHCI USB drivers and USB gadget controller supported by the DWC2 gadget driver, make it depend on them and default to ARCH_EXYNOS as they are meant for Exynos platforms. Also, make the sub-drivers silent options enabling them based on the SoC platforms that they are meant to work with. This will make life easier for end users who do not have any way knowing the dependencies. Signed-off-by: Sachin Kamat --- Changes since v1: * Added dependency on DWC2 gadget driver as suggested by Tomasz Figa. --- drivers/phy/Kconfig | 35 +++ 1 file changed, 11 insertions(+), 24 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index fcdfe7c0e4a7..128f8b92b55c 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -123,43 +123,30 @@ config PHY_SUN4I_USB config PHY_SAMSUNG_USB2 tristate "Samsung USB 2.0 PHY driver" depends on HAS_IOMEM + depends on USB_EHCI_EXYNOS || USB_OHCI_EXYNOS || USB_DWC2 select GENERIC_PHY select MFD_SYSCON + default ARCH_EXYNOS help Enable this to support the Samsung USB 2.0 PHY driver for Samsung - SoCs. This driver provides the interface for USB 2.0 PHY. Support for - particular SoCs has to be enabled in addition to this driver. Number - and type of supported phys depends on the SoC. + SoCs. This driver provides the interface for USB 2.0 PHY. Support + for particular PHYs will be enabled based on the SoC type in addition + to this driver. config PHY_EXYNOS4210_USB2 - bool "Support for Exynos 4210" + bool depends on PHY_SAMSUNG_USB2 - depends on CPU_EXYNOS4210 - help - Enable USB PHY support for Exynos 4210. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4210 four - phys are available - device, host, HSIC0 and HSIC1. + default CPU_EXYNOS4210 config PHY_EXYNOS4X12_USB2 - bool "Support for Exynos 4x12" + bool depends on PHY_SAMSUNG_USB2 - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) - help - Enable USB PHY support for Exynos 4x12. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4x12 four - phys are available - device, host, HSIC0 and HSIC1. + default SOC_EXYNOS4212 || SOC_EXYNOS4412 config PHY_EXYNOS5250_USB2 - bool "Support for Exynos 5250" + bool depends on PHY_SAMSUNG_USB2 - depends on SOC_EXYNOS5250 - help - Enable USB PHY support for Exynos 5250. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 5250 four - phys are available - device, host, HSIC0 and HSIC. + default SOC_EXYNOS5250 || SOC_EXYNOS5420 config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" -- 1.7.9.5 -- 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
[PATCH 1/1] ARM: exynos_defconfig: Update exynos_defconfig
Removed outdated configs. Enabled most of the configs used on latest Exynos based platforms. This will provide a reference for users trying to verify and test various features on Exynos based platforms and also help in detecting breakages by widening the build coverage. Signed-off-by: Sachin Kamat --- arch/arm/configs/exynos_defconfig | 56 +++-- 1 file changed, 48 insertions(+), 8 deletions(-) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index e07a227ec0db..fc7d1683bf67 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -8,15 +8,17 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y CONFIG_ARCH_EXYNOS=y -CONFIG_S3C_LOWLEVEL_UART_PORT=3 -CONFIG_S3C24XX_PWM=y -CONFIG_ARCH_EXYNOS5=y -CONFIG_MACH_EXYNOS4_DT=y +CONFIG_ARCH_EXYNOS3=y +CONFIG_EXYNOS5420_MCPM=y CONFIG_SMP=y +CONFIG_BIG_LITTLE=y +CONFIG_BL_SWITCHER=y +CONFIG_BL_SWITCHER_DUMMY_IF=y CONFIG_NR_CPUS=8 CONFIG_PREEMPT=y CONFIG_AEABI=y CONFIG_HIGHMEM=y +CONFIG_CMA=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y @@ -24,6 +26,7 @@ CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M console=ttySAC1,115200 init=/linuxrc mem=256M" CONFIG_VFP=y CONFIG_NEON=y +CONFIG_PM_RUNTIME=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y @@ -34,6 +37,8 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_PROC_DEVICETREE=y +CONFIG_DMA_CMA=y +CONFIG_CMA_SIZE_MBYTES=64 CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=y CONFIG_BLK_DEV_RAM=y @@ -66,11 +71,22 @@ CONFIG_I2C=y CONFIG_I2C_MUX=y CONFIG_I2C_ARB_GPIO_CHALLENGE=y CONFIG_I2C_EXYNOS5=y +CONFIG_I2C_CROS_EC_TUNNEL=y +CONFIG_SPI=y +CONFIG_SPI_S3C64XX=y CONFIG_I2C_S3C2410=y CONFIG_DEBUG_GPIO=y +CONFIG_POWER_SUPPLY=y +CONFIG_CHARGER_TPS65090=y # CONFIG_HWMON is not set +CONFIG_THERMAL=y +CONFIG_EXYNOS_THERMAL=y +CONFIG_EXYNOS_THERMAL_CORE=y +CONFIG_WATCHDOG=y +CONFIG_S3C2410_WATCHDOG=y CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_I2C=y +CONFIG_MFD_CROS_EC_SPI=y CONFIG_MFD_MAX77686=y CONFIG_MFD_MAX8997=y CONFIG_MFD_SEC_CORE=y @@ -80,6 +96,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_MAX8997=y CONFIG_REGULATOR_MAX77686=y +CONFIG_REGULATOR_S2MPA01=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS65090=y @@ -88,28 +105,50 @@ CONFIG_FB_MODE_HELPERS=y CONFIG_FB_SIMPLE=y CONFIG_EXYNOS_VIDEO=y CONFIG_EXYNOS_MIPI_DSI=y -CONFIG_EXYNOS_DP=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FONTS=y CONFIG_FONT_7x14=y CONFIG_LOGO=y +CONFIG_SOUND=y +CONFIG_SND=y +CONFIG_SND_SOC=y +CONFIG_SND_SOC_SAMSUNG=y +CONFIG_SND_SOC_SNOW=y CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_EXYNOS=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_EXYNOS=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC3=y -CONFIG_USB_PHY=y -CONFIG_SAMSUNG_USB2PHY=y -CONFIG_SAMSUNG_USB3PHY=y +CONFIG_USB_HSIC_USB3503=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_S3C=y +CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_DW=y CONFIG_MMC_DW_IDMAC=y CONFIG_MMC_DW_EXYNOS=y CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_MAX77686=y +CONFIG_RTC_DRV_S5M=y CONFIG_RTC_DRV_S3C=y +CONFIG_DMADEVICES=y +CONFIG_PL330_DMA=y CONFIG_COMMON_CLK_MAX77686=y +CONFIG_COMMON_CLK_S2MPS11=y +CONFIG_EXYNOS_IOMMU=y +CONFIG_IIO=y +CONFIG_EXYNOS_ADC=y +CONFIG_PWM=y +CONFIG_PWM_SAMSUNG=y +CONFIG_PHY_EXYNOS5250_SATA=y +CONFIG_PHY_SAMSUNG_USB2=y +CONFIG_PHY_EXYNOS4210_USB2=y +CONFIG_PHY_EXYNOS4X12_USB2=y +CONFIG_PHY_EXYNOS5250_USB2=y +CONFIG_PHY_EXYNOS5_USBDRD=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_EXT4_FS=y @@ -123,6 +162,7 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_PRINTK_TIME=y +CONFIG_DEBUG_FS=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y -- 1.7.9.5 -- 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 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
Hi Tomasz, On Tue, Jul 8, 2014 at 9:15 PM, Tomasz Figa wrote: > On 30.06.2014 10:56, Sachin Kamat wrote: >> Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, > > That's not true. They are also required for USB gadget controller > supported by the DWC2 gadget driver (formerly s3c-hsotg). Otherwise the > change makes sense to me. Do you propose I amend just the patch description or also add a dependency on USB_DWC2 along with EHCI and OHCI. I do not have anything to test this. Based on your input I will re-spin the patch. -- Regards, Sachin. -- 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 1/3] ARM: exynos: remove unused
On Wed, Jul 2, 2014 at 3:27 PM, Uwe Kleine-König wrote: > ARCH_EXYNOS doesn't select NEED_MACH_MEMORY_H, so doesn't > include and so this file is not used and can go away. > > Signed-off-by: Uwe Kleine-König > --- Reviewed-by: Sachin Kamat Tested on Arndale octa board (Exynos 5420). Tested-by: Sachin Kamat -- Regards, Sachin. -- 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 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
On Mon, Jun 30, 2014 at 2:26 PM, Sachin Kamat wrote: > Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, > make it depend on them and default to ARCH_EXYNOS as they are meant > for Exynos platforms. Also, make the sub-drivers silent options enabling > them based on the SoC platforms that they are meant to work with. This > will make life easier for end users who do not have any way knowing the > dependencies. > > Signed-off-by: Sachin Kamat > --- > drivers/phy/Kconfig | 35 +++ > 1 file changed, 11 insertions(+), 24 deletions(-) > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 16a2f067c242..9aab5dfb0adf 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -122,43 +122,30 @@ config PHY_SUN4I_USB > > config PHY_SAMSUNG_USB2 > tristate "Samsung USB 2.0 PHY driver" > + depends on USB_EHCI_EXYNOS || USB_OHCI_EXYNOS > select GENERIC_PHY > select MFD_SYSCON > + default ARCH_EXYNOS > help > Enable this to support the Samsung USB 2.0 PHY driver for Samsung > - SoCs. This driver provides the interface for USB 2.0 PHY. Support > for > - particular SoCs has to be enabled in addition to this driver. Number > - and type of supported phys depends on the SoC. > + SoCs. This driver provides the interface for USB 2.0 PHY. Support > + for particular PHYs will be enabled based on the SoC type in > addition > + to this driver. > > config PHY_EXYNOS4210_USB2 > - bool "Support for Exynos 4210" > + bool > depends on PHY_SAMSUNG_USB2 > - depends on CPU_EXYNOS4210 > - help > - Enable USB PHY support for Exynos 4210. This option requires that > - Samsung USB 2.0 PHY driver is enabled and means that support for > this > - particular SoC is compiled in the driver. In case of Exynos 4210 > four > - phys are available - device, host, HSIC0 and HSIC1. > + default CPU_EXYNOS4210 > > config PHY_EXYNOS4X12_USB2 > - bool "Support for Exynos 4x12" > + bool > depends on PHY_SAMSUNG_USB2 > - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) > - help > - Enable USB PHY support for Exynos 4x12. This option requires that > - Samsung USB 2.0 PHY driver is enabled and means that support for > this > - particular SoC is compiled in the driver. In case of Exynos 4x12 > four > - phys are available - device, host, HSIC0 and HSIC1. > + default SOC_EXYNOS4212 || SOC_EXYNOS4412 > > config PHY_EXYNOS5250_USB2 > - bool "Support for Exynos 5250" > + bool > depends on PHY_SAMSUNG_USB2 > - depends on SOC_EXYNOS5250 > - help > - Enable USB PHY support for Exynos 5250. This option requires that > - Samsung USB 2.0 PHY driver is enabled and means that support for > this > - particular SoC is compiled in the driver. In case of Exynos 5250 > four > - phys are available - device, host, HSIC0 and HSIC. > + default SOC_EXYNOS5250 || SOC_EXYNOS5420 > > config PHY_EXYNOS5_USBDRD > tristate "Exynos5 SoC series USB DRD PHY driver" > -- > 1.7.9.5 Kishon, Any comments on these patches? -- Regards, Sachin. -- 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] thermal: Add missing cpumask_clear
On Sat, Jul 5, 2014 at 6:04 AM, Tomasz Figa wrote:
> Hi Jonghwan,
>
> On 05.07.2014 01:37, Jonghwan Choi wrote:
>> On Fri, Jul 4, 2014 at 8:23 PM, Sachin Kamat wrote:
>>
>>>> Cpumasks should be cleared before using.
>>>
>>> Please explain why and what is issue observed without this.
>>>
>>
>> -> When I checked the mask value, I knew that unwanted bit is set.
>>
>> Test code without cpumask_clear.
>>
>> + cpumask_set_cpu(0, &mask_val);
>> + cpulist_scnprintf(buf, 64, &mask_val);
>> + printk("--ID [ %d] = %s \n", id, buf);
>> + th_zone->cool_dev[id] = cpufreq_cooling_register(&mask_val);
>>
>>
>> Console message-> 4.861157] [c6] --ID [ 1] = 0,4-5,7 (4,5,7 cpu bit was set.)
>>
>> And when I tried to register two cooling devices with cpumask_set_cpu(0,
>> &mask_val) and cpumask_set_cpu(4, &mask_val).
>>
>> I found that cpu 0 bit is also set in latter cpumask. (I hope latter cpumask
>> has a cpu 4 bit.)
>>
>> So I think that cpumask_clear should be inserted.
>
> I believe Sachin's concern was related to your patch description. A good
> description should say what the patch changes and what is the rationale
> behind this change. Also for fixes it is a good practice to specify
> observed issues in patch description as well.
Yes, that is correct. Sorry if it wasn't clear in my previous mail.
--
Regards,
Sachin.
--
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 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
On Wed, Jun 25, 2014 at 5:13 PM, Kukjin Kim wrote: > Sachin Kamat wrote: >> >> On Fri, May 30, 2014 at 11:49 PM, Andreas Färber wrote: >> > Am 28.05.2014 06:13, schrieb Sachin Kamat: >> >> Almost all Exynos-series of SoCs that run in secure mode don't need >> >> additional offset for every CPU, with Exynos4412 being the only >> >> exception. >> >> >> >> Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). >> >> >> >> While at it, fix the coding style (space around *). >> >> >> >> Signed-off-by: Sachin Kamat >> >> Signed-off-by: Tushar Behera >> >> --- >> >> arch/arm/mach-exynos/firmware.c |9 +++-- >> >> 1 file changed, 7 insertions(+), 2 deletions(-) >> > >> > Fixes ODROID-XU (Exynos5410) as well - thought it had been a prereq to >> > applying the 5410 patches... >> > >> > Tested-by: Andreas Färber >> > >> >> Kukjin, this patch is required to bring up 4 A15 cores on some 5410 >> and 5420 based >> boards. Can you please queue this up for the upcoming rc as fixes? > > Sure, I will take this into fixes. Kukjin, I don't see this patch in your fixes-2 branch yet. > > Thanks, > Kukjin > Regards, Sachin. -- 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] thermal: Add missing cpumask_clear
Hi Jonghwan, On Fri, Jul 4, 2014 at 3:52 PM, Jonghwan Choi wrote: > Cpumasks should be cleared before using. Please explain why and what is issue observed without this. > > Signed-off-by: Jonghwan Choi > --- -- Regards, Sachin. -- 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 2/6] pinctrl: samsung: Handle GPIO request and free using pinctrl helpers
Hi Tomasz, On Wed, Jul 2, 2014 at 9:11 PM, Tomasz Figa wrote: > This patch adds .request() and .free() operations to gpio_chip of > pinctrl-samsung driver, which call pinctrl request and free helpers to > request and free pinctrl pin along with GPIO pin. > > Signed-off-by: Tomasz Figa > --- > drivers/pinctrl/pinctrl-samsung.c | 15 ++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/drivers/pinctrl/pinctrl-samsung.c > b/drivers/pinctrl/pinctrl-samsung.c > index 779c8bc..6e099d6 100644 > --- a/drivers/pinctrl/pinctrl-samsung.c > +++ b/drivers/pinctrl/pinctrl-samsung.c > @@ -779,7 +779,8 @@ static int samsung_pinctrl_register(struct > platform_device *pdev, > pin_bank = &drvdata->ctrl->pin_banks[bank]; > pin_bank->grange.name = pin_bank->name; > pin_bank->grange.id = bank; > - pin_bank->grange.pin_base = pin_bank->pin_base; > + pin_bank->grange.pin_base = drvdata->ctrl->base > + + pin_bank->pin_base; Is this a fix? -- Regards, Sachin. -- 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] ARM: EXYNOS: Fix the check for non-smp configuration
On Thu, Jul 3, 2014 at 10:33 AM, Abhilash Kesavan wrote:
> Commit 1754c42e3db5("ARM: exynos: move sysram info to exynos.c") missed
> out the CONFIG_ prefix causing exynos_sysram_init() to get called twice
> for SMP configurations.
>
> Signed-off-by: Abhilash Kesavan
> ---
> arch/arm/mach-exynos/exynos.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index f38cf7c..95cad25 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -297,7 +297,7 @@ static void __init exynos_dt_machine_init(void)
> * This is called from smp_prepare_cpus if we've built for SMP, but
> * we still need to set it up for PM and firmware ops if not.
> */
> - if (!IS_ENABLED(SMP))
> + if (!IS_ENABLED(CONFIG_SMP))
> exynos_sysram_init();
>
> exynos_cpuidle_init();
If it's not too late
Reviewed-by: Sachin Kamat
--
Regards,
Sachin.
--
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 1/1] ARM: EXYNOS: Remove unused code in common.h
Hi Tomasz,
On Fri, Jul 4, 2014 at 2:13 PM, Sachin Kamat wrote:
> Hi Tomasz,
>
> On Fri, Jul 4, 2014 at 2:03 PM, Tomasz Figa wrote:
>> Hi Sachin,
>>
>> On 04.07.2014 10:29, Sachin Kamat wrote:
>>> On Mon, Jun 23, 2014 at 5:30 PM, Sachin Kamat
>>> wrote:
>>>> PINCTRL_EXYNOS is always selected by Exynos platform in its
>>>> machine Kconfig. Thus the code in the else part is never used.
>>>> Remove it.
>>>>
>>>> Signed-off-by: Sachin Kamat
>>>> ---
>>>> arch/arm/mach-exynos/common.h |4
>>>> 1 file changed, 4 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>>>> index 1ee91763fa7c..3371669dabc6 100644
>>>> --- a/arch/arm/mach-exynos/common.h
>>>> +++ b/arch/arm/mach-exynos/common.h
>>>> @@ -125,11 +125,7 @@ void exynos_init_late(void);
>>>>
>>>> void exynos_firmware_init(void);
>>>>
>>>> -#ifdef CONFIG_PINCTRL_EXYNOS
>>>> extern u32 exynos_get_eint_wake_mask(void);
>>>> -#else
>>>> -static inline u32 exynos_get_eint_wake_mask(void) { return 0x; }
>>>> -#endif
>>>>
>>>> #ifdef CONFIG_PM_SLEEP
>>>> extern void __init exynos_pm_init(void);
>>>> --
>>>> 1.7.9.5
>>>>
>>>
>>> Ping..
>>>
>>
>> For this change alone:
>>
>> Reviewed-by: Tomasz Figa
>
> Thanks.
>
>>
>> However I can see much more unused code in that header, more
>> specifically prototypes of mct_init() (replaced with DT-based init) and
>> most of other *init*() functions (which are now all in one file). Do you
>> plan to remove them as well?
>
> Sure. I will remove those too.
Some of the things that you suggested are already taken care of in the
patch at [1].
So will keep my patch in the current format and later if something else is
needed will send separate patch to avoid merge conflicts. What say?
[1] https://lkml.org/lkml/2014/6/25/375
Regards,
Sachin.
--
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 1/1] ARM: EXYNOS: Remove unused code in common.h
Hi Tomasz,
On Fri, Jul 4, 2014 at 2:03 PM, Tomasz Figa wrote:
> Hi Sachin,
>
> On 04.07.2014 10:29, Sachin Kamat wrote:
>> On Mon, Jun 23, 2014 at 5:30 PM, Sachin Kamat
>> wrote:
>>> PINCTRL_EXYNOS is always selected by Exynos platform in its
>>> machine Kconfig. Thus the code in the else part is never used.
>>> Remove it.
>>>
>>> Signed-off-by: Sachin Kamat
>>> ---
>>> arch/arm/mach-exynos/common.h |4
>>> 1 file changed, 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>>> index 1ee91763fa7c..3371669dabc6 100644
>>> --- a/arch/arm/mach-exynos/common.h
>>> +++ b/arch/arm/mach-exynos/common.h
>>> @@ -125,11 +125,7 @@ void exynos_init_late(void);
>>>
>>> void exynos_firmware_init(void);
>>>
>>> -#ifdef CONFIG_PINCTRL_EXYNOS
>>> extern u32 exynos_get_eint_wake_mask(void);
>>> -#else
>>> -static inline u32 exynos_get_eint_wake_mask(void) { return 0x; }
>>> -#endif
>>>
>>> #ifdef CONFIG_PM_SLEEP
>>> extern void __init exynos_pm_init(void);
>>> --
>>> 1.7.9.5
>>>
>>
>> Ping..
>>
>
> For this change alone:
>
> Reviewed-by: Tomasz Figa
Thanks.
>
> However I can see much more unused code in that header, more
> specifically prototypes of mct_init() (replaced with DT-based init) and
> most of other *init*() functions (which are now all in one file). Do you
> plan to remove them as well?
Sure. I will remove those too.
Regards,
Sachin.
--
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 1/1] ARM: EXYNOS: Remove unused code in common.h
On Mon, Jun 23, 2014 at 5:30 PM, Sachin Kamat wrote:
> PINCTRL_EXYNOS is always selected by Exynos platform in its
> machine Kconfig. Thus the code in the else part is never used.
> Remove it.
>
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/mach-exynos/common.h |4
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index 1ee91763fa7c..3371669dabc6 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -125,11 +125,7 @@ void exynos_init_late(void);
>
> void exynos_firmware_init(void);
>
> -#ifdef CONFIG_PINCTRL_EXYNOS
> extern u32 exynos_get_eint_wake_mask(void);
> -#else
> -static inline u32 exynos_get_eint_wake_mask(void) { return 0x; }
> -#endif
>
> #ifdef CONFIG_PM_SLEEP
> extern void __init exynos_pm_init(void);
> --
> 1.7.9.5
>
Ping..
--
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 00/17] ARM: S5P64X0, S5PC100: no more support in mainline
Hi Kukjin, On Thu, Jul 3, 2014 at 4:16 AM, Kukjin Kim wrote: > On 07/03/14 03:02, Tomasz Figa wrote: >> >> Hi Kukjin, >> > Hi, > > >> On 30.06.2014 23:32, Kukjin Kim wrote: >>> >>> This series removes S5P64X0 and S5PC100 related codes in mainline, >>> because no more user now. And if its supporting is required later, >>> it will be done with using device tree. >>> >>> [PATCH 01/17] ARM: S5P64X0: no more support S5P6440 and S5P6450 SoCs >>> [PATCH 02/17] gpio: samsung: remove s5p64x0 related gpio codes >>> [PATCH 03/17] spi: s3c64xx: remove s5p64x0 related spi codes >>> [PATCH 04/17] ASoC: samsung: no more support for S5P6440 and S5P6450 >>> [PATCH 05/17] pwm: samsung: remove s5p64x0 related pwm codes >>> [PATCH 06/17] video: fbdev: s3c-fb: remove s5p64x0 related fimd >>> [PATCH 07/17] serial: samsung: no more support for S5P6440 and >>> [PATCH 08/17] ARM: S5PC100: no more support S5PC100 SoC >>> [PATCH 09/17] gpio: samsung: remov s5pc100 related gpio codes >>> [PATCH 10/17] spi: s3c64xx: remove s5pc100 related spi codes >>> [PATCH 11/17] pwm: samsung: remove s5pc100 related pwm codes >>> [PATCH 12/17] serial: samsung: no more support for S5PC100 SoC >>> [PATCH 13/17] ata: pata_samsung_cf: removes s5pc100 related ata >>> [PATCH 14/17] mtd: onenand: remove s5pc100 related onenand codes >>> [PATCH 15/17] video: fbdev: s3c-fb: remove s5pc100 related fimd and >>> [PATCH 16/17] [media] exynos4-is: removes s5pc100 related fimc codes >>> [PATCH 17/17] ASoC: Samsung: remove s5pc100 related codes >> >> >> Thanks for this series. >> >> Just letting you know that I have rebased my s5pv210 DT migration series >> on top of this and will be sending the patches after some more testing. >> > Just note since I've missed one more change in the series, I amended it just > now but it should be fine with your series I think. > > Please see v3.17-next/cleanup-s5p branch. Can you please push out the other patches that you applied last week? Thanks. -- Regards, Sachin. -- 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] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250
On Wed, Jul 2, 2014 at 5:22 AM, Chanwoo Choi wrote:
> On 07/01/2014 01:10 PM, Sachin Kamat wrote:
>> Hi Chanwoo,
>>
>> On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi wrote:
>>> Hi Sachin,
>>>
>>> On 07/01/2014 12:33 PM, Sachin Kamat wrote:
>>>> Hi Chanwoo,
>>>>
>>>> On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi wrote:
>>>>> This patch add TMU (Thermal Management Unit) dt node to monitor the high
>>>>> temperature for Exynos3250.
>>>>>
>>>>> Signed-off-by: Chanwoo Choi
>>>>> Acked-by: Kyungmin Park
>>>>> ---
>>>>> This patch has a dependency on following patch [1]:
>>>>> [1] https://lkml.org/lkml/2014/6/30/805
>>>>>
>>>>> arch/arm/boot/dts/exynos3250.dtsi | 10 ++
>>>>> 1 file changed, 10 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>>>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>>>> index 3660cab..1e566af 100644
>>>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>>>> @@ -192,6 +192,16 @@
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + tmu: tmu@100C {
>>>>> + compatible = "samsung,exynos3250-tmu";
>>>>> + interrupt-parent = <&gic>;
>>>>> + reg = <0x100C 0x100>;
>>>>> + interrupts = <0 216 0>;
>>>>> + clocks = <&cmu CLK_TMU_APBIF>;
>>>>> + clock-names = "tmu_apbif";
>>>>> + status = "disabled";
>>>>
>>>> I don't think there would be any board specific properties needed. Hence
>>>> leave the status as enabled (by deleting the above line).
>>>>
>>>
>>> I think that if specific board need TMU feature, dts file for specific board
>>> should include tmu dt node with 'okay' status. The specific board based on
>>> Exynos3250 might not need TMU feature.
>>
>> The status field in DT node is not meant for stating the build configuration
>> but
>> represents the readiness of the hardware for usage on the platform. If
>> a particular
>> board does not need this feature it needs to be disabled in the build
>> config and only
>> for any special requirements disable it in board file.
>
> TMU (Thermal Management Unit) needs specific regulator for TMU power as
> following:
> The regulator for TMU is dependent on board.
In this case it makes sense to leave it disabled in dtsi.
--
Regards,
Sachin.
--
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: [PATCHv2 0/5] ARM: remove the sub-node and deprecated supports-highspeed property for dwmmc.
Hi Jaehoon, On Mon, Jun 30, 2014 at 5:19 PM, Jaehoon Chung wrote: > Since used the mmc_of_parse(), didn't parse the sub-node. > So we can remove the sub-node, because almost SoC used the only one card per > a host. > And supports-highspeed can be replaced to "cap-mmc/sd-highspeed" property. > > Jaehoon Chung (5): > mmc: dw_mmc: modify the dt-binding for removing slot-node and > supports-highspeed > ARM: dts: exynos: unuse the slot-node and deprecated the > supports-highspeed for dw-mmc > ARM: dts: socfpga: unuse the slot-node and deprecated the > supports-highspeed for dw-mmc > ARM: dts: rockchip: unuse the slot-node and deprecated the > supports-highspeed for dw-mmc > mmc: dw_mmc: replace "disable-wp" from slot's quirk to host's quirk It is a good practice to include revision history for subsequent versions. Tested on Exynos 5250 based Snow and Arndale boards. Works fine now. Tested-by: Sachin Kamat -- Regards, Sachin. -- 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] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250
Hi Chanwoo,
On Tue, Jul 1, 2014 at 9:34 AM, Chanwoo Choi wrote:
> Hi Sachin,
>
> On 07/01/2014 12:33 PM, Sachin Kamat wrote:
>> Hi Chanwoo,
>>
>> On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi wrote:
>>> This patch add TMU (Thermal Management Unit) dt node to monitor the high
>>> temperature for Exynos3250.
>>>
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> ---
>>> This patch has a dependency on following patch [1]:
>>> [1] https://lkml.org/lkml/2014/6/30/805
>>>
>>> arch/arm/boot/dts/exynos3250.dtsi | 10 ++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>> index 3660cab..1e566af 100644
>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>> @@ -192,6 +192,16 @@
>>> status = "disabled";
>>> };
>>>
>>> + tmu: tmu@100C {
>>> + compatible = "samsung,exynos3250-tmu";
>>> + interrupt-parent = <&gic>;
>>> + reg = <0x100C 0x100>;
>>> + interrupts = <0 216 0>;
>>> + clocks = <&cmu CLK_TMU_APBIF>;
>>> + clock-names = "tmu_apbif";
>>> + status = "disabled";
>>
>> I don't think there would be any board specific properties needed. Hence
>> leave the status as enabled (by deleting the above line).
>>
>
> I think that if specific board need TMU feature, dts file for specific board
> should include tmu dt node with 'okay' status. The specific board based on
> Exynos3250 might not need TMU feature.
The status field in DT node is not meant for stating the build configuration but
represents the readiness of the hardware for usage on the platform. If
a particular
board does not need this feature it needs to be disabled in the build
config and only
for any special requirements disable it in board file.
--
Regards,
Sachin.
--
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] ARM: dts: Add TMU dt node to monitor the temperature for Exynos3250
Hi Chanwoo,
On Tue, Jul 1, 2014 at 6:10 AM, Chanwoo Choi wrote:
> This patch add TMU (Thermal Management Unit) dt node to monitor the high
> temperature for Exynos3250.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
> This patch has a dependency on following patch [1]:
> [1] https://lkml.org/lkml/2014/6/30/805
>
> arch/arm/boot/dts/exynos3250.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 3660cab..1e566af 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -192,6 +192,16 @@
> status = "disabled";
> };
>
> + tmu: tmu@100C {
> + compatible = "samsung,exynos3250-tmu";
> + interrupt-parent = <&gic>;
> + reg = <0x100C 0x100>;
> + interrupts = <0 216 0>;
> + clocks = <&cmu CLK_TMU_APBIF>;
> + clock-names = "tmu_apbif";
> + status = "disabled";
I don't think there would be any board specific properties needed. Hence
leave the status as enabled (by deleting the above line).
--
Regards,
Sachin.
--
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 0/4] ARM: remove the sub-node and deprecated supports-highspeed property.
Hi Jaehoon, On Mon, Jun 30, 2014 at 12:52 PM, Jaehoon Chung wrote: > Since used the mmc_of_parse(), didn't parse the sub-node. > So we can remove the sub-node, because almost SoC used the only one card per > a host. > And supports-highspeed can be replaced to "cap-mmc/sd-highspeed" property. > > Jaehoon Chung (4): > mmc: dw_mmc: modify the dt-binding for removing slot-node and > supports-highspeed > ARM: dts: exynos: unuse the slot-node and deprecated the > supports-highspeed for dw-mmc I still get the below crash on Exynos5250 Arndale boards with the above patches. It works fine on 5250 Snow board. [3.072323] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [3.072421] mmc1: new high speed SDHC card at address [3.075159] mmcblk1: mmc1: SU04G 3.69 GiB (ro) [3.076614] mmcblk1: p1 p2 p3 [3.098050] of_get_named_gpiod_flags exited with status 0 [3.103444] of_get_named_gpiod_flags exited with status 0 [3.108836] gpio-144: gpiod_set_debounce: missing set() or set_debounce() operations [3.116626] gpio-145: gpiod_set_debounce: missing set() or set_debounce() operations [3.124326] gpio-146: gpiod_set_debounce: missing set() or set_debounce() operations [3.132060] gpio-147: gpiod_set_debounce: missing set() or set_debounce() operations [3.139780] gpio-148: gpiod_set_debounce: missing set() or set_debounce() operations [3.147507] gpio-149: gpiod_set_debounce: missing set() or set_debounce() operations [3.155458] input: gpio_keys as /devices/gpio_keys/input/input0 [3.161395] s3c-rtc 101e.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [3.184653] hdmi-en: disabling [3.186272] MAIN_DC: disabling [3.190510] VFS: Cannot open root device "mmcblk1p3" or unknown-block(179,35): error -30 [3.197417] Please append a correct "root=" boot option; here are the available partitions: [3.205736] b300 3907584 mmcblk0 driver: mmcblk [3.211009] b301 2352800 mmcblk0p1 -01 [3.216269] b302 507872 mmcblk0p2 -02 [3.221563] b303 507840 mmcblk0p3 -03 [3.226858] b304 507840 mmcblk0p4 -04 [3.232155] b318 128 mmcblk0rpmb (driver?) [3.237363] b3101024 mmcblk0boot1 (driver?) [3.242657] b3081024 mmcblk0boot0 (driver?) [3.247951] b320 3872256 mmcblk1 driver: mmcblk [3.253246] b3214095 mmcblk1p1 0005ac11-01 [3.258539] b322 53248 mmcblk1p2 0005ac11-02 [3.263835] b323 3814912 mmcblk1p3 0005ac11-03 [3.269132] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,35) [3.277647] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 3.16.0-rc3-next-20140630-00049-g6a4f4b293862 #182 [3.288161] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [3.295878] [] (show_stack) from [] (dump_stack+0x84/0xc4) [3.303079] [] (dump_stack) from [] (panic+0xa4/0x200) [3.309937] [] (panic) from [] (mount_block_root+0x218/0x298) [3.317403] [] (mount_block_root) from [] (prepare_namespace+0x190/0x1d4) [3.325910] [] (prepare_namespace) from [] (kernel_init_freeable+0x1c8/0x1d8) [3.334763] [] (kernel_init_freeable) from [] (kernel_init+0xc/0xe8) [3.342835] [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) [3.350388] CPU1: stopping [3.353070] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.16.0-rc3-next-20140630-00049-g6a4f4b293862 #182 [3.363586] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [3.371306] [] (show_stack) from [] (dump_stack+0x84/0xc4) [3.378507] [] (dump_stack) from [] (handle_IPI+0x17c/0x18c) [3.385885] [] (handle_IPI) from [] (gic_handle_irq+0x64/0x68) [3.393438] [] (gic_handle_irq) from [] (__irq_svc+0x40/0x70) [3.400898] Exception stack(0xee09ffa0 to 0xee09ffe8) [3.405930] ffa0: 0001 c04a5378 058a ee09e030 c0576484 c03cba84 c05ab257 [3.414095] ffc0: c05ab257 ee09e000 c0305d78 ee09ffe8 c000f1a0 c000f1a4 [3.422251] ffe0: 6113 [3.425724] [] (__irq_svc) from [] (arch_cpu_idle+0x2c/0x30) [3.433109] [] (arch_cpu_idle) from [] (cpu_startup_entry+0x118/0x174) [3.441351] [] (cpu_startup_entry) from [<40008684>] (0x40008684) [3.448294] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,35) -- Regards, Sachin. -- 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] ARM: dts: Move display-timings node under fimd node
On Mon, Jun 23, 2014 at 10:29 AM, Tushar Behera wrote: > 'display-timings' should be a subnode for fimd node. Moving this > node appropriately gets the display back on Origen/Origen-Quad boards. > > Signed-off-by: Tushar Behera Works fine on Origen 4210 board. Tested-by: Sachin Kamat -- Regards, Sachin. -- 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
[PATCH 2/2] phy: Kconfig: Update config for Exynos USB DRD
USB DWC3 driver on Exynos platform does not work without its corresponding phy driver. Hence make the PHY driver depend on Exynos DWC3 driver and default it to yes to make things easier for the end user. Signed-off-by: Sachin Kamat --- drivers/phy/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 9aab5dfb0adf..6f90ee3c7ed1 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -151,8 +151,10 @@ config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" depends on ARCH_EXYNOS5 && OF depends on HAS_IOMEM + depends on USB_DWC3_EXYNOS select GENERIC_PHY select MFD_SYSCON + default y help Enable USB DRD PHY support for Exynos 5 SoC series. This driver provides PHY interface for USB 3.0 DRD controller -- 1.7.9.5 -- 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
[PATCH 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, make it depend on them and default to ARCH_EXYNOS as they are meant for Exynos platforms. Also, make the sub-drivers silent options enabling them based on the SoC platforms that they are meant to work with. This will make life easier for end users who do not have any way knowing the dependencies. Signed-off-by: Sachin Kamat --- drivers/phy/Kconfig | 35 +++ 1 file changed, 11 insertions(+), 24 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 16a2f067c242..9aab5dfb0adf 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -122,43 +122,30 @@ config PHY_SUN4I_USB config PHY_SAMSUNG_USB2 tristate "Samsung USB 2.0 PHY driver" + depends on USB_EHCI_EXYNOS || USB_OHCI_EXYNOS select GENERIC_PHY select MFD_SYSCON + default ARCH_EXYNOS help Enable this to support the Samsung USB 2.0 PHY driver for Samsung - SoCs. This driver provides the interface for USB 2.0 PHY. Support for - particular SoCs has to be enabled in addition to this driver. Number - and type of supported phys depends on the SoC. + SoCs. This driver provides the interface for USB 2.0 PHY. Support + for particular PHYs will be enabled based on the SoC type in addition + to this driver. config PHY_EXYNOS4210_USB2 - bool "Support for Exynos 4210" + bool depends on PHY_SAMSUNG_USB2 - depends on CPU_EXYNOS4210 - help - Enable USB PHY support for Exynos 4210. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4210 four - phys are available - device, host, HSIC0 and HSIC1. + default CPU_EXYNOS4210 config PHY_EXYNOS4X12_USB2 - bool "Support for Exynos 4x12" + bool depends on PHY_SAMSUNG_USB2 - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) - help - Enable USB PHY support for Exynos 4x12. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4x12 four - phys are available - device, host, HSIC0 and HSIC1. + default SOC_EXYNOS4212 || SOC_EXYNOS4412 config PHY_EXYNOS5250_USB2 - bool "Support for Exynos 5250" + bool depends on PHY_SAMSUNG_USB2 - depends on SOC_EXYNOS5250 - help - Enable USB PHY support for Exynos 5250. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 5250 four - phys are available - device, host, HSIC0 and HSIC. + default SOC_EXYNOS5250 || SOC_EXYNOS5420 config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" -- 1.7.9.5 -- 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 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
On Fri, Jun 27, 2014 at 10:23 PM, Olof Johansson wrote: > On Fri, Jun 27, 2014 at 9:32 AM, Doug Anderson wrote: >> Felipe, >> >> On Fri, Jun 27, 2014 at 8:59 AM, Felipe Balbi wrote: I'll admit to not having been involved with the previous discussions, but this seems strange to me. Are we throwing in the towel and deciding that it's too hard to get the Kconfigs right and that we'll just rely on individual users to figure out the right answer for themselves? >>> >>> no. select prevents a driver from be built as a dynamically linked >>> module and distro-kernels might want to enable everything as modules. >> >> Ah, that's what the problem was! I wasn't aware of this issue with >> SELECT. Sorry for the noob-ness. > > Select is also fragile, for example if a main subsystem isn't enabled, > the specific option will still be enabled (or there'll be a > warning/error about it). Overall it tends to cause headaches so many > maintainers are starting to push back against it. > >> Really we want the PHY to be "=y" if the USB driver is "=y" or "=m" if >> the USB driver is "=m", I think. You could argue that one might want >> to build the main USB driver into the kernel but have the phy drivers >> as modules, so you could possibly also try to support that... >> >> If there's not a good way to specify that, I guess we'll just have to >> use "default" and rely on the user not to purposely choose the wrong >> thing. Like the following (untested): >> >> config PHY_SAMSUNG_USB2 >> depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS >> default y if ARCH_EXYNOS=y && (USB_OHCI_EXYNOS=y || USB_EHCI_EXYNOS=y) >> default m if ARCH_EXYNOS=m && (USB_OHCI_EXYNOS=m || USB_EHCI_EXYNOS=m) >> ... >> >> I see some syntax like that elsewhere in Kconfig so I assume it's >> reasonable... > > I think you can take out the test for ARCH_EXYNOS here (first of all, > it can never be modular). > > I'm not sure it makes sense to work so hard to set the default right > either, as long as the dependencies are correct. I.e. it'll still mess > up randconfig if the combination doesn't build, and distros can still > downgrade to 'm' if they want to. That'll just leave: > > config PHY_SAMSUNG_USB2 > tristate "foo" > depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS > default y (no need to add an if since it's taken care of by the depends) > >> With the above the user could purposely enable the OHCI or EHCI driver >> and disable the PHY driver which is not really sensible. ...but it >> wouldn't cause a compile failure or crash--USB just won't work. > > Just make the sub-drivers silent options with defaults. I.e: > > config PHY_EXYNOS5250_USB2 > bool SOC_EXYNOS5250 > depends on PHY_SAMSUNG_USB2 > > and so on. Note that it doesn't actually scale to make it depend on a > specific SoC though, so it should probably just be cut down the line > of EXYNOS4/5 and err on the side of including a bit too much code > instead. Yes, that seems the right thing to do. However, for now I will retain the SoC based structure. Considering the fragility involved in using 'select', I will re-do this by playing around with the default option. Thanks everyone for your inputs. -- Regards, Sachin. -- 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 RESEND] ARM: EXYNOS: Do not calculate boot address twice
Hi Krzysztof,
On Thu, Jun 26, 2014 at 5:16 PM, Krzysztof Kozlowski
wrote:
> Commit b3205dea8fbf ("ARM: EXYNOS: Map SYSRAM through generic DT
> bindings") introduced local variable boot_reg where boot address from
> cpu_boot_reg() call is stored. Re-use it instead calling cpu_boot_reg()
> again.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
Thanks for the patch.
Reviewed-by: Sachin Kamat
Regards,
Sachin.
--
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 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Kishon, On Thu, Jun 26, 2014 at 2:19 PM, Kishon Vijay Abraham I wrote: > Hi Sachin, > > On Thursday 26 June 2014 11:09 AM, Sachin Kamat wrote: >> EHCI and OHCI drivers on Exynos platforms do not work without their >> corresponding SoC specific phy drivers. Hence it makes no sense to >> keep these phy drivers as user selectable. Instead select them from >> the respective USB configs to make things easier for the end user. >> While at it enable 5250 phy for Exynos 5420 SoC too. >> >> Signed-off-by: Sachin Kamat >> Cc: Kishon Vijay Abraham I >> --- >> drivers/phy/Kconfig | 37 +++-- >> drivers/usb/host/Kconfig | 10 ++ >> 2 files changed, 13 insertions(+), 34 deletions(-) >> >> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig >> index 16a2f067c242..7fe7ef5f1322 100644 >> --- a/drivers/phy/Kconfig >> +++ b/drivers/phy/Kconfig > > > >> >> config USB_EHCI_EXYNOS >> - tristate "EHCI support for Samsung S5P/EXYNOS SoC Series" >> - depends on PLAT_S5P || ARCH_EXYNOS >> - help >> - Enable support for the Samsung Exynos SOC's on-chip EHCI controller. >> + tristate "EHCI support for Samsung S5P/EXYNOS SoC Series" >> + depends on PLAT_S5P || ARCH_EXYNOS >> + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS > > I am skeptical to add select after the problems it created during previous > releases. If you could point me to some link/discussion about this, I could check if such problem is applicable here. IMHO, there shouldn't be any in this case. > Maybe use 'default y if ARCH_EXYNOS' in PHY_SAMSUNG_USB2 Kconfig? I would prefer to use this option only if there is a strong objection to doing it the current way as I do not see any benefits of exposing the PHY entries that are only prerequisites for the USB functionality (in this case) to users. Regards, Sachin. -- 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 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Vivek, On Thu, Jun 26, 2014 at 1:55 PM, Sachin Kamat wrote: > Hi Vivek, > > On Thu, Jun 26, 2014 at 1:39 PM, Vivek Gautam > wrote: >> Hi Sachin, >> >> >> On Thu, Jun 26, 2014 at 11:09 AM, Sachin Kamat >> wrote: >>> EHCI and OHCI drivers on Exynos platforms do not work without their >>> corresponding SoC specific phy drivers. Hence it makes no sense to >>> keep these phy drivers as user selectable. Instead select them from >>> the respective USB configs to make things easier for the end user. >>> While at it enable 5250 phy for Exynos 5420 SoC too. > > > >>> + select PHY_EXYNOS4210_USB2 if CPU_EXYNOS4210 >>> + select PHY_EXYNOS4X12_USB2 if (SOC_EXYNOS4212 || SOC_EXYNOS4412) >>> + select PHY_EXYNOS5250_USB2 if (SOC_EXYNOS5250 || SOC_EXYNOS5420) >> >> also || SOC_EXYNOS5800 >> same controller present on Exynos5800 too. Just checked that SOC_EXYNOS5800 is dependent on SOC_EXYNOS5420. Hence explicit option for SOC_EXYNOS5800 is redundant here. Will keep it as is. Regards, Sachin. -- 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 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
Hi Vivek, On Thu, Jun 26, 2014 at 1:39 PM, Vivek Gautam wrote: > Hi Sachin, > > > On Thu, Jun 26, 2014 at 11:09 AM, Sachin Kamat > wrote: >> EHCI and OHCI drivers on Exynos platforms do not work without their >> corresponding SoC specific phy drivers. Hence it makes no sense to >> keep these phy drivers as user selectable. Instead select them from >> the respective USB configs to make things easier for the end user. >> While at it enable 5250 phy for Exynos 5420 SoC too. >> + select PHY_EXYNOS4210_USB2 if CPU_EXYNOS4210 >> + select PHY_EXYNOS4X12_USB2 if (SOC_EXYNOS4212 || SOC_EXYNOS4412) >> + select PHY_EXYNOS5250_USB2 if (SOC_EXYNOS5250 || SOC_EXYNOS5420) > > also || SOC_EXYNOS5800 > same controller present on Exynos5800 too. Thanks. Will add. >> @@ -520,6 +521,7 @@ config USB_OHCI_SH >> config USB_OHCI_EXYNOS >> tristate "OHCI support for Samsung S5P/EXYNOS SoC Series" >> depends on PLAT_S5P || ARCH_EXYNOS >> + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS >> help >> Enable support for the Samsung Exynos SOC's on-chip OHCI controller. >> > > rest looks fine. Thanks. Sachin. -- 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
[PATCH 2/2] usb: dwc3: Kconfig: Select PHY drivers for Exynos DWC3
USB DWC3 driver on Exynos platforms does not work without its corresponding phy driver. Hence it makes no sense to keep the phy driver as user selectable. Instead select it from USB config to make things easier for the end user. While at it make the config depend on ARCH_EXYNOS5 instead of ARCH_EXYNOS as this IP is available only on Exynos5 platforms. Signed-off-by: Sachin Kamat Cc: Kishon Vijay Abraham I --- drivers/phy/Kconfig |8 +--- drivers/usb/dwc3/Kconfig |3 ++- 2 files changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 7fe7ef5f1322..6be353c9dc4c 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -138,15 +138,9 @@ config PHY_EXYNOS5250_USB2 bool config PHY_EXYNOS5_USBDRD - tristate "Exynos5 SoC series USB DRD PHY driver" - depends on ARCH_EXYNOS5 && OF - depends on HAS_IOMEM + tristate select GENERIC_PHY select MFD_SYSCON - help - Enable USB DRD PHY support for Exynos 5 SoC series. - This driver provides PHY interface for USB 3.0 DRD controller - present on Exynos5 SoC series. config PHY_XGENE tristate "APM X-Gene 15Gbps PHY support" diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 261c3b428220..501477452ad8 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -55,7 +55,8 @@ config USB_DWC3_OMAP config USB_DWC3_EXYNOS tristate "Samsung Exynos Platform" - depends on ARCH_EXYNOS || COMPILE_TEST + depends on ARCH_EXYNOS5 || COMPILE_TEST + select PHY_EXYNOS5_USBDRD default USB_DWC3 help Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside, -- 1.7.9.5 -- 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
[PATCH 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
EHCI and OHCI drivers on Exynos platforms do not work without their corresponding SoC specific phy drivers. Hence it makes no sense to keep these phy drivers as user selectable. Instead select them from the respective USB configs to make things easier for the end user. While at it enable 5250 phy for Exynos 5420 SoC too. Signed-off-by: Sachin Kamat Cc: Kishon Vijay Abraham I --- drivers/phy/Kconfig | 37 +++-- drivers/usb/host/Kconfig | 10 ++ 2 files changed, 13 insertions(+), 34 deletions(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 16a2f067c242..7fe7ef5f1322 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -121,44 +121,21 @@ config PHY_SUN4I_USB parts, as well as the 2 regular USB 2 host PHYs. config PHY_SAMSUNG_USB2 - tristate "Samsung USB 2.0 PHY driver" + tristate select GENERIC_PHY select MFD_SYSCON - help - Enable this to support the Samsung USB 2.0 PHY driver for Samsung - SoCs. This driver provides the interface for USB 2.0 PHY. Support for - particular SoCs has to be enabled in addition to this driver. Number - and type of supported phys depends on the SoC. + select PHY_EXYNOS4210_USB2 if CPU_EXYNOS4210 + select PHY_EXYNOS4X12_USB2 if (SOC_EXYNOS4212 || SOC_EXYNOS4412) + select PHY_EXYNOS5250_USB2 if (SOC_EXYNOS5250 || SOC_EXYNOS5420) config PHY_EXYNOS4210_USB2 - bool "Support for Exynos 4210" - depends on PHY_SAMSUNG_USB2 - depends on CPU_EXYNOS4210 - help - Enable USB PHY support for Exynos 4210. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4210 four - phys are available - device, host, HSIC0 and HSIC1. + bool config PHY_EXYNOS4X12_USB2 - bool "Support for Exynos 4x12" - depends on PHY_SAMSUNG_USB2 - depends on (SOC_EXYNOS4212 || SOC_EXYNOS4412) - help - Enable USB PHY support for Exynos 4x12. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 4x12 four - phys are available - device, host, HSIC0 and HSIC1. + bool config PHY_EXYNOS5250_USB2 - bool "Support for Exynos 5250" - depends on PHY_SAMSUNG_USB2 - depends on SOC_EXYNOS5250 - help - Enable USB PHY support for Exynos 5250. This option requires that - Samsung USB 2.0 PHY driver is enabled and means that support for this - particular SoC is compiled in the driver. In case of Exynos 5250 four - phys are available - device, host, HSIC0 and HSIC. + bool config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 61b7817bd66b..2938807331de 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -211,10 +211,11 @@ config USB_EHCI_SH If you use the PCI EHCI controller, this option is not necessary. config USB_EHCI_EXYNOS - tristate "EHCI support for Samsung S5P/EXYNOS SoC Series" - depends on PLAT_S5P || ARCH_EXYNOS - help - Enable support for the Samsung Exynos SOC's on-chip EHCI controller. + tristate "EHCI support for Samsung S5P/EXYNOS SoC Series" + depends on PLAT_S5P || ARCH_EXYNOS + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS + help + Enable support for the Samsung Exynos SOC's on-chip EHCI controller. config USB_EHCI_MV bool "EHCI support for Marvell PXA/MMP USB controller" @@ -520,6 +521,7 @@ config USB_OHCI_SH config USB_OHCI_EXYNOS tristate "OHCI support for Samsung S5P/EXYNOS SoC Series" depends on PLAT_S5P || ARCH_EXYNOS + select PHY_SAMSUNG_USB2 if ARCH_EXYNOS help Enable support for the Samsung Exynos SOC's on-chip OHCI controller. -- 1.7.9.5 -- 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 2/2] i2c: exynos5: fix minor styling nits
Hi Naveen,
On Wed, Jun 25, 2014 at 4:08 PM, Naveen Krishna Chatradhi
wrote:
> This patch removes an extra line and fixes a styling nit
> in exynos5_i2c_message_start()
>
> Signed-off-by: Naveen Krishna Chatradhi
> ---
> drivers/i2c/busses/i2c-exynos5.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-exynos5.c
> b/drivers/i2c/busses/i2c-exynos5.c
> index 0d1a7bc..4c2e6f3 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -525,7 +525,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
> *i2c, int stop)
> if (i2c->msg->flags & I2C_M_RD) {
> i2c_ctl |= HSI2C_RXCHON;
>
> - i2c_auto_conf = HSI2C_READ_WRITE;
> + i2c_auto_conf |= HSI2C_READ_WRITE;
This change looks more than just a styling nit. Please update the commit message
accordingly.
--
Regards,
Sachin.
--
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
[PATCH 1/1] i2c: Kconfig: Enable HSI2C for Exynos5 platform
All Exynos5 platforms have HSI2C controllers and are needed by various IPs connected to the boards based on these SoCs. Thus select this by default for Exynos5 platforms. Signed-off-by: Sachin Kamat Cc: Doug Anderson --- drivers/i2c/busses/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 9f7d5859cf65..c7918cffe790 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -465,9 +465,9 @@ config I2C_EG20T config I2C_EXYNOS5 tristate "Exynos5 high-speed I2C driver" depends on ARCH_EXYNOS5 && OF + default y help - Say Y here to include support for high-speed I2C controller in the - Exynos5 based Samsung SoCs. + High-speed I2C controller on Exynos5 based Samsung SoCs. config I2C_GPIO tristate "GPIO-based bitbanging I2C" -- 1.7.9.5 -- 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
[PATCH 1/1] ARM: Kconfig.debug: Update Samsung UART config options
In a multiplatform config, the low level debug option shows several UART port entries. Improve the user visible string so that it becomes clear to the user about Samsung UART ports. While at it also remove some lines from the help text that are no longer applicable across all Samsung platforms. Signed-off-by: Sachin Kamat --- arch/arm/Kconfig.debug | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 3548612b0bfe..b92993e59a12 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -617,53 +617,41 @@ choice depends on PLAT_SAMSUNG select DEBUG_EXYNOS_UART if ARCH_EXYNOS select DEBUG_S3C24XX_UART if ARCH_S3C24XX - bool "Use S3C UART 0 for low-level debug" + bool "Use Samsung S3C UART 0 for low-level debug" help Say Y here if you want the debug print routines to direct their output to UART 0. The port must have been initialised by the boot-loader before use. - The uncompressor code port configuration is now handled - by CONFIG_S3C_LOWLEVEL_UART_PORT. - config DEBUG_S3C_UART1 depends on PLAT_SAMSUNG select DEBUG_EXYNOS_UART if ARCH_EXYNOS select DEBUG_S3C24XX_UART if ARCH_S3C24XX - bool "Use S3C UART 1 for low-level debug" + bool "Use Samsung S3C UART 1 for low-level debug" help Say Y here if you want the debug print routines to direct their output to UART 1. The port must have been initialised by the boot-loader before use. - The uncompressor code port configuration is now handled - by CONFIG_S3C_LOWLEVEL_UART_PORT. - config DEBUG_S3C_UART2 depends on PLAT_SAMSUNG select DEBUG_EXYNOS_UART if ARCH_EXYNOS select DEBUG_S3C24XX_UART if ARCH_S3C24XX - bool "Use S3C UART 2 for low-level debug" + bool "Use Samsung S3C UART 2 for low-level debug" help Say Y here if you want the debug print routines to direct their output to UART 2. The port must have been initialised by the boot-loader before use. - The uncompressor code port configuration is now handled - by CONFIG_S3C_LOWLEVEL_UART_PORT. - config DEBUG_S3C_UART3 depends on PLAT_SAMSUNG && ARCH_EXYNOS select DEBUG_EXYNOS_UART - bool "Use S3C UART 3 for low-level debug" + bool "Use Samsung S3C UART 3 for low-level debug" help Say Y here if you want the debug print routines to direct their output to UART 3. The port must have been initialised by the boot-loader before use. - The uncompressor code port configuration is now handled - by CONFIG_S3C_LOWLEVEL_UART_PORT. - config DEBUG_S3C2410_UART0 depends on ARCH_S3C24XX select DEBUG_S3C2410_UART -- 1.7.9.5 -- 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
[PATCH 1/1] ARM: EXYNOS: Remove unused code in common.h
PINCTRL_EXYNOS is always selected by Exynos platform in its
machine Kconfig. Thus the code in the else part is never used.
Remove it.
Signed-off-by: Sachin Kamat
---
arch/arm/mach-exynos/common.h |4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 1ee91763fa7c..3371669dabc6 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -125,11 +125,7 @@ void exynos_init_late(void);
void exynos_firmware_init(void);
-#ifdef CONFIG_PINCTRL_EXYNOS
extern u32 exynos_get_eint_wake_mask(void);
-#else
-static inline u32 exynos_get_eint_wake_mask(void) { return 0x; }
-#endif
#ifdef CONFIG_PM_SLEEP
extern void __init exynos_pm_init(void);
--
1.7.9.5
--
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 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
On Fri, May 30, 2014 at 11:49 PM, Andreas Färber wrote: > Am 28.05.2014 06:13, schrieb Sachin Kamat: >> Almost all Exynos-series of SoCs that run in secure mode don't need >> additional offset for every CPU, with Exynos4412 being the only >> exception. >> >> Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). >> >> While at it, fix the coding style (space around *). >> >> Signed-off-by: Sachin Kamat >> Signed-off-by: Tushar Behera >> --- >> arch/arm/mach-exynos/firmware.c |9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) > > Fixes ODROID-XU (Exynos5410) as well - thought it had been a prereq to > applying the 5410 patches... > > Tested-by: Andreas Färber > Kukjin, this patch is required to bring up 4 A15 cores on some 5410 and 5420 based boards. Can you please queue this up for the upcoming rc as fixes? -- 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: MMC error on Exynos4210 board
Hi Tim, On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger wrote: > On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat wrote: >> On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung >> wrote: >>> On 06/19/2014 07:40 PM, Sachin Kamat wrote: >>>> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger wrote: >>>>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat wrote: >>>>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: >>>>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat >>>>>>> wrote: >>>>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat >>>>>>>>> wrote: >>>>>>> >>>>>>>>>> I see the below error on Exynos4210 based Origen board with >>>>>>>>>> linux-next >>>>>>>>>> (20140618). >>>>>>>>>> Reverting the below commit works fine. >>>>>>>>>> >>>>>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >>>>>>> >>>>>>>>>> >>>>>>>>>> -- [2.068992] sdhci: Secure Digital Host Controller Interface >>>>>>>>>> driver >>>>>>>>>> [2.075059] sdhci: Copyright(c) Pierre Ossman >>>>>>>>>> [2.079762] of_get_named_gpiod_flags: can't parse gpios property >>>>>>>>>> of >>>>>>>>>> node '/sdhci@1251[0]' >>>>>>>>>> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >>>>>>>>>> (5000 Hz) >>>>>>>>>> [2.095322] of_get_named_gpiod_flags: can't parse gpios property >>>>>>>>>> of >>>>>>>>>> node '/sdhci@1251[0]' >>>>>>>>>> [2.103794] of_get_named_gpiod_flags: can't parse gpios property >>>>>>>>>> of >>>>>>>>>> node '/sdhci@1251[0]' >>>>>>>>>> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >>>>>>>>>> [2.118117] mmc0: Hardware doesn't report any support voltages. >>>>>>>>>> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >>>>>>>>>> [2.130080] of_get_named_gpiod_flags: can't parse gpios property >>>>>>>>>> of >>>>>>>>>> node '/sdhci@1253[0]' >>>>>>>>>> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >>>>>>>>>> (1667 Hz) >>>>>>>>>> [2.145661] of_get_named_gpiod_flags: can't parse gpios property >>>>>>>>>> of >>>>>>>>>> node '/sdhci@1253[0]' >>>>>>>>>> [2.154139] of_get_named_gpiod_flags: can't parse gpios property >>>>>>>>>> of >>>>>>>>>> node '/sdhci@1253[0]' >>>>>>>>>> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >>>>>>>>>> [2.168464] mmc0: Hardware doesn't report any support voltages. >>>>>>>>>> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >>>>>>> >>>>>>>>>> [2.336148] Waiting for root device /dev/mmcblk0p1... >>>>>>> >>>>>>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. >>>>>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more >>>>>>>> details. >>>>>>> >>>>>>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 >>>>>>> | MMC_VDD_28_29. >>>>>>> >>>>>>> The SDHCI capabilities register only indicates support of three voltage >>>>>>> levels >>>>>>> - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 >>>>>>> - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 >>>>>>> - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 >>> >>> Right. sdhci capabilities only indicated them. >&g
Re: [PATCH 2/4] Documentation: devicetree: Fix s2mps11 example syntax
On Mon, Jun 23, 2014 at 6:51 AM, Andreas Färber wrote:
> It's <1>, not 1.
>
> Signed-off-by: Andreas Färber
> ---
> Documentation/devicetree/bindings/mfd/s2mps11.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> index 55ab4f4..99a0c52 100644
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> @@ -96,7 +96,7 @@ Example:
>
> s2m_osc: clocks {
> compatible = "samsung,s2mps11-clk";
> - #clock-cells = 1;
> + #clock-cells = <1>;
> clock-output-names = "xx", "yy", "zz";
> };
>
> --
> 1.9.3
>
Reviewed-by: Sachin Kamat
--
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 1/4] Documentation: devicetree: Fix s2mps11 and s5m8767 typos
On Mon, Jun 23, 2014 at 6:51 AM, Andreas Färber wrote: > It's LDO2, not LD02. > > Signed-off-by: Andreas Färber > --- > Documentation/devicetree/bindings/mfd/s2mps11.txt | 2 +- > Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt > b/Documentation/devicetree/bindings/mfd/s2mps11.txt > index d81ba30..55ab4f4 100644 > --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt > +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt > @@ -81,7 +81,7 @@ as per the datasheet of s2mps11. > - valid values for n are: > - S2MPS11: 1 to 38 > - S2MPS14: 1 to 25 > - - Example: LDO1, LD02, LDO28 > + - Example: LDO1, LDO2, LDO28 > - BUCKn > - valid values for n are: > - S2MPS11: 1 to 10 > diff --git > a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > index d290988..2019131 100644 > --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > @@ -86,7 +86,7 @@ as per the datasheet of s5m8767. > > - LDOn > - valid values for n are 1 to 28 > - - Example: LDO1, LD02, LDO28 > + - Example: LDO1, LDO2, LDO28 > - BUCKn > - valid values for n are 1 to 9. > - Example: BUCK1, BUCK2, BUCK9 > -- Very keen observation :) Reviewed-by: Sachin Kamat -- 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: MMC error on Exynos4210 board
On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung wrote: > On 06/19/2014 07:40 PM, Sachin Kamat wrote: >> On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger wrote: >>> On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat wrote: >>>> +cc Some relevant guys from Samsung >>>> >>>> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: >>>>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: >>>>> >>>>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat >>>>>>> wrote: >>>>> >>>>>>>> I see the below error on Exynos4210 based Origen board with linux-next >>>>>>>> (20140618). >>>>>>>> Reverting the below commit works fine. >>>>>>>> >>>>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >>>>> >>>>>>>> >>>>>>>> -- [2.068992] sdhci: Secure Digital Host Controller Interface >>>>>>>> driver >>>>>>>> [2.075059] sdhci: Copyright(c) Pierre Ossman >>>>>>>> [2.079762] of_get_named_gpiod_flags: can't parse gpios property of >>>>>>>> node '/sdhci@1251[0]' >>>>>>>> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >>>>>>>> (5000 Hz) >>>>>>>> [2.095322] of_get_named_gpiod_flags: can't parse gpios property of >>>>>>>> node '/sdhci@1251[0]' >>>>>>>> [2.103794] of_get_named_gpiod_flags: can't parse gpios property of >>>>>>>> node '/sdhci@1251[0]' >>>>>>>> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >>>>>>>> [2.118117] mmc0: Hardware doesn't report any support voltages. >>>>>>>> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >>>>>>>> [2.130080] of_get_named_gpiod_flags: can't parse gpios property of >>>>>>>> node '/sdhci@1253[0]' >>>>>>>> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >>>>>>>> (1667 Hz) >>>>>>>> [2.145661] of_get_named_gpiod_flags: can't parse gpios property of >>>>>>>> node '/sdhci@1253[0]' >>>>>>>> [2.154139] of_get_named_gpiod_flags: can't parse gpios property of >>>>>>>> node '/sdhci@1253[0]' >>>>>>>> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >>>>>>>> [2.168464] mmc0: Hardware doesn't report any support voltages. >>>>>>>> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >>>>> >>>>>>>> [2.336148] Waiting for root device /dev/mmcblk0p1... >>>>> >>>>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. >>>>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more >>>>>> details. >>>>> >>>>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 >>>>> | MMC_VDD_28_29. >>>>> >>>>> The SDHCI capabilities register only indicates support of three voltage >>>>> levels >>>>> - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 >>>>> - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 >>>>> - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 > > Right. sdhci capabilities only indicated them. > But I think SoC can be support the specific VDD range. > >>>>> >>>>> Even if all capability bits of the host controller were set, there >>>>> still wouldn't be any overlap. Thus you see a "Hardware doesn't >>>>> report any support voltages" message. >>>>> >>>>> Previously, this issue was being swept under the rug by cec2e21 mmc: >>>>> sdhci: Use regulator min/max voltage range according to spec. That >>>>> change hacked up the voltage range checks such that with your 2.8v >>>>> fixed regulator, the driver would believe the host could support >>>>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The >>>>> driver wou
Re: MMC error on Exynos4210 board
On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger wrote: > On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat wrote: >> +cc Some relevant guys from Samsung >> >> On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: >>> On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: >>> >>>>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat wrote: >>> >>>>>> I see the below error on Exynos4210 based Origen board with linux-next >>>>>> (20140618). >>>>>> Reverting the below commit works fine. >>>>>> >>>>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >>> >>>>>> >>>>>> -- [2.068992] sdhci: Secure Digital Host Controller Interface driver >>>>>> [2.075059] sdhci: Copyright(c) Pierre Ossman >>>>>> [2.079762] of_get_named_gpiod_flags: can't parse gpios property of >>>>>> node '/sdhci@1251[0]' >>>>>> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >>>>>> (5000 Hz) >>>>>> [2.095322] of_get_named_gpiod_flags: can't parse gpios property of >>>>>> node '/sdhci@1251[0]' >>>>>> [2.103794] of_get_named_gpiod_flags: can't parse gpios property of >>>>>> node '/sdhci@1251[0]' >>>>>> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >>>>>> [2.118117] mmc0: Hardware doesn't report any support voltages. >>>>>> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >>>>>> [2.130080] of_get_named_gpiod_flags: can't parse gpios property of >>>>>> node '/sdhci@1253[0]' >>>>>> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >>>>>> (1667 Hz) >>>>>> [2.145661] of_get_named_gpiod_flags: can't parse gpios property of >>>>>> node '/sdhci@1253[0]' >>>>>> [2.154139] of_get_named_gpiod_flags: can't parse gpios property of >>>>>> node '/sdhci@1253[0]' >>>>>> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >>>>>> [2.168464] mmc0: Hardware doesn't report any support voltages. >>>>>> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >>> >>>>>> [2.336148] Waiting for root device /dev/mmcblk0p1... >>> >>>> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. >>>> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. >>> >>> A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 >>> | MMC_VDD_28_29. >>> >>> The SDHCI capabilities register only indicates support of three voltage >>> levels >>> - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 >>> - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 >>> - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 >>> >>> Even if all capability bits of the host controller were set, there >>> still wouldn't be any overlap. Thus you see a "Hardware doesn't >>> report any support voltages" message. >>> >>> Previously, this issue was being swept under the rug by cec2e21 mmc: >>> sdhci: Use regulator min/max voltage range according to spec. That >>> change hacked up the voltage range checks such that with your 2.8v >>> fixed regulator, the driver would believe the host could support >>> MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The >>> driver would start down the path of commanding 3.3v-3.4v (the highest >>> voltage range believed to be supported). At the last second, the >>> driver would see the regulator was fixed and blindly skip over the set >>> voltage operation, saving it from failure. >>> >>> Since my patch eliminates the bogus voltage range checks, your board >>> is now getting caught playing too loose with the SDHCI regulator >>> voltages. >>> >>> Furthermore, the fixed regulator special-case logic that helped hide >>> your issue should also be considered for removal given that fixed >>> regulators now behave properly thanks to c00dc35 regulator: core: >>> Allow regulator_set_voltage for fixed regulators. >> >> Thanks for the detailed explanation. What do you propose to get this fixed? > > I'm not really sure of the best path forward. I suppose you could > modify your device tree to lie about the voltage of the fixed > regulator. Changing it to 3.0v should allow it to boot up but that is > definitely a hack. Or I could simply remove the vmmc-supply property altogether (as it is optional) and get the board to work. > It would be nice if the driver could be extended > to handle the peculiarities of your board in a deliberate manner but > limiting the common sdhci driver to supporting only the three voltages > from the spec also seems sensible. Until such time that the driver gets fixed to handle 2.8V fixed supply your current patch leaves several of Exynos boards broken for now. -- Regards, Sachin. -- 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: MMC error on Exynos4210 board
+cc Some relevant guys from Samsung On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger wrote: > On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat wrote: > >>> On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat wrote: > >>>> I see the below error on Exynos4210 based Origen board with linux-next >>>> (20140618). >>>> Reverting the below commit works fine. >>>> >>>> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" > >>>> >>>> -- [2.068992] sdhci: Secure Digital Host Controller Interface driver >>>> [2.075059] sdhci: Copyright(c) Pierre Ossman >>>> [2.079762] of_get_named_gpiod_flags: can't parse gpios property of >>>> node '/sdhci@1251[0]' >>>> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >>>> (5000 Hz) >>>> [2.095322] of_get_named_gpiod_flags: can't parse gpios property of >>>> node '/sdhci@1251[0]' >>>> [2.103794] of_get_named_gpiod_flags: can't parse gpios property of >>>> node '/sdhci@1251[0]' >>>> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >>>> [2.118117] mmc0: Hardware doesn't report any support voltages. >>>> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >>>> [2.130080] of_get_named_gpiod_flags: can't parse gpios property of >>>> node '/sdhci@1253[0]' >>>> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >>>> (1667 Hz) >>>> [2.145661] of_get_named_gpiod_flags: can't parse gpios property of >>>> node '/sdhci@1253[0]' >>>> [2.154139] of_get_named_gpiod_flags: can't parse gpios property of >>>> node '/sdhci@1253[0]' >>>> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >>>> [2.168464] mmc0: Hardware doesn't report any support voltages. >>>> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed > >>>> [2.336148] Waiting for root device /dev/mmcblk0p1... > >> FYI, the board has a 2.8V fixed regulator supply connected to the MMC. >> You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. > > A 2.8v regulator results in mmc->ocr_avail being set to MMC_VDD_27_28 > | MMC_VDD_28_29. > > The SDHCI capabilities register only indicates support of three voltage levels > - 1.8v: SDHCI_CAN_VDD_180 => MMC_VDD_165_195 > - 3.0v: SDHCI_CAN_VDD_300 => MMC_VDD_29_30 | MMC_VDD_30_31 > - 3.3v: SDHCI_CAN_VDD_330 => MMC_VDD_32_33 | MMC_VDD_33_34 > > Even if all capability bits of the host controller were set, there > still wouldn't be any overlap. Thus you see a "Hardware doesn't > report any support voltages" message. > > Previously, this issue was being swept under the rug by cec2e21 mmc: > sdhci: Use regulator min/max voltage range according to spec. That > change hacked up the voltage range checks such that with your 2.8v > fixed regulator, the driver would believe the host could support > MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The > driver would start down the path of commanding 3.3v-3.4v (the highest > voltage range believed to be supported). At the last second, the > driver would see the regulator was fixed and blindly skip over the set > voltage operation, saving it from failure. > > Since my patch eliminates the bogus voltage range checks, your board > is now getting caught playing too loose with the SDHCI regulator > voltages. > > Furthermore, the fixed regulator special-case logic that helped hide > your issue should also be considered for removal given that fixed > regulators now behave properly thanks to c00dc35 regulator: core: > Allow regulator_set_voltage for fixed regulators. Thanks for the detailed explanation. What do you propose to get this fixed? -- Regards, Sachin. -- 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] ARM: dts: exynos4: fix pwm-cells in pwm node
Hi Jaewon, On Thu, Jun 19, 2014 at 7:33 AM, Jaewon Kim wrote: > pwm-cells should be 3. Third cell is optional PWM flags. And This flag > supported by this binding is PWM_POLARITY_INVERTED. > > Signed-off-by: Jaewon Kim > --- > > Changes in v2: > - Remove unnecessary handle. > > arch/arm/boot/dts/exynos4.dtsi |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi > index b8ece4b..e118356 100644 > --- a/arch/arm/boot/dts/exynos4.dtsi > +++ b/arch/arm/boot/dts/exynos4.dtsi > @@ -554,7 +554,7 @@ > interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>; > clocks = <&clock CLK_PWM>; > clock-names = "timers"; > - #pwm-cells = <2>; > + #pwm-cells = <3>; > status = "disabled"; > }; I think I had already reviewed this patch. Anyway, Reviewed-by: Sachin Kamat -- 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] clk/exynos5250: fix bit number for tv sysmmu clock
On Thu, Jun 19, 2014 at 11:17 AM, Rahul Sharma wrote:
> Change bit from 2 to 9 for tv (mixer) sysmmu clock.
>
> Signed-off-by: Rahul Sharma
> ---
> Based on Kukjin's for-next branch.
>
> drivers/clk/samsung/clk-exynos5250.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5250.c
> b/drivers/clk/samsung/clk-exynos5250.c
> index 1fad4c5..184f642 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -661,7 +661,7 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
> __initdata = {
> GATE(CLK_RTC, "rtc", "div_aclk66", GATE_IP_PERIS, 20, 0, 0),
> GATE(CLK_TMU, "tmu", "div_aclk66", GATE_IP_PERIS, 21, 0, 0),
> GATE(CLK_SMMU_TV, "smmu_tv", "mout_aclk200_disp1_sub",
> - GATE_IP_DISP1, 2, 0, 0),
> + GATE_IP_DISP1, 9, 0, 0),
SysMMU TV corresponds to bit 9 as per user manual of 5250.
Reviewed-by: Sachin Kamat
--
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: MMC error on Exynos4210 board
On Wed, Jun 18, 2014 at 7:41 PM, Tim Kryger wrote: > On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat wrote: >> Hi Tim, >> >> I see the below error on Exynos4210 based Origen board with linux-next >> (20140618). >> Reverting the below commit works fine. >> >> Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" >> >> Any ideas? >> >> *** >> >> -- [2.068992] sdhci: Secure Digital Host Controller Interface driver >> [2.075059] sdhci: Copyright(c) Pierre Ossman >> [2.079762] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1251[0]' >> [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 >> (5000 Hz) >> [2.095322] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1251[0]' >> [2.103794] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1251[0]' >> [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found >> [2.118117] mmc0: Hardware doesn't report any support voltages. >> [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed >> [2.130080] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1253[0]' >> [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 >> (1667 Hz) >> [2.145661] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1253[0]' >> [2.154139] of_get_named_gpiod_flags: can't parse gpios property of >> node '/sdhci@1253[0]' >> [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found >> [2.168464] mmc0: Hardware doesn't report any support voltages. >> [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed >> [2.180281] Synopsys Designware Multimedia Card Interface Driver >> [2.188131] usbcore: registered new interface driver usbhid >> [2.192287] usbhid: USB HID core driver >> [2.196329] TCP: cubic registered >> [2.199362] NET: Registered protocol family 17 >> [2.203917] NET: Registered protocol family 15 >> [2.208404] Registering SWP/SWPB emulation handler >> [2.214357] of_get_named_gpiod_flags exited with status 0 >> [2.218430] of_get_named_gpiod_flags exited with status 0 >> [2.223803] of_get_named_gpiod_flags exited with status 0 >> [2.229170] of_get_named_gpiod_flags exited with status 0 >> [2.234560] of_get_named_gpiod_flags exited with status 0 >> [2.239953] gpio-229: gpiod_set_debounce: missing set() or >> set_debounce() operations >> [2.247773] gpio-230: gpiod_set_debounce: missing set() or >> set_debounce() operations >> [2.255473] gpio-228: gpiod_set_debounce: missing set() or >> set_debounce() operations >> [2.263221] gpio-227: gpiod_set_debounce: missing set() or >> set_debounce() operations >> [2.270918] gpio-226: gpiod_set_debounce: missing set() or >> set_debounce() operations >> [2.278899] input: gpio_keys as /devices/gpio_keys/input/input0 >> [2.285196] s3c-rtc 1007.rtc: setting system clock to >> 2000-01-01 00:00:00 UTC (946684800) >> [2.295072] VDD_G3D_1.1V: disabling >> [2.304744] VADC_3.3V: disabling >> [2.312095] VDD_AUD_1.8V: disabling >> [2.319714] VMIPI_1.1V: disabling >> [2.327193] VDD_ABB_3.3V: disabling >> [2.332779] VMEM_VDD_2.8V: disabling >> [2.336148] Waiting for root device /dev/mmcblk0p1... >> >> * >> Regards, >> Sachin. > > Would you mind reverting just this part of the commit to see if it > clears up your trouble? > >> if (host->ocr_mask) >> - ocr_avail = host->ocr_mask; >> + ocr_avail &= host->ocr_mask; Reverting this did not help. I still get the above error. My diff: diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index c23a87285a95..f4135094320d 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -3096,7 +3096,7 @@ int sdhci_add_host(struct sdhci_host *host) ocr_avail &= mmc->ocr_avail; if (host->ocr_mask) - ocr_avail &= host->ocr_mask; + ocr_avail = host->ocr_mask; mmc->ocr_avail = ocr_avail; mmc->ocr_avail_sdio = ocr_avail; FYI, the board has a 2.8V fixed regulator supply connected to the MMC. You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. -- Regards, Sachin. -- 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
MMC error on Exynos4210 board
Hi Tim, I see the below error on Exynos4210 based Origen board with linux-next (20140618). Reverting the below commit works fine. Commit: 8d02e775a6 "mmc: sdhci: Use mmc core regulator infrastucture" Any ideas? *** -- [2.068992] sdhci: Secure Digital Host Controller Interface driver [2.075059] sdhci: Copyright(c) Pierre Ossman [2.079762] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 (5000 Hz) [2.095322] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.103794] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found [2.118117] mmc0: Hardware doesn't report any support voltages. [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed [2.130080] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 (1667 Hz) [2.145661] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.154139] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found [2.168464] mmc0: Hardware doesn't report any support voltages. [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed [2.180281] Synopsys Designware Multimedia Card Interface Driver [2.188131] usbcore: registered new interface driver usbhid [2.192287] usbhid: USB HID core driver [2.196329] TCP: cubic registered [2.199362] NET: Registered protocol family 17 [2.203917] NET: Registered protocol family 15 [2.208404] Registering SWP/SWPB emulation handler [2.214357] of_get_named_gpiod_flags exited with status 0 [2.218430] of_get_named_gpiod_flags exited with status 0 [2.223803] of_get_named_gpiod_flags exited with status 0 [2.229170] of_get_named_gpiod_flags exited with status 0 [2.234560] of_get_named_gpiod_flags exited with status 0 [2.239953] gpio-229: gpiod_set_debounce: missing set() or set_debounce() operations [2.247773] gpio-230: gpiod_set_debounce: missing set() or set_debounce() operations [2.255473] gpio-228: gpiod_set_debounce: missing set() or set_debounce() operations [2.263221] gpio-227: gpiod_set_debounce: missing set() or set_debounce() operations [2.270918] gpio-226: gpiod_set_debounce: missing set() or set_debounce() operations [2.278899] input: gpio_keys as /devices/gpio_keys/input/input0 [2.285196] s3c-rtc 1007.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [2.295072] VDD_G3D_1.1V: disabling [2.304744] VADC_3.3V: disabling [2.312095] VDD_AUD_1.8V: disabling [2.319714] VMIPI_1.1V: disabling [2.327193] VDD_ABB_3.3V: disabling [2.332779] VMEM_VDD_2.8V: disabling [2.336148] Waiting for root device /dev/mmcblk0p1... * Regards, Sachin. -- 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: MMC regression with linux-next on Exynos5250
Hi Ulf, On Wed, Jun 18, 2014 at 4:43 PM, Ulf Hansson wrote: > On 18 June 2014 13:10, Sachin Kamat wrote: >> Hi Jaehoon, >> >> On Wed, Jun 18, 2014 at 3:50 PM, Jaehoon Chung >> wrote: >>> Hi, Sachin. >>> >>> Did you check the below patch? >>> https://patchwork.kernel.org/patch/4346781/ >> >> Thanks for the patch. But even with this patch, I continue to get the >> aforementioned crash. > > Hi Sachin / Jaehoon, > > Until we sorted out the problem, I will drop the related patch from my mmc > tree. OK. Also, I feel the mmc patch and the corresponding DT changes should go through single tree to avoid dependency issues. Regards, Sachin. -- 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: MMC regression with linux-next on Exynos5250
Hi Jaehoon, On Wed, Jun 18, 2014 at 3:50 PM, Jaehoon Chung wrote: > Hi, Sachin. > > Did you check the below patch? > https://patchwork.kernel.org/patch/4346781/ Thanks for the patch. But even with this patch, I continue to get the aforementioned crash. > > I will resend the patch after including the ARM soc mailing. > > dw-mmc controller used the mmc_of_parse(), but it can't parse the sub-node. > After checking it, let me know your result, plz. Regards, Sachin. -- 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
MMC regression with linux-next on Exynos5250
Hi Jaehoon,
I get the below crash on Exyos5250 based Arndale board with linux-next
(20140618) kernel.
Looks like the following patch is causing it
Commit da118915cc72 " mmc: dw_mmc: replace "disable-wp" from slot's
quirk to host's quirk"
Reverting the above patch fixes the issue.
The below changes in dts file also did not help.
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f50d15b..617fc5fe50f7 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -422,6 +422,7 @@
num-slots = <1>;
supports-highspeed;
card-detect-delay = <200>;
+ disable-wp;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
@@ -432,7 +433,6 @@
slot@0 {
reg = <0>;
bus-width = <4>;
- disable-wp;
};
};
Please check.
-- [2.043665] mmc_host mmc0: Bus speed (slot 0) = 1Hz
(slot req 5200Hz, actual 5000HZ div = 1)
[2.044300] Waiting for root device /dev/mmcblk1p3...
[2.058350] mmc0: new DDR MMC card at address 0001
[2.063256] mmcblk0: mmc0:0001 M4G1FA 3.72 GiB
[2.067633] mmcblk0boot0: mmc0:0001 M4G1FA partition 1 1.00 MiB
[2.073531] mmcblk0boot1: mmc0:0001 M4G1FA partition 2 1.00 MiB
[2.079433] mmcblk0rpmb: mmc0:0001 M4G1FA partition 3 128 KiB
[2.086554] mmcblk0: p1 p2 p3 p4
[2.089706] mmcblk0boot1: unknown partition table
[2.093953] mmcblk0boot0: unknown partition table
[2.098345] platform 122f.sata: Driver ahci requests probe deferral
[2.172280] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
req 5000Hz, actual 5000HZ div = 0)
[2.180563] mmc1: new high speed SDHC card at address
[2.186220] mmcblk1: mmc1: SU04G 3.69 GiB (ro)
[2.192336] mmcblk1: p1 p2 p3
[2.194654] platform 122f.sata: Driver ahci requests probe deferral
[2.250761] VFS: Cannot open root device "mmcblk1p3" or
unknown-block(179,67): error -30
[2.257452] Please append a correct "root=" boot option; here are
the available partitions:
[2.265787] b300 3907584 mmcblk0 driver: mmcblk
[2.271059] b301 2352800 mmcblk0p1 -01
[2.276312] b302 507872 mmcblk0p2 -02
[2.281606] b303 507840 mmcblk0p3 -03
[2.286899] b304 507840 mmcblk0p4 -04
[2.292206] b330 128 mmcblk0rpmb (driver?)
[2.297406] b3201024 mmcblk0boot1 (driver?)
[2.302700] b3101024 mmcblk0boot0 (driver?)
[2.307994] b340 3872256 mmcblk1 driver: mmcblk
[2.313289] b3414095 mmcblk1p1 0005ac11-01
[2.318582] b342 53248 mmcblk1p2 0005ac11-02
[2.323876] b343 3814912 mmcblk1p3 0005ac11-03
[2.329174] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(179,67)
[2.337696] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.16.0-rc1-next-20140618-00048-g868c90fe6c88 #2106
[2.347186] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[2.354895] [] (show_stack) from []
(dump_stack+0x8c/0x9c)
[2.362090] [] (dump_stack) from [] (panic+0xa4/0x21c)
[2.368950] [] (panic) from []
(mount_block_root+0x1a0/0x230)
[2.376415] [] (mount_block_root) from []
(mount_root+0x108/0x110)
[2.384313] [] (mount_root) from []
(prepare_namespace+0x158/0x19c)
[2.392301] [] (prepare_namespace) from []
(kernel_init_freeable+0x1cc/0x1dc)
[2.401159] [] (kernel_init_freeable) from []
(kernel_init+0xc/0xe8)
[2.409229] [] (kernel_init) from []
(ret_from_fork+0x14/0x3c)
[2.416770] CPU1: stopping
[2.419453] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
3.16.0-rc1-next-20140618-00048-g868c90fe6c88 #2106
[2.428948] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[2.436660] [] (show_stack) from []
(dump_stack+0x8c/0x9c)
[2.443856] [] (dump_stack) from []
(handle_IPI+0x150/0x170)
[2.451233] [] (handle_IPI) from []
(gic_handle_irq+0x64/0x68)
[2.458781] [] (gic_handle_irq) from []
(__irq_svc+0x40/0x50)
[2.466239] Exception stack(0xe989ff90 to 0xe989ffd8)
[2.471268] ff80: ffed
ffed c021f6c0
[2.479438] ffa0: e989e020 c0b94458 c0b944c4
e989e000 c082ef44 c0b88da8
[2.487594] ffc0: c0b95858 e989ffd8 c020f374 c020f378 6113
[2.494195] [] (__irq_svc) from []
(arch_cpu_idle+0x38/0x3c)
[2.501587] [] (arch_cpu_idle) from []
(cpu_startup_entry+0x1e8/0x23c)
[2.509823] [] (cpu_startup_entry) from [<40208a44>] (0x40208a44)
[2.516761] ---[ end Kernel panic - not syncing: VFS: Unable to
mount root fs on unknown-block(179,67)
***
Regards,
Sachin.
--
To unsubscri
Re: Boot warnings on exynos5420 based boards
Hi Srivatsa, On Tue, Jun 17, 2014 at 3:24 PM, Srivatsa S. Bhat wrote: > On 06/17/2014 03:03 PM, Sachin Kamat wrote: > >>> Below is an updated patch, please let me know how it goes. (You'll have to >>> revert c47a9d7cca first, and then 56e692182, before trying this patch). >> >> I am unable to apply your below patch on top of the above 2 reverts. >> Applying: CPU hotplug, smp: Execute any pending IPI callbacks before CPU >> offline >> fatal: corrupt patch at line 106 >> Patch failed at 0001 CPU hotplug, smp: Execute any pending IPI >> callbacks before CPU offline >> >> Even with 'patch' I get the below failures: >> patching file kernel/smp.c >> Hunk #2 FAILED at 53. >> Hunk #3 FAILED at 179. >> 2 out of 3 hunks FAILED -- saving rejects to file kernel/smp.c.rej >> > > Hmm, weird. My mailer must have screwed it up. > > Let's try again: > > [In case this also doesn't work for you, please use this git tree in which > I have reverted the 2 old commits and added this updated patch. > > git://github.com/srivatsabhat/linux.git ipi-offline-fix-v3 > ] Unfortunately the attached patch did not apply either. Nevertheless, I applied the patch from your above mentioned tree. With that patch I do not see the warnings that I mentioned in my first mail. Thanks for fixing it. Regards, Sachin. -- 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: Boot warnings on exynos5420 based boards
Hi Srivatsa,
Thanks for your prompt reply.
On Tue, Jun 17, 2014 at 2:48 PM, Srivatsa S. Bhat
wrote:
> Hi Sachin,
>
> On 06/17/2014 01:39 PM, Sachin Kamat wrote:
>> Hi,
>>
>> I observe the below warnings while trying to boot Exynos5420 based boards
>> since yesterday's linux-next (next-20140616) using multi_v7_defconfig. Looks
>
> I guess you meant next-20140617.
I meant I started observing this warning next-20140616 onwards
(next-20140617 as well).
>
>> like it is triggered by the commit 56e6921829 ("CPU hotplug, smp:
>> flush any pending IPI callbacks before CPU offline"). Any ideas?
>>
>>
>> *
>> [0.046521] Exynos MCPM support installed
>> [0.048939] CPU1: Booted secondary processor
>> [0.065005] CPU1: update cpu_capacity 1535
>> [0.065011] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
>> [0.065660] CPU2: Booted secondary processor
>> [0.085005] CPU2: update cpu_capacity 1535
>> [0.085012] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
>> [0.085662] CPU3: Booted secondary processor
>> [0.105005] CPU3: update cpu_capacity 1535
>> [0.105011] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
>> [1.105031] CPU4: failed to come online
>> [1.105081] [ cut here ]
>> [1.105104] WARNING: CPU: 0 PID: 1 at kernel/smp.c:228
>> flush_smp_call_function_queue+0xc0/0x178()
>> [1.105112] Modules linked in:
>> [1.105129] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>> 3.15.0-next-20140616-2-g38f9385a061b #2035
>> [1.105157] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [1.105179] [] (show_stack) from []
>> (dump_stack+0x8c/0x9c)
>> [1.105198] [] (dump_stack) from []
>> (warn_slowpath_common+0x70/0x8c)
>> [1.105216] [] (warn_slowpath_common) from []
>> (warn_slowpath_null+0x1c/0x24)
>> [1.105235] [] (warn_slowpath_null) from []
>> (flush_smp_call_function_queue+0xc0/0x178)
>> [1.105253] [] (flush_smp_call_function_queue) from
>> [] (hotplug_cfd+0x98/0xd8)
>> [1.105269] [] (hotplug_cfd) from []
>> (notifier_call_chain+0x44/0x84)
>> [1.105285] [] (notifier_call_chain) from []
>> (_cpu_up+0x120/0x170)
>> [1.105302] [] (_cpu_up) from [] (cpu_up+0x70/0x94)
>> [1.105319] [] (cpu_up) from [] (smp_init+0xac/0xb0)
>> [1.105337] [] (smp_init) from []
>> (kernel_init_freeable+0x90/0x1dc)
>> [1.105353] [] (kernel_init_freeable) from []
>> (kernel_init+0xc/0xe8)
>> [1.105368] [] (kernel_init) from []
>> (ret_from_fork+0x14/0x3c)
>> [1.105389] ---[ end trace bc66942e4ab63168 ]---
>
> Argh! I had put the switch-case handling for CPU_DYING at the 'wrong' place,
> since I hadn't noticed that CPU_UP_CANCELED silently falls-through to
> CPU_DEAD.
> This is what happens when people don't explicitly write "fall-through" in the
> comments in a switch-case statement :-(
>
> Below is an updated patch, please let me know how it goes. (You'll have to
> revert c47a9d7cca first, and then 56e692182, before trying this patch).
I am unable to apply your below patch on top of the above 2 reverts.
Applying: CPU hotplug, smp: Execute any pending IPI callbacks before CPU offline
fatal: corrupt patch at line 106
Patch failed at 0001 CPU hotplug, smp: Execute any pending IPI
callbacks before CPU offline
Even with 'patch' I get the below failures:
patching file kernel/smp.c
Hunk #2 FAILED at 53.
Hunk #3 FAILED at 179.
2 out of 3 hunks FAILED -- saving rejects to file kernel/smp.c.rej
Regards,
Sachin.
--
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
Boot warnings on exynos5420 based boards
Hi,
I observe the below warnings while trying to boot Exynos5420 based boards
since yesterday's linux-next (next-20140616) using multi_v7_defconfig. Looks
like it is triggered by the commit 56e6921829 ("CPU hotplug, smp:
flush any pending IPI callbacks before CPU offline"). Any ideas?
*
[0.046521] Exynos MCPM support installed
[0.048939] CPU1: Booted secondary processor
[0.065005] CPU1: update cpu_capacity 1535
[0.065011] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.065660] CPU2: Booted secondary processor
[0.085005] CPU2: update cpu_capacity 1535
[0.085012] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
[0.085662] CPU3: Booted secondary processor
[0.105005] CPU3: update cpu_capacity 1535
[0.105011] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
[1.105031] CPU4: failed to come online
[1.105081] [ cut here ]
[1.105104] WARNING: CPU: 0 PID: 1 at kernel/smp.c:228
flush_smp_call_function_queue+0xc0/0x178()
[1.105112] Modules linked in:
[1.105129] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.15.0-next-20140616-2-g38f9385a061b #2035
[1.105157] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[1.105179] [] (show_stack) from []
(dump_stack+0x8c/0x9c)
[1.105198] [] (dump_stack) from []
(warn_slowpath_common+0x70/0x8c)
[1.105216] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[1.105235] [] (warn_slowpath_null) from []
(flush_smp_call_function_queue+0xc0/0x178)
[1.105253] [] (flush_smp_call_function_queue) from
[] (hotplug_cfd+0x98/0xd8)
[1.105269] [] (hotplug_cfd) from []
(notifier_call_chain+0x44/0x84)
[1.105285] [] (notifier_call_chain) from []
(_cpu_up+0x120/0x170)
[1.105302] [] (_cpu_up) from [] (cpu_up+0x70/0x94)
[1.105319] [] (cpu_up) from [] (smp_init+0xac/0xb0)
[1.105337] [] (smp_init) from []
(kernel_init_freeable+0x90/0x1dc)
[1.105353] [] (kernel_init_freeable) from []
(kernel_init+0xc/0xe8)
[1.105368] [] (kernel_init) from []
(ret_from_fork+0x14/0x3c)
[1.105389] ---[ end trace bc66942e4ab63168 ]---
[2.105047] CPU5: failed to come online
[2.105073] [ cut here ]
[2.105091] WARNING: CPU: 0 PID: 1 at kernel/smp.c:228
flush_smp_call_function_queue+0xc0/0x178()
[2.105099] Modules linked in:
[2.105114] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.15.0-next-20140616-2-g38f9385a061b #2035
[2.105135] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[2.105153] [] (show_stack) from []
(dump_stack+0x8c/0x9c)
[2.105170] [] (dump_stack) from []
(warn_slowpath_common+0x70/0x8c)
[2.105187] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[2.105205] [] (warn_slowpath_null) from []
(flush_smp_call_function_queue+0xc0/0x178)
[2.105222] [] (flush_smp_call_function_queue) from
[] (hotplug_cfd+0x98/0xd8)
[2.105237] [] (hotplug_cfd) from []
(notifier_call_chain+0x44/0x84)
[2.105252] [] (notifier_call_chain) from []
(_cpu_up+0x120/0x170)
[2.105268] [] (_cpu_up) from [] (cpu_up+0x70/0x94)
[2.105285] [] (cpu_up) from [] (smp_init+0xac/0xb0)
[2.105301] [] (smp_init) from []
(kernel_init_freeable+0x90/0x1dc)
[2.105316] [] (kernel_init_freeable) from []
(kernel_init+0xc/0xe8)
[2.105330] [] (kernel_init) from []
(ret_from_fork+0x14/0x3c)
[2.105339] ---[ end trace bc66942e4ab63169 ]---
[3.105064] CPU6: failed to come online
[3.105089] [ cut here ]
[3.105107] WARNING: CPU: 0 PID: 1 at kernel/smp.c:228
flush_smp_call_function_queue+0xc0/0x178()
[3.105115] Modules linked in:
[3.105131] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.15.0-next-20140616-2-g38f9385a061b #2035
[3.105150] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[3.105168] [] (show_stack) from []
(dump_stack+0x8c/0x9c)
[3.105185] [] (dump_stack) from []
(warn_slowpath_common+0x70/0x8c)
[3.105202] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[3.105220] [] (warn_slowpath_null) from []
(flush_smp_call_function_queue+0xc0/0x178)
[3.105237] [] (flush_smp_call_function_queue) from
[] (hotplug_cfd+0x98/0xd8)
[3.105252] [] (hotplug_cfd) from []
(notifier_call_chain+0x44/0x84)
[3.105267] [] (notifier_call_chain) from []
(_cpu_up+0x120/0x170)
[3.105283] [] (_cpu_up) from [] (cpu_up+0x70/0x94)
[3.105299] [] (cpu_up) from [] (smp_init+0xac/0xb0)
[3.105315] [] (smp_init) from []
(kernel_init_freeable+0x90/0x1dc)
[3.105330] [] (kernel_init_freeable) from []
(kernel_init+0xc/0xe8)
[3.105344] [] (kernel_init) from []
(ret_from_fork+0x14/0x3c)
[3.105353] ---[ end trace bc66942e4ab6316a ]---
[4.105081] CPU7: failed to come online
[4.105106] [ cut here ]
[4.105124] WARNING: CPU: 0 PID: 1 at kernel/smp.c:228
flush_smp_call_function_queue+0xc0/0x178()
[4.1051
Re: [PATCH v2 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
Kukjin, On Sat, May 31, 2014 at 12:12 AM, Kukjin Kim wrote: > On 05/31/14 03:19, Andreas Färber wrote: >> >> Am 28.05.2014 06:13, schrieb Sachin Kamat: >>> >>> Almost all Exynos-series of SoCs that run in secure mode don't need >>> additional offset for every CPU, with Exynos4412 being the only >>> exception. >>> >>> Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). >>> >>> While at it, fix the coding style (space around *). >>> >>> Signed-off-by: Sachin Kamat >>> Signed-off-by: Tushar Behera >>> --- >>> arch/arm/mach-exynos/firmware.c |9 +++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> >> Fixes ODROID-XU (Exynos5410) as well - thought it had been a prereq to >> applying the 5410 patches... >> >> Tested-by: Andreas Färber >> > Andreas, thanks for your test :-) > > Sachin, How about exynos4210, 5250, 5260 and 5440?... > I need to check again, honestly I don't remember all of Exynos SoCs' > different things ;-) Then will apply into fixes for 3.16. ping.. -- Regards, Sachin. -- 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] ARM: dts: exynos4: fix pwm-cells in pwm node
Hi Jaewon,
On Thu, Jun 12, 2014 at 1:53 PM, Jaewon Kim wrote:
> pwm-cells should be 3. Third cell is optional PWM flags.
> And This flag supported by this binding is PWM_POLARITY_INVERTED
>
> Signed-off-by: Jaewon Kim
> ---
> arch/arm/boot/dts/exynos4.dtsi |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index b8ece4b..b687e53 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -548,13 +548,13 @@
> status = "disabled";
> };
>
> - pwm@139D {
> + pwm: pwm@139D {
unrelated change.
> compatible = "samsung,exynos4210-pwm";
> reg = <0x139D 0x1000>;
> interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
> clocks = <&clock CLK_PWM>;
> clock-names = "timers";
> - #pwm-cells = <2>;
> + #pwm-cells = <3>;
> status = "disabled";
> };
Otherwise looks good.
Reviewed-by: Sachin Kamat
Regards,
Sachin
--
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 2/3] spi: s3c64xx: remove a compilation warning with an assignment
Hi Naveen,
On Tue, Jun 10, 2014 at 2:30 PM, Naveen Krishna Chatradhi
wrote:
> This patch returns an integer error value instead of the
> pointer.
>
> "warning: return makes integer from pointer without a cast"
>
> Signed-off-by: Naveen Krishna Chatradhi
> Cc: Javier Martinez Canillas
> Cc: Doug Anderson
> ---
> drivers/spi/spi-s3c64xx.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 0c6013f..4594dde 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -817,7 +817,7 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
>
> if (!spi->dev.of_node) {
> dev_err(&spi->dev, "device node not found\n");
> - return ERR_PTR(-EINVAL);
> + return -EINVAL;
Isn't this warning introduced by the previous patch (patch1/3)?
If so then this patch should be squashed into that.
--
Regards,
Sachin.
--
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] serial: samsung: fix typo in debug code
Hi Arnd,
On Tue, Jun 3, 2014 at 3:23 PM, Arnd Bergmann wrote:
> commit e4ac92df2791 ("serial: samsung: Neaten dbg uses") introduced
> a regression in the conversion from vsprintf to vsnprintf.
>
> This fixes the build error by passing the correct variable name.
I submitted a similar patch sometime back.
http://www.spinics.net/lists/linux-serial/msg12843.html
Regards,
Sachin
--
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 1/1] i2c: s3c2410: Remove class based instantiation
Hi Wolfram, On Tue, Jun 3, 2014 at 3:35 PM, Wolfram Sang wrote: > On Tue, Jun 03, 2014 at 02:30:22PM +0530, Sachin Kamat wrote: >> With multiplatform support enabled for Exynos, class based >> instantiation causes a boot time delay due to I2C_CLASS_HWMON >> triggered probe. Since class based instantiation has been >> deprecated since some time now, remove it for Samsung I2C driver. >> >> Signed-off-by: Sachin Kamat >> Cc: Olof Johansson > > In my book, not long enough. I suggest I will take care of the removal. > I'll do it for all class deprecating drivers. The reason for the removal is the boot delay it is causing on Exynos 5250 based boards by throwing the following errors continuously. [ 55.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110) [ 59.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110) [ 63.005300] s3c-i2c 12ce.i2c: cannot get bus (error -110) Regards, Sachin -- 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
[PATCH 1/1] i2c: s3c2410: Remove class based instantiation
With multiplatform support enabled for Exynos, class based instantiation causes a boot time delay due to I2C_CLASS_HWMON triggered probe. Since class based instantiation has been deprecated since some time now, remove it for Samsung I2C driver. Signed-off-by: Sachin Kamat Cc: Olof Johansson --- drivers/i2c/busses/i2c-s3c2410.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index bb3a9964f7e0..6f1706cdd9ba 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -1135,7 +1135,6 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev) i2c->adap.owner = THIS_MODULE; i2c->adap.algo= &s3c24xx_i2c_algorithm; i2c->adap.retries = 2; - i2c->adap.class = I2C_CLASS_HWMON | I2C_CLASS_SPD | I2C_CLASS_DEPRECATED; i2c->tx_setup = 50; init_waitqueue_head(&i2c->wait); -- 1.7.9.5 -- 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] arm: exynos: Fix "allmodconfig" build errors in mcpm and hotplug
+ Olof On 26 May 2014 12:19, Sachin Kamat wrote: > Thanks Abhilash. > > On 26 May 2014 11:24, Abhilash Kesavan wrote: >> This fixes the following build errors: >> >> /tmp/ccRbZlaA.s: Assembler messages: >> /tmp/ccRbZlaA.s:69: Error: selected processor does not support ARM mode `isb >> ' >> /tmp/ccRbZlaA.s:75: Error: selected processor does not support ARM mode `isb >> ' >> /tmp/ccRbZlaA.s:76: Error: selected processor does not support ARM mode `dsb >> ' >> make[1]: *** [arch/arm/mach-exynos/hotplug.o] Error 1 >> >> /tmp/ccJEg4jw.s: Assembler messages: >> /tmp/ccJEg4jw.s:454: Error: selected processor does not support ARM mode >> `isb' >> /tmp/ccJEg4jw.s:455: Error: selected processor does not support ARM mode >> `dsb' >> /tmp/ccJEg4jw.s:465: Error: selected processor does not support ARM mode >> `isb' >> /tmp/ccJEg4jw.s:474: Error: selected processor does not support ARM mode >> `isb' >> /tmp/ccJEg4jw.s:475: Error: selected processor does not support ARM mode >> `dsb' >> /tmp/ccJEg4jw.s:516: Error: selected processor does not support ARM mode >> `isb' >> /tmp/ccJEg4jw.s:525: Error: selected processor does not support ARM mode >> `isb' >> /tmp/ccJEg4jw.s:526: Error: selected processor does not support ARM mode >> `dsb' >> make[1]: *** [arch/arm/mach-exynos/mcpm-exynos.o] Error 1 >> >> Reported-by: Sachin Kamat >> Signed-off-by: Abhilash Kesavan > > This patch fixes the above reported issues. > > Tested-by: Sachin Kamat Kukjin, This patch is also needed to fix the reported build error. -- With warm regards, Sachin -- 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 1/1] clk: exynos5420: Staticize local variables
Hi Tomasz,
On 28 May 2014 16:32, Tomasz Figa wrote:
> Hi Sachin,
>
> On 28.05.2014 10:01, Sachin Kamat wrote:
>> On 21 May 2014 17:28, Sachin Kamat wrote:
>>> Local symbols are made static.
>>>
>>> Signed-off-by: Sachin Kamat
>>> ---
>>> drivers/clk/samsung/clk-exynos5420.c | 10 +-
>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>>> b/drivers/clk/samsung/clk-exynos5420.c
>>> index 9d7d7eed03fd..41b507baf5d6 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -474,7 +474,7 @@ static struct samsung_fixed_factor_clock
>>> FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
>>> };
>>>
>>> -struct samsung_mux_clock exynos5800_mux_clks[] __initdata = {
>>> +static struct samsung_mux_clock exynos5800_mux_clks[] __initdata = {
>>> MUX(0, "mout_aclk400_isp", mout_group3_5800_p, SRC_TOP0, 0, 3),
>>> MUX(0, "mout_aclk400_mscl", mout_group3_5800_p, SRC_TOP0, 4, 3),
>>> MUX(0, "mout_aclk400_wcore", mout_group2_5800_p, SRC_TOP0, 16, 3),
>>> @@ -523,7 +523,7 @@ struct samsung_mux_clock exynos5800_mux_clks[]
>>> __initdata = {
>>> MUX(0, "mout_fimd1", mout_group2_p, SRC_DISP10, 4, 3),
>>> };
>>>
>>> -struct samsung_div_clock exynos5800_div_clks[] __initdata = {
>>> +static struct samsung_div_clock exynos5800_div_clks[] __initdata = {
>>> DIV(0, "dout_aclk400_wcore", "mout_aclk400_wcore", DIV_TOP0, 16, 3),
>>>
>>> DIV(0, "dout_aclk550_cam", "mout_aclk550_cam",
>>> @@ -539,14 +539,14 @@ struct samsung_div_clock exynos5800_div_clks[]
>>> __initdata = {
>>> DIV(0, "dout_sclk_sw", "sclk_spll", DIV_TOP9, 24, 6),
>>> };
>>>
>>> -struct samsung_gate_clock exynos5800_gate_clks[] __initdata = {
>>> +static struct samsung_gate_clock exynos5800_gate_clks[] __initdata = {
>>> GATE(CLK_ACLK550_CAM, "aclk550_cam", "mout_user_aclk550_cam",
>>> GATE_BUS_TOP, 24, 0, 0),
>>> GATE(CLK_ACLK432_SCALER, "aclk432_scaler",
>>> "mout_user_aclk432_scaler",
>>> GATE_BUS_TOP, 27, 0, 0),
>>> };
>>>
>>> -struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
>>> +static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
>>> MUX(0, "sclk_bpll", mout_bpll_p, TOP_SPARE2, 0, 1),
>>> MUX(0, "mout_aclk400_wcore_bpll", mout_aclk400_wcore_bpll_p,
>>> TOP_SPARE2, 4, 1),
>>> @@ -576,7 +576,7 @@ struct samsung_mux_clock exynos5420_mux_clks[]
>>> __initdata = {
>>> MUX(0, "mout_fimd1", mout_group3_p, SRC_DISP10, 4, 1),
>>> };
>>>
>>> -struct samsung_div_clock exynos5420_div_clks[] __initdata = {
>>> +static struct samsung_div_clock exynos5420_div_clks[] __initdata = {
>>> DIV(0, "dout_aclk400_wcore", "mout_aclk400_wcore_bpll",
>>> DIV_TOP0, 16, 3),
>>> };
>>> --
>>
>> Mike,
>>
>> Tomasz is probably on vacation. Can you please take this patch?
>>
>
> Sorry for late reply. Yes, I'm on vacation right now until 9.06, so I'm
> going to be less active through this period of time.
No worries.
> As for this patch, I'm not sure if it will apply to Mike's tree, as it
> seems to depend on patches that went through Kukjin's tree. Since this
> isn't anything critical, I'd suggest deferring this for next release, so
> I can pick this patch up directly after 3.16-rc1 is released.
>
> In case you want to proceed with it now, feel free to add my Acked-by.
Thanks Tomasz.
Kukjin,
If you still can take it, please do so with Tomasz's ack. Else he will handle it
after the merge window.
--
With warm regards,
Sachin
--
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
[PATCH 1/1] PCI: exynos: Fix section mismatch warning
add_pcie_port is called from probe which is annotated with __init.
add_pcie_port calls dw_pcie_host_init which is also annotated with
__init. Thus it makes sense to annotate add_pcie_port with __init
to avoid the following section mismatch warning:
WARNING: drivers/pci/built-in.o(.text.unlikely+0xf8): Section mismatch in
reference from the function add_pcie_port() to the function
.init.text:dw_pcie_host_init()
The function add_pcie_port() references
the function __init dw_pcie_host_init().
This is often because add_pcie_port lacks a __init
annotation or the annotation of dw_pcie_host_init is wrong.
Reported-by: kbuild test robot
Signed-off-by: Sachin Kamat
---
drivers/pci/host/pci-exynos.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 3de6bfbbe8e9..3c1ff89829ec 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -511,7 +511,8 @@ static struct pcie_host_ops exynos_pcie_host_ops = {
.host_init = exynos_pcie_host_init,
};
-static int add_pcie_port(struct pcie_port *pp, struct platform_device *pdev)
+static int __init add_pcie_port(struct pcie_port *pp,
+ struct platform_device *pdev)
{
int ret;
--
1.7.9.5
--
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 1/1] clk: exynos5420: Staticize local variables
On 21 May 2014 17:28, Sachin Kamat wrote:
> Local symbols are made static.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/clk/samsung/clk-exynos5420.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 9d7d7eed03fd..41b507baf5d6 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -474,7 +474,7 @@ static struct samsung_fixed_factor_clock
> FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
> };
>
> -struct samsung_mux_clock exynos5800_mux_clks[] __initdata = {
> +static struct samsung_mux_clock exynos5800_mux_clks[] __initdata = {
> MUX(0, "mout_aclk400_isp", mout_group3_5800_p, SRC_TOP0, 0, 3),
> MUX(0, "mout_aclk400_mscl", mout_group3_5800_p, SRC_TOP0, 4, 3),
> MUX(0, "mout_aclk400_wcore", mout_group2_5800_p, SRC_TOP0, 16, 3),
> @@ -523,7 +523,7 @@ struct samsung_mux_clock exynos5800_mux_clks[] __initdata
> = {
> MUX(0, "mout_fimd1", mout_group2_p, SRC_DISP10, 4, 3),
> };
>
> -struct samsung_div_clock exynos5800_div_clks[] __initdata = {
> +static struct samsung_div_clock exynos5800_div_clks[] __initdata = {
> DIV(0, "dout_aclk400_wcore", "mout_aclk400_wcore", DIV_TOP0, 16, 3),
>
> DIV(0, "dout_aclk550_cam", "mout_aclk550_cam",
> @@ -539,14 +539,14 @@ struct samsung_div_clock exynos5800_div_clks[]
> __initdata = {
> DIV(0, "dout_sclk_sw", "sclk_spll", DIV_TOP9, 24, 6),
> };
>
> -struct samsung_gate_clock exynos5800_gate_clks[] __initdata = {
> +static struct samsung_gate_clock exynos5800_gate_clks[] __initdata = {
> GATE(CLK_ACLK550_CAM, "aclk550_cam", "mout_user_aclk550_cam",
> GATE_BUS_TOP, 24, 0, 0),
> GATE(CLK_ACLK432_SCALER, "aclk432_scaler", "mout_user_aclk432_scaler",
> GATE_BUS_TOP, 27, 0, 0),
> };
>
> -struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
> +static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
> MUX(0, "sclk_bpll", mout_bpll_p, TOP_SPARE2, 0, 1),
> MUX(0, "mout_aclk400_wcore_bpll", mout_aclk400_wcore_bpll_p,
> TOP_SPARE2, 4, 1),
> @@ -576,7 +576,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata
> = {
> MUX(0, "mout_fimd1", mout_group3_p, SRC_DISP10, 4, 1),
> };
>
> -struct samsung_div_clock exynos5420_div_clks[] __initdata = {
> +static struct samsung_div_clock exynos5420_div_clks[] __initdata = {
> DIV(0, "dout_aclk400_wcore", "mout_aclk400_wcore_bpll",
> DIV_TOP0, 16, 3),
> };
> --
Mike,
Tomasz is probably on vacation. Can you please take this patch?
--
With warm regards,
Sachin
--
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 1/5] ARM: dts: Enable RTC node on Origen boards
On 28 May 2014 09:23, Sachin Kamat wrote:
> Hi Kukjin,
>
> On 27 May 2014 21:09, Kukjin Kim wrote:
>> On 05/26/14 12:29, Sachin Kamat wrote:
>>>
>>> On 23 May 2014 11:38, Sachin Kamat wrote:
>>>>
>>>> Enabled RTC node on Origen 4210 and 4412 boards.
>>>>
>>>> Signed-off-by: Sachin Kamat
>>>> ---
>>>> arch/arm/boot/dts/exynos4210-origen.dts |4
>>>> arch/arm/boot/dts/exynos4412-origen.dts |4
>>>> 2 files changed, 8 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
>>>> b/arch/arm/boot/dts/exynos4210-origen.dts
>>>> index 72fb11f7ea21..95efb1189cf0 100644
>>>> --- a/arch/arm/boot/dts/exynos4210-origen.dts
>>>> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
>>>> @@ -48,6 +48,10 @@
>>>> };
>>>> };
>>>>
>>>> + rtc@1007 {
>>>> + status = "okay";
>>>> + };
>>>> +
>>>> tmu@100C {
>>>> status = "okay";
>>>> };
>>>> diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
>>>> b/arch/arm/boot/dts/exynos4412-origen.dts
>>>> index e2c0dcab4d81..934fe7ecca7e 100644
>>>> --- a/arch/arm/boot/dts/exynos4412-origen.dts
>>>> +++ b/arch/arm/boot/dts/exynos4412-origen.dts
>>>> @@ -48,6 +48,10 @@
>>>> };
>>>> };
>>>>
>>>> + rtc@1007 {
>>>> + status = "okay";
>>>> + };
>>>> +
>>>> pinctrl@1100 {
>>>> keypad_rows: keypad-rows {
>>>> samsung,pins = "gpx2-0", "gpx2-1", "gpx2-2";
>>>> --
>>>> 1.7.9.5
>>>>
>>>
>>> Kukjin,
>>>
>>> The patches in this series are really simple and do not want them to
>>> wait for another
>>> cycle. Please review and send them with your next pull request for
>>> 3.16. Also please
>>> look at the 2 patches related to secondary cpu boot sent by Tushar.
>>>
>> Applied, but I'm not sure this can be sent to upstream in this time, I will
>> try to do it though ;-) Because already queued a bunch of exynos stuff for
>> arm-soc and this is not really critical at this moment?...
>
> Thanks for applying. These patches are not critical. However there are 2 more
> patches posted by Tushar which are critical (have already sent pings for that,
> will send once again separately for your reference). You may send these
> patches
> along with those.
>
> [PATCH V2 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
> http://www.spinics.net/lists/linux-samsung-soc/msg31258.html
>
> [PATCH RESEND 2/2] ARM: dts: Add secure firmware support for Arndale-octa
> http://www.spinics.net/lists/linux-samsung-soc/msg31259.html
Re-sent both the above patches once again after rebasing on your
latest for-next branch.
--
With warm regards,
Sachin
--
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
[PATCH v2 Resend 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
Almost all Exynos-series of SoCs that run in secure mode don't need additional offset for every CPU, with Exynos4412 being the only exception. Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). While at it, fix the coding style (space around *). Signed-off-by: Sachin Kamat Signed-off-by: Tushar Behera --- arch/arm/mach-exynos/firmware.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c index eb91d2350f8c..e8797bb78871 100644 --- a/arch/arm/mach-exynos/firmware.c +++ b/arch/arm/mach-exynos/firmware.c @@ -57,8 +57,13 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr) boot_reg = sysram_ns_base_addr + 0x1c; - if (!soc_is_exynos4212() && !soc_is_exynos3250()) - boot_reg += 4*cpu; + /* +* Almost all Exynos-series of SoCs that run in secure mode don't need +* additional offset for every CPU, with Exynos4412 being the only +* exception. +*/ + if (soc_is_exynos4412()) + boot_reg += 4 * cpu; __raw_writel(boot_addr, boot_reg); return 0; -- 1.7.9.5 -- 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
[PATCH v2 Resend 2/2] ARM: dts: Add secure firmware support for Arndale-octa
From: Tushar Behera
Arndale-Octa board is always configured to work with trustzone
firmware binary. Added DTS node entry to enable this support.
Signed-off-by: Tushar Behera
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 6ee8149fd5c4..434fd9d3e09d 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -26,6 +26,11 @@
bootargs = "console=ttySAC3,115200";
};
+ firmware@02073000 {
+ compatible = "samsung,secure-firmware";
+ reg = <0x02073000 0x1000>;
+ };
+
fixed-rate-clocks {
oscclk {
compatible = "samsung,exynos5420-oscclk";
--
1.7.9.5
--
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 1/5] ARM: dts: Enable RTC node on Origen boards
Hi Kukjin,
On 27 May 2014 21:09, Kukjin Kim wrote:
> On 05/26/14 12:29, Sachin Kamat wrote:
>>
>> On 23 May 2014 11:38, Sachin Kamat wrote:
>>>
>>> Enabled RTC node on Origen 4210 and 4412 boards.
>>>
>>> Signed-off-by: Sachin Kamat
>>> ---
>>> arch/arm/boot/dts/exynos4210-origen.dts |4
>>> arch/arm/boot/dts/exynos4412-origen.dts |4
>>> 2 files changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
>>> b/arch/arm/boot/dts/exynos4210-origen.dts
>>> index 72fb11f7ea21..95efb1189cf0 100644
>>> --- a/arch/arm/boot/dts/exynos4210-origen.dts
>>> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
>>> @@ -48,6 +48,10 @@
>>> };
>>> };
>>>
>>> + rtc@1007 {
>>> + status = "okay";
>>> + };
>>> +
>>> tmu@100C {
>>> status = "okay";
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
>>> b/arch/arm/boot/dts/exynos4412-origen.dts
>>> index e2c0dcab4d81..934fe7ecca7e 100644
>>> --- a/arch/arm/boot/dts/exynos4412-origen.dts
>>> +++ b/arch/arm/boot/dts/exynos4412-origen.dts
>>> @@ -48,6 +48,10 @@
>>> };
>>> };
>>>
>>> + rtc@1007 {
>>> + status = "okay";
>>> + };
>>> +
>>> pinctrl@1100 {
>>> keypad_rows: keypad-rows {
>>> samsung,pins = "gpx2-0", "gpx2-1", "gpx2-2";
>>> --
>>> 1.7.9.5
>>>
>>
>> Kukjin,
>>
>> The patches in this series are really simple and do not want them to
>> wait for another
>> cycle. Please review and send them with your next pull request for
>> 3.16. Also please
>> look at the 2 patches related to secondary cpu boot sent by Tushar.
>>
> Applied, but I'm not sure this can be sent to upstream in this time, I will
> try to do it though ;-) Because already queued a bunch of exynos stuff for
> arm-soc and this is not really critical at this moment?...
Thanks for applying. These patches are not critical. However there are 2 more
patches posted by Tushar which are critical (have already sent pings for that,
will send once again separately for your reference). You may send these patches
along with those.
[PATCH V2 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
http://www.spinics.net/lists/linux-samsung-soc/msg31258.html
[PATCH RESEND 2/2] ARM: dts: Add secure firmware support for Arndale-octa
http://www.spinics.net/lists/linux-samsung-soc/msg31259.html
--
With warm regards,
Sachin
--
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] arm: exynos: Fix "allmodconfig" build errors in mcpm and hotplug
Thanks Abhilash. On 26 May 2014 11:24, Abhilash Kesavan wrote: > This fixes the following build errors: > > /tmp/ccRbZlaA.s: Assembler messages: > /tmp/ccRbZlaA.s:69: Error: selected processor does not support ARM mode `isb ' > /tmp/ccRbZlaA.s:75: Error: selected processor does not support ARM mode `isb ' > /tmp/ccRbZlaA.s:76: Error: selected processor does not support ARM mode `dsb ' > make[1]: *** [arch/arm/mach-exynos/hotplug.o] Error 1 > > /tmp/ccJEg4jw.s: Assembler messages: > /tmp/ccJEg4jw.s:454: Error: selected processor does not support ARM mode `isb' > /tmp/ccJEg4jw.s:455: Error: selected processor does not support ARM mode `dsb' > /tmp/ccJEg4jw.s:465: Error: selected processor does not support ARM mode `isb' > /tmp/ccJEg4jw.s:474: Error: selected processor does not support ARM mode `isb' > /tmp/ccJEg4jw.s:475: Error: selected processor does not support ARM mode `dsb' > /tmp/ccJEg4jw.s:516: Error: selected processor does not support ARM mode `isb' > /tmp/ccJEg4jw.s:525: Error: selected processor does not support ARM mode `isb' > /tmp/ccJEg4jw.s:526: Error: selected processor does not support ARM mode `dsb' > make[1]: *** [arch/arm/mach-exynos/mcpm-exynos.o] Error 1 > > Reported-by: Sachin Kamat > Signed-off-by: Abhilash Kesavan This patch fixes the above reported issues. Tested-by: Sachin Kamat -- With warm regards, Sachin -- 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
[PATCH 1/1] clk/exynos4: Fix compilation warning
Fixes the following warning:
WARNING: drivers/built-in.o(.text.unlikely+0x2c50): Section mismatch in
reference from the function exynos4_clk_sleep_init() to the (unknown reference)
.init.data:(unknown)
The function exynos4_clk_sleep_init() references
the (unknown reference) __initdata (unknown).
This is often because exynos4_clk_sleep_init lacks a __initdata
annotation or the annotation of (unknown) is wrong.
Signed-off-by: Sachin Kamat
Reported-by: kbuild test robot
---
drivers/clk/samsung/clk-exynos4.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index c4df294bb7fb..4f150c9dd38c 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -324,7 +324,7 @@ static struct syscore_ops exynos4_clk_syscore_ops = {
.resume = exynos4_clk_resume,
};
-static void exynos4_clk_sleep_init(void)
+static void __init exynos4_clk_sleep_init(void)
{
exynos4_save_common = samsung_clk_alloc_reg_dump(exynos4_clk_regs,
ARRAY_SIZE(exynos4_clk_regs));
@@ -359,7 +359,7 @@ err_warn:
__func__);
}
#else
-static void exynos4_clk_sleep_init(void) {}
+static void __init exynos4_clk_sleep_init(void) {}
#endif
/* list of all parent clock list */
--
1.7.9.5
--
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 1/1] clk: exynos5420: Staticize local variables
On 21 May 2014 17:28, Sachin Kamat wrote:
> Local symbols are made static.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/clk/samsung/clk-exynos5420.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 9d7d7eed03fd..41b507baf5d6 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -474,7 +474,7 @@ static struct samsung_fixed_factor_clock
> FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
> };
>
> -struct samsung_mux_clock exynos5800_mux_clks[] __initdata = {
> +static struct samsung_mux_clock exynos5800_mux_clks[] __initdata = {
> MUX(0, "mout_aclk400_isp", mout_group3_5800_p, SRC_TOP0, 0, 3),
> MUX(0, "mout_aclk400_mscl", mout_group3_5800_p, SRC_TOP0, 4, 3),
> MUX(0, "mout_aclk400_wcore", mout_group2_5800_p, SRC_TOP0, 16, 3),
> @@ -523,7 +523,7 @@ struct samsung_mux_clock exynos5800_mux_clks[] __initdata
> = {
> MUX(0, "mout_fimd1", mout_group2_p, SRC_DISP10, 4, 3),
> };
>
> -struct samsung_div_clock exynos5800_div_clks[] __initdata = {
> +static struct samsung_div_clock exynos5800_div_clks[] __initdata = {
> DIV(0, "dout_aclk400_wcore", "mout_aclk400_wcore", DIV_TOP0, 16, 3),
>
> DIV(0, "dout_aclk550_cam", "mout_aclk550_cam",
> @@ -539,14 +539,14 @@ struct samsung_div_clock exynos5800_div_clks[]
> __initdata = {
> DIV(0, "dout_sclk_sw", "sclk_spll", DIV_TOP9, 24, 6),
> };
>
> -struct samsung_gate_clock exynos5800_gate_clks[] __initdata = {
> +static struct samsung_gate_clock exynos5800_gate_clks[] __initdata = {
> GATE(CLK_ACLK550_CAM, "aclk550_cam", "mout_user_aclk550_cam",
> GATE_BUS_TOP, 24, 0, 0),
> GATE(CLK_ACLK432_SCALER, "aclk432_scaler", "mout_user_aclk432_scaler",
> GATE_BUS_TOP, 27, 0, 0),
> };
>
> -struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
> +static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
> MUX(0, "sclk_bpll", mout_bpll_p, TOP_SPARE2, 0, 1),
> MUX(0, "mout_aclk400_wcore_bpll", mout_aclk400_wcore_bpll_p,
> TOP_SPARE2, 4, 1),
> @@ -576,7 +576,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata
> = {
> MUX(0, "mout_fimd1", mout_group3_p, SRC_DISP10, 4, 1),
> };
>
> -struct samsung_div_clock exynos5420_div_clks[] __initdata = {
> +static struct samsung_div_clock exynos5420_div_clks[] __initdata = {
> DIV(0, "dout_aclk400_wcore", "mout_aclk400_wcore_bpll",
> DIV_TOP0, 16, 3),
> };
> --
> 1.7.9.5
>
Gentle ping, Tomasz :)
--
With warm regards,
Sachin
--
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 1/5] ARM: dts: Enable RTC node on Origen boards
On 23 May 2014 11:38, Sachin Kamat wrote:
> Enabled RTC node on Origen 4210 and 4412 boards.
>
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/boot/dts/exynos4210-origen.dts |4
> arch/arm/boot/dts/exynos4412-origen.dts |4
> 2 files changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
> b/arch/arm/boot/dts/exynos4210-origen.dts
> index 72fb11f7ea21..95efb1189cf0 100644
> --- a/arch/arm/boot/dts/exynos4210-origen.dts
> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> @@ -48,6 +48,10 @@
> };
> };
>
> + rtc@1007 {
> + status = "okay";
> + };
> +
> tmu@100C {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
> b/arch/arm/boot/dts/exynos4412-origen.dts
> index e2c0dcab4d81..934fe7ecca7e 100644
> --- a/arch/arm/boot/dts/exynos4412-origen.dts
> +++ b/arch/arm/boot/dts/exynos4412-origen.dts
> @@ -48,6 +48,10 @@
> };
> };
>
> + rtc@1007 {
> + status = "okay";
> + };
> +
> pinctrl@1100 {
> keypad_rows: keypad-rows {
> samsung,pins = "gpx2-0", "gpx2-1", "gpx2-2";
> --
> 1.7.9.5
>
Kukjin,
The patches in this series are really simple and do not want them to
wait for another
cycle. Please review and send them with your next pull request for
3.16. Also please
look at the 2 patches related to secondary cpu boot sent by Tushar.
--
With warm regards,
Sachin
--
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 V5 00/20] ARM: exynos: cpuidle: Move the driver to drivers/cpuidle
On 24 May 2014 03:01, Tomasz Figa wrote: > Hi Daniel, > > On 23.05.2014 17:32, Daniel Lezcano wrote: >> On 05/22/2014 08:35 PM, Kukjin Kim wrote: >>> On 04/26/14 20:05, Kukjin Kim wrote: >>>> Tomasz Figa wrote: >>>>> >>>>> On 14.04.2014 11:01, Daniel Lezcano wrote: >>>>>> >>>>>> Hi Kukjin, >>>>>> >>>>>> I believe I addressed all the comments. Is it possible to take this >>>>>> patchset for next ? >>>>> >>>> Sure ;-) >>>> >>>>> +1. >>>>> >>>>> Also when applying you might add >>>>> >>>>> Reviewed-by: Tomasz Figa >>>>> >>>>> to any patches that don't have it yet. >>>>> >>>> Tomasz, thanks for your review. >>>> >>>> I will take this series, "moving exynos-cpuidle into drivers/cpuidle" >>>> into samsung tree if Rafael is OK on that. >>>> >>> Daniel, >>> >>> Can you please check/test the functionality your series with using my >>> for-next because there were merge conflicts with mcpm-exynos stuff...? >> >> Hi Kukjin, >> >> I tested the latest tree. Unfortunately it panics when unplugging cpu1: >> >> [3.124189] Unable to handle kernel paging request at virtual address >> f8400024 >> [3.129950] pgd = c0004000 >> [3.132626] [f8400024] *pgd=6f7f7841, *pte=, *ppte= >> [3.138877] Internal error: Oops: 827 [#1] PREEMPT SMP ARM >> [3.192782] r3 : f8400024 r2 : f8180800 r1 : ee836e44 r0 : f8400024 >> [3.199293] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM >> Segment kernel >> [3.206673] Control: 10c5387d Table: 6e37c04a DAC: 0015 >> [3.212398] Process swapper/0 (pid: 0, stack limit = 0xc0510240) >> [3.218388] Stack: (0xc0511ef4 to 0xc0512000) >> [3.222728] 1ee0: 0030 c02b20f8 ee836e40 >> [3.230894] 1f00: c001234c 6e88 c0511f34 40018a80 >> 0015 >> [3.239053] 1f20: 4000404a 10c5387d 0041 00f0 >> c02b20e4 edc4a540 >> [3.247212] 1f40: c038dacc eefc5cf8 c050ecf0 c0543210 >> c0012460 0001 c0543210 >> [3.255371] 1f60: eefc5cf8 c02b2148 b9f92927 c054326c >> c02b0968 b9f92927 >> [3.263530] 1f80: c051 c0518480 c038dacc c051 c051 >> c0518480 c038dacc eefc5cf8 >> [3.271689] 1fa0: c0543210 c004e990 c0511fb4 c03873b8 >> c04f90c8 c04d4b18 >> [3.279848] 1fc0: c04d457c 0000 >> c04f90c8 10c5387d >> [3.288007] 1fe0: c0518410 c04f90c4 c051bd5c 4000406a >> 40008074 >> [3.296184] [] (exynos_enter_aftr) from [] >> (idle_finisher+0x14/0x20) >> [3.304247] [] (idle_finisher) from [] >> (cpu_suspend_abort+0x0/0x14) >> [3.312226] [] (cpu_suspend_abort) from [<>] ( >> (null)) >> [3.318994] Code: e34f3840 e3500010 11a2 01a3 (e5804000) >> [3.325069] ---[ end trace fca911f75a18c040 ]--- >> >> >> After git bisecting I falls on this commit: >> >> commit b3205dea8fbf6db9b1e46a0dad19a0712fdff44f >> Author: Sachin Kamat >> Date: Tue May 13 07:13:44 2014 +0900 >> >> ARM: EXYNOS: Map SYSRAM through generic DT bindings >> >> Instead of hardcoding the SYSRAM details for each SoC, >> pass this information through device tree (DT) and make >> the code SoC agnostic. Generic DT SRAM bindings are >> used for achieving this. >> >> Signed-off-by: Sachin Kamat >> Acked-by: Arnd Bergmann >> Acked-by: Heiko Stuebner >> Reviewed-by: Tomasz Figa >> Signed-off-by: Kukjin Kim >> >> >> ... which is before my series is applied. >> >> So I am not able to tell yet if my series is correctly rebased or not. >> >> And before someone asks me, yes I updated the dtb :) > > The driver seemed to be working fine for me on Exynos4210-TRATS board > (with right bootloader, which supports AFTR). > > Still, a quick look at the code reveals use of S5P_VA_SYSRAM macro, in > case of certain SoC revisions, which is not valid any longer, after > SYSRAM started to be mapped dynamically. As you can see in platsmp.c, > the new dynamic mapping is stored in sysram_base_addr variable, which is > static right now. > > My proposed fix would be to make it non-static, declare it in one of > existing private headers (common.h probably) and use it in pm.c instead > of S5P_VA_SYSRAM. Yes, that is right. Just like the way it is done for sysram_ns_base_addr in common.h -- With warm regards, Sachin -- 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 1/2] ARM: EXYNOS: Update secondary boot addr for secure mode
On 20 May 2014 09:20, Tushar Behera wrote: > From: Sachin Kamat > > Almost all Exynos-series of SoCs that run in secure mode don't need > additional offset for every CPU, with Exynos4412 being the only > exception. > > Tested on Origen-Quad (Exynos4412) and Arndale-Octa (Exynos5420). > > While at it, fix the coding style (space around *). > > Signed-off-by: Sachin Kamat > Signed-off-by: Tushar Behera > --- > Changes for V2: > * Changed the condition statement as per review comment > * Fixed coding style > > arch/arm/mach-exynos/firmware.c |9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c > index 739bdc8..7d18103 100644 > --- a/arch/arm/mach-exynos/firmware.c > +++ b/arch/arm/mach-exynos/firmware.c > @@ -50,8 +50,13 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long > boot_addr) > > boot_reg = sysram_ns_base_addr + 0x1c; > > - if (!soc_is_exynos4212()) > - boot_reg += 4*cpu; > + /* > +* Almost all Exynos-series of SoCs that run in secure mode don't need > +* additional offset for every CPU, with Exynos4412 being the only > +* exception. > +*/ > + if (soc_is_exynos4412()) > + boot_reg += 4 * cpu; > > __raw_writel(boot_addr, boot_reg); > return 0; > -- > 1.7.9.5 > Kukjin, This series is required for properly booting A15 cores on Arndale octa. Please apply them. -- With warm regards, Sachin -- 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
[PATCH v2 3/3] ARM: multi_v7_defconfig: Enable Exynos platform
Enable Exynos platform and its related IPs. Signed-off-by: Sachin Kamat --- No changes since v1. --- arch/arm/configs/multi_v7_defconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 6a27f90ab7bc..bbdcadf642b6 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -48,6 +48,7 @@ CONFIG_ARCH_SPEAR13XX=y CONFIG_MACH_SPEAR1310=y CONFIG_MACH_SPEAR1340=y CONFIG_ARCH_STI=y +CONFIG_ARCH_EXYNOS=y CONFIG_ARCH_SUNXI=y CONFIG_ARCH_SIRF=y CONFIG_ARCH_TEGRA=y @@ -72,6 +73,7 @@ CONFIG_PCI_MSI=y CONFIG_PCI_MVEBU=y CONFIG_PCI_TEGRA=y CONFIG_SMP=y +CONFIG_NR_CPUS=8 CONFIG_HIGHPTE=y CONFIG_CMA=y CONFIG_ARM_APPENDED_DTB=y @@ -160,6 +162,8 @@ CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +CONFIG_SERIAL_SAMSUNG=y +CONFIG_SERIAL_SAMSUNG_CONSOLE=y CONFIG_SERIAL_SIRFSOC=y CONFIG_SERIAL_SIRFSOC_CONSOLE=y CONFIG_SERIAL_TEGRA=y @@ -183,6 +187,7 @@ CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PCA954x=y CONFIG_I2C_MUX_PINCTRL=y CONFIG_I2C_DESIGNWARE_PLATFORM=y +CONFIG_I2C_EXYNOS5=y CONFIG_I2C_MV64XXX=y CONFIG_I2C_SIRF=y CONFIG_I2C_TEGRA=y @@ -218,6 +223,7 @@ CONFIG_MFD_AS3722=y CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_SPI=y CONFIG_MFD_MAX8907=y +CONFIG_MFD_SEC_CORE=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS6586X=y @@ -228,6 +234,8 @@ CONFIG_REGULATOR_AS3722=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_PALMAS=y +CONFIG_REGULATOR_S2MPS11=y +CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS51632=y CONFIG_REGULATOR_TPS62360=y CONFIG_REGULATOR_TPS65090=y @@ -284,12 +292,16 @@ CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ESDHC_IMX=y CONFIG_MMC_SDHCI_PXAV3=y CONFIG_MMC_SDHCI_TEGRA=y +CONFIG_MMC_SDHCI_S3C=y CONFIG_MMC_SDHCI_DOVE=y CONFIG_MMC_SDHCI_SPEAR=y +CONFIG_MMC_SDHCI_S3C_DMA=y CONFIG_MMC_SDHCI_BCM_KONA=y CONFIG_MMC_OMAP=y CONFIG_MMC_OMAP_HS=y CONFIG_MMC_MVSDIO=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_EXYNOS=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_HIGHBANK_MC=y -- 1.7.9.5 -- 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
[PATCH v2 1/3] ARM: EXYNOS: Consolidate Kconfig entries
Instead of repeating the Kconfig entries for every SoC, move them under ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under ARCH_EXYNOS. Signed-off-by: Sachin Kamat --- No changes since v1 --- arch/arm/Kconfig | 10 ++ arch/arm/mach-exynos/Kconfig | 45 -- 2 files changed, 14 insertions(+), 41 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index eae853bb7ee5..b8d47ca91406 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -832,18 +832,28 @@ config ARCH_S5PV210 config ARCH_EXYNOS bool "Samsung EXYNOS" + select ARCH_HAS_BANDGAP select ARCH_HAS_CPUFREQ select ARCH_HAS_HOLES_MEMORYMODEL select ARCH_REQUIRE_GPIOLIB select ARCH_SPARSEMEM_ENABLE + select ARM_AMBA select ARM_GIC + select CLKSRC_OF select COMMON_CLK_SAMSUNG select CPU_V7 select GENERIC_CLOCKEVENTS + select HAVE_ARM_SCU if SMP select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS + select HAVE_SMP select NEED_MACH_MEMORY_H + select PINCTRL + select PINCTRL_EXYNOS + select PM_GENERIC_DOMAINS if PM_RUNTIME + select S5P_DEV_MFC + select SAMSUNG_DMADEV select SPARSE_IRQ select SRAM select USE_OF diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 1602abce6ec0..138070e42aa9 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -14,30 +14,20 @@ menu "SAMSUNG EXYNOS SoCs Support" config ARCH_EXYNOS4 bool "SAMSUNG EXYNOS4" default y - select ARM_AMBA - select CLKSRC_OF + select ARM_CPU_SUSPEND if PM_SLEEP select CLKSRC_SAMSUNG_PWM if CPU_EXYNOS4210 select CPU_EXYNOS4210 select GIC_NON_BANKED select KEYBOARD_SAMSUNG if INPUT_KEYBOARD - select HAVE_ARM_SCU if SMP - select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 - select PINCTRL - select PM_GENERIC_DOMAINS if PM_RUNTIME - select S5P_DEV_MFC help - Samsung EXYNOS4 SoCs based systems + Samsung EXYNOS4 (Cortex-A9) SoC based systems config ARCH_EXYNOS5 bool "SAMSUNG EXYNOS5" - select ARM_AMBA - select CLKSRC_OF - select HAVE_ARM_SCU if SMP - select HAVE_SMP - select PINCTRL + default y help - Samsung EXYNOS5 (Cortex-A15) SoC based systems + Samsung EXYNOS5 (Cortex-A15/A7) SoC based systems comment "EXYNOS SoCs" @@ -45,59 +35,32 @@ config CPU_EXYNOS4210 bool "SAMSUNG EXYNOS4210" default y depends on ARCH_EXYNOS4 - select ARCH_HAS_BANDGAP - select ARM_CPU_SUSPEND if PM_SLEEP - select PINCTRL_EXYNOS - select SAMSUNG_DMADEV - help - Enable EXYNOS4210 CPU support config SOC_EXYNOS4212 bool "SAMSUNG EXYNOS4212" default y depends on ARCH_EXYNOS4 - select ARCH_HAS_BANDGAP - select PINCTRL_EXYNOS - select SAMSUNG_DMADEV - help - Enable EXYNOS4212 SoC support config SOC_EXYNOS4412 bool "SAMSUNG EXYNOS4412" default y depends on ARCH_EXYNOS4 - select ARCH_HAS_BANDGAP - select PINCTRL_EXYNOS - select SAMSUNG_DMADEV - help - Enable EXYNOS4412 SoC support config SOC_EXYNOS5250 bool "SAMSUNG EXYNOS5250" default y depends on ARCH_EXYNOS5 - select ARCH_HAS_BANDGAP - select PINCTRL_EXYNOS - select PM_GENERIC_DOMAINS if PM_RUNTIME - select S5P_DEV_MFC - select SAMSUNG_DMADEV - help - Enable EXYNOS5250 SoC support config SOC_EXYNOS5420 bool "SAMSUNG EXYNOS5420" default y depends on ARCH_EXYNOS5 - select PM_GENERIC_DOMAINS if PM_RUNTIME - help - Enable EXYNOS5420 SoC support config SOC_EXYNOS5440 bool "SAMSUNG EXYNOS5440" default y depends on ARCH_EXYNOS5 select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE - select ARCH_HAS_BANDGAP select ARCH_HAS_OPP select HAVE_ARM_ARCH_TIMER select AUTO_ZRELADDR -- 1.7.9.5 -- 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
[PATCH v2 0/3] Exynos multi-platform support
The patches in this series were earlier sent as part of other series. Now that the other patches have been merged, re-sending these after rebasing them on linux-next (20140523). Tested on Exynos4210, 4412, 5250 and 5420 based boards. A particular change in this series is the removal of single platform support for Exynos as suggested by Arnd and Olof (patch 2/3). With this change certain features (drivers) which are not yet multi-platform aware like cpufreq, devfreq and DRM based gscaler will not be available now. Changes since v1: Patch 2/3: Dropped some duplicated config symbols as suggested by Arnd. Arnd Bergmann (1): ARM: EXYNOS: Enable multi-platform build support Sachin Kamat (2): ARM: EXYNOS: Consolidate Kconfig entries ARM: multi_v7_defconfig: Enable Exynos platform arch/arm/Kconfig| 20 --- arch/arm/configs/multi_v7_defconfig | 12 +++ arch/arm/mach-exynos/Kconfig| 66 +-- arch/arm/mach-exynos/Makefile |2 ++ arch/arm/plat-samsung/Makefile |3 ++ 5 files changed, 42 insertions(+), 61 deletions(-) -- 1.7.9.5 -- 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
[PATCH v2 2/3] ARM: EXYNOS: Enable multi-platform build support
From: Arnd Bergmann This makes it possible to enable the Exynos platform as part of a multiplatform kernel. Signed-off-by: Arnd Bergmann Signed-off-by: Sachin Kamat --- Changes since v1: Dropped duplicate config symbols as suggested by Arnd. Updated commit log. --- arch/arm/Kconfig | 30 -- arch/arm/mach-exynos/Kconfig | 21 + arch/arm/mach-exynos/Makefile |2 ++ arch/arm/plat-samsung/Makefile |3 +++ 4 files changed, 26 insertions(+), 30 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b8d47ca91406..a2a0153c94e7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -830,36 +830,6 @@ config ARCH_S5PV210 help Samsung S5PV210/S5PC110 series based systems -config ARCH_EXYNOS - bool "Samsung EXYNOS" - select ARCH_HAS_BANDGAP - select ARCH_HAS_CPUFREQ - select ARCH_HAS_HOLES_MEMORYMODEL - select ARCH_REQUIRE_GPIOLIB - select ARCH_SPARSEMEM_ENABLE - select ARM_AMBA - select ARM_GIC - select CLKSRC_OF - select COMMON_CLK_SAMSUNG - select CPU_V7 - select GENERIC_CLOCKEVENTS - select HAVE_ARM_SCU if SMP - select HAVE_S3C2410_I2C if I2C - select HAVE_S3C2410_WATCHDOG if WATCHDOG - select HAVE_S3C_RTC if RTC_CLASS - select HAVE_SMP - select NEED_MACH_MEMORY_H - select PINCTRL - select PINCTRL_EXYNOS - select PM_GENERIC_DOMAINS if PM_RUNTIME - select S5P_DEV_MFC - select SAMSUNG_DMADEV - select SPARSE_IRQ - select SRAM - select USE_OF - help - Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5) - config ARCH_DAVINCI bool "TI DaVinci" select ARCH_HAS_HOLES_MEMORYMODEL diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 138070e42aa9..7035131a1c99 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -7,6 +7,27 @@ # Configuration options for the EXYNOS4 +config ARCH_EXYNOS + bool "Samsung EXYNOS" if ARCH_MULTI_V7 + select ARCH_HAS_BANDGAP + select ARCH_HAS_CPUFREQ + select ARCH_HAS_HOLES_MEMORYMODEL + select ARCH_REQUIRE_GPIOLIB + select ARM_AMBA + select ARM_GIC + select COMMON_CLK_SAMSUNG + select HAVE_ARM_SCU if SMP + select HAVE_S3C2410_I2C if I2C + select HAVE_S3C2410_WATCHDOG if WATCHDOG + select HAVE_S3C_RTC if RTC_CLASS + select PINCTRL + select PINCTRL_EXYNOS + select PM_GENERIC_DOMAINS if PM_RUNTIME + select S5P_DEV_MFC + select SRAM + help + Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) + if ARCH_EXYNOS menu "SAMSUNG EXYNOS SoCs Support" diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index df809039b017..6f3608602bfa 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -5,6 +5,8 @@ # # Licensed under GPLv2 +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree)/arch/arm/plat-samsung/include + obj-y := obj-m := obj-n := diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile index 25c826ed3b65..5e5beaa9ae15 100644 --- a/arch/arm/plat-samsung/Makefile +++ b/arch/arm/plat-samsung/Makefile @@ -4,6 +4,9 @@ # # Licensed under GPLv2 +ccflags-$(CONFIG_ARCH_MULTI_V7) += -I$(srctree)/$(src)/include +ccflags-$(CONFIG_ARCH_EXYNOS) += -I$(srctree)/arch/arm/mach-exynos/include + obj-y := obj-m := obj-n := dummy.o -- 1.7.9.5 -- 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] drm/exynos: remove redundant mutex_unlock
Hi Andrzej,
On 23 May 2014 16:27, Andrzej Hajda wrote:
> The patch fixes unlocking in exynos_drm_component_del.
This patch actually removes multiple unlocking issue.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki,
>
> This patch is based on exynos_drm_next branch.
>
> Regards
> Andrzej
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 4cef88f..c5a401ae 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -417,7 +417,6 @@ void exynos_drm_component_del(struct device *dev,
> if (dev == cdev->dev) {
> list_del(&cdev->list);
> kfree(cdev);
> - mutex_unlock(&drm_component_lock);
> break;
> }
> }
> --
> 1.9.1
>
> --
> 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
--
With warm regards,
Sachin
--
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] drm/exynos/fimd: allow multiplatform configuration
On 23 May 2014 16:28, Andrzej Hajda wrote: > The patch removes dependency on !ARCH_MULTIPLATFORM. > This dependency seems to be not longer valid. > > Signed-off-by: Andrzej Hajda Reviewed-by: Sachin Kamat -- With warm regards, Sachin -- 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
[PATCH 3/5] ARM: dts: Replace numbers with key code macros on Origen boards
Key code macros improve readability.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos4210-origen.dts | 11 ++-
arch/arm/boot/dts/exynos4412-origen.dts | 13 +++--
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index f018e2149168..f767c425d0b5 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -16,6 +16,7 @@
/dts-v1/;
#include "exynos4210.dtsi"
+#include
/ {
model = "Insignal Origen evaluation board based on Exynos4210";
@@ -259,35 +260,35 @@
up {
label = "Up";
gpios = <&gpx2 0 1>;
- linux,code = <103>;
+ linux,code = ;
gpio-key,wakeup;
};
down {
label = "Down";
gpios = <&gpx2 1 1>;
- linux,code = <108>;
+ linux,code = ;
gpio-key,wakeup;
};
back {
label = "Back";
gpios = <&gpx1 7 1>;
- linux,code = <158>;
+ linux,code = ;
gpio-key,wakeup;
};
home {
label = "Home";
gpios = <&gpx1 6 1>;
- linux,code = <102>;
+ linux,code = ;
gpio-key,wakeup;
};
menu {
label = "Menu";
gpios = <&gpx1 5 1>;
- linux,code = <139>;
+ linux,code = ;
gpio-key,wakeup;
};
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index bd3985b767c4..e925c9fbfb07 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include "exynos4412.dtsi"
+#include
/ {
model = "Insignal Origen evaluation board based on Exynos4412";
@@ -84,37 +85,37 @@
key_home {
keypad,row = <0>;
keypad,column = <0>;
- linux,code = <102>;
+ linux,code = ;
};
key_down {
keypad,row = <0>;
keypad,column = <1>;
- linux,code = <108>;
+ linux,code = ;
};
key_up {
keypad,row = <1>;
keypad,column = <0>;
- linux,code = <103>;
+ linux,code = ;
};
key_menu {
keypad,row = <1>;
keypad,column = <1>;
- linux,code = <139>;
+ linux,code = ;
};
key_back {
keypad,row = <2>;
keypad,column = <0>;
- linux,code = <158>;
+ linux,code = ;
};
key_enter {
keypad,row = <2>;
keypad,column = <1>;
- linux,code = <28>;
+ linux,code = ;
};
};
--
1.7.9.5
--
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
[PATCH 4/5] ARM: dts: Replace numbers with key code macros on Arndale board
Key code macros improve readability.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5250-arndale.dts | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index cde19c818667..d0de1f50d15b 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include "exynos5250.dtsi"
#include
+#include
/ {
model = "Insignal Arndale evaluation board based on EXYNOS5250";
@@ -445,42 +446,42 @@
menu {
label = "SW-TACT2";
gpios = <&gpx1 4 1>;
- linux,code = <139>;
+ linux,code = ;
gpio-key,wakeup;
};
home {
label = "SW-TACT3";
gpios = <&gpx1 5 1>;
- linux,code = <102>;
+ linux,code = ;
gpio-key,wakeup;
};
up {
label = "SW-TACT4";
gpios = <&gpx1 6 1>;
- linux,code = <103>;
+ linux,code = ;
gpio-key,wakeup;
};
down {
label = "SW-TACT5";
gpios = <&gpx1 7 1>;
- linux,code = <108>;
+ linux,code = ;
gpio-key,wakeup;
};
back {
label = "SW-TACT6";
gpios = <&gpx2 0 1>;
- linux,code = <158>;
+ linux,code = ;
gpio-key,wakeup;
};
wakeup {
label = "SW-TACT7";
gpios = <&gpx2 1 1>;
- linux,code = <143>;
+ linux,code = ;
gpio-key,wakeup;
};
};
--
1.7.9.5
--
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
[PATCH 1/5] ARM: dts: Enable RTC node on Origen boards
Enabled RTC node on Origen 4210 and 4412 boards.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos4210-origen.dts |4
arch/arm/boot/dts/exynos4412-origen.dts |4
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 72fb11f7ea21..95efb1189cf0 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -48,6 +48,10 @@
};
};
+ rtc@1007 {
+ status = "okay";
+ };
+
tmu@100C {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index e2c0dcab4d81..934fe7ecca7e 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -48,6 +48,10 @@
};
};
+ rtc@1007 {
+ status = "okay";
+ };
+
pinctrl@1100 {
keypad_rows: keypad-rows {
samsung,pins = "gpx2-0", "gpx2-1", "gpx2-2";
--
1.7.9.5
--
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
[PATCH 2/5] ARM: dts: Enable watchdog node on Origen boards
Enabled watchdog nodes on Origen 4210 and 4412 boards.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos4210-origen.dts |4
arch/arm/boot/dts/exynos4412-origen.dts |4
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 95efb1189cf0..f018e2149168 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -48,6 +48,10 @@
};
};
+ watchdog@1006 {
+ status = "okay";
+ };
+
rtc@1007 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos4412-origen.dts
b/arch/arm/boot/dts/exynos4412-origen.dts
index 934fe7ecca7e..bd3985b767c4 100644
--- a/arch/arm/boot/dts/exynos4412-origen.dts
+++ b/arch/arm/boot/dts/exynos4412-origen.dts
@@ -48,6 +48,10 @@
};
};
+ watchdog@1006 {
+ status = "okay";
+ };
+
rtc@1007 {
status = "okay";
};
--
1.7.9.5
--
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
