* Stephen Warren wrote:
> On 03/14/2012 09:56 AM, Thierry Reding wrote:
> > This commit adds very basic support for device tree probing. Currently,
> > only a PWM and a list of distinct brightness levels can be specified.
> > Enabling or disabling backlight power via GPIOs is not yet supported.
> >
* Stephen Warren wrote:
> On 03/14/2012 09:56 AM, Thierry Reding wrote:
> > A subsequent patch will add a generic PWM API driver for the Tegra PWFM
> > controller, supporting all four PWM devices with a single PWM chip. The
> > device will be named tegra-pwm and only one clock needs to be provided.
* Stephen Warren wrote:
> On 03/14/2012 09:56 AM, Thierry Reding wrote:
> > Add auxdata to instantiate the PWFM controller from a device tree,
> > include the corresponding nodes in the dtsi files for Tegra 20 and
> > Tegra 30 and add binding documentation.
> >
> > Signed-off-by: Thierry Reding
>
On 2012-03-13 at 19:13:24 +0100, Grant Likely wrote:
> On Tue, 13 Mar 2012 12:31:26 +0100, Tobias Klauser
> wrote:
> > On 2012-03-12 at 17:04:18 +0100, Grant Likely
> > wrote:
> > > On Mon, 6 Feb 2012 18:59:02 +0100, Tobias Klauser
> > > wrote:
> > > > This driver supports the Altera PIO co
Those selftests are covering the new DT DMA helpers. They will test both
error and normal cases.
A custom .xlate() function is also provided to show the use of this API in case
of a different need than the single cell argument.
Signed-off-by: Nicolas Ferre
Cc: Benoit Cousson
Cc: Stephen Warren
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be impl
---
include/linux/of_dma.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 2865480..da95e37 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -18,7 +18,7 @@
struct device_node;
-#ifdef CONFIG
On Fri, Mar 16, 2012 at 9:54 PM, Stephen Warren wrote:
> Macros in call ARRAY_SIZE(), the definition of
> which eventually calls BUILD_BUG_ON_ZERO(), which is defined in
> . Include that so that every .c file using the pinctrl macros
> doesn't have to do that itself.
>
> Signed-off-by: Stephen W
On Fri, Mar 16, 2012 at 9:54 PM, Stephen Warren wrote:
> Most code assumes that the pinctrl ops are present. Validate this when
> registering a pinctrl driver. Remove the one place in the code that
> was checking whether one of these non-optional ops was present.
>
> Signed-off-by: Stephen Warren
On Fri, Mar 16, 2012 at 9:54 PM, 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 entrie
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 Mar 2012 07:54:33 +0100, Lothar Waßmann
>> > wrote:
>> > > Grant Likely writes:
>> > > > On Fri, 16 Mar 2012 11:01:35 +0800, Dong
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 Mar 2012 07:54:33 +0100, Lothar Waßmann
> >> > wrote:
> >> > > Grant Likely writes:
>
On Thu, Mar 15, 2012 at 10:39:12PM +0100, Cousson, Benoit wrote:
> On 3/15/2012 9:41 PM, Arnd Bergmann wrote:
> >The numbers definitely need to become local to each of the controllers, but
> >that is the case pretty much automatically using the proposed binding,
> >because each dma request identifi
On Tue, 20 Mar 2012 11:13:32 +0100, Nicolas Ferre
wrote:
> Those selftests are covering the new DT DMA helpers. They will test both
> error and normal cases.
> A custom .xlate() function is also provided to show the use of this API in
> case
> of a different need than the single cell argument.
On Tue, 20 Mar 2012 00:12:56 +0100, Sylwester Nawrocki
wrote:
> On 03/08/2012 03:51 PM, Thierry Reding wrote:
> > From: Grant Likely
> >
> > Allow drivers to report at probe time that they cannot get all the resources
> > required by the device, and should be retried at a later time.
> >
> > This
On 03/19/2012 03:45 PM, Grant Likely :
> On Mon, 19 Mar 2012 14:30:05 +0100, Nicolas Ferre
> wrote:
>> On 03/17/2012 10:40 AM, Grant Likely :
>>> On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
>>> wrote:
+struct of_dma {
+ struct list_head of_dma_controllers;
+ struct device
On 03/20/2012 02:39 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 03/14/2012 09:56 AM, Thierry Reding wrote:
>>> This commit adds very basic support for device tree probing. Currently,
>>> only a PWM and a list of distinct brightness levels can be specified.
>>> Enabling or disabling ba
On 03/20/2012 02:44 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 03/14/2012 09:56 AM, Thierry Reding wrote:
>>> A subsequent patch will add a generic PWM API driver for the Tegra PWFM
>>> controller, supporting all four PWM devices with a single PWM chip. The
>>> device will be named t
On 03/20/2012 02:48 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 03/14/2012 09:56 AM, Thierry Reding wrote:
>>> Add auxdata to instantiate the PWFM controller from a device tree,
>>> include the corresponding nodes in the dtsi files for Tegra 20 and
>>> Tegra 30 and add binding documen
On 03/20/2012 04:13 AM, Nicolas Ferre wrote:
> Add some basic helpers to retrieve a DMA controller device_node and the
> DMA request specifications. By making DMA controllers register a generic
> translation function, we allow the management of any type of DMA requests
> specification.
> The void *
* Stephen Warren wrote:
> On 03/20/2012 02:39 AM, Thierry Reding wrote:
> > * Stephen Warren wrote:
> >> On 03/14/2012 09:56 AM, Thierry Reding wrote:
> >>> This commit adds very basic support for device tree probing. Currently,
> >>> only a PWM and a list of distinct brightness levels can be speci
* Stephen Warren wrote:
> On 03/20/2012 02:48 AM, Thierry Reding wrote:
> > * Stephen Warren wrote:
> >> On 03/14/2012 09:56 AM, Thierry Reding wrote:
> >>> Add auxdata to instantiate the PWFM controller from a device tree,
> >>> include the corresponding nodes in the dtsi files for Tegra 20 and
>
On 03/20/2012 09:43 AM, Thierry Reding wrote:
> * Stephen Warren wrote:
>> On 03/20/2012 02:39 AM, Thierry Reding wrote:
...
>>> I think in the long run it
>>> would be much better to get rid of pwm_request() altogether and unify by
>>> having the non-DT case request the PWM device on a per-chip ba
On Tue, Mar 20, 2012 at 09:56:09AM -0600, Stephen Warren wrote:
> On 03/20/2012 09:43 AM, Thierry Reding wrote:
> > What would be a good way to represent this in platform data?
> I think most get subsystems have a get API that works for both DT and
> non-DT, rather than using platform data:
Yes,
On Tuesday 20 March 2012, Nicolas Ferre wrote:
>
> Add some basic helpers to retrieve a DMA controller device_node and the
> DMA request specifications. By making DMA controllers register a generic
> translation function, we allow the management of any type of DMA requests
> specification.
> The v
On Tue, 21 Jun 2011 12:45:13 -0600
Grant Likely wrote:
> of_platform_populate() also handles nodes at the root of the tree,
> which is wanted for things like describing the sound complex. This
> patch converts mpc5200 support to use of_platform_populate() instead
> of of_platform_bus_probe().
>
On Fri, 16 Mar 2012 14:54:22 -0600, Stephen Warren
wrote:
> This patch adds macros for_each_u32_property_value and
> for_each_string_property_value, which iterate over an array of values
> within a device-tree property. Usage is for example:
>
> struct of_iter_string_prop iter;
> for_each_string
On Tue, Mar 13, 2012 at 03:57:49PM +, Arnd Bergmann wrote:
> On Monday 12 March 2012, Jason Cooper wrote:
> > Only issue I have (I think unrelated) is that orion-ehci isn't coming
> > up. But these patches don't touch that, so I think it might be my
> > config again. Although it doesn't look
Hi Michal,
On Mon, Mar 19, 2012 at 3:38 PM, Michal Simek wrote:
> Maybe I am trying to do things more complicated than they are but
> I still see that make sense to do it.
I agree, it definitely does.
OMAP4 is using this kind of resource allocation for a plethora of resources.
In general there
This patch adds macros of_property_for_each_u32() and
of_property_for_each_string(), which iterate over an array of values
within a device-tree property. Usage is for example:
struct property *prop;
const __be32 *p;
u32 u;
of_property_for_each_u32(np, "propname", prop, p, u)
printk("U32 va
The core pin controller bindings define:
* The fact that pin controllers expose pin configurations as nodes in
device tree.
* That the bindings for those pin configuration nodes is defined by the
individual pin controller drivers.
* A standardized set of properties for client devices to define
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 entries from them.
During pinctrl_put(), free any results of device tr
This places the file in the new location for all pin controller bindings.
Also, rename the file using the full compatible value for easier
avoidance of conflicts between multiple bindings.
Signed-off-by: Stephen Warren
---
.../bindings/pinctrl/nvidia,tegra20-pinmux.txt |5 +
.../dev
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 on Tegra20 binding.
Add some basic stuff that was missing before:
* How ma
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_string() API changes.
---
drivers/pinctrl/pinctrl-tegra.c | 181 ++
On Tue, 20 Mar 2012, Jason Cooper wrote:
> On Tue, Mar 13, 2012 at 03:57:49PM +, Arnd Bergmann wrote:
> > On Monday 12 March 2012, Jason Cooper wrote:
> > > Only issue I have (I think unrelated) is that orion-ehci isn't coming
> > > up. But these patches don't touch that, so I think it might
On 03/13/2012 04:48 PM, Stephen Warren wrote:
> dtc currently allows the contents of properties to be changed, and the
> contents of nodes to be added to. There are situations where removing
> properties or nodes may be useful. This change implements the following
> syntax to do that:
>
> / {
On Tue, Mar 20, 2012 at 02:03:23PM -0400, Nicolas Pitre wrote:
> On Tue, 20 Mar 2012, Jason Cooper wrote:
>
> > On Tue, Mar 13, 2012 at 03:57:49PM +, Arnd Bergmann wrote:
> > > On Monday 12 March 2012, Jason Cooper wrote:
> > > > Only issue I have (I think unrelated) is that orion-ehci isn't c
On Tue, 20 Mar 2012, Jason Cooper wrote:
> On Tue, Mar 20, 2012 at 02:03:23PM -0400, Nicolas Pitre wrote:
> > On Tue, 20 Mar 2012, Jason Cooper wrote:
> >
> > > I figure most folks will build orion-ehci as a module and use an initrd.
> >
> > Possibly, however that doesn't mean this shouldn't be
On Tuesday 20 March 2012, Jason Cooper wrote:
> diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> index 6c6a5a3..0808417 100644
> --- a/drivers/usb/host/ehci-orion.c
> +++ b/drivers/usb/host/ehci-orion.c
> @@ -318,3 +318,5 @@ static struct platform_driver ehci_orion_drive
On Tue, Mar 20, 2012 at 03:03:45PM -0400, Nicolas Pitre wrote:
> On Tue, 20 Mar 2012, Jason Cooper wrote:
>
> > On Tue, Mar 20, 2012 at 02:03:23PM -0400, Nicolas Pitre wrote:
> > > On Tue, 20 Mar 2012, Jason Cooper wrote:
> > >
> > > > I figure most folks will build orion-ehci as a module and use
On Tue, Mar 20, 2012 at 07:15:07PM +, Arnd Bergmann wrote:
> On Tuesday 20 March 2012, Jason Cooper wrote:
> > diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> > index 6c6a5a3..0808417 100644
> > --- a/drivers/usb/host/ehci-orion.c
> > +++ b/drivers/usb/host/ehci-ori
Adding linux-usb to the CC:.
We're trying to figure out how to compile the orion-ehci.c driver into
the kernel. This is needed for the Globalscale Technologies Dreamplug
to boot and find it's root filesystem (on an internal usb attached
microsd card).
On Tue, Mar 20, 2012 at 07:15:07PM +, Ar
On Tue, Mar 20, 2012 at 08:32:22PM +0100, Andrew Lunn wrote:
> On Tue, Mar 20, 2012 at 07:15:07PM +, Arnd Bergmann wrote:
> > On Tuesday 20 March 2012, Jason Cooper wrote:
> > > diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> > > index 6c6a5a3..0808417 100644
> > >
On Tue, Mar 20, 2012 at 10:44 AM, Stephen Warren wrote:
> The core pin controller bindings define:
> * The fact that pin controllers expose pin configurations as nodes in
> device tree.
> * That the bindings for those pin configuration nodes is defined by the
> individual pin controller drivers.
On 03/20/2012 12:44 PM, Stephen Warren wrote:
> This patch adds macros of_property_for_each_u32() and
> of_property_for_each_string(), which iterate over an array of values
> within a device-tree property. Usage is for example:
>
> struct property *prop;
> const __be32 *p;
> u32 u;
> of_property_f
> > Hi Jason
> >
> > I fell fowl of something in this area. Do you have CONFIG_USB_EHCI_MV=y?
> > Make sure you do not have this.
> >
> > drivers/usb/host/ehci-hcd.c has some unusual code, and if you have
> > both CONFIG_USB_EHCI_MV and CONFIG_PLAT_ORION, the CONFIG_USB_EHCI_MV
> > is given pref
On Tuesday 20 March 2012, Andrew Lunn wrote:
> > Is there a scenario where someone would want to select
> > CONFIG_USB_EHCI_MV in menuconfig?
>
> Not on an Orion platform, as far as i know. Maybe
>
> config USB_EHCI_MV
> bool "EHCI support for Marvell on-chip controller"
> -depend
On Tue, Mar 20, 2012 at 08:57:38PM +, Arnd Bergmann wrote:
> On Tuesday 20 March 2012, Andrew Lunn wrote:
> > > Is there a scenario where someone would want to select
> > > CONFIG_USB_EHCI_MV in menuconfig?
> >
> > Not on an Orion platform, as far as i know. Maybe
> >
> > config USB_EHCI_MV
>
On Tuesday 20 March 2012, Jason Cooper wrote:
> > If you want to add a dependency, it should be
> >
> > depends on PLAT_PXA
> >
> > Most other platform drivers have a dependency on the platform
> > they are for, but USB_EHCI_MV was only recently added, and nobody
> > has bothered to fix thi
On Tue, Mar 20, 2012 at 10:15:09PM +, Arnd Bergmann wrote:
> On Tuesday 20 March 2012, Jason Cooper wrote:
> > > If you want to add a dependency, it should be
> > >
> > > depends on PLAT_PXA
> > >
> > > Most other platform drivers have a dependency on the platform
> > > they are for, bu
This patch adds macros of_property_for_each_u32() and
of_property_for_each_string(), which iterate over an array of values
within a device-tree property. Usage is for example:
struct property *prop;
const __be32 *p;
u32 u;
of_property_for_each_u32(np, "propname", prop, p, u)
printk("U32 va
On 03/20/2012 06:08 PM, Stephen Warren wrote:
> This patch adds macros of_property_for_each_u32() and
> of_property_for_each_string(), which iterate over an array of values
> within a device-tree property. Usage is for example:
>
> struct property *prop;
> const __be32 *p;
> u32 u;
> of_property_f
On Ubuntu, /bin/sh is dash (at least by default), and dash's echo doesn't
accept the -e option. This means that fdtget-runtest.sh's EXPECT file will
contain "-e foo" rather than just "foo", which causes a test failure.
To work around this, run /bin/echo instead of (builtin) echo, which has
more ch
Hi,
Exynos5 includes a gpio wakeup interrupt controller that generates 32
interrupts. The first 16 interrupts are routed to the interrupt
combiner controller. The last 16 are muxed into one interrupt and this
interrupt line is connected to the GIC interrupt controller.
So, the wakeup interrupt co
Written by David Gibson . Ported to ToT
dtc by me. Added >> test. Commented a couple of failing tests.
Signed-off-by: Stephen Warren
---
This is a port of David's cell expressions patch to ToT. It passes all
enabled tests, but a few fail and are commented out.
dtc-lexer.l |9 +++
On Tue, Mar 20, 2012 at 08:23:46PM -0600, Stephen Warren wrote:
> On Ubuntu, /bin/sh is dash (at least by default), and dash's echo doesn't
> accept the -e option. This means that fdtget-runtest.sh's EXPECT file will
> contain "-e foo" rather than just "foo", which causes a test failure.
>
> To wo
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 last 16 are muxed into one interrupt and this
> interrupt lin
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 ehci driver.
BTW, as someone who once was the active maintainer f
On Tue, Mar 20, 2012 at 08:29:11PM -0600, Stephen Warren wrote:
> Written by David Gibson . Ported to ToT
> dtc by me. Added >> test. Commented a couple of failing tests.
Thanks for doing this port. Some recommendations below, though.
First, "cell expressions" was a term that made sense when I f
On Wed, Mar 21, 2012 at 01:44:35AM +0800, Stephen Warren wrote:
> The core pin controller bindings define:
> * The fact that pin controllers expose pin configurations as nodes in
> device tree.
> * That the bindings for those pin configuration nodes is defined by the
> individual pin controller
On Tue, Mar 20, 2012 at 12:03:35PM -0600, Stephen Warren wrote:
> On 03/13/2012 04:48 PM, Stephen Warren wrote:
> > dtc currently allows the contents of properties to be changed, and the
> > contents of nodes to be added to. There are situations where removing
> > properties or nodes may be useful.
62 matches
Mail list logo
