Hi Tomasz,
Hi,
On 10.05.2014 08:56, Pankaj Dubey wrote:
From: Young-Gun Jang yg1004.j...@samsung.com
Add support for mapping Samsung Power Management Unit (PMU) base
address from device tree. This patch also adds helper function as
get_exynos_pmuregmap. This function can be used by
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?
Doug,
On Fri, 2014-06-13 at 08:22 -0700, Doug Anderson wrote:
On Fri, Jun 13, 2014 at 1:08 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote:
This is a config option on the ChromeOS EC
https://chromium.googlesource.com/chromiumos/platform/ec.
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.
like it is triggered by the commit 56e6921829
This patch adds port sub-nodes to exynos4 ehci and ohci modules, which
are required by recently merged new exynos4 usb2 phy support.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4.dtsi | 24
1 file changed, 24 insertions(+)
diff
This patch adds support for common hardware modules available on all
Exynos4412-based Odroid boards, which already have complete support in
mainline kernel. This includes secure firmware calls, watchdog, g2d and
fimc (mem2mem) multimedia accelerators.
Signed-off-by: Marek Szyprowski
This patch moves some parts of exynos4412-odroidx.dts to common
exynos4412-odroid-common.dtsi file and adds support for Odroid X2 and
U2/U3 boards. X2 is same as X, but it has faster SoC module (1.7GHz
instead of 1.4GHz), while U2/U3 differs from X2 by different way of
routing signals to host USB
Hello,
This is the initial patch series adding support for Exynos 4412 based
Odroid X2 and U2/U3/U3+ boards and improving support for Odroid X.
Complete USB support for Odroid U2/U3/U3+ still requires some fixes in
Exynos4 USB2 Phy driver and clock driver for CLKOUT:
From: Kamil Debski k.deb...@samsung.com
This patch adds basic support for USB modules (host and device) on
OdroidX board.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroidx.dts | 30
-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
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:
-Original Message-
From: Yoder Stuart-B08248
Sent: Tuesday, June 17, 2014 12:24 AM
To: Will Deacon
Cc: Sethi Varun-B16395; Thierry Reding; Mark Rutland;
devicet...@vger.kernel.org; linux-samsung-soc@vger.kernel.org; Pawel
Moll; Arnd Bergmann; Ian Campbell; Grant Grundler; Stephen
On Tue, Jun 17, 2014 at 11:26:48AM +0100, Varun Sethi wrote:
The way we generally thought it would work was something like
this:
-u-boot/bootloader makes any static streamID allocation if needed,
sets a default streamID (e.g. 0x0) in device and expresses
that in the device
Hello Mark,
Thanks a lot for your feedback.
On 06/16/2014 09:25 PM, Mark Brown wrote:
On Mon, Jun 16, 2014 at 08:02:35PM +0200, Javier Martinez Canillas wrote:
--- a/drivers/mfd/max77802.c
+++ b/drivers/mfd/max77802.c
@@ -37,6 +37,7 @@
#include linux/err.h
static const struct
Hello Mark,
On 06/16/2014 09:27 PM, Mark Brown wrote:
On Mon, Jun 16, 2014 at 08:02:34PM +0200, Javier Martinez Canillas wrote:
+- max77802,pmic-buck-dvs-gpios: The DVS GPIOs. We'll try to set these GPIOs
+ to match pmic-buck-default-dvs-idx at probe time if they are defined. If
+ some or
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Will Deacon
Sent: Tuesday, June 17, 2014 4:13 PM
To: Sethi Varun-B16395
Cc: Mark Rutland; devicet...@vger.kernel.org; linux-samsung-
Hi Srivatsa,
On Tue, Jun 17, 2014 at 3:24 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com 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).
On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote:
On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
[...]
Arnd, can you take another
On 06/04/2014 07:30 PM, Doug Anderson wrote:
In (93bfb76 clocksource: exynos_mct: register sched_clock callback) we
supported using the MCT as a scheduler clock. We properly marked
exynos4_read_sched_clock() as notrace. However, we then went and
called another function that _wasn't_ notrace.
On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote:
On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
It can easily be argued that if the algorithm used to remap the ID
varies, the compatibility of the
On 06/17/2014 05:25 PM, Sachin Kamat wrote:
Hi Srivatsa,
On Tue, Jun 17, 2014 at 3:24 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com 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
On Tue, Jun 17, 2014 at 12:49:56PM +0200, Javier Martinez Canillas wrote:
On 06/16/2014 09:25 PM, Mark Brown wrote:
+ config.dev = pdev-dev;
Are you sure this shouldn't be the MFD?
I just looked at regulator_register() and saw that it does rdev-dev.parent =
dev, so yes this has to be
-Original Message-
From: Sethi Varun-B16395
Sent: Tuesday, June 17, 2014 5:27 AM
To: Yoder Stuart-B08248; Will Deacon
Cc: Thierry Reding; Mark Rutland; devicet...@vger.kernel.org; linux-
samsung-...@vger.kernel.org; Pawel Moll; Arnd Bergmann; Ian Campbell;
Grant Grundler; Stephen
-Original Message-
From: Sethi Varun-B16395
Sent: Tuesday, June 17, 2014 6:22 AM
To: Will Deacon
Cc: Mark Rutland; devicet...@vger.kernel.org; linux-samsung-
s...@vger.kernel.org; Arnd Bergmann; Pawel Moll; Ian Campbell; Grant
Grundler; Stephen Warren; Yoder Stuart-B08248; Rob
Changes since v5:
- Configuration data for cpu clock block is embedded with the code. The cpu
clock
logic can later to extended to obtain this data from DT.
- Excluded the support for Exynos4x12 SoC since the work on boost OPP bindings
is
still incomplete.
- Included cpufreq support for
From: Thomas Abraham thomas...@samsung.com
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new
From: Thomas Abraham thomas...@samsung.com
Remove the platform device instantiation for Exynos4210/5250 cpufreq
driver and add the platform device for generic cpufreq drivers.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
From: Thomas Abraham thomas...@samsung.com
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type and the independent
clock blocks that made up the arm clock can be removed.
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Thomas
From: Thomas Abraham thomas...@samsung.com
For Exynos 4210/5250/5420 based platforms, add CPU nodes, operating points and
cpu clock data for migrating from Exynos specific cpufreq driver to using
generic cpufreq drivers.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Thomas Abraham
From: Thomas Abraham thomas...@samsung.com
Register the PLL configuration data for APLL and KPLL on Exynos5420. This
configuration data table specifies PLL coefficients for supported PLL
clock speeds when a 24MHz clock is supplied as the input clock source
for these PLLs.
Cc: Tomasz Figa
Hi Pankaj,
On 17.06.2014 08:43, Pankaj Dubey wrote:
Hi Tomasz,
Hi,
On 10.05.2014 08:56, Pankaj Dubey wrote:
From: Young-Gun Jang yg1004.j...@samsung.com
Add support for mapping Samsung Power Management Unit (PMU) base
address from device tree. This patch also adds helper function as
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated driver. However in certain use
cases it is desirable to make a device used with another driver a syscon
interface provider. For example, certain SoCs (e.g. Exynos) contain
system
Changes since v5:
- Configuration data for cpu clock block is embedded with the code. The cpu
clock
logic can later to extended to obtain this data from DT.
- Excluded the support for Exynos4x12 SoC since the work on boost OPP bindings
is
still incomplete.
- Included cpufreq support for
From: Thomas Abraham thomas...@samsung.com
Exynos4210 and Exynos5250 based platforms have switched over to use generic
cpufreq drivers for cpufreq functionality. So the Exynos specific cpufreq
drivers for these platforms can be removed.
Cc: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by:
On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated driver. However in certain use
cases it is desirable to make a device used with another driver a syscon
interface provider. For
Hi Pankaj,
[Dropped yg1004.j...@samsung.com from CC, as apparently his mailbox is
temporarily locked, at least from the point of view of my mail server.]
Please see my comments inline.
On 10.05.2014 08:56, Pankaj Dubey wrote:
Under arm/mach-exynos many files are using PMU register offsets.
On 10.05.2014 08:56, Pankaj Dubey wrote:
As we have removed static mappings from regs-pmu.h it does not
need map.h anymore. But platsmp.c needed this and till now it
got included indirectly. So lets move header inclusion of
mach/map.h from regs-pmu.h to platsmp.c.
Signed-off-by: Pankaj
Hello Mark,
On 06/17/2014 04:12 PM, Mark Brown wrote:
On Tue, Jun 17, 2014 at 12:49:56PM +0200, Javier Martinez Canillas wrote:
On 06/16/2014 09:25 PM, Mark Brown wrote:
+ config.dev = pdev-dev;
Are you sure this shouldn't be the MFD?
I just looked at regulator_register() and saw
On 06/17/2014 02:53 AM, Paul Bolle wrote:
Doug,
On Fri, 2014-06-13 at 08:22 -0700, Doug Anderson wrote:
On Fri, Jun 13, 2014 at 1:08 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote:
This is a config option on the ChromeOS EC
On 06/13/2014 08:13 PM, Doug Anderson wrote:
This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
including:
* The keyboard
* The i2c tunnel
* The tps65090 under the i2c tunnel
* The battery under the i2c tunnel
To add extra motivation, it should be noted that tps65090 is
On Tue, 2014-06-17 at 10:20 -0600, Stephen Warren wrote:
On 06/17/2014 02:53 AM, Paul Bolle wrote:
So, in summary, while we're apparently only discussing a single comment,
I would appreciate it if it could be reworded, preferably by dropping
that the CONFIG_ prefix. But other people might
Hi Pankaj,
[dropping Young-Gun Jang yg1004.j...@samsung.com, as my mailer denies
to send to this address]
Please see my comments inline. I have skipped comments for changed
related to regmap, as according to our previous discussion they will be
dropped in next version.
On 10.05.2014 08:56,
Remove unused / write-only entries from struct exynos_tmu_registers.
Then remove unused defines while at it.
We don't keep the unused/untested features in the kernel just
in case that some future hardware might need it. Such code has
a real maintainance cost (all other code changes have to take
Hi,
This patch series contains various cleanups for EXYNOS thermal
driver. Overall it decreases driver's LOC by 12%. It is based
on next-20140617 kernel. It should not cause any functionality
changes.
Changes since v1:
- synced patches against next-20140617
- merged patch thermal: exynos
The commit 1928457 (thermal: exynos: Add hardware mode thermal
calibration support) has added HW_MODE feature but it has never
been enabled. As such it has been a dead code for almost a year
now and should be removed from the kernel.
We don't keep the unused/untested features in the kernel just
There are two types of calibration (TYPE_[ONE,TWO]_POINT_TRIMMING)
implemented in the driver currently, the other ones are defined in
calibration_type enum but are not implemented.
The commit 9d97e5c8 (hwmon: Add driver for EXYNOS4 TMU) added
TYPE_TWO_POINT_TRIMMING implementation but no users of
There is no need for abstracting configuration for registers that
are identical on all SoC types.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Amit
* Remove dead temp check from temp_to_code() (this function users
in exynos_tmu_initialize() always pass correct temperatures and
exynos_tmu_set_emulation() returns early for EXYNOS4210 because
TMU_SUPPORT_EMULATION flag is not set on this SoC).
* Move temp_code check from code_to_temp() to
Cache number of non-hardware trigger levels in a new pdata field
(non_hw_trigger_levels) and convert code in exynos_tmu_initialize()
accordingly.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park
Remove runtime checks for negative return values of temp_to_code()
from exynos_tmu_initialize().
The current level temperature data hardcoded in pdata will never
cause a negative temp_to_code() return values and checking itself
is not proper. The checks in question are done at runtime in
a
pdata-reference_voltage and pdata-gain are always defined
to non-zero values so remove the redundant checks from
exynos_tmu_control().
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park
On Mon, 16 Jun 2014, Javier Martinez Canillas wrote:
By using the generic IRQ support in the Register map API, it
is possible to get rid of max77686-irq.c and simplify the code.
Suggested-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Javier Martinez Canillas
The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout
(LDO) regulators. This patch adds support for all these regulators
found on the MAX77802 PMIC and is based on a driver added by Simon
Glass to the Chrome OS kernel 3.8 tree.
Signed-off-by: Javier Martinez Canillas
Hi Arnd,
On 17.06.2014 17:42, Arnd Bergmann wrote:
On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote:
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated driver. However in certain use
cases it is desirable to make a device used with
Javier,
On Mon, Jun 16, 2014 at 11:02 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
@@ -127,15 +175,48 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
}
i2c_set_clientdata(max77686-rtc, max77686);
- max77686_irq_init(max77686);
+
On Tue, Jun 17, 2014 at 01:18:11PM +0100, Will Deacon wrote:
On Tue, Jun 17, 2014 at 12:58:30PM +0100, Thierry Reding wrote:
On Mon, Jun 16, 2014 at 01:57:04PM +0100, Will Deacon wrote:
On Wed, Jun 04, 2014 at 10:12:38PM +0100, Thierry Reding wrote:
It can easily be argued that if the
On 10.06.2014 22:57, Tomasz Figa wrote:
If there is no panel node in DT and instead display timings are provided
directly in FIMD node, there is no panel object created and ctx-panel
becomes NULL. However during Exynos DRM initialization
drm_helper_hpd_irq_event() is called, which in turns
On Wednesday, June 11, 2014 5:58 AM, Tomasz Figa wrote:
If there is no panel node in DT and instead display timings are provided
directly in FIMD node, there is no panel object created and ctx-panel
becomes NULL. However during Exynos DRM initialization
drm_helper_hpd_irq_event() is called,
This patchset add 'exynos_adc_ops' structure which includes some functions
to control ADC operation according to ADC version (v1 or v2).
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/iio/adc/exynos_adc.c | 174
This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.
Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC
Exynos3250
This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
need to control only special clock for ADC. Exynos SoC except for Exynos3250
has not included special clock for ADC. The exynos ADC driver can control
special clock if compatible string is 'exynos3250-adc-v2'.
This patchset support Exynos3250 ADC (Analog Digital Converter) because
Exynos3250 has additional special clock for ADC IP and add 'exynos_adc_ops'
structure to improve readability.
Changes from v3:
- Add new 'exynos_adc_ops' structure to improve readability according to
Tomasz Figa comment[1]
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
Preparing the way for the LPC device, which is just a plaform_device without
interrupts.
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
The lower-level driver may want to provide its own buffers. If so,
there's no need to allocate new ones. This already happens to work
just fine (since we check for size of 0 and use
Hi Doug,
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
The members of struct cros_ec_device were improperly commented, and
intermixed the private and public sections. This is just cleanup to make it
more obvious what goes with
Hi Doug,
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
struct cros_ec_device has a superfluous name field. We can get all the
debugging info we need from the existing ec_name and phys_name fields, so
let's take out the extra
Hi Doug,
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
Remove the three wrapper functions that talk to the EC without passing all
the desired arguments and just use the underlying communication function
that passes everything in
Hi Doug,
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
Just because the host was able to talk to the EC doesn't mean that the EC
was happy with what it was told. Errors in communincation are not the same
as error messages from
Hi,
On 16 June 2014 14:40, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
When communicating with the EC, the cmd_xfer() function should return the
number of bytes it received from the EC, or negative on error.
This is just for the I2C tunnel feature,
Simon,
On Tue, Jun 17, 2014 at 8:35 PM, Simon Glass s...@chromium.org wrote:
Hi Doug,
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
The members of struct cros_ec_device were improperly commented, and
intermixed the private and
Simon,
On Tue, Jun 17, 2014 at 8:39 PM, Simon Glass s...@chromium.org wrote:
Hi Doug,
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
struct cros_ec_device has a superfluous name field. We can get all the
debugging info we need
Hi Doug,
On 17 June 2014 21:22, Doug Anderson diand...@chromium.org wrote:
Simon,
On Tue, Jun 17, 2014 at 8:39 PM, Simon Glass s...@chromium.org wrote:
Hi Doug,
On 16 June 2014 14:39, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
struct
Simon,
On Tue, Jun 17, 2014 at 8:42 PM, Simon Glass s...@chromium.org wrote:
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 4083796..dc37b6b 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@
Simon,
On Tue, Jun 17, 2014 at 9:25 PM, Simon Glass s...@chromium.org wrote:
Hi Doug,
On 17 June 2014 21:22, Doug Anderson diand...@chromium.org wrote:
Simon,
On Tue, Jun 17, 2014 at 8:39 PM, Simon Glass s...@chromium.org wrote:
Hi Doug,
On 16 June 2014 14:39, Doug Anderson
Simon,
On Tue, Jun 17, 2014 at 8:43 PM, Simon Glass s...@chromium.org wrote:
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 09ca789..4d34f1c 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -289,21 +289,23 @@ static int
Simon,
On Tue, Jun 17, 2014 at 8:46 PM, Simon Glass s...@chromium.org wrote:
Hi,
On 16 June 2014 14:40, Doug Anderson diand...@chromium.org wrote:
From: Bill Richardson wfric...@chromium.org
When communicating with the EC, the cmd_xfer() function should return the
number of bytes it
Hi Doug,
On 17 June 2014 21:27, Doug Anderson diand...@chromium.org wrote:
Simon,
On Tue, Jun 17, 2014 at 8:42 PM, Simon Glass s...@chromium.org wrote:
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 4083796..dc37b6b 100644
---
On 2014년 06월 18일 09:09, Tomasz Figa wrote:
On 10.06.2014 22:57, Tomasz Figa wrote:
If there is no panel node in DT and instead display timings are provided
directly in FIMD node, there is no panel object created and ctx-panel
becomes NULL. However during Exynos DRM initialization
On 2014년 06월 11일 15:36, Dan Carpenter wrote:
We recently changed this function to return a pointer instead of an int
so we need to change this zero to a NULL or Sparse complains:
drivers/gpu/drm/exynos/exynos_drm_drv.h:346:47:
warning: Using plain integer as NULL pointer
Hello Chanwoo,
On 18 June 2014 07:50, Chanwoo Choi cw00.c...@samsung.com wrote:
This patchset add 'exynos_adc_ops' structure which includes some functions
to control ADC operation according to ADC version (v1 or v2).
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park
Hi Naveen,
On 06/18/2014 02:27 PM, Naveen Krishna Ch wrote:
Hello Chanwoo,
On 18 June 2014 07:50, Chanwoo Choi cw00.c...@samsung.com wrote:
This patchset add 'exynos_adc_ops' structure which includes some functions
to control ADC operation according to ADC version (v1 or v2).
82 matches
Mail list logo
