On 03/07/2013 01:45 PM, Linus Walleij wrote:
On Wed, Mar 6, 2013 at 1:36 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
This patch series populates the default pin states in client nodes
of Exynos4 and Exynos5 platforms. Exynos4/5 platforms are migrating
to use pinctrl framework and
Heiko Stübner wrote:
Second version of the fixes to address comments gathered from the first
version, like not entering the dt code on non-dt platforms even if
dt-support is present in the kernel.
Patch 1 and 3 got Reviewed-by tags but I only included the one for
patch 1, because patch 3
Abhilash Kesavan wrote:
Adding Kukjin Kim who was accidentally missed out in the re-worked
patches.
Abhilash, please re-send patch so that I could apply this into samsung tree.
Thanks.
- Kukjin
On Wed, Dec 5, 2012 at 8:51 AM, Abhilash Kesavan a.kesa...@samsung.com
wrote:
The exynos5250
This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to
drivers/cpufreq.
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
arch/arm/Kconfig
On Sat, Mar 23, 2013 at 01:37:04PM +, Thomas Petazzoni wrote:
On Sat, 23 Mar 2013 10:41:56 +, Russell King - ARM Linux wrote:
Please look at how IORESOURCE_* stuff is defined:
#define IORESOURCE_TYPE_BITS0x1f00 /* Resource type */
#define IORESOURCE_IO
Linus Walleij wrote:
On Wed, Mar 6, 2013 at 1:36 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
This patch series populates the default pin states in client nodes
of Exynos4 and Exynos5 platforms. Exynos4/5 platforms are migrating
to use pinctrl framework and having the default
Tushar Behera wrote:
On 03/07/2013 01:45 PM, Linus Walleij wrote:
On Wed, Mar 6, 2013 at 1:36 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
This patch series populates the default pin states in client nodes
of Exynos4 and Exynos5 platforms. Exynos4/5 platforms are migrating
to
Hi Kukjin Kim,
Can you please apply these patches?
On Fri, Mar 22, 2013 at 7:26 PM, Vikas Sajjan vikas.saj...@linaro.org wrote:
This patch series adds support for DRM FIMD DT for Exynos4 DT Machines,
specifically for Exynos4412 SoC.
changes since v8:
- addressed comments to add
On 22 March 2013 19:26, Vikas Sajjan vikas.saj...@linaro.org wrote:
From: Sachin Kamat sachin.ka...@linaro.org
Adds the lcd panel related picntrl nodes for Exynos4412 SoC
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
Hi all,
As we discussed before, it's time to decide to support non-DT for EXYNOS
SoCs.
If everybody else agrees to drop non-DT support from v3.10, I will. Feel
free to talk your opinion about that.
Thanks.
- Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
On 22 March 2013 19:26, Vikas Sajjan vikas.saj...@linaro.org wrote:
Adds FIMD DT support to Origen quad board
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos4412-origen.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git
Vikas Sajjan wrote:
Hi Kukjin Kim,
Can you please apply these patches?
Please address comments from Thomas about board-specific feature.
Thanks.
- Kukjin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
On 22 March 2013 19:26, Vikas Sajjan vikas.saj...@linaro.org wrote:
Adds FIMD DT binding documentation for both Samsung SoC and Board, with an
example
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
.../devicetree/bindings/video/samsung-fimd.txt | 68
On Monday 25 March 2013, Kukjin Kim wrote:
Hi all,
As we discussed before, it's time to decide to support non-DT for EXYNOS
SoCs.
If everybody else agrees to drop non-DT support from v3.10, I will. Feel
free to talk your opinion about that.
+1
That will certainly simplify enabling
On Wed, Mar 20, 2013 at 9:54 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
Adds support for High Speed I2C driver found in Exynos5 and later
SoCs from Samsung. This driver currently supports Auto mode.
Driver only supports Device Tree method.
Note: Added debugfs support for
On 03/25/2013 12:10 PM, Thomas Abraham wrote:
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -0,0 +1,68 @@
+Device-Tree bindings for Samsung SoC display controller (FIMD)
[...]
+- interrupts : should contain a list of all FIMD IP block interrupts:
+ FIFO
On Mon, Mar 25, 2013 at 08:01:23PM +0900, Kukjin Kim wrote:
As we discussed before, it's time to decide to support non-DT for EXYNOS
SoCs.
If everybody else agrees to drop non-DT support from v3.10, I will. Feel
free to talk your opinion about that.
No problem for me on Exynos, though it
Am Montag, 25. März 2013, 12:01:23 schrieb Kukjin Kim:
Hi all,
As we discussed before, it's time to decide to support non-DT for EXYNOS
SoCs.
If everybody else agrees to drop non-DT support from v3.10, I will. Feel
free to talk your opinion about that.
no problems here ... as long as the
On Monday 25 March 2013, Mark Brown wrote:
On Mon, Mar 25, 2013 at 08:01:23PM +0900, Kukjin Kim wrote:
As we discussed before, it's time to decide to support non-DT for EXYNOS
SoCs.
If everybody else agrees to drop non-DT support from v3.10, I will. Feel
free to talk your opinion
On Mon, Mar 25, 2013 at 12:37:38PM +, Arnd Bergmann wrote:
We don't have any DT support for S3C and S5P upstream yet, so I would
certainly agree on that. I think we should plan at least one release of
supporting both simultaneously in order to find bugs with the DT
implementation before
On Monday 25 March 2013, Mark Brown wrote:
On Mon, Mar 25, 2013 at 12:37:38PM +, Arnd Bergmann wrote:
We don't have any DT support for S3C and S5P upstream yet, so I would
certainly agree on that. I think we should plan at least one release of
supporting both simultaneously in order
This patch adds device node for the SYSREG registers block
present in Exynos SoC series. The SYSREG block generates
control signals for the ARM CPU and various IP blocks and
buses. The SYSREG registers are exposed through APB bus
interface. The sysreg device tree node is to be associated
with the
Thomas,
On Mon, Mar 11, 2013 at 10:53 AM, Doug Anderson diand...@google.com wrote:
It would be good to address Seungwon Jeon's comments (change prefix to
dw_mmc and remove setup_bus), but in general this looks good to me,
so...
Are you planning on doing this? I noticed that Chris pulled your
On Thu, Mar 21, 2013 at 11:06:47AM +, Mark Rutland wrote:
On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
in preference to the architected timer:
Architected local timer running at 24.00MHz (virt).
Switching to timer-based delay loop
Registered
After more discussion with Arnd Bergmann on v4 it seems a better way to
handle the interrupt controllers inside the s3c24xx SoCs is to not have
separate controller nodes, but to bundle the controllers into one node
and access the individual controllers via interrupt descriptor of the
device nodes.
This move is necessary to make use of the irqchip infrastructure
for the following devicetree support for s3c24xx architectures.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
arch/arm/mach-s3c24xx/Makefile |2 +-
drivers/irqchip/Makefile
Might be confusing for people to read the code without having the
datasheet nearby.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/irqchip/irq-s3c24xx.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-s3c24xx.c
On 03/25/2013 12:26 PM, Russell King - ARM Linux wrote:
On Thu, Mar 21, 2013 at 11:06:47AM +, Mark Rutland wrote:
On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
in preference to the architected timer:
Architected local timer running at 24.00MHz (virt).
The list in used was from the s3c2450, a close cousin of the s3c2416.
As it's not possible to distinguish between the s3c2416 and s3c2450
the additional interrupts of the s3c2450 will only be available thru
devicetree later.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
Enables post-init setting of the desired typehandler for the interrupt.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/irqchip/irq-s3c24xx.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/irqchip/irq-s3c24xx.c b/drivers/irqchip/irq-s3c24xx.c
For dt-enabled machines we want to use a big irq_domain over all controllers
and therefore need to access not only the main controllers but the
sub-controller as well.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/irqchip/irq-s3c24xx.c | 99 +
Keep a pointer to the corresponding s3c_irq_data struct as irq_chip_data.
This removes the need to fetch the intc struct from the irq_domains
host_data, thus making it independent of the underlying irq_domain
structure.
Also keep the real register offset of the interrupt in the s3c_irq_data
On Monday 25 March 2013, Heiko Stübner wrote:
Add the necessary code to initialize the interrupt controller
thru devicetree data using the irqchip infrastructure.
Signed-off-by: Heiko Stuebner he...@sntech.de
The binding looks fine now. I have a few detail comments but am happy
with the
On Monday 25 March 2013, Rob Herring wrote:
I count integrator-cp, realview, versatile and non-DT VExpress that do
this (not surprisingly) and 25 platforms or timer implementations plus
arm64 that do sched_clock setup in time_init. What's broken by not
moving these earlier?
timekeeping_init()
On 03/25/2013 03:36 PM, Arnd Bergmann wrote:
On Monday 25 March 2013, Rob Herring wrote:
I count integrator-cp, realview, versatile and non-DT VExpress that do
this (not surprisingly) and 25 platforms or timer implementations plus
arm64 that do sched_clock setup in time_init. What's broken by
On Mon, Mar 25, 2013 at 09:28:10PM +, Rob Herring wrote:
On 03/25/2013 12:26 PM, Russell King - ARM Linux wrote:
On Thu, Mar 21, 2013 at 11:06:47AM +, Mark Rutland wrote:
On TC2 this series leads to using the vexpress 24MHz clock as the sched
clock
in preference to the
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/mach-s3c24xx/mach-h1940.c | 8
Many backlights are enabled via GPIO. We can generalize the GPIO to a
fixed regulator.
The power regulator needs to be mandatory because there was no good way
to determine the difference between opting out of the regulator, and probe
deferral.
This series of patches is intended to add a dummy
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Alexandre Courbot acour...@nvidia.com
Acked-by: Tony Prisk li...@prisktech.co.nz
---
Made
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Alexandre Courbot acour...@nvidia.com
---
Moved backlight power regulator into top-level
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Alexandre Courbot acour...@nvidia.com
---
arch/unicore32/kernel/puv3-nb0916.c | 9
Many backlights need to be explicitly powered. Typically, this is done
with a GPIO. For flexibility, we generalize the power mechanism to a
regulator.
If a power regulator is not needed, then a dummy fixed regulator can be
given to the backlight driver. If a GPIO is used to enable the
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Tested-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Alexandre Courbot acour...@nvidia.com
---
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/mach-pxa/cm-x300.c | 7
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Alexandre Courbot acour...@nvidia.com
---
arch/arm/mach-exynos/mach-nuri.c | 7
On 03/25/2013 05:53 PM, John Stultz wrote:
On 03/25/2013 03:36 PM, Arnd Bergmann wrote:
On Monday 25 March 2013, Rob Herring wrote:
I count integrator-cp, realview, versatile and non-DT VExpress that do
this (not surprisingly) and 25 platforms or timer implementations plus
arm64 that do
From: Prasanna Kumar prasanna...@samsung.com
Gscaler :
1. For aclk_300_gscl,following clocks are added
Mux clocks
mout_aclk_300_gscl_mid,
mout_aclk_300_gscl_mid1,
mout_aclk_300_gscl
Divider clock
From: Prasanna Kumar prasanna...@samsung.com
This patch adds support for restoring CLK_SRC_TOP3 register
which gets modified while powergating corresponding power domains
after a cycle of Suspend-to-Resume.
Please refer below URL to know the background of this issue.
From: Prasanna Kumar prasanna...@samsung.com
According to Common clock framework, clock definition is added
for exynos5250
Signed-off-by: Prasanna Kumar prasanna...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
From: Prasanna Kumar prasanna...@samsung.com
According to Common Clock framework , modified the method of getting
clock for MFC Block.
Signed-off-by: Prasanna Kumar prasanna...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |2 +-
1 files changed, 1 insertions(+), 1
On Mon, Mar 25, 2013 at 06:21:50PM -0700, Andrew Chew wrote:
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew ac...@nvidia.com
Acked-by: Alexandre Courbot
51 matches
Mail list logo
