On Wed, Mar 21, 2012 at 01:44:36AM +0800, Stephen Warren wrote:
> During pinctrl_get(), if the client device has a device tree node, look
> for the common pinctrl properties there. If found, parse the referenced
> device tree nodes, with the help of the pinctrl drivers, and generate
> mapping table
On Wed, Mar 21, 2012 at 11:54 AM, Nicolas Pitre wrote:
> On Tue, 20 Mar 2012, Arnd Bergmann wrote:
>
>> ehci-orion only makes sense on PLAT_ORION, and they never have any
>> other platform ehci driver.
>>
>> ehci-mv only makese sense on PLAT_PXA, and they also don't have any
>> other platform ehc
On Wed, Mar 21, 2012 at 04:21:45PM +0800, Haojian Zhuang wrote:
> On Wed, Mar 21, 2012 at 11:54 AM, Nicolas Pitre wrote:
> > On Tue, 20 Mar 2012, Arnd Bergmann wrote:
> >
> >> ehci-orion only makes sense on PLAT_ORION, and they never have any
> >> other platform ehci driver.
> >>
> >> ehci-mv only
On Wed, Mar 21, 2012 at 4:34 PM, Andrew Lunn wrote:
> On Wed, Mar 21, 2012 at 04:21:45PM +0800, Haojian Zhuang wrote:
>> On Wed, Mar 21, 2012 at 11:54 AM, Nicolas Pitre wrote:
>> > On Tue, 20 Mar 2012, Arnd Bergmann wrote:
>> >
>> >> ehci-orion only makes sense on PLAT_ORION, and they never have
On Wed, Mar 21, 2012 at 01:44:38AM +0800, Stephen Warren wrote:
> Define a new binding for the Tegra pin controller, which is capable of
> defining all aspects of desired pin multiplexing and pin configuration.
> This is all based on the new common pinctrl bindings.
>
> Add Tegra30 binding based o
On Wed, Mar 21, 2012 at 01:44:39AM +0800, Stephen Warren wrote:
> Implement pinctrl_ops dt_node_to_map() and dt_free_map(). These allow
> complete specification of the desired pinmux configuration using device
> tree.
>
> Signed-off-by: Stephen Warren
> ---
> v2: Rebase on of_property_for_each_st
On Wednesday 21 March 2012, Haojian Zhuang wrote:
> The driver isn't used by any other platform. It's only used in
> arch-pxa & arch-mmp.
>
> I can't find the original mail. But I remembered that maintainer said
> the driver should be built with any other platform, even with x86. So
> we aren't al
On 19.03.2012 20:55, Mark Brown wrote:
> On Thu, Mar 15, 2012 at 05:54:33PM +0100, Karol Lewandowski wrote:
>
>> If you consider code to be inherently less readable because of this
>> approach I'll rework it. If it's not a such big deal for you I would
>> prefer to keep it as is.
>
> The thing
On Tue, Mar 20, 2012 at 09:17:48PM +0800, Lothar Waßmann wrote:
> Hi,
>
> Dong Aisheng writes:
> > On Mon, Mar 19, 2012 at 3:02 PM, Grant Likely
> > wrote:
> > > On Mon, 19 Mar 2012 17:49:02 +0100, Lothar Waßmann
> > > wrote:
> > >> Hi,
> > >>
> > >> Grant Likely writes:
> > >> > On Mon, 19 Ma
On 3/15/2012 7:09 PM, Arnd Bergmann wrote:
> On Thursday 15 March 2012, Stefan Roese wrote:
>> On Thursday 15 March 2012 10:00:27 Viresh Kumar wrote:
>>> On 3/15/2012 2:18 PM, Stefan Roese wrote:
+static const struct of_device_id vic_of_match[] __initconst = {
+ { .compatible
On Wed, Mar 21, 2012 at 11:33:58AM +0100, Karol Lewandowski wrote:
> What do you think about following changes, then?
That looks reasonable.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozla
On 21.03.2012 12:50, Mark Brown wrote:
> On Wed, Mar 21, 2012 at 11:33:58AM +0100, Karol Lewandowski wrote:
>
>> What do you think about following changes, then?
>
> That looks reasonable.
Thanks. I'll incorporate this change and post whole patchset again.
Regards,
--
Karol Lewandowski | Sam
On Wed, Mar 21, 2012 at 10:09:40AM +, Arnd Bergmann wrote:
> On Wednesday 21 March 2012, Haojian Zhuang wrote:
> > The driver isn't used by any other platform. It's only used in
> > arch-pxa & arch-mmp.
> >
> > I can't find the original mail. But I remembered that maintainer said
> > the drive
On Wednesday 21 March 2012, Viresh Kumar wrote:
> >
> > What's wrong with one vic_dt_init_irq() function and an array with two
> > entries?
>
> Hey Arnd,
>
> Actually i was doing 3xx DT porting and again came to this thing. I believe
> what
> you suggested should be fine too as the actual vic
Hi Artem,
On Friday 16 March 2012 11:42:11 Stefan Roese wrote:
> This patch adds support to configure the SPEAr SMI driver via
> device-tree instead of platform_data.
I noticed that you pushed the first part of this patch:
[PATCH 1/2] MTD: spear_smi: Remove default partition information from dri
On Wednesday 21 March 2012, Felipe Balbi wrote:
> I have explained an easy way to achieve that to Alan Stern, but he did
> not like it. Basically, we should add a platform_device to ehci-hcd.ko
> and make ehci-{omap,mv,fsl,atmel,etc} a parent device/driver which
> basically passes the correct resou
On Wed, Mar 21, 2012 at 01:17:38PM +, Arnd Bergmann wrote:
> On Wednesday 21 March 2012, Felipe Balbi wrote:
> > I have explained an easy way to achieve that to Alan Stern, but he did
> > not like it. Basically, we should add a platform_device to ehci-hcd.ko
> > and make ehci-{omap,mv,fsl,atmel
Hi David,
On 21 March 2012 09:11, David Gibson wrote:
> On Wed, Mar 21, 2012 at 07:55:43AM +0530, Thomas Abraham wrote:
>> Hi,
>>
>> Exynos5 includes a gpio wakeup interrupt controller that generates 32
>> interrupts. The first 16 interrupts are routed to the interrupt
>> combiner controller. The
On Tue, Mar 20, 2012 at 11:54:53PM -0400, Nicolas Pitre wrote:
> On Tue, 20 Mar 2012, Arnd Bergmann wrote:
>
> > ehci-orion only makes sense on PLAT_ORION, and they never have any
> > other platform ehci driver.
> >
> > ehci-mv only makese sense on PLAT_PXA, and they also don't have any
> > othe
On Wed, 2012-03-21 at 14:12 +0100, Stefan Roese wrote:
> I noticed that you pushed the first part of this patch:
>
> [PATCH 1/2] MTD: spear_smi: Remove default partition information from driver
>
> into l2-mtd.git. What's do plan for this patch?
http://git.infradead.org/users/dedekind/l2-mtd.git
On Wed, 21 Mar 2012, Jason Cooper wrote:
> On Tue, Mar 20, 2012 at 11:54:53PM -0400, Nicolas Pitre wrote:
> > On Tue, 20 Mar 2012, Arnd Bergmann wrote:
> >
> > > ehci-orion only makes sense on PLAT_ORION, and they never have any
> > > other platform ehci driver.
> > >
> > > ehci-mv only makese s
On Wednesday 21 March 2012, viresh kumar wrote:
> On Wed, Mar 21, 2012 at 6:06 PM, Arnd Bergmann wrote:
> > Just let me know how you want to handle
> > these things in the future -- the normal way would be to always let you
> > forward the patches to me, rather than having them applied to arm-soc
On Wednesday 21 March 2012, viresh kumar wrote:
> On Wed, Mar 21, 2012 at 7:34 PM, Arnd Bergmann wrote:
> > On Wednesday 21 March 2012, viresh kumar wrote:
> >> - Pinmux: I would remove our padmux and use pinmux, but what about its
> >> DT support.
> >> I know stephen had few patches for it, but
On Wed, Mar 21, 2012 at 09:56:24AM -0400, Alan Stern wrote:
> On Wed, 21 Mar 2012, Jason Cooper wrote:
>
> > On Tue, Mar 20, 2012 at 11:54:53PM -0400, Nicolas Pitre wrote:
> > > On Tue, 20 Mar 2012, Arnd Bergmann wrote:
> > >
> > > > ehci-orion only makes sense on PLAT_ORION, and they never have
On 03/21/2012 01:31 AM, Dong Aisheng wrote:
> On Wed, Mar 21, 2012 at 01:44:36AM +0800, Stephen Warren wrote:
>> During pinctrl_get(), if the client device has a device tree node, look
>> for the common pinctrl properties there. If found, parse the referenced
>> device tree nodes, with the help of
On 03/21/2012 03:19 AM, Dong Aisheng wrote:
> On Wed, Mar 21, 2012 at 01:44:38AM +0800, Stephen Warren wrote:
>> Define a new binding for the Tegra pin controller, which is capable of
>> defining all aspects of desired pin multiplexing and pin configuration.
>> This is all based on the new common p
On 03/21/2012 03:35 AM, Dong Aisheng wrote:
> On Wed, Mar 21, 2012 at 01:44:39AM +0800, Stephen Warren wrote:
>> Implement pinctrl_ops dt_node_to_map() and dt_free_map(). These allow
>> complete specification of the desired pinmux configuration using device
>> tree.
>>
>> Signed-off-by: Stephen War
On Wed, 21 Mar 2012, Alan Stern wrote:
> On Wed, 21 Mar 2012, Jason Cooper wrote:
>
> > On Tue, Mar 20, 2012 at 11:54:53PM -0400, Nicolas Pitre wrote:
> > > On Tue, 20 Mar 2012, Arnd Bergmann wrote:
> > >
> > > > ehci-orion only makes sense on PLAT_ORION, and they never have any
> > > > other pl
On Wed, 21 Mar 2012, Nicolas Pitre wrote:
> On Wed, 21 Mar 2012, Alan Stern wrote:
>
> > On Wed, 21 Mar 2012, Jason Cooper wrote:
> >
> > > On Tue, Mar 20, 2012 at 11:54:53PM -0400, Nicolas Pitre wrote:
> > > > On Tue, 20 Mar 2012, Arnd Bergmann wrote:
> > > >
> > > > > ehci-orion only makes se
On Mar 17, 2012, at 3:39 AM, Prabhakar Kushwaha wrote:
> BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The BSC9131
> is
> integrated SoC that targets Femto base station market. It combines Power
> Architecture e500v2 and DSP StarCore SC3850 core technologies with MAPLE-B2F
> b
On 03/21/2012 09:48 AM, Stephen Warren wrote:
> On 03/21/2012 01:31 AM, Dong Aisheng wrote:
>> On Wed, Mar 21, 2012 at 01:44:36AM +0800, Stephen Warren wrote:
...
>>> +int pinctrl_dt_to_map(struct pinctrl *p)
>>> +{
>>> + struct device_node *np = p->dev->of_node;
>>> + int state, ret;
>>> + c
Hi Kumar,
Thanks for reviewing it.
Please find my response in-lined.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 10:51 PM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-...@lists.ozlabs.org; devicetree-discuss@lists.ozlabs.o
On Mar 21, 2012, at 12:29 PM, Kushwaha Prabhakar-B32579 wrote:
>>
>>
>> [snip]
>>
>
> ??
> Not getting you..
Just meant, I was removing parts of the patch in the email to reduce things.
>
>>> diff --git a/arch/powerpc/platforms/85xx/bsc913x_rdb.c
>>> b/arch/powerpc/platforms/85xx/bsc913x_r
Thanks Kumar for clarifying my doubts.
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 11:08 PM
> To: Kushwaha Prabhakar-B32579
> Cc: linuxppc-...@lists.ozlabs.org; devicetree-discuss@lists.ozlabs.org;
> Jain Priyanka-B32167; Meh
On Mar 19, 2012, at 8:02 PM, Poonam Aggrwal wrote:
> This TDM controller is available in various Freescale SOCs like MPC8315,
> P1020,
> P1022, P1010.
>
> Signed-off-by: Sandeep Singh
> Signed-off-by: Poonam Aggrwal
> ---
> Changes in v2:
> - Incorporated Scott's Review comments
> Docum
On Wednesday 21 March 2012, Arnd Bergmann wrote:
>
> On Wednesday 21 March 2012, viresh kumar wrote:
> > On Wed, Mar 21, 2012 at 6:06 PM, Arnd Bergmann wrote:
> > > Just let me know how you want to handle
> > > these things in the future -- the normal way would be to always let you
> > > forward
Hi,
I've done some digging and not found any info, maybe I looked in the
wrong places.
I'm trying to better understand how the dtsi file works with the dts
file and what can go in each file.
Our SOC has the same issues as everyone else where we don't want to
replicate stuff across a bunch of dev
Use standard of_match_ptr() to avoid defining variable unused
in non device tree builds.
Signed-off-by: Karol Lewandowski
Signed-off-by: Kyungmin Park
Acked-by: Grant Likely
---
drivers/i2c/busses/i2c-s3c2410.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers
Changes since v2:
- Merge device type and flags into flat bitmask named quirks -
Consequently, treat s3c24xx as baseline hardware platform and
support all hw variations via quirks [Suggested by Mark Brown]
Changes since v1:
- Move unrelated code fragment to separate patch (of_match_ptr())
This patch adds support for s3c2440 I2C bus controller dedicated HDMIPHY device
on
Exynos4 platform. Some quirks are introduced due to differences between HDMIPHY
and other I2C controllers on Exynos4. These differences are:
- no GPIOs, HDMIPHY is inside the SoC and the controller is connected
i
Reorganize driver a bit to better handle device tree-based systems:
- move machine type to driver's private structure instead of
quering platform device variants in runtime
- replace s3c24xx_i2c_type enum with unsigned int that holds
bitmask with revision-specific quirks
Signed-off-by: K
On Wed, Mar 21, 2012 at 08:11:52PM +0100, Karol Lewandowski wrote:
> Reorganize driver a bit to better handle device tree-based systems:
>
> - move machine type to driver's private structure instead of
>quering platform device variants in runtime
>
> - replace s3c24xx_i2c_type enum with uns
On 03/21/2012 12:36 PM, John Linn wrote:
> Hi,
>
> I've done some digging and not found any info, maybe I looked in the
> wrong places.
>
> I'm trying to better understand how the dtsi file works with the dts
> file and what can go in each file.
The basic idea is that what's inside the SoC is id
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, March 21, 2012 1:37 PM
> To: John Linn
> Cc: devicetree-discuss@lists.ozlabs.org
> Subject: Re: dtsi vs dts files, where to better understand this
>
> On 03/21/2012 12:36 PM, John Linn wrote:
> >
Hello,
I'm working on adding the device tree support for two devices that
share some IO registers. Exactly, there is one shared SFR that
contains a common bit to enable two PHY devices, and another two
bits, each to separately reset each PHY.
Currently this shared register is statically memory
On Wed, Mar 21, 2012 at 02:50:09PM -0600, John Linn wrote:
> > -Original Message-
> > From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> > Sent: Wednesday, March 21, 2012 1:37 PM
> > To: John Linn
> > Cc: devicetree-discuss@lists.ozlabs.org
> > Subject: Re: dtsi vs dts files, where to be
On Wed, Mar 21, 2012 at 07:05:26PM +0530, Thomas Abraham wrote:
> Hi David,
>
> On 21 March 2012 09:11, David Gibson wrote:
> > On Wed, Mar 21, 2012 at 07:55:43AM +0530, Thomas Abraham wrote:
> >> Hi,
> >>
> >> Exynos5 includes a gpio wakeup interrupt controller that generates 32
> >> interrupts.
On Wed, Mar 21, 2012 at 11:48:20PM +0800, Stephen Warren wrote:
> On 03/21/2012 01:31 AM, Dong Aisheng wrote:
> > On Wed, Mar 21, 2012 at 01:44:36AM +0800, Stephen Warren wrote:
> >> During pinctrl_get(), if the client device has a device tree node, look
> >> for the common pinctrl properties there
On Wed, Mar 21, 2012 at 11:57:14PM +0800, Stephen Warren wrote:
> On 03/21/2012 03:19 AM, Dong Aisheng wrote:
> > On Wed, Mar 21, 2012 at 01:44:38AM +0800, Stephen Warren wrote:
> >> Define a new binding for the Tegra pin controller, which is capable of
> >> defining all aspects of desired pin mult
On Thu, Mar 22, 2012 at 12:07:27AM +0800, Stephen Warren wrote:
> On 03/21/2012 03:35 AM, Dong Aisheng wrote:
> > On Wed, Mar 21, 2012 at 01:44:39AM +0800, Stephen Warren wrote:
> >> Implement pinctrl_ops dt_node_to_map() and dt_free_map(). These allow
> >> complete specification of the desired pin
BSC9131RDB is a Freescale reference design board for BSC9131 SoC.The BSC9131
is integrated SoC that targets Femto base station market. It combines Power
Architecture e500v2 and DSP StarCore SC3850 core technologies with MAPLE-B2F
baseband acceleration processing elements.
The BSC9131 SoC includes
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: Wednesday, March 21, 2012 11:37 PM
> To: Aggrwal Poonam-B10812
> Cc: devicetree-discuss@lists.ozlabs.org; linuxppc-...@lists.ozlabs.org;
> Singh Sandeep-B37400
> Subject: Re: [PATCH][v2] Device Tree Binding
On Thu, Mar 22, 2012 at 01:25:25AM +0800, Stephen Warren wrote:
> On 03/21/2012 09:48 AM, Stephen Warren wrote:
> > On 03/21/2012 01:31 AM, Dong Aisheng wrote:
> >> On Wed, Mar 21, 2012 at 01:44:36AM +0800, Stephen Warren wrote:
> ...
> >>> +int pinctrl_dt_to_map(struct pinctrl *p)
> >>> +{
> >>> +
53 matches
Mail list logo
