On 2013년 06월 19일 15:50, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
This patch can be merged after merging "[PATCH 1/4] drm/exynos: rename
compatible strings for hdmi subsystem".
Best Regards,
- Seu
Add support for exynos5420 mixer IP in the drm mixer driver.
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/video/exynos_mixer.txt |1 +
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +++-
drivers/gpu/drm/exynos/regs-mixer.h|7 +++
Applied.
Thanks,
Inki Dae
> -Original Message-
> From: 김승우 [mailto:sw0312@samsung.com]
> Sent: Wednesday, June 19, 2013 2:34 PM
> To: Rahul Sharma
> Cc: linux-samsung-...@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org;
> dri-de...@lists.freedesktop.org; kgene@samsung.com;
>
On 6/7/2013 5:02 PM, Mugunthan V N wrote:
Add pinmux DT nodes to CPSW for the following AM335x boards
* AM335x Beaglebone
* AM335x EVM
* AM335x EVMsk
default state contains the pinmux required for active mode and
sleep mode contains pinmux reset values for energy saving.
Mugunthan V N (3):
AR
To disable spurious interrupts, that get triggered on certain hardware, the
irqpin driver masks them on the parent interrupt controller. To specify
such broken devices a .control_parent parameter can be provided in the
platform data. In the DT case we need a property, to do the same.
Signed-off-by
Hi Rahul,
It looks good, at least, to me.
Best Regards,
- Seung-Woo Kim
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was a
Hi Rahul,
This patch looks good to me.
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
> Modified code for calculating hdmi IP register values from drm timing
> values. The modification is based on the inputs from hw team and specifically
> proposed for 1440x576i and 1440x480i. But same changes holds
Sure Seung-Woo,
I will update binding document along with this patch.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 10:54 AM, 김승우 wrote:
> Hi Rahul,
>
> Code part looks good to me but IMHO, binding document for exynos_mixer
> is also fixed like following because compitable string
> samsung,exy
From: Kishon Vijay Abraham I
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
---
Chang
Hi Rahul,
Code part looks good to me but IMHO, binding document for exynos_mixer
is also fixed like following because compitable string
samsung,exynos5420-mixer is added with this patch.
Required properties:
- compatible: value should be:
1) "samsung,exynos4210-mixer"
2) "samsun
On 06/17/2013 10:20 AM, Tushar Behera wrote:
> On 06/11/2013 12:23 AM, Tomasz Figa wrote:
>> On Monday 10 of June 2013 09:13:11 Tushar Behera wrote:
>>> On 06/08/2013 05:20 PM, Tomasz Figa wrote:
On Thursday 06 of June 2013 16:52:28 Tushar Behera wrote:
>
> [ ... ]
>
> MUX_A(mout_core,
+ mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote:
> Add clock changes for hdmi subsystem for exynos5250 SoC. These
> include addition of new clocks like mout_hdmi and smmu_tv, associating
> ID to clk_hdmiphy and some essential corrections.
>
> This set is based on kukjin's for-next bran
From: Wei Yongjun
Fix to return -ENOMEM in the kmem_cache_create() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun
---
drivers/infiniband/hw/ehca/ehca_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/hw/ehca/ehca_mai
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dts
Hi Eduardo,
On 06/18/2013 03:16 PM, Eduardo Valentin wrote:
Benoit
On 07-06-2013 16:46, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: l
On Tuesday, June 18, 2013 10:57 PM, Arnd Bergmann wrote:
> On Tuesday 18 June 2013, Jingoo Han wrote:
> > On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
> > > On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
> > > > On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
> > > > >
[.]
On Tue, Jun 18, 2013 at 07:09:29PM -0300, Ezequiel Garcia wrote:
> On Tue, Jun 18, 2013 at 06:16:26PM +0200, Arnd Bergmann wrote:
> > On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> > >
> > > + devbus-bootcs {
> > > + compatible = "marvell,mvebu-devbus";
> > >
On Tue, Jun 18, 2013 at 06:16:26PM +0200, Arnd Bergmann wrote:
> On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> >
> > + devbus-bootcs {
> > + compatible = "marvell,mvebu-devbus";
> > + reg = <0x0001 0x10400 0x8>;
> > +
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> On Tue, Jun 18, 2013 at 06:14:33PM +0200, Arnd Bergmann wrote:
> > On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> > > +Required properties:
> > > +
> > > +- compatible: Should be set to one of the following:
> > > + marvell,armada370
On Tue, Jun 18, 2013 at 11:20:07PM +0200, Arnd Bergmann wrote:
> On Tuesday 18 June 2013, Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote:
> >
> > > > > > Arnd, we've discussed this at length with you while getting the PCIe
> > > > > > driver merged, and we
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> +
> + ranges =
> + <0x8200 0 0x40x0001 0x4 0
> 0x2000
> + 0x8200 0 0x80x0001 0x8 0
> 0x2000
> +
Arnd,
On Tue, Jun 18, 2013 at 06:14:33PM +0200, Arnd Bergmann wrote:
> On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> > +Required properties:
> > +
> > +- compatible: Should be set to one of the following:
> > +marvell,armada370-mbus
> > +marvell,armadaxp-mbus
> >
Hi Kishon,
I've noticed there is a little inconsistency between the code and
documentation.
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provid
On Tuesday 18 June 2013, Jason Gunthorpe wrote:
> On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote:
>
> > > > > Arnd, we've discussed this at length with you while getting the PCIe
> > > > > driver merged, and we've explained this to you numerous times. Could
> > > > > you please unde
On Tue, Jun 18, 2013 at 02:55:22PM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 18, 2013 at 05:49:11PM -0300, Ezequiel Garcia wrote:
> > Hi Sebastian,
> >
> > You loose +1 internet points for dropping me from Cc ;-)
> >
> > On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
> >
On Tue, Jun 18, 2013 at 05:49:11PM -0300, Ezequiel Garcia wrote:
> Hi Sebastian,
>
> You loose +1 internet points for dropping me from Cc ;-)
>
> On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
> > On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
> > >
> > > The forms could b
Hi Sebastian,
You loose +1 internet points for dropping me from Cc ;-)
On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
> On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
> >
> > The forms could be:
> >
> > 0IAA
> > FK00
> > - K=0 -> internal regs
> > - K=
From: Dinh Nguyen
Add bindings for SD/MMC for SOCFPGA.
Add "syscon" to the "altr,sys-mgr" binding.
Signed-off-by: Dinh Nguyen
Reviewed-by: Pavel Machek
CC: Arnd Bergmann
CC: Olof Johansson
Cc: Pavel Machek
Cc: Grant Likely
Cc: Rob Herring
Cc: Chris Ball
Cc: devicetree-discuss@lists.ozlab
On Tue, Jun 18, 2013 at 02:10:21PM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 18, 2013 at 05:02:42PM -0300, Ezequiel Garcia wrote:
> > > Having the kernel enforce that the DT node is present and at the right
> > > location, I think, is helpful for the bootloader folks to ensure they
> > > write co
On Tue, Jun 18, 2013 at 11:40 AM, John Stultz wrote:
> On 06/18/2013 11:28 AM, Heiko Stübner wrote:
>>
>> Am Dienstag, 18. Juni 2013, 17:38:35 schrieb Heiko Stübner:
>>>
>>> Hi Pavel,
>>>
>>> Am Dienstag, 18. Juni 2013, 17:02:44 schrieb Pavel Machek:
Hi!
>> The following 2 patch
On Tue, Jun 18, 2013 at 05:02:42PM -0300, Ezequiel Garcia wrote:
> > Having the kernel enforce that the DT node is present and at the right
> > location, I think, is helpful for the bootloader folks to ensure they
> > write correct DTs.
> Granted. But then I wonder... why do we bother to put the B
On Tue, Jun 18, 2013 at 01:51:11PM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 18, 2013 at 04:43:31PM -0300, Ezequiel Garcia wrote:
>
> > > I think some kind of test is needed here. As I understand it the SMP
> > > startup uses a trampoline in the boot rom and the boot rom *must* be
> > > mapped t
On Tue, Jun 18, 2013 at 04:43:31PM -0300, Ezequiel Garcia wrote:
> > I think some kind of test is needed here. As I understand it the SMP
> > startup uses a trampoline in the boot rom and the boot rom *must* be
> > mapped to 0xfff0 ?
> Yes, that's my understanding as well, but I will do some
On Tue, Jun 18, 2013 at 09:42:48PM +0200, Sebastian Hesselbarth wrote:
> On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
> > Although the internal register window size is 1 MiB, the previous
> > ranges translation for the internal register space had a size of
> > 0x400. This was done to allow th
On Tue, Jun 18, 2013 at 11:39:06AM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 18, 2013 at 08:25:30AM -0300, Ezequiel Garcia wrote:
> > The address decoding window to access the BootROM should not be
> > allocated programatically, but instead declared in the device tree.
> >
> > Signed-off-by: Eze
On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
Although the internal register window size is 1 MiB, the previous
ranges translation for the internal register space had a size of
0x400. This was done to allow the crypto and nand node to access
the corresponding 'sram' and 'nand' decoding windo
On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:59:03PM +0200, Sebastian Hesselbarth wrote:
S = 0 means 4 bit I, 8 bit A
S = F means special
S = 1 could mean 16 bit I, etc , etc
S& 0x8 == 0x0 means 7b target
S& 0x8 == 0x8 means 7b special ?
No need, special == mb
On Tue, Jun 18, 2013 at 08:59:03PM +0200, Sebastian Hesselbarth wrote:
> >S = 0 means 4 bit I, 8 bit A
> >S = F means special
> >S = 1 could mean 16 bit I, etc , etc
>
> S & 0x8 == 0x0 means 7b target
> S & 0x8 == 0x8 means 7b special ?
No need, special == mbus driver defined. There is no target
On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote:
> > > > Arnd, we've discussed this at length with you while getting the PCIe
> > > > driver merged, and we've explained this to you numerous times. Could
> > > > you please understand that any of your proposal that suggests writing
> >
On 06/18/2013 08:47 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:44:30PM +0200, Sebastian Hesselbarth wrote:
Yeah, I also recall Thomas or Gregory mention a 32b limitation in
remap windows. But we don't need to waste addresses here
And even if SIAA is a concern because there may be
On Tue, Jun 18, 2013 at 08:44:30PM +0200, Sebastian Hesselbarth wrote:
> On 06/18/2013 08:39 PM, Arnd Bergmann wrote:
> >On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
> >>Also allows you to have up to 40b offset, which might be important
> >>with LPAE enabled.
> >
> >Not with the current ge
On 06/18/2013 08:39 PM, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
Also allows you to have up to 40b offset, which might be important
with LPAE enabled.
Not with the current generation I think, since the mbus windows are
32 bit only, but it would avoid having to
On 06/18/2013 11:28 AM, Heiko Stübner wrote:
Am Dienstag, 18. Juni 2013, 17:38:35 schrieb Heiko Stübner:
Hi Pavel,
Am Dienstag, 18. Juni 2013, 17:02:44 schrieb Pavel Machek:
Hi!
The following 2 patches will eliminate the need for the patch in John
Stultz's tree. If there is to be merge of th
On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
> On 06/18/2013 07:46 PM, Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
> >> +
> >> +IIAA
> >> +
> >> +Where:
> >> + -- I = Marvell defined target ID for programmable windows
> >> + -- A = Marv
On Tue, Jun 18, 2013 at 04:11:16PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 05:02:49PM +0200, Linus Walleij wrote:
> > Nowadays I would do the above with regmap_update_bits().
> > Mutual exclusion for read-modify-write of individual bits in a
> > register is one of those ca
Am Dienstag, 18. Juni 2013, 17:38:35 schrieb Heiko Stübner:
> Hi Pavel,
>
> Am Dienstag, 18. Juni 2013, 17:02:44 schrieb Pavel Machek:
> > Hi!
> >
> > > >The following 2 patches will eliminate the need for the patch in John
> > > >Stultz's tree. If there is to be merge of the 2 trees, then the
>
On 06/18/2013 07:46 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
+
+IIAA
+
+Where:
+ -- I = Marvell defined target ID for programmable windows
+ -- A = Marvell defined target attributes for programmable windows
I thought we agreed to somethi
On Tue, Jun 18, 2013 at 07:44:48PM +0200, Lubomir Rintel wrote:
> This adds a driver for watchdog timer hardware present on Broadcom BCM2835
> SoC,
> used in Raspberry Pi and Roku 2 devices.
>
> Signed-off-by: Lubomir Rintel
> Tested-by: Stephen Warren
> Cc: Stephen Warren
> Cc: Wim Van Sebroe
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
> On Tue, 18 Jun 2013 19:18:58 +0200, Arnd Bergmann wrote:
>
> > > >ranges =
> > > > <0x8200 0 0x40x0001
> > > > 0x4 0 0x2000
> > > >0x820
On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
> +
> +IIAA
> +
> +Where:
> + -- I = Marvell defined target ID for programmable windows
> + -- A = Marvell defined target attributes for programmable windows
I thought we agreed to something like:
SIAA
Where 'S' is the de
On Tue, Jun 18, 2013 at 08:25:30AM -0300, Ezequiel Garcia wrote:
> The address decoding window to access the BootROM should not be
> allocated programatically, but instead declared in the device tree.
>
> Signed-off-by: Ezequiel Garcia
> arch/arm/mach-mvebu/platsmp.c | 1 -
> 1 file changed, 1 d
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
> > To clarify my earlier comment, I think it would be nicer to write this as
> >
> >ranges =
> > <0x8200 0 0x40x0001 0x4 0
> > 0x2000
> >
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
>
> On Tue, 18 Jun 2013 18:14:33 +0200, Arnd Bergmann wrote:
>
> > Using 0x0002 as a placeholder for the pcie translation is definitely
> > better than 0x as you had before, but let me ask again in case
> > you mis
Dear Arnd Bergmann,
On Tue, 18 Jun 2013 19:18:58 +0200, Arnd Bergmann wrote:
> > >ranges =
> > > <0x8200 0 0x40x0001 0x4
> > > 0 0x2000
> > >0x8200 0 0x80x0001 0x8
>
On 06/11/13 15:29, Sachin Kamat wrote:
This series is based on for-next branch of Kukjin's tree.
Tested on Origen board.
Changes since v1:
* Split LCD patch into LCD and PWM as suggested by Tomasz Figa.
* Added all PWM output nodes to pinctrl dtsi file.
Sachin Kamat (3):
ARM: dts: exynos4210
Dear Arnd Bergmann,
On Tue, 18 Jun 2013 18:29:35 +0200, Arnd Bergmann wrote:
> To clarify my earlier comment, I think it would be nicer to write this as
>
>ranges =
> <0x8200 0 0x40x0001 0x4 0
> 0x2000
>
On 06/18/13 14:09, Rahul Sharma wrote:
Hi Mr. Kukjin,
Kindly consider the following patches for review and integration.
(+ Mike)
Rahul, basically, looks good to me but I'm waiting for Mike's ack on
this series...
regards,
Rahul Sharma.
On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K wrote
Dear Arnd Bergmann,
On Tue, 18 Jun 2013 18:14:33 +0200, Arnd Bergmann wrote:
> Using 0x0002 as a placeholder for the pcie translation is definitely
> better than 0x as you had before, but let me ask again in case
> you missed it the last time (and sorry if I missed the answer):
>
> W
On Tuesday 18 June 2013, Guennadi Liakhovetski wrote:
> This patch adds Device Tree support to the shdma driver. No special DT
> properties are used, only standard DMA DT bindings are implemented. Since
> shdma controllers reside on SoCs, their configuration is SoC-specific and
> shall be passed to
> Perhaps a more specific subject.
I can just specify stub function names in the subject.
Is this enough?
> On 06/17/2013 12:24 PM, Alexander Shiyan wrote:
> > Patch adds of_get_next_child and of_get_next_available_child
> > stubs for non-OF builds.
> >
> > Signed-off-by: Alexander Shiyan
> > -
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> + ranges =
> + <0x8200 0 0x40x0001 0x4 0
> 0x2000
> + 0x8200 0 0x80x0001 0x8 0
> 0x2000
> +
Perhaps a more specific subject.
On 06/17/2013 12:24 PM, Alexander Shiyan wrote:
> Patch adds of_get_next_child and of_get_next_available_child
> stubs for non-OF builds.
>
> Signed-off-by: Alexander Shiyan
> ---
What changed for v2?
> include/linux/of.h | 16 ++--
> 1 file change
This patch adds Device Tree support to the shdma driver. No special DT
properties are used, only standard DMA DT bindings are implemented. Since
shdma controllers reside on SoCs, their configuration is SoC-specific and
shall be passed to the driver from the SoC platform data, using the
auxdata proc
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
>
> + devbus-bootcs {
> + compatible = "marvell,mvebu-devbus";
> + reg = <0x0001 0x10400 0x8>;
> + ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x>;
> +
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
> +Required properties:
> +
> +- compatible: Should be set to one of the following:
> + marvell,armada370-mbus
> + marvell,armadaxp-mbus
> +
> +- reg:Device's register space.
> + Two entri
USB Host PHY clock on port 2 must be configured to 19.2MHz.
Provide this information.
CC: Sricharan R
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5-uevm.dts |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot
Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.
Without this, USB Host & Ethernet will not be functional with
device tree boots on Panda and uEVM.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-generic.
On Panda the +5V supply for DVI EDID is supplied by the
same regulator that poweres the USB Hub. Currently, the
DSS/DVI subsystem doesn't know how to manage this regulator
and so DVI EDID reads will fail if USB Hub is not enabled.
As a temporary fix we keep this regulator permanently enabled
on bo
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 62 +
1 files changed, 62
Hi Benoit & Tony,
The first two patches make changes to dts files to get USB host support
and DVI EDID to work on Panda.
The third patch should get USB host functional on uEVM.
The fourth patch is a temporary workaround to create a clock alias to
the USB PHY clock as it is not possible to define
On Tue, Jun 18, 2013 at 05:02:49PM +0200, Linus Walleij wrote:
> Nowadays I would do the above with regmap_update_bits().
>
> Mutual exclusion for read-modify-write of individual bits in a
> register is one of those cases where doing a regmap over
> a memory-mapped register range makes a lot of se
Hi Pavel,
Am Dienstag, 18. Juni 2013, 17:02:44 schrieb Pavel Machek:
> Hi!
>
> > >The following 2 patches will eliminate the need for the patch in John
> > >Stultz's tree. If there is to be merge of the 2 trees, then the
> > >patch:
> > >
> > >dw_apb_timer_of.c: Remove parts that were picoxcell-s
Although the internal register window size is 1 MiB, the previous
ranges translation for the internal register space had a size of
0x400. This was done to allow the crypto and nand node to access
the corresponding 'sram' and 'nand' decoding windows.
In order to describe the hardware more accur
On Tue, Jun 18, 2013 at 5:11 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 18, 2013 at 05:02:49PM +0200, Linus Walleij wrote:
>> Nowadays I would do the above with regmap_update_bits().
>>
>> Mutual exclusion for read-modify-write of individual bits in a
>> register is one of those cases where
Jaehoon,
On Mon, Jun 17, 2013 at 9:51 PM, Jaehoon Chung wrote:
> Hi Doug,
>
> I have one question for using .
> I found the fixed-rate-clocks feature.
> If we want to set , then can we use the fixed-rate-clocks?
> i'm not sure how use the fixed-rate-clocks. but it seems to set fixed-rate
> value
On Tuesday 18 June 2013 22:22:17 zhangfei wrote:
> > With no need to have a filter function.
>
> Cool, then I would like to wait for the patch.
Maybe you can try to add the dma_get_slave_channel() function I proposed here
as a first patch and add your driver on top. There may be issues I missed,
On Tue, Jun 18, 2013 at 1:36 PM, Russell King - ARM Linux
wrote:
> Maybe what we need is something like this:
>
> static DEFINE_SPINLOCK(io_lock);
> static void modifyl(u32 new, u32 mask, void __iomem *reg)
> {
> unsigned long flags;
> u32 val;
>
> spin_lock_irqsave(&io_lo
Hi,
On Tue, Jun 18, 2013 at 08:25:00PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 18 June 2013 06:05 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Jun 18, 2013 at 04:43:44PM +0530, Kishon Vijay Abraham I wrote:
> >>>On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I w
Hi,
On Tuesday 18 June 2013 06:05 PM, Felipe Balbi wrote:
Hi,
On Tue, Jun 18, 2013 at 04:43:44PM +0530, Kishon Vijay Abraham I wrote:
On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote:
On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote:
On Thu, Jun 13, 2013 at 02:13:55
Patch adds of_get_next_child and of_get_next_available_child
stubs for non-OF builds.
Signed-off-by: Alexander Shiyan
---
include/linux/of.h | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 1fd08ca..c086c1a 100644
With this patch, it is at par with Exynos5250 and Exynos4 clocks
where sclk_pixel ID is assigned to a divider clock but in real,
sclk_pixel is listed under gate clocks (enum value).
Alternate to this, I can allocate a new ID, div_pixel, listed under
new category of Divider Clocks for Exyno4, 5250
Adding sysmmu clock for tv for exynos5420.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/d
On Tuesday 18 June 2013, Heiko Stübner wrote:
> > Side comment: I think it would be nice if the generic code did this
> > init if a l2x0 device node was in the device tree, since the only
> > reason to override init_machine is to do this call in addition to
> > of_platform_populate().
>
> Arnd sai
hdmi driver needs to change the parent of hdmi clock
to pixel clock or hdmiphy clock, based on the stability
of hdmiphy. This patch is exposing the mux for changing
the parent.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |5 +
drivers/clk/
Listing sclk_hdmiphy at 0th position in the list of parents is
causing wrong configuration in reg SRC_DISP10.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-exynos5420.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/driver
sclk_pixel is used to represent pixel clock divider on all exynos
SoCs not as a gate clock. It is queried in driver to pass as the
parent to hdmi clock while switching between parents. A new ID can
be asssigned Pixel gate clock which is currently not in use. Pixel
clock gate is default 'on'.
Signe
Add sclk_hdmiphy to the list of exposed clocks. This is required
by hdmi driver to change the parent of hdmi clock.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |4 ++--
2 f
Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.
This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.g
On Tuesday 18 June 2013, zhangfei gao wrote:
> On Tue, Jun 18, 2013 at 4:58 AM, Arnd Bergmann wrote:
> >
> >> +static struct of_dma_filter_info k3_dma_filter;
> >> +static bool k3_dma_filter_fn(struct dma_chan *chan, void *param)
> >> +{
> >> + return (*(int *)param == chan->chan_id);
> >> +}
On Tuesday 18 June 2013, Jingoo Han wrote:
> On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
> > On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
> > > On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
> > > >
> > > > Please look up the documentation about inbound viewport and describe
On Tuesday 18 June 2013, Guennadi Liakhovetski wrote:
> Hi Arnd
>
> On Mon, 17 Jun 2013, Arnd Bergmann wrote:
>
> > On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
> > > +Required properties:
> > > +- dmas: a list of <[DMA controller phandle] [MID/RID value]>
> > > pairs
> > > +-
On 06/18/2013 02:11 PM, Roger Quadros wrote:
> On Panda the +5V supply for DVI EDID is supplied by the
> same regulator that poweres the USB Hub. Currently, the
> DSS/DVI subsystem doesn't know how to manage this regulator
> and so DVI EDID reads will fail if USB Hub is not enabled.
>
> As a tempo
On Tuesday 18 June 2013, Guennadi Liakhovetski wrote:
> >
> > Hmm, you've clearly shown that this can work, but it feels like a really
> > odd way to
> > do this. I don't think we should do it this way, because it tries to be
> > really
> > generic but then cannot some of the interesting cases,
If an error occurs when loading power scripts or resources, the
registers are not correctly relocked. Fix it.
Signed-off-by: Florian Vaussard
---
drivers/mfd/twl4030-power.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/
Support for loading twl4030-power module via devicetree.
For now, when booting with a DT, only the poweroff callback
feature is supported through the ti,use_poweroff property.
Signed-off-by: Florian Vaussard
---
.../devicetree/bindings/mfd/twl4030-power.txt | 28
drivers/mfd/
Remove unnecessary goto statements, causing duplicated if
conditions.
Signed-off-by: Florian Vaussard
---
drivers/mfd/twl4030-power.c | 38 +++---
1 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-
Increase lisibility when probing power scripts and resources by
creating dedicated functions.
Signed-off-by: Florian Vaussard
---
drivers/mfd/twl4030-power.c | 60 --
1 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/mfd/twl4030-po
Hello,
This series enables a partial DT support for twl4030-power. The
missing part is the power management scripts, as the required
binding should be defined first. It however enables the complete
shutdown of the processor at poweroff when booting with DT,
dropping the power consumption from arou
For now, the call to twl4030-power is hard-wired inside twl-core.
To ease the future transition to DT, make twl4030-power as a
separate module, like what is already done for twl4030-audio
and others.
Signed-off-by: Florian Vaussard
---
drivers/mfd/twl-core.c | 12 +++---
drivers/mfd/t
On Tuesday 18 June 2013, dingu...@altera.com wrote:
> @@ -476,27 +476,31 @@
> };
>
> timer0: timer0@ffc08000 {
> - compatible = "snps,dw-apb-timer-sp";
> + compatible = "snps,dw-apb-timer";
> inter
1 - 100 of 178 matches
Mail list logo
