On Fri, 30 Nov 2012, Philip, Avinash wrote:
> Is there any way to get HWMOD and DT patches getting accepted in 3.8?
> Or should I wait and send rebased patch based on 3.8-rc1?
Our upstreams aren't taking any more new features for v3.8, so basing on
v3.8-rc1 is the best thing to do now.
In the m
On Fri, 26 Oct 2012, Benoit Cousson wrote:
> On 10/26/2012 05:16 PM, Roger Quadros wrote:
>
> > I still can't get musb to work on 3.7-rc2. Apparently it is still
> > missing the patches from Benoit's for_3.7/dts_part2.
> >
> > Maybe I just need to wait for it to be merged?
>
> They are now in a
r to be present on
those chips. The patch has been modified to restrict these hwmods to
OMAP34xx/36xx chips; updated patch below.
- Paul
From: Paul Walmsley
Date: Thu, 20 Sep 2012 18:23:22 -0600
Subject: [PATCH] ARM: OMAP3: hwmod data: add mmu data for iva and isp
Add mmu hwmod data for iva and
On Thu, 13 Sep 2012, Jon Hunter wrote:
> Some instances of the DMTIMER peripheral on OMAP devices have the ability
> to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER
> attribute to indicate which timers can interrupt the DSP. By using the
> omap_dm_timer_request_by_cap() API,
On Thu, 13 Sep 2012, Jon Hunter wrote:
> For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER)
> power domains. Hence, when the dmtimer is configured to use the "timer_sys_ck"
> as its functional clock the actual clock used is different depending on
> whether
> the clock is
On Wed, 12 Sep 2012, Omar Ramirez Luna wrote:
> Add mmu hwmod data for iva and isp.
>
> Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
> propagated (previously on iommu resource info) to hwmod data in OMAP3,
> so users of iommu and tidspbridge can avoid issues of two modules
> m
On Wed, 19 Sep 2012, Cousson, Benoit wrote:
> On 9/12/2012 2:45 PM, Omar Ramirez Luna wrote:
> > Add mmu hwmod data for ipu and dsp.
> >
> > Cc: Benoit Cousson
> > Signed-off-by: Omar Ramirez Luna
>
> Acked-by: Benoit Cousson
Thanks, queued for 3.7.
- Paul
__
On Wed, 12 Sep 2012, Omar Ramirez Luna wrote:
> If included without IOMMU_API being selected it will break
> compilation:
>
> arch/arm/plat-omap/include/plat/iommu.h:
> In function 'dev_to_omap_iommu':
> arch/arm/plat-omap/include/plat/iommu.h:148:
> error: 'struct dev_archdata' has n
Hi Benoît,
On Wed, 12 Sep 2012, Omar Ramirez Luna wrote:
> Add mmu hwmod data for ipu and dsp.
>
> Cc: Benoit Cousson
> Signed-off-by: Omar Ramirez Luna
Care to ack this one?
- Paul___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlab
On Mon, 27 Aug 2012, Hiremath, Vaibhav wrote:
> On Mon, Aug 27, 2012 at 22:50:12, Paul Walmsley wrote:
>
> > Is the dcan driver present in v3.6-rc kernels?
>
> Multiple versions have been submitted already, I have validated using them.
> Irrespective of this, it is i
Hi
On Mon, 27 Aug 2012, Vaibhav Hiremath wrote:
> Currently, the device names for the dcan module follows the
> format "dcan.X", where 'X' is the dcan instance number.
> On other side, driver may request for clock with/without con_id
> and dev_id, and it is expected that platform should respect t
Hi
On Thu, 2 Aug 2012, Daniel Mack wrote:
> Make the driver control the device clocks. Appearantly, the Davinci
> platform probes this driver with the clock all powered up, but on OMAP,
> this isn't the case.
>
> Signed-off-by: Daniel Mack
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 16 +
Hi Rob,
On Sat, 14 Jul 2012, Paul Walmsley wrote:
> My point, perhaps unclear, was about the aliases. Do you have a different
> approach in mind that applications should use, other than requesting a
> specific timer by ID?
Please disregard this question, I think I'm mi
Hi Rob,
thanks for your response.
On Sat, 14 Jul 2012, Rob Herring wrote:
> On 07/14/2012 01:56 AM, Paul Walmsley wrote:
> > On Fri, 13 Jul 2012, Rob Herring wrote:
> >
> >> I'm not sure this is really a good use of aliases. UARTs use aliases
> >> becaus
Hi
On Fri, 13 Jul 2012, Rob Herring wrote:
> I'm not sure this is really a good use of aliases. UARTs use aliases
> because it is important that the UART number to tty number is known and
> fixed. IIUC, as an example you are picking timer1 because it has
> properties X, Y and Z. If so, then yo
Hi
On Fri, 13 Jul 2012, Jon Hunter wrote:
> 1. If DT blob is present, then let HWMOD create the timer devices dynamically.
This probably should read "is _not_ present", yes?
- Paul
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.o
On Thu, 8 Mar 2012, Grant Likely wrote:
> Yes, absolutely use separate compatible values. It is always important
> to be specific as to the silicon implementing the IP.
In that case, it is probably best to use the full chip name in the
compatible string, e.g., omap2420 or omap2430 rather than j
+ devicetree-discuss, lkml
On Mon, 3 Oct 2011, Cousson, Benoit wrote:
> But at that time, device tree was not there...
> Now, the whole dev_attr stuff will be replaced because device tree is able to
> provide the driver any kind of custom information that can be retrieved
> directly from the driv
On Tue, 30 Aug 2011, Gary Thomas wrote:
> On 2011-08-30 15:43, Paul Walmsley wrote:
>
> > So are these addresses virtual? My (perhaps incorrect) understanding of
> > the device tree files was that they were intended to describe the physical
> > memory map, rather tha
On Tue, 30 Aug 2011, Pierre Beaumon wrote:
> Also I believe one big arm problem is a lack of common infrastructure
> that lead to code duplication. Some machine try to do too much things.
> omap2 (mach-omap2 + plat-omap) is about 80 KSLOC over 400KSLOC (76 mach
> + plat directories). That 8 tim
Hi,
Looking at some of the PPC DTS files in arch/powerpc/boot/dts, there are
some files that are mostly identical, except for some strange
differences.
For example, tqm8548.dts and tqm8548-bigflash.dts differ mostly in that
the former file claims that the SoC registers start at 0xe000[1],
Hi,
On Tue, 30 Aug 2011, Stephen Warren wrote:
> David Gibson wrote at Monday, August 29, 2011 10:23 PM:
> > On Tue, Aug 23, 2011 at 04:43:20PM -0600, Stephen Warren wrote:
> > > You may define constants as follows:
> > >
> > > /define/ $TWO 2;
> > > /define/ $FOUR 4;
> > > /define/ $OTHER $FOUR;
On Fri, 26 Aug 2011, David Gibson wrote:
> static struct of_device_id foodevice_of_match[] __devinitdata = {
> { .compatible = "foocorp,foodevice1234",
> .resource_names = {"base_regs", "extra_regs", }, },
> { .compatible = "foocorp,foodevice1239",
> .resource_names = {
On Fri, 26 Aug 2011, Arnd Bergmann wrote:
> I don't think anyone was talking about converting driver /to/ the
> _byname method
For drivers that use multiple resources of the same type, converting those
to use platform_get_resource_byname() does indeed seem appropriate.
By the way, the same IP b
On Sat, 27 Aug 2011, Arnd Bergmann wrote:
> Right, and I guess we can simply ignore DMA and ioport resources because
> they are extremely rare, right?
DMA resources are quite widely used.
For example, looking at the SoCs with some publicly-available
documentation, the Motorola i.MX51 reference
On Thu, 25 Aug 2011, Arnd Bergmann wrote:
> It's not at all about whether the Linux codein drivers/of supports this
> or not, adding it would be trivial. The point is that it would be
> *wrong* to add it because there already exists a way to identify every
> resource in the device tree and we shou
On Wed, 10 Aug 2011, David Gibson wrote:
> Of course, the problem with reg-names is that it will be ignored by
> older OSes, and so 'reg' must still be in the correct order.
Most ARM SoC Linux ports aren't using DT now, so there isn't really an
older OS case here. Might as well try to get somet
On Wed, 10 Aug 2011, David Gibson wrote:
> The difficulty with adding th enames to the DT itself is that it
> exposes the essentially Linux-specific names in what's supposed to be
> an OS neutral data structure.
The names are supposed to pertain to the hardware IP block, not the OS.
See for exa
Hi,
one case that I forgot to mention:
On Sun, 28 Aug 2011, Paul Walmsley wrote:
> Several upstream device drivers get their DMA request line IDs from the
> device data format[14][15][16]. But more drivers should be doing this
> than currently are[17]:
>
> - the device dr
On Sun, 28 Aug 2011, David Gibson wrote:
> I've never been very clear on what exactly DMA resources cover,
DMA resource data are usually DMA request line ID numbers.
DMA request lines are dedicated, unidirectional hardware signals from I/O
devices to one or more independent DMA controllers[1][2
30 matches
Mail list logo
