Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag

2014-11-07 Thread Rafael J. Wysocki
On Friday, November 07, 2014 02:27:27 PM Ulf Hansson wrote: > The initial state of the device's need_restore flag should'nt depend on > the current state of the PM domain. For example it should be perfectly > valid to attach an inactive device to a powered PM domain. > > The pm_genpd_dev_need_rest

Re: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

2014-11-07 Thread Dmitry Torokhov
Hi Lukasz, On Fri, Nov 7, 2014 at 2:05 AM, Lukasz Majewski wrote: > Hi Eduardo, > >> On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote: >> > This patch extends the of-thermal.c to provide information about >> > number of available non critical (i.e. non HW) trip points in the >> > s

Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag

2014-11-07 Thread Kevin Hilman
Dmitry Torokhov writes: > On Fri, Nov 07, 2014 at 11:47:53AM -0800, Kevin Hilman wrote: >> Ulf Hansson writes: >> >> > The initial state of the device's need_restore flag should'nt depend on >> > the current state of the PM domain. For example it should be perfectly >> > valid to attach an inac

Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag

2014-11-07 Thread Dmitry Torokhov
On Fri, Nov 07, 2014 at 11:47:53AM -0800, Kevin Hilman wrote: > Ulf Hansson writes: > > > The initial state of the device's need_restore flag should'nt depend on > > the current state of the PM domain. For example it should be perfectly > > valid to attach an inactive device to a powered PM domai

Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag

2014-11-07 Thread Kevin Hilman
Ulf Hansson writes: > The initial state of the device's need_restore flag should'nt depend on > the current state of the PM domain. For example it should be perfectly > valid to attach an inactive device to a powered PM domain. > > The pm_genpd_dev_need_restore() API allow us to update the need_r

Re: [PATCH] thermal: exynos: use correct offset for TMU_CONTROL register on Exynos5260

2014-11-07 Thread Eduardo Valentin
Hi Bartlomiej, On Mon, Oct 20, 2014 at 02:41:07PM +0200, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > Eduardo, could you please merge this patch? > I queued this in my -fixes branch. It should appear also in linux-next. Can you please refresh your patch series https://lkml.org/lkml/2014/9/18/

Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag

2014-11-07 Thread Sylwester Nawrocki
On 07/11/14 14:27, Ulf Hansson wrote: [...] > To handle things more properly in the generic PM domain, let's change > the default initial value of the need_restore flag to reflect that the > state is unknown. As soon as some of the runtime PM callbacks gets > invoked, update the initial value accor

Re: [PATCH 03/12] PM / Domains: Add notifier support for power domain transitions

2014-11-07 Thread Kevin Hilman
Sylwester Nawrocki writes: > On 04/11/14 07:44, amit daniel kachhap wrote: >> On Mon, Nov 3, 2014 at 11:53 PM, Kevin Hilman wrote: >>> "Rafael J. Wysocki" writes: On Monday, November 03, 2014 09:23:01 AM Amit Daniel Kachhap wrote: > These power domain transition notifiers will assist i

[PATCH 1/2] ARM: EXYNOS: apply S5P_CENTRAL_SEQ_OPTION fix only when necessary

2014-11-07 Thread Bartlomiej Zolnierkiewicz
Commit c2dd114d2486 ("ARM: EXYNOS: fix register setup for AFTR mode code") added S5P_CENTRAL_SEQ_OPTION register setup fix for all Exynos SoCs to AFTR mode code-path. It turned out that for coupled cpuidle AFTR mode on Exynos4210 (added by the next patch) applying this fix causes lockup so enable

[PATCH 2/2] cpuidle: exynos: add coupled cpuidle support for Exynos4210

2014-11-07 Thread Bartlomiej Zolnierkiewicz
The following patch adds coupled cpuidle support for Exynos4210 to an existing cpuidle-exynos driver. As a result it enables AFTR mode to be used by default on Exynos4210 without the need to hot unplug CPU1 first. The patch is heavily based on earlier cpuidle-exynos4210 driver from Daniel Lezcano

[PATCH 0/2] cpuidle: exynos: add coupled cpuidle support for Exynos4210

2014-11-07 Thread Bartlomiej Zolnierkiewicz
Hi, The following patchset adds coupled cpuidle support for Exynos4210 to an existing cpuidle-exynos driver. As a result it enables AFTR mode to be used by default on Exynos4210 without the need to hot unplug CPU1 first. This work is heavily based on earlier cpuidle-exynos4210 driver from Daniel

Re: [PATCH v3 0/9] PM / Domains: Fix race conditions during boot

2014-11-07 Thread Grygorii Strashko
Hi All, Uh... just finished reading this thread and finally decided to add my 5 cents here as I've already had very bad experience with some changes introduced to DD/PM core :( (just check the history of the change 1e2ef05bb "PM: Limit race conditions between runtime PM and system sleep (v2)" O

Re: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

2014-11-07 Thread Lukasz Majewski
Hi Eduardo, > > Hello Lukasz, > > On Fri, Nov 07, 2014 at 11:05:51AM +0100, Lukasz Majewski wrote: > > Hi Eduardo, > > > > > On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote: > > > > This patch extends the of-thermal.c to provide information about > > > > number of available non

Re: [PATCH] drm/exynos: resolve infinite loop issue on non multi-platform

2014-11-07 Thread Greg Kroah-Hartman
On Fri, Nov 07, 2014 at 12:11:24PM +0100, Andrzej Hajda wrote: > On 11/06/2014 06:08 PM, Sjoerd Simons wrote: > > On Thu, 2014-11-06 at 23:10 +0900, Inki Dae wrote: > >> This patch resovles the infinite loop issue incurred > >> when Exyno drm driver is enabled but all kms drivers > >> are disabled

Re: [PATCH v5 5/5] regulator: of: Add support for parsing initial and suspend modes

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 05:15:38PM +0100, Javier Martinez Canillas wrote: > On 11/07/2014 04:47 PM, Mark Brown wrote: > >> + if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) { > >> + if (desc && desc->map_modes) > >> + constraints->initial_mode = desc->map

Re: [PATCH v5 5/5] regulator: of: Add support for parsing initial and suspend modes

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 02:00:05PM +0100, Javier Martinez Canillas wrote: > + if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) { > + if (desc && desc->map_modes) > + constraints->initial_mode = desc->map_modes(pval); > + else > +

Re: [PATCH v5 3/5] regulator: of: Add regulator desc param to of_get_regulator_init_data()

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 02:00:03PM +0100, Javier Martinez Canillas wrote: > - initdata = of_get_regulator_init_data(dev, np); > sreg = devm_kzalloc(dev, sizeof(*sreg), GFP_KERNEL); > if (!sreg) > return -ENOMEM; > - sreg->initdata = initdata; > sreg->name =

Re: [PATCH v5 1/5] regulator: Document binding for initial and suspend modes

2014-11-07 Thread Javier Martinez Canillas
Hello Mark, On 11/07/2014 05:10 PM, Mark Brown wrote: > > You're also saying that the OS won't manage the mode here, that's a step > further. > I see >> So should I just explain what each property is about without trying to make >> assumptions about the limitations that different devices could

Re: [PATCH v5 2/5] regulator: Add function to map modes to struct regulator_desc

2014-11-07 Thread Javier Martinez Canillas
On 11/07/2014 04:54 PM, Mark Brown wrote: > of_map_mode - it's only one mode and this is mapping to/from DT. > Ok >> + * If the callback is not defined, the "regulator-initial-mode" >> + * and suspend states "regulator-mode" properties won't be >> parsed. > > Just remov

Re: [PATCH v5 5/5] regulator: of: Add support for parsing initial and suspend modes

2014-11-07 Thread Javier Martinez Canillas
On 11/07/2014 04:47 PM, Mark Brown wrote: > On Fri, Nov 07, 2014 at 02:00:05PM +0100, Javier Martinez Canillas wrote: > >> +if (!of_property_read_u32(np, "regulator-initial-mode", &pval)) { >> +if (desc && desc->map_modes) >> +constraints->initial_mode = desc->m

Re: [PATCH v5 3/5] regulator: of: Add regulator desc param to of_get_regulator_init_data()

2014-11-07 Thread Javier Martinez Canillas
Hello Krzysztof, On 11/07/2014 04:23 PM, Krzysztof Kozlowski wrote: >> >> static struct fan53555_platform_data *fan53555_parse_dt(struct device *dev, >> -struct device_node *np) >> +struct device_nod

Re: [PATCH v5 1/5] regulator: Document binding for initial and suspend modes

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 04:38:04PM +0100, Javier Martinez Canillas wrote: > On 11/07/2014 03:58 PM, Mark Brown wrote: > > On Fri, Nov 07, 2014 at 02:00:01PM +0100, Javier Martinez Canillas wrote: > >> +The "regulator-mode" property only takes effect if the regulator is > >> +enabled for th

Re: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

2014-11-07 Thread Eduardo Valentin
Hello Lukasz, On Fri, Nov 07, 2014 at 11:05:51AM +0100, Lukasz Majewski wrote: > Hi Eduardo, > > > On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote: > > > This patch extends the of-thermal.c to provide information about > > > number of available non critical (i.e. non HW) trip poi

Re: [PATCH v5 2/5] regulator: Add function to map modes to struct regulator_desc

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 02:00:02PM +0100, Javier Martinez Canillas wrote: > + * @map_modes: Callback invoked to translate from hardware to standard modes. > + * The function returns the standard REGULATOR_MODE that maps to > + * the hardware specific mode passed as an argum

Re: [PATCH v5 3/5] regulator: of: Add regulator desc param to of_get_regulator_init_data()

2014-11-07 Thread Javier Martinez Canillas
Hello Mark, On 11/07/2014 04:07 PM, Mark Brown wrote: > > This is using the regulator descriptor before it is initialized which > doesn't seem ideal... > You are right, even if most of them are not used currently, that may change in the future so is safer to use it after all fields have been ini

Re: [PATCH v5 1/5] regulator: Document binding for initial and suspend modes

2014-11-07 Thread Javier Martinez Canillas
Hello Mark, Thanks a lot for your feedback. On 11/07/2014 03:58 PM, Mark Brown wrote: > On Fri, Nov 07, 2014 at 02:00:01PM +0100, Javier Martinez Canillas wrote: > >> + The "regulator-mode" property only takes effect if the regulator is >> + enabled for the given suspend state using "r

Re: [PATCH v5 0/5] regulator: of: Add initial and suspend modes support

2014-11-07 Thread Krzysztof Kozlowski
On pią, 2014-11-07 at 14:00 +0100, Javier Martinez Canillas wrote: > Hello Mark, > > This is the fifth version of the series that adds regulator initial > and suspend operating modes support. It relies on the existing work > that added suspend states bindings. The opmodes are parsed by the > regul

Re: [PATCH v5 3/5] regulator: of: Add regulator desc param to of_get_regulator_init_data()

2014-11-07 Thread Krzysztof Kozlowski
On pią, 2014-11-07 at 14:00 +0100, Javier Martinez Canillas wrote: > The of_get_regulator_init_data() function is used to extract the regulator > init_data but information on how to extract certain data is defined in the > static regulator descriptor (e.g: how to map the hardware operating modes).

Re: [PATCH v5 1/5] regulator: Document binding for initial and suspend modes

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 02:00:01PM +0100, Javier Martinez Canillas wrote: > + The "regulator-mode" property only takes effect if the regulator is > + enabled for the given suspend state using "regulator-on-in-suspend". Why? > + If the regulator has not been explicitly disabled

[PATCH v2 1/2] drm/exynos: Fix DSI resuming fail because power domain being off

2014-11-07 Thread Krzysztof Kozlowski
During system resume from suspend to RAM the Exynos DRM driver forced CRTC mode thus turning display on (DPMS_ON). This lead to runtime resuming of DSI which failed because whole LCD power domain was off and it was not allowed to turn on because of system resume in progress. Forcing mode should no

[PATCH v2 2/2] drm/exynos/dsi: Add runtime PM so LCD power domain could be turned off

2014-11-07 Thread Krzysztof Kozlowski
Add runtime Power Management to the Exynos DSI driver so the LCD power domain could be turned off. This slightly reduces the energy consumption when screen is completely turned off. On Trats2 board when the system was idle the energy consumption dropped by 1% (from 92.2 mA to 91.1 mA). Before the

[PATCH v2 0/2] DRM: Add runtime PM to Exynos DSI

2014-11-07 Thread Krzysztof Kozlowski
Hi, Changes since v1 1. Replace patch 1 changing PM core with fix only for DRM exynos driver. Description === The goal of the patch 2 is to add runtime PM to the Exynos DSI driver. This allows LCD power domain to be turned off. However after adding this patch an interesi

[PATCH v2] thermal: cpu_cooling: Update always cpufreq policy with thermal constraints

2014-11-07 Thread Yadwinder Singh Brar
Existing code updates cupfreq policy only while executing cpufreq_apply_cooling() function (i.e. when notify_device != NOTIFY_INVALID). It doesn't apply constraints when cpufreq policy update happens from any other place but it should update the cpufreq policy with thermal constraints every time wh

[PATCH] PM / Domains: Fix initial default state of the need_restore flag

2014-11-07 Thread Ulf Hansson
The initial state of the device's need_restore flag should'nt depend on the current state of the PM domain. For example it should be perfectly valid to attach an inactive device to a powered PM domain. The pm_genpd_dev_need_restore() API allow us to update the need_restore flag to somewhat cope wi

[PATCH v5 2/5] regulator: Add function to map modes to struct regulator_desc

2014-11-07 Thread Javier Martinez Canillas
The "regulator-initial-mode" and "regulator-mode" DT properties allows to configure the regulator operating modes at startup or when a system enters into a susend state. But these properties use as valid values the operating modes supported by each device while the core deals with the standard ope

[PATCH v5 1/5] regulator: Document binding for initial and suspend modes

2014-11-07 Thread Javier Martinez Canillas
Some regulators can run on different operating modes (opmodes). This allows systems to choose the most efficient opmode for each regulator. This patch builds on top of (291d761 regulator: Document binding for regulator suspend state for PM state) adding a regulator-initial-mode DT property to conf

[PATCH v5 3/5] regulator: of: Add regulator desc param to of_get_regulator_init_data()

2014-11-07 Thread Javier Martinez Canillas
The of_get_regulator_init_data() function is used to extract the regulator init_data but information on how to extract certain data is defined in the static regulator descriptor (e.g: how to map the hardware operating modes). Add a const struct regulator_desc * parameter to the function signature

[PATCH v5 4/5] regulator: of: Pass the regulator description in the match table

2014-11-07 Thread Javier Martinez Canillas
Drivers can use the of_regulator_match() function to parse the regulator init_data from DT. A match table is used to specify the name of the node containing the regulators, the device node and to return the init_data to the caller. But also the static regulator descriptor is needed to correctly ex

[PATCH v5 5/5] regulator: of: Add support for parsing initial and suspend modes

2014-11-07 Thread Javier Martinez Canillas
Some regulators support their operating mode to be changed on startup or by consumers when the system is running while others only support their operating mode to be changed while the system has entered in a suspend state. The regulator Device Tree binding documents a set of properties to configur

[PATCH v5 0/5] regulator: of: Add initial and suspend modes support

2014-11-07 Thread Javier Martinez Canillas
Hello Mark, This is the fifth version of the series that adds regulator initial and suspend operating modes support. It relies on the existing work that added suspend states bindings. The opmodes are parsed by the regulator core and drivers should only define a translation function to map between

[PATCH] drm/exynos: fix possible infinite loop issue

2014-11-07 Thread Inki Dae
This patch fixes possible infinite loop issue by postponing registration to non kms drivers after component_master_add_with_match call, which can be incurred in all cases that non kms driver is probed and then component bind is failed This patch should be applied on top of below patches, h

Re: [PATCH v4] arm64: dts: exynos7: add support for cpuidle core power down

2014-11-07 Thread Lorenzo Pieralisi
On Wed, Nov 05, 2014 at 01:15:31PM +, Chander Kashyap wrote: > Exynos7 has core power down state where cores can be powered off > independently. "...has a core power down idle state..." > This patch adds support for this state. "...for this idle state." > Entry latency for the core power d

Re: [PATCH] ARM: dts: Fix booting on Rinato market device

2014-11-07 Thread Krzysztof Kozlowski
On pią, 2014-11-07 at 20:50 +0900, Chanwoo Choi wrote: > Hi Krzysztof, > > On 11/07/2014 08:44 PM, Krzysztof Kozlowski wrote: > > The bootloader on market Rinato (Gear 2) device checks for revision in > > compatible field of DTB. If it is not present or lower than required > > then booting fails w

Re: [PATCH] ARM: dts: Fix booting on Rinato market device

2014-11-07 Thread Chanwoo Choi
Hi Krzysztof, On 11/07/2014 08:44 PM, Krzysztof Kozlowski wrote: > The bootloader on market Rinato (Gear 2) device checks for revision in > compatible field of DTB. If it is not present or lower than required > then booting fails with: "Could not do normal boot. (no DTB found)". > > Log of bootlo

[PATCH] ARM: dts: Fix booting on Rinato market device

2014-11-07 Thread Krzysztof Kozlowski
The bootloader on market Rinato (Gear 2) device checks for revision in compatible field of DTB. If it is not present or lower than required then booting fails with: "Could not do normal boot. (no DTB found)". Log of bootloader in case of failure: h/w: revision = 0x06 h/w: schematic = SM-R380_Rev0

[PATCH] drm/exynos: g2d: fix null pointer dereference

2014-11-07 Thread Inki Dae
This patch fixes a null pointer dereference issue incurred by calling g2d_remove when exynos_drm_platform_probe is failed. cmdlist_pool of g2d is allocated when g2d sub driver is probed. So if exynos_drm_platform_probe is failed, the g2d sub driver is not probed and the cmdlist_pool is still NULL.

RE: [PATCH] thermal: cpu_cooling: Update always cpufreq policy with thermal constraints

2014-11-07 Thread Yadwinder Singh Brar
Hello Eduardo Valentin, On Thursday, November 06, 2014 1:19 PM, Eduardo Valentin wrote: > Hello Yadwinder, > > On Thu, Nov 06, 2014 at 04:26:27PM +0530, Yadwinder Singh Brar wrote: > > Hello Eduardo Valentin, > > > > On Thursday, November 06, 2014 2:17 AM, Eduardo Valentin wrote: > > > Hello Yad

Re: [PATCH] drm/exynos: resolve infinite loop issue on non multi-platform

2014-11-07 Thread Inki Dae
On 2014년 11월 07일 17:29, Andrzej Hajda wrote: > On 11/06/2014 03:10 PM, Inki Dae wrote: >> This patch resovles the infinite loop issue incurred >> when Exyno drm driver is enabled but all kms drivers >> are disabled on Exynos board by returning -EPROBE_DEFER >> only in case that there is kms device

Re: [PATCH 04/21] thermal: of: Extend current of-thermal.c code to allow setting emulated temp

2014-11-07 Thread Lukasz Majewski
Hi Eduardo, > Hello, > > On Thu, Oct 09, 2014 at 06:38:40PM +0200, Lukasz Majewski wrote: > > Before this change it was only possible to set get_temp() and > > get_trend() methods to be used in the common code handling passing > > parameters via device tree to "cpu-thermal" CPU thermal zone devic

Re: [PATCH] drm/exynos: resolve infinite loop issue on non multi-platform

2014-11-07 Thread Andrzej Hajda
On 11/06/2014 06:08 PM, Sjoerd Simons wrote: > On Thu, 2014-11-06 at 23:10 +0900, Inki Dae wrote: >> This patch resovles the infinite loop issue incurred >> when Exyno drm driver is enabled but all kms drivers >> are disabled on Exynos board by returning -EPROBE_DEFER >> only in case that there is

Re: [PATCH 2/2] ASoC: samsung: add support for exynos7 I2S controller

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 12:24:40PM +0530, Padmavathi Venna wrote: > Exynos7 I2S controller has no internal dma, supports more > no. of root clock sampling frequencies and has more no.of Rx > fifos to support 7.1CH recording in TDM mode. Due to more no. Applied, thanks. signature.asc Description:

Re: [PATCH 1/2] ASoC: Samsung: Add quirk for internal DMA

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 12:24:39PM +0530, Padmavathi Venna wrote: > Internal DMA is available only on some of Samsung platforms. > So added a quirk for the same and made it optional. Applied, thanks. signature.asc Description: Digital signature

Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller

2014-11-07 Thread Mark Brown
On Fri, Nov 07, 2014 at 02:01:57PM +0530, Padma Venkat wrote: > CS can also be controlled automatically by setting AUTO_N_MANUAL to 1 > in CS_CFG. When it is auto CS automatically toggles between packet to > packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The > driver by default use

Re: [PATCH 03/21] thermal: of: Extend of-thermal.c to provide number of non critical trip points

2014-11-07 Thread Lukasz Majewski
Hi Eduardo, > On Thu, Oct 09, 2014 at 06:38:39PM +0200, Lukasz Majewski wrote: > > This patch extends the of-thermal.c to provide information about > > number of available non critical (i.e. non HW) trip points in the > > system. > > > > Signed-off-by: Lukasz Majewski > > --- > > drivers/therma

Re: [PATCH 02/21] thermal: of: Extend of-thermal.c to provide check if trip point is enabled

2014-11-07 Thread Lukasz Majewski
Hi Eduardo, > Hello Lukasz, > > On Thu, Oct 09, 2014 at 06:38:38PM +0200, Lukasz Majewski wrote: > > This patch extends the of-thermal.c to provide check if trip point > > is enabled. > > > > Signed-off-by: Lukasz Majewski > > --- > > drivers/thermal/of-thermal.c | 9 + > > drivers/t

Re: [PATCH 01/21] thermal: of: Extend of-thermal.c to provide number of trip points

2014-11-07 Thread Lukasz Majewski
Hi Eduardo, > Hello Lukasz, > > On Thu, Oct 09, 2014 at 06:38:37PM +0200, Lukasz Majewski wrote: > > This patch extends the of-thermal.c to provide information about > > number of available trip points. > > > > Signed-off-by: Lukasz Majewski > > --- > > drivers/thermal/of-thermal.c | 6 +

Re: "asix: Don't reset PHY on if_up for ASIX 88772" breaks net onarndale platform

2014-11-07 Thread Riku Voipio
On Thu, Nov 06, 2014 at 02:09:40PM +, Charles Keepax wrote: > On Thu, Nov 06, 2014 at 03:01:56PM +0100, Stam, Michel [FINT] wrote: > > Hello Charles and Riku, > > > > I've quickly tested this on a 3.10 kernel i had around; > > I enabled CONFIG_PM, CONFIG_PM_RUNTIME, CONFIG_PM_AUTOSLEEP, > > CO

Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller

2014-11-07 Thread Padma Venkat
Hi Mark, CCing Kukjin Kim. On 11/6/14, Mark Brown wrote: > On Thu, Nov 06, 2014 at 03:21:49PM +0530, Padmavathi Venna wrote: >> Exynos7 SPI controller supports only the auto Selection of >> CS toggle mode and Exynos7 SoC includes six SPI controllers. >> Add support for these changes in Exynos7 S

Re: [PATCH] drm/exynos: resolve infinite loop issue on non multi-platform

2014-11-07 Thread Andrzej Hajda
On 11/06/2014 03:10 PM, Inki Dae wrote: > This patch resovles the infinite loop issue incurred > when Exyno drm driver is enabled but all kms drivers > are disabled on Exynos board by returning -EPROBE_DEFER > only in case that there is kms device registered. There are many different cases it can