Hi Joonyoung,
Thanks for review.
On 08/26/2014 04:59 AM, Joonyoung Shim wrote:
On 08/26/2014 11:55 AM, Joonyoung Shim wrote:
Hi Andrzej,
On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
Command node should contain file reference to distinguish commands
created by different processes.
On 08/26/2014 07:53 AM, Joonyoung Shim wrote:
Hi Andrzej,
On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
The patch removes redundant checks, redundant HW reads
and simplifies code.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 64
Hello,
On 2014-08-25 22:05, Greg Kroah-Hartman wrote:
On Tue, Aug 05, 2014 at 12:47:32PM +0200, Marek Szyprowski wrote:
This patch adds support for getting a notify for failed device driver
bind, so all the items done in BUS_NOTIFY_BIND_DRIVER event can be
cleaned if the driver fails to bind.
Hello,
On 2014-08-25 23:18, Joerg Roedel wrote:
On Tue, Aug 05, 2014 at 12:47:32PM +0200, Marek Szyprowski wrote:
+ if (failed dev-bus)
+ blocking_notifier_call_chain(dev-bus-p-bus_notifier,
+BUS_NOTIFY_DRVBIND_FAILED, dev);
+
On 08/26/2014 07:57 AM, Joonyoung Shim wrote:
Hi Andrzej,
On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
FIMC in default mode of operation uses only one input buffer,
but the driver used also second buffer, as a result only the
first frame was processed correctly. The patch fixes it.
I can't
On 08/26/2014 03:35 PM, Andrzej Hajda wrote:
On 08/26/2014 07:57 AM, Joonyoung Shim wrote:
Hi Andrzej,
On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
FIMC in default mode of operation uses only one input buffer,
but the driver used also second buffer, as a result only the
first frame was
On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
This set of patches contains various improvement and fixes
for exynos_drm ipp framework.
The patchset is based on exynos-drm-next branch.
IPP framework was tested for regressions on exynos4210-trats target.
Regards
Andrzej
Andrzej Hajda
On Mon, Aug 25, 2014 at 08:40:40AM -0700, Doug Anderson wrote:
On Mon, Aug 25, 2014 at 2:07 AM, Javier Martinez Canillas
I see, so probably until we have a way to define the operating mode for
each regulator using DT we should set the opmode to normal when enabling a
regulator
When building a kernel with support for both USB host and USB Gadget support on
the dwc3 controller on the Exynos5 soc will go into USB OTG mode unless
otherwise specified in the dtb, which is unhelpful for boards hooked up to run
as USB host.
First patch in this set explicitely set the dual-role
Enable USB gadget support without support for any specific gadgets to
more easily catch cases where a devices dts doesn't specify the usb
controllers dr_mode while it should.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes in v2: none
arch/arm/configs/exynos_defconfig |
In case the optional dr_mode property isn't set in the dwc3 nodes the
the controller will go into OTG mode iff both USB host and USB gadget
functionality are enabled in the kernel configuration. Unfortunately this
results in USB not working on exynos5420-peach-pit and
exynos5800-peach-pi with such
On 25 August 2014 17:20, Doug Anderson diand...@google.com wrote:
Ulf,
On Mon, Aug 25, 2014 at 1:13 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 22 August 2014 20:27, Sonny Rao sonny...@chromium.org wrote:
On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 22
To enable the cros-ec-tunnel driver to be auto-loaded when build as a
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons
To enable the cros_ec_keyb driver to be auto-loaded when build as
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: Sjoerd Simons
The ChromeOS EC MFD driver registers its sub-devices with both a (platform)
name and an of compatibility string. As a result of this the modalias passed on
to user-space will be based on the of compatibility string. Thus to be able to
rely on autoloading in case the subdevices are build as modules
Hello Dmitry,
On 08/25/2014 08:01 PM, Dmitry Torokhov wrote:
On Mon, Aug 25, 2014 at 07:28:01PM +0200, Javier Martinez Canillas wrote:
#7 does not apply to my tree (I guess it depends on the 1st batch which I
expect will go through MFD tree?). Maybe you could rebase it on top of my
Hello Mark,
On 08/26/2014 09:17 AM, Mark Brown wrote:
On Mon, Aug 25, 2014 at 08:40:40AM -0700, Doug Anderson wrote:
Can you please test the following change [0] so I can post as a proper
patch? Doug, Mark do you think that forcing the regulator to opmode normal
when enabling is the right
On Tue, Aug 26, 2014 at 11:08:07AM +0200, Javier Martinez Canillas wrote:
On 08/26/2014 09:17 AM, Mark Brown wrote:
No, this doesn't make any obvious sense to me at all. Picking normal as
a default if the hardware reads back off due to overlapping
impelementation or something *might* make
Hi!
Would you elaborate?
If I have a device like a phone, I may want to put one slot inside
phone for basic system, and offer second slot for user expansion
(initially empty).
if multiple slot is supported, then a mmcqd should be processing for
multiple slots.
It's too
Hi kukjin,
On Tue, Aug 19, 2014 at 12:37 PM, Vikas Sajjan vikas.saj...@samsung.com wrote:
Refactoring the pm.c to avoid using soc_is_exynos checks,
instead use the DT based lookup.
While at it, consolidate the common code across SoCs
and create static helper functions.
Signed-off-by: Vikas
The max77802 driver reads the default operating mode (opmode)
set for regulators when enabled from the hardware registers.
But if a regulator is disabled and the system warm restarted,
the hardware reports OFF as the opmode so the regulator is
not enabled. Default to operating mode NORMAL if OFF
From: Tomasz Figa t.f...@samsung.com
This patch moves Exynos power domain code to use the new generic power
domain look-up framework introduced in previous patches, thus also
allowing the new code to be compiled with CONFIG_ARCH_EXYNOS as well.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Cc:
Hello,
This is another approach to finish support for reserved memory regions
defined in device tree. Previous attempts
(http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html
and https://lkml.org/lkml/2014/7/14/108) ended in merging parts of the
code and documentation. Merged
Enable support for Multimedia Codec (MFC) device for all Exynos4412-based
Odroid boards.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24
1 file changed, 24 insertions(+)
diff --git
This patch removes custom initialization of reserved memory regions from
s5p-mfc driver and adds a new code for handling reserved memory with
generic named reserved memory regions read from device tree.
s5p-mfc driver now handles two reserved memory regions: left and
right, defined by generic
Add a function to create CMA region from previously reserved memory
and add support for handling 'shared-dma-pool' reserved-memory device
tree nodes.
Based on previous code provided by Josh Cartwright jo...@codeaurora.org
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
This patch adds a code to initialize memory regions also for child devices
if parent device has memory-region and memory-region-names device tree
properties and given device's name matches parent_name:region_name
template.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
Driver calling of_reserved_mem_device_init() might be interested if the
initialization has been successful or not, so add support for returning
error code.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/of/of_reserved_mem.c| 3 ++-
include/linux/of_reserved_mem.h | 9
Initialization procedure of dma coherent pool has been split into two
parts, so memory pool can now be initialized without assigning to
particular struct device. Then initialized region can be assigned to
more than one struct device. To protect from concurent allocations from
different devices, a
Support for reserved memory for MFC device (samsung,mfc-r and samsung,mfc-l
properties) was merged quickly without any deep review and discussion. This
patch replaces those custom properties with support for
generic reserved memory bindings. All custom code for handling MFC-specific
reserved
Hello,
On 2014-08-12 15:00, Tomeu Vizoso wrote:
On 1 July 2014 10:10, Marek Szyprowski m.szyprow...@samsung.com wrote:
This is a long awaited patch series enabling support for HDMI output
available on Exynos4412-based Odroid boards (X/X2/U2/U3/U3+) and
Exynos4210 Universal C210 board.
Hello,
This patch adds sleep mode pin configuration using pin control hog
mechanism to configure states of GPIO pins in sleep mode. This is
required to reduce leakage current in sleep mode and prevent glitching
of components on the board.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
This patch extends the firmware_ops structure with two new callbacks:
.suspend() and .resume(). The former is intended to ask the firmware to
save all its volatile state and suspend the system, without returning
back to the kernel in between. The latter is to be called early by
very low level
This patch adds a convenient macro which constructs an Exynos pinctrl
pinconf node containing properties needed to configure sleep state of
given pin with given parameters. It will be used by further patch which
adds a large number of sleep states for pins that need such
configuration on certain
)
- added board-specific fixes for device tree sources of Trats2 board,
- rebased on next-20140826 of linux-next tree.
Changes since v1:
- dropped outer_resume() - will be handled in assembly in further patches,
as support for L2C in non-secure mode gets added,
- moved CP15 resume to assembly
The group has the samsung,pin-pud property set to 4, which is not a
correct value. This patch fixes this by replacing it with 3, which is
the correct value for pull-up.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 2 +-
1 file changed, 1
On a numer of Exynos-based boards Linux kernel is running in non-secure
mode under a secure firmware. This means that certain operations need to
be handled in special way, with firmware assistance. System-wide
suspend/resume is an example of such operations.
This patch adds support for
On Exynos SoCs it is necessary to resume operation of L2C early in
assembly code, because otherwise certain systems will crash. This patch
adds necessary code to non-secure resume handler.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/common.h | 1 +
Certain platforms (i.e. Exynos) might need to set .write_sec callback
from firmware initialization which is happenning in .init_early callback
of machine descriptor. However current code will overwrite the pointer
with whatever is present in machine descriptor, even though it can be
already set
Exynos4 SoCs equipped with an L2C-310 cache controller and running under
secure firmware require certain registers of aforementioned IP to be
accessed only from secure mode. This means that SMC calls are required
for certain register writes. To handle this, an implementation of
.write_sec and
Certain implementations of secure hypervisors (namely the one found on
Samsung Exynos-based boards) do not provide access to individual L2C
registers. This makes the .write_sec()-based interface insufficient and
provoking ugly hacks.
This patch is first step to make the driver not rely on
This patch adds device tree nodes for L2 cache controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
2 files changed, 23 insertions(+)
diff --git
This series intends to add support for L2 cache on Exynos4 SoCs on boards
running under secure firmware, which requires certain initialization steps
to be done with help of firmware, as selected registers are writable only
from secure mode.
First four patches extend existing support for secure
Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
settings configured in registers leading to crashes if L2C is enabled
without overriding them. This patch introduces bindings to enable
prefetch settings to be specified from DT and necessary support in the
driver.
Because certain secure hypervisor do not allow writes to individual L2C
registers, but rather expect set of parameters to be passed as argument
to secure monitor calls, there is a need to provide an interface for the
L2C driver to ask the firmware to configure the hardware according to
specified
I am leaving Samsung, so my current e-mail address is not going to work
any longer. Replace it with my private one. In addition, Sylwester
Nawrocki is being added as co-maintainer for Samsung clock drivers to
take some of the responsibilities, as I will be doing my part in my spare
time.
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com wrote:
Hi Kevin,
On Mon, Aug 25, 2014 at 9:02 PM, Kevin Hilman khil...@linaro.org wrote:
Hi Chander,
Chander Kashyap k.chan...@samsung.com writes:
[...]
I'm trying it on the 5800/Chromebook2 and it's not terribly
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
The Peach Pit board has an Atmel maXTouch trackpad device.
Add the needed Device Tree nodes to support it.
This Device Tree change is based on the Chrome OS 3.8 tree
but adapted to use the mainline Atmel maXTouch DT binding.
Signed-off-by:
This is a second version of the series that adds support
for the atmel trackpad found on the Exynos5420 Peach Pit.
The first version was [0] but I missunderstood the DT
bindings since I don't have documentation about this hw.
After the feedback provided by Nick Dyer and Yufeng Shen
I think
Many Exynos based Chromebooks have an Atmel trackpad so enable
support for it by default will make easier for users.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/configs/exynos_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
Some boards with multi platform support (e.g: Exynos based
Chromebooks) have an Atmel trackpad so enable support for
as a module will make easier for users.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1
Javier,
On Tue, Aug 26, 2014 at 4:37 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The max77802 driver reads the default operating mode (opmode)
set for regulators when enabled from the hardware registers.
But if a regulator is disabled and the system warm restarted,
On Mon, 25 Aug 2014 09:57:33 +0900 Chanwoo Choi cw00.c...@samsung.com wrote:
Dear Andrew,
On 08/23/2014 05:42 AM, Andrew Morton wrote:
On Tue, 12 Aug 2014 11:01:07 +0900 y...@samsung.com wrote:
This patch define s3c_rtc structure including necessary variables for S3C
RTC
device
On Tue, Aug 26, 2014 at 8:15 AM, Kevin Hilman khil...@linaro.org wrote:
On Mon, Aug 25, 2014 at 10:25 PM, Chander Kashyap k.chan...@samsung.com
wrote:
[...]
Can you clarify how you're setting the voltages to ensure stability?
below is the diff : wip/exynos/integ
Thanks.
I've applied
Hi Javier,
Am 26.08.2014 17:28, schrieb Javier Martinez Canillas:
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
The Peach Pit board has an Atmel maXTouch trackpad device.
Add the needed Device Tree nodes to support it.
This Device Tree change is based on the Chrome OS 3.8 tree
but
Am 26.08.2014 09:30, schrieb Sjoerd Simons:
In case the optional dr_mode property isn't set in the dwc3 nodes the
the controller will go into OTG mode iff both USB host and USB gadget
functionality are enabled in the kernel configuration. Unfortunately this
results in USB not working on
Am 26.08.2014 09:30, schrieb Sjoerd Simons:
Enable USB gadget support without support for any specific gadgets to
more easily catch cases where a devices dts doesn't specify the usb
controllers dr_mode while it should.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
Changes
On Thursday, August 21, 2014 11:55 PM, Vivek Gautam wrote:
Adding phy calibrate callback, which facilitates setting certain
PHY settings post initialization of the PHY controller.
Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
the Loss-of-Signal (LOS) Detector Threshold Level
Hi,
Am 26.08.2014 09:30, schrieb Sjoerd Simons:
I suspect other boards base using exynos5420/5800 might need the similar fixes
(Arndale Octa and Samsung SMDK5420) to their dts files, so would be great if
folks with those board could verify this.
usbdrd_dwc3_1 is indeed required for the
Hi,
On 08/26/2014 07:19 PM, Pavel Machek wrote:
Hi!
Would you elaborate?
If I have a device like a phone, I may want to put one slot inside
phone for basic system, and offer second slot for user expansion
(initially empty).
if multiple slot is supported, then a mmcqd should be
Hi, Doug,
On 08/26/2014 12:25 AM, Doug Anderson wrote:
Jaehoon,
On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
On 08/25/2014 05:13 PM, Ulf Hansson wrote:
On 22 August 2014 20:27, Sonny Rao sonny...@chromium.org wrote:
On Fri, Aug 22, 2014 at 8:31 AM, Ulf
Hi.
On 08/26/2014 12:20 AM, Doug Anderson wrote:
Ulf,
On Mon, Aug 25, 2014 at 1:13 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 22 August 2014 20:27, Sonny Rao sonny...@chromium.org wrote:
On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 22 August 2014
Jaehoon,
On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi, Doug,
On 08/26/2014 12:25 AM, Doug Anderson wrote:
Jaehoon,
On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung jh80.ch...@samsung.com
wrote:
On 08/25/2014 05:13 PM, Ulf Hansson wrote:
On 22 August 2014
Doug,
On 08/27/2014 01:14 PM, Doug Anderson wrote:
Jaehoon,
On Tue, Aug 26, 2014 at 8:48 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi, Doug,
On 08/26/2014 12:25 AM, Doug Anderson wrote:
Jaehoon,
On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung jh80.ch...@samsung.com
wrote:
On
64 matches
Mail list logo
