On 7/6/2012 3:23 PM, David VomLehn (dvomlehn) wrote:
The kernel *must* go where it is linked, but the FDT contains only relative
references and is thus free to go anywhere. The same is true of ramdisks, which
are usually placed after the kernel.
Right, but the kernel image is compressed, so aft
The kernel *must* go where it is linked, but the FDT contains only relative
references and is thus free to go anywhere. The same is true of ramdisks, which
are usually placed after the kernel. How about doing the same with your FDT?
> -Original Message-
> From: devicetree-discuss [mailto:d
I'm passing a flatted device tree from OLPC's bootloader (which
is a full Open Firmware implementation) to the kernel. If I
put the FDT at the "traditional" address 0x100, bad things
happen when the DT is larger than 16K. The FDT extends past
the 0x4000 boundary and gets overwritten by the early
On Fri, 6 Jul 2012, Russell King - ARM Linux wrote:
> On Fri, Jul 06, 2012 at 01:36:32PM +0200, Guennadi Liakhovetski wrote:
> > I like this idea, but why don't we extend it to also cover the non-DT
> > case? I.e., why don't we add the above callback (call it "match" or
> > "filter" or anything
On Fri, Jul 06, 2012 at 05:43:38PM +0200, Guennadi Liakhovetski wrote:
> Hi Arnd
>
> On Fri, 6 Jul 2012, Arnd Bergmann wrote:
> > How would the individual driver know the size of the filter_arg?
>
> In exactly the same way as most dmaengine drivers do it today: they don't
> touch filter_arg unti
On Fri, Jul 06, 2012 at 08:08:23PM +, Arnd Bergmann wrote:
> On Thursday 05 July 2012, Andrew Lunn wrote:
> > > I think the latter one needs to be
> > >
> > > +static int __initdata gpio1_irqs[4] = {
> > > + IRQ_DOVE_HIGH_GPIO,
> > > + IRQ_DOVE_HIGH_GPIO,
> > > + IRQ_DOVE_HIGH_GPIO
On Fri, Jul 06, 2012 at 01:36:32PM +0200, Guennadi Liakhovetski wrote:
> I like this idea, but why don't we extend it to also cover the non-DT
> case? I.e., why don't we add the above callback (call it "match" or
> "filter" or anything else) to dmaengine operations and inside (the
> extended) dm
On Thursday 05 July 2012, Andrew Lunn wrote:
> > I think the latter one needs to be
> >
> > +static int __initdata gpio1_irqs[4] = {
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > +};
> >
> > so we register all four part
On 07/05/2012 06:15 AM, Thierry Reding wrote:
> Here's a new proposal that should address all issues collected
> during the discussion of the previous one:
>
> From tegra20.dtsi:
...
At a quick glance, that all seems pretty reasonable now.
> One problem I've come across when trying to get some r
On Friday 06 July 2012, Guennadi Liakhovetski wrote:
> > >
> > > for_each_channel() {
> > > ret = chan->device->device_alloc_chan_resources(chan,
> > > filter_arg);
> > > if (!ret)
> > > return chan;
> > > else if (ret != -ENODEV)
> > >
Hi Shaik,
On 07/06/2012 02:45 PM, Shaik Ameer Basha wrote:
Adding all 4 gscalar devices from DT device list in machine file.
nit: s/gscalar/gscaler
The above sentence doesn't quite parse though.
Signed-off-by: Abhilash Kesavan
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Shaik Ameer
On Thu, Jul 05, 2012 at 10:09:17PM +0200, Wolfram Sang wrote:
> Hi Grant,
> > the next merge window, and quite possibly the next window. Since you
> > three have agreed to co-maintain those subsystems with me, can you
> > please take a look at the patches that have been posted, pick up the
> > on
On Fri, Jul 06, 2012 at 02:13:12PM +0530, Laxman Dewangan wrote:
> There is multiple voltage input pins on device which
> takes the voltage input for different voltage regulator.
> Support to configure the voltage input supplied by
> different regulator for each regulators.
Applied, thanks.
sign
On Mar 21, 2012, at 11:54 PM, 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
> bas
On Fri, Jun 29, 2012 at 05:48:54PM +0800, Richard Zhao wrote:
> struct ci13xxx represent the controller, which may be device or host,
> so name its variables as ci.
>
> Signed-off-by: Richard Zhao
> Reviewed-by: Felipe Balbi
> Signed-off-by: Alexander Shishkin
> Reviewed-by: Marek Vasut
This
> -Original Message-
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+stephen.neuendorffer=xilinx@lists.ozlabs.org] On Behalf Of
> Benjamin Herrenschmidt
> Sent: Friday, July 06, 2012 1:10 AM
> To: mon...@monstr.eu
> Cc: devicetree-discuss@lists.ozlabs.org
> Subject: Re:
Hi Grant,
On 7/5/2012 6:13 PM, Heiko Schocher wrote:
> Hello Sekhar,
>
> On 03.07.2012 21:16, Sekhar Nori wrote:
>> From: Heiko Schocher
>>
>> Add a function to initialize the Common Platform Interrupt Controller
>> (cp_intc) from TI used on OMAP-L1x SoCs using a device tree node.
>>
>> Signed-of
On Fri, Jul 06, 2012 at 06:07:43AM +, Jia Hongtao-B38951 wrote:
>
> > -Original Message-
> > From: Greg KH [mailto:g...@kroah.com]
> > Sent: Friday, July 06, 2012 12:26 PM
> > To: Jia Hongtao-B38951
> > Cc: Rob Herring; devicetree-discuss@lists.ozlabs.org; linux-
> > ker...@vger.kernel
On 07/06/2012 03:09 AM, Dong Aisheng wrote:
> From: Dong Aisheng
>
> The General Purpose Registers (GPR) is used to select operating modes for
> general features in the SoC, usually not related to the IOMUX itself,
> but it does belong to IOMUX controller.
> We simply provide an convient API for
On 07/06/2012 02:43 AM, Laxman Dewangan wrote:
> There is multiple voltage input pins on device which
> takes the voltage input for different voltage regulator.
> Support to configure the voltage input supplied by
> different regulator for each regulators.
>
> Signed-off-by: Laxman Dewangan
Acke
Hi Arnd
On Fri, 6 Jul 2012, Arnd Bergmann wrote:
> On Friday 06 July 2012, Guennadi Liakhovetski wrote:
> > On Mon, 25 Jun 2012, Arnd Bergmann wrote:
> >
> > [snip]
> >
> > > The channel data in the device tree is still in a format
> > > that is specific to that dmaengine driver and interpreted
On Friday 06 July 2012, Guennadi Liakhovetski wrote:
> On Mon, 25 Jun 2012, Arnd Bergmann wrote:
>
> [snip]
>
> > The channel data in the device tree is still in a format
> > that is specific to that dmaengine driver and interpreted
> > by it. Using the regular dma_filter_fn prototype is not
> >
On Thu, Jun 28, 2012 at 11:15:37AM +0800, Shawn Guo wrote:
> The of_get_named_gpio_flags can retrieve the second cell of
> gpio-specifier as the "flags". The imx and mxs gpio driver do not
> have their own .xlate callback, which means of_gpio_simple_xlate is
> used and it's a 1:1 mapping between g
On Mon, 25 Jun 2012, Arnd Bergmann wrote:
[snip]
> The channel data in the device tree is still in a format
> that is specific to that dmaengine driver and interpreted
> by it. Using the regular dma_filter_fn prototype is not
> necessary, but it would be convenient because the dmaengine
> code al
On 06/30/2012 03:41 AM, David VomLehn (dvomlehn) wrote:
-Original Message-
From: devicetree-discuss [mailto:devicetree-discuss-
bounces+dvomlehn=cisco@lists.ozlabs.org] On Behalf Of Michal Simek
Sent: Tuesday, June 26, 2012 4:17 AM
To: devicetree-discuss@lists.ozlabs.org
Cc: John Will
On Tue, Jun 26, 2012 at 07:40:10AM +0800, Rob Herring wrote:
> On 06/25/2012 01:28 AM, Dong Aisheng wrote:
> > From: Dong Aisheng
> >
> > prom_update_property() currently fails if the property doesn't
> > actually exist yet which isn't what we want. Change to add-or-update
> > instead of update-o
From: Dong Aisheng
The General Purpose Registers (GPR) is used to select operating modes for
general features in the SoC, usually not related to the IOMUX itself,
but it does belong to IOMUX controller.
We simply provide an convient API for driver to call to set the general purpose
register bits
From: Dong Aisheng
The original pin registers table is derived from u-boot mainline,
but somehow it was found missing some mux functions for USBOTG_ID.
We added it at the bottom by following the exist pin function ids,
then it will not break the exist using of pin function id in dts file.
Report
Hi Wim,
* jgq...@gmail.com [120531 20:56]:
> From: Xiao Jiang
>
> Add device table for omap_wdt to support dt.
Care to ack this patch in the series?
Regards,
Tony
>
> Signed-off-by: Xiao Jiang
> ---
> drivers/watchdog/omap_wdt.c |7 +++
> 1 files changed, 7 insertions(+), 0 delet
* AnilKumar Ch [120705 02:18]:
> Adds basic pinctrl support for AM33XX family of devices. This patch
> is based on the pinctrl-simple driver submitted by Tony Lindgren's
> here: http://lwn.net/Articles/496075/
>
> Signed-off-by: AnilKumar Ch
> ---
> arch/arm/boot/dts/am33xx.dtsi | 12
On 07/06/2012 10:10 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-07-06 at 10:02 +0200, Michal Simek wrote:
ok. How that FDT blob segment should look like?
It can't be just one node because it also requires path where it is connected.
It means at least the part like below for injecting.
No,
On Fri, 2012-07-06 at 10:02 +0200, Michal Simek wrote:
> ok. How that FDT blob segment should look like?
> It can't be just one node because it also requires path where it is connected.
>
> It means at least the part like below for injecting.
No, my idea was to pass 3 arguments:
- action (enum
On 07/06/2012 09:08 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-07-06 at 08:51 +0200, Michal Simek wrote:
On 07/06/2012 08:19 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-07-06 at 08:03 +0200, Michal Simek wrote:
The way it works at the moment is that when something new is plugged in,
th
On Fri, 2012-07-06 at 08:51 +0200, Michal Simek wrote:
> On 07/06/2012 08:19 AM, Benjamin Herrenschmidt wrote:
> > On Fri, 2012-07-06 at 08:03 +0200, Michal Simek wrote:
> >>>
> >>> The way it works at the moment is that when something new is plugged in,
> >>> the hypervisor talks to a proprietary
34 matches
Mail list logo
