On Thu, Jun 14, 2012 at 01:50:56PM -0600, Stephen Warren wrote:
> On 06/14/2012 01:29 PM, Thierry Reding wrote:
> > On Thu, Jun 14, 2012 at 12:30:50PM -0600, Stephen Warren wrote:
> >> On 06/14/2012 03:19 AM, Thierry Reding wrote:
> ...
> >>> #address-cells = <1>; #size-cells = <1>;
> >>>
> >>> pc
On 06/14/2012 10:17 PM, Shawn Guo wrote:
> On Tue, Jun 12, 2012 at 09:41:48AM -0500, Rob Herring wrote:
>> +struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
>> +{
>> +struct of_clk_provider *provider;
>> +struct clk *clk = NULL;
>
> Both clk and clkdev treat NULL as a
On Tue, Jun 12, 2012 at 09:41:48AM -0500, Rob Herring wrote:
> +struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
> +{
> + struct of_clk_provider *provider;
> + struct clk *clk = NULL;
Both clk and clkdev treat NULL as a valid clock and return ERR_PTR for
error case, wh
On Thu, Jun 14, 2012 at 08:46:24AM -0700, Greg KH wrote:
> On Thu, Jun 14, 2012 at 10:52:57AM +0300, Alexander Shishkin wrote:
> > Greg KH writes:
> >
> > > On Fri, Jun 08, 2012 at 08:37:06PM +0800, Richard Zhao wrote:
> > >> Sometimes, the driver bindings may know what phy they use.
> > >> For e
Grant,
Please pull. Mainly some documentation updates and 2 fixes:
- An export symbol fix for of_platform_populate from Stephen W.
- A fix for the order compatible entries are matched to ensure the
first compatible string is matched when there are multiple matches.
Rob
The following changes sin
On 06/13/2012 10:19 AM, Simon Glass wrote:
> Add LCD definitions and also a proposed binding for LCD displays.
>
> The PWFM is in progress on the device-tree-discuss list, so only a
> very basic binding is offered here.
I believe we have settled on a final representation, it just hasn't been
adde
On 06/13/2012 10:19 AM, Simon Glass wrote:
> This is a commonly-used requirement, so add a function to support it
> easily.
Uggh. Why would this ever be needed; shouldn't the driver for the node
referenced by the phandle fully control its own registers; why would any
other driver randomly trample
On 06/11/2012 07:58 AM, Tony Lindgren wrote:
> Add one-register-per-pin type device tree based pinctrl driver.
>
> Currently this driver only works on omap2+ series of processors,
> where there is either an 8 or 16-bit padconf register for each pin.
> Support for other similar pinmux controllers c
On 06/14/2012 01:29 PM, Thierry Reding wrote:
> On Thu, Jun 14, 2012 at 12:30:50PM -0600, Stephen Warren wrote:
>> On 06/14/2012 03:19 AM, Thierry Reding wrote:
...
>>> #address-cells = <1>; #size-cells = <1>;
>>>
>>> pci@8000 {
>>
>> I'm still not convinced that using the address of the port
On Thu, Jun 14, 2012 at 12:30:50PM -0600, Stephen Warren wrote:
> On 06/14/2012 03:19 AM, Thierry Reding wrote:
> ...
> > Okay, so the new pcie-controller node looks like this:
> >
> > pcie-controller { compatible = "nvidia,tegra20-pcie",
> > "simple-bus"; reg = <0x80003000 0x0800 /* PADS re
On 06/14/2012 03:19 AM, Thierry Reding wrote:
...
> Okay, so the new pcie-controller node looks like this:
>
> pcie-controller { compatible = "nvidia,tegra20-pcie",
> "simple-bus"; reg = <0x80003000 0x0800 /* PADS registers */
> 0x80003800 0x0200 /* AFI registers */ 0x80004000 0x00100
On Sun, May 6, 2012 at 11:52 PM, Vinh Nguyen Huu Tuong
wrote:
> This patch consists of:
> - Add driver for OCM component
> - Export OCM Information at /sys/class/ocm/ocminfo
Again, apologies for the delay. Aside from the incorrect sysfs usage
I pointed out in my other reply, I have just a few co
On 06/14/2012 06:12 AM, Mark Brown wrote:
> On Thu, Jun 14, 2012 at 08:31:20AM +0200, Thierry Reding wrote:
>> On Wed, Jun 13, 2012 at 03:17:06PM -0600, Stephen Warren wrote:
>
>>> The core of the issue is that:
>
>>> * Tegra30 support is via device tree. * We have an SDIO bus,
>>> and the WiFi d
On Thu, Jun 14, 2012 at 10:52:57AM +0300, Alexander Shishkin wrote:
> Greg KH writes:
>
> > On Fri, Jun 08, 2012 at 08:37:06PM +0800, Richard Zhao wrote:
> >> Sometimes, the driver bindings may know what phy they use.
> >> For example, when using device tree, the usb controller may have a
> >> ph
On Thu, 14 Jun 2012 16:45:33 +0200
Sascha Hauer wrote:
> On Thu, Jun 14, 2012 at 04:10:16PM +0200, David Jander wrote:
> > On Thu, 14 Jun 2012 15:07:56 +0200
> > Sascha Hauer wrote:
> >
> > > +
> > > +Required properties:
> > > +- compatible: Should be "fsl,imx-parallel-display"
> > > +- crtc:
Hi all
Sorry for jumping in so late in the game. But I think, the model, to which
this discussion is slowly converging, is not very well suitable for the
shdma DMACs, present on SH and ARM sh-mobile SoCs. I might be wrong and
the model is indeed suitable, in which case I'd be grateful, if someo
On Thu, Jun 14, 2012 at 04:10:16PM +0200, David Jander wrote:
> On Thu, 14 Jun 2012 15:07:56 +0200
> Sascha Hauer wrote:
>
> > +
> > +Required properties:
> > +- compatible: Should be "fsl,imx-parallel-display"
> > +- crtc: the crtc this display is connected to, see below
> > +Optional properties
On Thu, 14 Jun 2012 15:07:56 +0200
Sascha Hauer wrote:
> Hi All,
>
> The following is an attempt to come up with a devicetree binding for
> DRM graphics on i.MX SoCs. I'm posting this seperate from the actual
> code to not bury this in big patches.
>
> The bindings should cover most of the prob
On Thu, 14 Jun 2012, Richard Zhao wrote:
> > > + if (unlikely(hcd->phy && !hdev->level)) {
> >
> > This is okay, but it's more common to test for root hubs with
> > "!hdev->parent".
> So it will be like:
> if (unlikely(hcd->phy && !hdev->parent)) {
Yes.
> And,
> I didn't check (portchange & US
Hi All,
The following is an attempt to come up with a devicetree binding for
DRM graphics on i.MX SoCs. I'm posting this seperate from the actual
code to not bury this in big patches.
The bindings should cover most of the problems we had while implementing
the possible IPU <-> (LVDS, HDMI, parall
On Thu, Jun 14, 2012 at 12:47:13PM +, Hebbar, Gururaja wrote:
> On Tue, Apr 10, 2012 at 20:36:23, Thierry Reding wrote:
> > This patch series adds very rudimentary device-tree support for PWM
> > devices. With all of these patches applied (plus one board-specific
> > patch that is not included)
On Thu, Jun 14, 2012 at 08:31:20AM +0200, Thierry Reding wrote:
> On Wed, Jun 13, 2012 at 03:17:06PM -0600, Stephen Warren wrote:
> > The core of the issue is that:
> > * Tegra30 support is via device tree.
> > * We have an SDIO bus, and the WiFi device attached to that bus is
> > enumerable.
> >
On Thu, Jun 14, 2012 at 11:06:48AM +, Arnd Bergmann wrote:
> On Thursday 14 June 2012, Thierry Reding wrote:
> > On Thu, Jun 14, 2012 at 10:25:09AM +, Arnd Bergmann wrote:
> > > On Thursday 14 June 2012, Thierry Reding wrote:
> > > > >
> > > > > I believe you will need an "interrupt-map" p
On Thursday 14 June 2012, Andrew Lunn wrote:
> > I think if you compute the number of interrupts in the domain from the
> > number of
> > registers that are described in the device tree, call orion_irq_init()
> > based on those registers, and use irq domains for the gpio stuff as Rob
> > suggeste
On Wednesday 13 June 2012, Jon Hunter wrote:
> > As I said previously, I think just encoding the direction but not
> > the client specific ID (meaning we would have to disambiguate
> > the more complex cases that Stephen mentioned using a dma-names
> > property) would be the best because it keeps
On Thursday 14 June 2012, Thierry Reding wrote:
> On Thu, Jun 14, 2012 at 10:25:09AM +, Arnd Bergmann wrote:
> > On Thursday 14 June 2012, Thierry Reding wrote:
> > > >
> > > > I believe you will need an "interrupt-map" property here, to map the
> > > > host
> > > > interrupts to the INTA-INT
On Thursday 14 June 2012, Andrew Lunn wrote:
> We either have auxdata and clean clock code, or no auxdata and messy
> clock code with lots of aliases.
>
> The auxdata is also not limited to the name of the clocks. It allows
> me to diff the kernel log for a DT boot and a none DT boot of the same
>
On Thu, Jun 14, 2012 at 10:25:09AM +, Arnd Bergmann wrote:
> On Thursday 14 June 2012, Thierry Reding wrote:
> > >
> > > I believe you will need an "interrupt-map" property here, to map the host
> > > interrupts to the INTA-INTD lines of the attached devices.
> >
> > Legacy interrupts are some
On Thursday 14 June 2012, Thierry Reding wrote:
> >
> > I believe you will need an "interrupt-map" property here, to map the host
> > interrupts to the INTA-INTD lines of the attached devices.
>
> Legacy interrupts are something I cannot test at all because I have no
> hardware that supports them.
On Wed, Jun 13, 2012 at 09:10:30PM +, Arnd Bergmann wrote:
> On Sunday 10 June 2012, Andrew Lunn wrote:
> > @@ -26,6 +26,11 @@ static struct of_device_id kirkwood_dt_match_table[]
> > __initdata = {
> > { }
> > };
> >
> > +struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata =
On Tue, Jun 12, 2012 at 10:36:55PM -1000, Mitch Bradley wrote:
> On 6/12/2012 10:19 PM, Thierry Reding wrote:
> >On Tue, Jun 12, 2012 at 10:05:35PM -1000, Mitch Bradley wrote:
> >>On 6/12/2012 9:52 PM, Thierry Reding wrote:
> >>>I think the configuration spaces and downstream I/O ranges need to be
On Thu, Jun 14, 2012 at 08:12:34AM +, Arnd Bergmann wrote:
> On Sunday 10 June 2012, Andrew Lunn wrote:
> > +static int __init kirkwood_add_irq_domain(struct device_node *np,
> > + struct device_node
> > *interrupt_parent)
> > +{
> > + kirkwood_ini
On Tue, Jun 12, 2012 at 11:23:18AM -0500, Rob Herring wrote:
> Right. This is why I have reposted and copied those whom commented on my
> pull request. I think at least some of Saravana's concerns boiled down
> to not requiring using DT clock bindings and not requiring driver
> changes to move to D
On Wed, Jun 13, 2012 at 08:21:08PM +, Arnd Bergmann wrote:
> On Wednesday 13 June 2012, Thierry Reding wrote:
> > pci@8000 {
> > reg = <0x8000 0x1000>;
> > status = "disabled";
> >
> > #address-
On Sunday 10 June 2012, Andrew Lunn wrote:
> +static int __init kirkwood_add_irq_domain(struct device_node *np,
> + struct device_node
> *interrupt_parent)
> +{
> + kirkwood_init_irq();
> + irq_domain_add_legacy(np, 64, 0, 0, &irq_domain_simple_o
When matching devices against an OF device ID table, the first string of
the compatible property that is listed in the table should match,
regardless of its position in the table.
Cc: Grant Likely
Cc: Rob Herring
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Thierry Reding
---
Changes
36 matches
Mail list logo
