On Monday 17 September 2012, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [120914 02:21]:
OMAP interconnect drivers are used for the interconnect error handling.
Since they are bus driver, lets move it to newly created drivers/bus.
Cc: Arnd Bergmann a...@arndb.de
On Thursday 20 September 2012, Tony Lindgren wrote:
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -798,14 +801,26 @@ static int omap2_mcspi_request_dma(struct spi_device
*spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig =
On Wednesday 24 October 2012, Tony Lindgren wrote:
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
On Friday 26 October 2012, Felipe Balbi wrote:
+static void omap_init_ocp2scp(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ int bus_id = -1, dev_cnt = 0, i;
+ struct omap_ocp2scp_dev *ocp2scp_dev;
+ const char
On Friday 19 October 2012, Tony Lindgren wrote:
Hi Arnd Olof,
Here's the first set of omap plat header removal for v3.8 merge
window. I have at least one more related set coming, but I wanted
to get these into linux next before driver patches add more
things for me to chase down and fix.
On Friday 26 October 2012, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [121026 07:04]:
I tried running my old multiplatform scripts again and have a few
comments, but none of them serious:
$ git grep include.*mach-omap2
arch/arm/plat-omap/debug-devices.c:#include ../mach-omap2
On Friday 26 October 2012, Tony Lindgren wrote:
Here's a patch for that. It's against what I have queued up in
omap-for-v3.8/cleanup-headers. Does that look OK to you?
Hi Tony,
thanks for the quick follow-up. Using the absolute #include statements
again looks good, but now there is another
On Thursday 03 May 2012, Stephen Warren wrote:
+- #dma-channels: Number of DMA channels supported by the controller.
+- #dma-requests: Number of DMA requests signals supported by the
controller.
I don't see why those properties would be mandatory in device tree. They
don't
On Monday 30 April 2012, Jon Hunter wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Thanks for picking this up again,
On Friday 04 May 2012, Jon Hunter wrote:
I believe this is not entirely correct: sometimes the filter_fn is provided
by the slave driver, sometimes by the master driver.
Ok, but in the master case I assume they still use the same API?
The all use dma_request_channel, but the format of
On Friday 04 May 2012, Jassi Brar wrote:
I see this requires a client driver to specify a particular req_line on a
particular dma controller. I am not sure if this is most optimal.
I think such client-req_line map should be provided to the dmac controller
driver via its dt node in some
On Monday 07 May 2012, Stephen Warren wrote:
That way dmac and client drivers using DT could do away with the filter_fn.
Roughly speaking (I am not very well versed with DT syntax)
Client Node:-
mmc1: mmc@13002000 {
...
dma_tx = 891 //some platform-wide
On Tuesday 08 May 2012, Jassi Brar wrote:
On 8 May 2012 22:05, Stephen Warren swar...@wwwdotorg.org wrote:
The data doesn't need to be part of the DMA controller node in order for
the DMA controller driver to be the entity interpreting it.
I rather say, if the dma controller driver is
On Wednesday 09 May 2012, Dave Chinner wrote:
In low end flash devices, some requests might take too long than normal
due to background device maintenance (i.e flash erase / reclaim procedure)
kicking in in the context of an ongoing write, stalling them by several
orders of magnitude.
On Wednesday 09 May 2012, kdorf...@codeaurora.org wrote:
+static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
+ struct request *req, unsigned int thpi)
+{
+
+ /*
+ * If some time has elapsed since the issuing of previous write
+ * command, or
On Wednesday 09 May 2012, Christoph Hellwig wrote:
On Wed, May 09, 2012 at 01:59:40PM +, Arnd Bergmann wrote:
My feeling is that we should just treat every (REQ_SYNC | REQ_READ)
request the same and let them interrupt long-running writes,
independent of whether it's REQ_META or demand
On Wednesday 16 May 2012, Jassi Brar wrote:
On 16 May 2012 21:45, Stephen Warren swar...@wwwdotorg.org wrote:
Generic binding to provide a way to provide the client-channel map and
other dmac specific parameters to the dma controller driver
DMA Model:-
Only the most common
On Wednesday 16 May 2012, Stephen Warren wrote:
Simple case:
/* e.g. FIFO TX DMA req - 2 DMACs possible */
dma-req-0 = dmac1 DMAC1_DMA_REQ_6;
/* e.g. FIFO RX DMA req 1 DMAC possible */
dma-req-1 = dmac1 DMAC1_DMA_REQ_8;
Multiple DMAC case:
/* e.g. FIFO TX DMA req - 2 DMACs possible */
On Wednesday 16 May 2012, Jassi Brar wrote:
On 17 May 2012 01:12, Arnd Bergmann a...@arndb.de wrote:
I'm still anything but convinced by this model. Basically it's the
exact opposite of what we do for every other subsystem (irq, pinctrl,
regulator, gpio, ...), where the device using some
On Friday 18 May 2012, Stephen Warren wrote:
The driver can still request the dma line by name tx and the subsystem
would pick one out of those with the same name.
For the majority of cases, we would only need a single dma request line
Hmm. Many devices have multiple different FIFOs,
On Friday 18 May 2012, Stephen Warren wrote:
On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
So if we do that, we might want to make the dma-names property mandatory
for every device, and document what the names are.
We could do that, but one more proposal: Add the client's ID/index
On Monday 21 May 2012, Stephen Warren wrote:
The point with the direction was that it covers most cases and makes
them rather simple, while for the rare case where you need more than
two channels, you just use the otherwise optional named interface
rather than the numbered one. My
On Wednesday 30 May 2012, Kishon Vijay Abraham I wrote:
This patch series is done as a preparatory step for adding phy drivers
for dwc3 and musb.
This series adds a new driver for ocp2scp to which phy drivers are connected.
I'm planning to send phy drivers asap. Meanwhile I'd like to get
On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote:
Just put the devices you actually want into the device tree instead and
have them automatically created.
But shouldn't device tree support and non-device tree support co-exist
till the non-device tree is completely knocked out of the
On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote:
I would mark the multiplexed device compatible with simple-bus, which
results in the child devices automatically getting added.
hmm.. ocp2scp has a sysconfig register and it also has a module mode
by which it can be enabled/disabled. I
On Friday 08 June 2012, Jon Hunter wrote:
On 05/21/2012 03:32 PM, Stephen Warren wrote:
On 05/21/2012 12:18 PM, Arnd Bergmann wrote:
On Monday 21 May 2012, Stephen Warren wrote:
If so, that seems a little odd; you have to request a DMA channel for
TX, but then end up having the common
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 the
On Thursday 14 June 2012, Jon Hunter wrote:
On 06/14/2012 06:48 AM, Arnd Bergmann wrote:
On Wednesday 13 June 2012, Jon Hunter wrote:
So in that case, I don't see why the first cell after the phandle could
not be an index which could be either a direction or request-id and then
the next
On Thursday 14 June 2012, Jon Hunter wrote:
Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot.
Generic DMACs can serve any slave (peripheral) request line on any their
physical channel, USB DMACs only serve fixed USB controller instances. To
configure (connect) a
On Friday 15 June 2012, Guennadi Liakhovetski wrote:
In the common case, you could have one device connected to the third
slave ID of the first controller but the fifth slave ID of the
second controller. In this case, you really have to specify each
controller with its slave ID separately,
On Friday 15 June 2012, Mitch Bradley wrote:
#address-cells =1;
#size-cells =1;
ranges;
In light of the reg entries below, perhaps #size-cells=0 ?
dmae@0xfe008020{
compatible = renesas,sh-dma;
On Thursday 21 June 2012, Guennadi Liakhovetski wrote:
Indeed, this solution should be good enough, thanks! I'm not sure, whether
making this multiplexing available requires any additional code to the
generic DMA DT binding implementation. If it does - please, let's make
this a part of the
On Monday 25 June 2012, Vinod Koul wrote:
On Mon, 2012-06-25 at 11:51 -0500, Jon Hunter wrote:
Hi Russell,
Dan, Vinod, in this thread we have been discussing the addition of a
generic device-tree binding for DMA controllers. In the below, we were
discussing the addition of a device-tree
then?
On Mon, 2012-06-25 at 20:30 +, Arnd Bergmann wrote:
I agree, at least for the long run. However, that is a separate issue to
work on.
Right now we need a generic way to represent dma requests independent of how
they are used in the kernel. The device tree binding is supposed
On Tuesday 26 June 2012, Vinod Koul wrote:
On Tue, 2012-06-26 at 14:59 +, Arnd Bergmann wrote:
On Tuesday 26 June 2012, Vinod Koul wrote:
Today, we just ask for a channel with specific mask. Further filtering
is done in filter function as we request a channel, not a specific one
On Wednesday 27 June 2012, Vinod Koul wrote:
On Tue, 2012-06-26 at 20:27 +, Arnd Bergmann wrote:
On Tuesday 26 June 2012, Vinod Koul wrote:
On Tue, 2012-06-26 at 14:59 +, Arnd Bergmann wrote:
If we instead modify the dmaengine code itself to know about DT
rather than wrapping
On Thursday 24 March 2011, Andy Green wrote:
The following series solves a problem Panda suffers from where
because there is no local MAC address storage on the board, a
new random MAC address is applied to the onboard Ethernet
interface each time, and the wl12xx module's wlan0 interface is
Acked-by: Arnd Bergmann a...@arndb.de
when we discussed this last year, and Steven also gave his
Tested-by: Steven Rostedt rost...@goodmis.org
I have one comment to the second patch, which is changed slightly
from the older version.
Arnd
--
To unsubscribe from this list: send the line
On Friday 29 June 2012, Andy Green wrote:
+static int omap_panda_netdev_event(struct notifier_block *this,
+ unsigned long event, void
*ptr)
+{
+ struct net_device *dev = ptr;
+ struct sockaddr sa;
+ int n;
+
+ if
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
and other dynamically generated data to the drivers that are device
tree based?
The issue is that both these
On Friday 29 June 2012, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120629 06:50]:
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
and other dynamically
On Friday 29 June 2012, Andy Green wrote:
On 06/29/12 21:45, the mail apparently from Arnd Bergmann included:
On Friday 29 June 2012, Tony Lindgren wrote:
In case we have a device tree, we should just be using the USB binding
to find the specific device node, and add the property
On Friday 29 June 2012, Tony Lindgren wrote:
A lot of devices already provide the mac address in the device tree,
wherever that comes from. Ideally that would always be possible but
never necessary.
I'm not sure what it takes to add the link for the device node in the
usb probing
On Sunday 01 July 2012, Tony Lindgren wrote:
2. Pass the Panda mac information as platform data to this
driver for now with a comment on the usb path naming being
potentially wrong in the loadable modules case.
IMHO code outside of the platform driver world would be more
On Friday 01 April 2011, Tomi Valkeinen wrote:
On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote:
* The DSS display drivers introduce new infrastructure include new bus
types that have the complexity to make them completely generic, but
in practice can only work on OMAP
On Thursday 31 March 2011, Kevin Hilman wrote:
Arnd Bergmann a...@arndb.de writes:
But that's the point. The incentive is there for managing the infrastructure
within the SoC, but not across SoCs.
OK, but the rest of my thread went on to describe how at least a few ARM
SoC maintainers
On Thursday 31 March 2011, Thomas Gleixner wrote:
On Thu, 31 Mar 2011, Arnd Bergmann wrote:
Right, but the problem starts in way simpler areas like irq chips and
gpio stuff, where lots of the IP cores are similar and trivial enough
to be shared across many SoC families.
Yes, I'm sure
On Friday 01 April 2011, Tomi Valkeinen wrote:
Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged,
though. I need to contact them and see if they're still interested in
working on the common interface.
I pushed back quite hard on some of the aspects there, which probably
On Friday 01 April 2011, Ingo Molnar wrote:
IMO the right answer is what Linus and Thomas outlined:
1) provide a small number of clean examples and clean abstractions
2) to not pull new crap from that point on
3) do this gradually but consistently
I.e. make all your requirements
On Wednesday 30 March 2011, Russell King - ARM Linux wrote:
On Wed, Mar 30, 2011 at 07:06:41PM +0200, Arnd Bergmann wrote:
I'm still new to the ARM world, but I think one real problem is the way
that all platforms have their own trees with a very flat hierarchy --
a lot of people
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of which
are ARMv7 based.
Define interesting.
The ones that are causing the churn that we're talking about.
Platforms that have been
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 16:59, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of which
are ARMv7 based.
Define
On Friday 01 April 2011, Will Deacon wrote:
1. The core arch code is not a problem (Russell does a great job here)
2. The platform specific code contains a lot of crap that doesn't belong
there
(not enough reviewers to push back on crap)
3. The amount of crap in platform specfic
On Friday 01 April 2011 23:10:04 Kevin Hilman wrote:
Arnd Bergmann a...@arndb.de writes:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all of
which
are ARMv7 based
On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote:
On Fri, 1 Apr 2011, Arnd Bergmann wrote:
I thought new ones were generally Cortex-M3 based. Either way, even
if there are exceptions, focusing on ARMv7 at first should give
a good representation of the new development.
The actual
On Saturday 02 April 2011, Nicolas Pitre wrote:
On Sat, 2 Apr 2011, Arnd Bergmann wrote:
On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote:
I however don't think it is practical to go off in a separate
mach-nocrap space and do things in parallel. Taking OMAP as an example
On Monday 04 April 2011, Benjamin Herrenschmidt wrote:
On Fri, 2011-04-01 at 16:28 +0200, Detlef Vollmann wrote:
* No board files
Where do you put code that needs to run very early (e.g. pinging the
watchdog)?
Even on powerpc I keep board files :-)
The main thing is:
- The
On Sunday 03 April 2011, Russell King - ARM Linux wrote:
On Sun, Apr 03, 2011 at 05:26:37PM +0200, Arnd Bergmann wrote:
There are a few other examples that were done in a similar way:
* The drivers/ide code still serves a few hardware platforms that
never had anyone write a new libata
On Wednesday 06 April 2011, Catalin Marinas wrote:
On Wed, 2011-04-06 at 00:19 +0100, Linus Walleij wrote:
2011/4/1 Linus Torvalds torva...@linux-foundation.org:
Basically it requires you to get the physical address and size of
each peripheral, then at offset -0x10 from the end address
On Friday 15 April 2011 15:39:55 Rob Herring wrote:
On 04/15/2011 08:06 AM, Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
It's more than
On Friday 15 April 2011, Russell King - ARM Linux wrote:
On Fri, Apr 15, 2011 at 09:32:01AM -0600, Grant Likely wrote:
Yes, once the infrastructure is in place, powerpc can do its own
migration to the new code. I vote for putting it in lib at the
outset.
I don't agree with stuffing
On Friday 15 April 2011, Russell King - ARM Linux wrote:
On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote:
From: Ramesh Gupta grgu...@ti.com
This patch is to flush the iommu page table entries from L1 and L2
caches using dma_map_single. This also simplifies the
On Monday 18 April 2011, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [110418 10:26]:
On Friday 15 April 2011, Russell King - ARM Linux wrote:
On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote:
From: Ramesh Gupta grgu...@ti.com
This patch is to flush
On Monday 18 April 2011, Hiroshi DOYU wrote:
From: ext Tony Lindgren t...@atomide.com
have a generic replacement for this code we should start using it.
I'm afraid that there's no general IOMMU APIs yet, or already? If
there is, migrating to those general IOMMU API is the way, but still
On Monday 18 April 2011, Kyungmin Park wrote:
On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann a...@arndb.de wrote:
One missing piece is still a way for a platform to provide both
the iommu and the dma-mapping API in a unified driver. Right now,
you have to export both interface
On Tuesday 19 April 2011, Kyungmin Park wrote:
On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 18 April 2011, Kyungmin Park wrote:
On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann a...@arndb.de wrote:
One missing piece is still a way for a platform
On Tuesday 19 April 2011, Kyungmin Park wrote:
On Tue, Apr 19, 2011 at 9:01 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 19 April 2011, Kyungmin Park wrote:
On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 18 April 2011, Kyungmin Park wrote:
On Mon
On Thursday 12 May 2011, Mike Rapoport wrote:
@@ -299,17 +299,14 @@ static struct omap2_hsmmc_info mmc[] = {
static struct gpio_led igep_gpio_leds[] = {
[0] = {
.name = gpio-led:red:d0,
- .gpio = IGEP2_GPIO_LED0_RED,
On Sunday 15 May 2011, m...@compulab.co.il wrote:
We can keep all the data structures that differ between IGEP2 and IGEP3.
However, this significantly reduces the benifit of the series.
There's already code in the IGEP2 that differentiates between HW
revisions, so anyway the board support will
On Friday 03 June 2011, Ohad Ben-Cohen wrote:
First stab at iommu consolidation:
Hi Ohad,
Great to see your progress here!
- Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
users can now start using the generic iommu layer instead of calling
omap-specific iommu
On Sunday 05 June 2011, Ohad Ben-Cohen wrote:
As far as I can tell, once we have that in
place, we you can migrate omap3isp from iovmm to dma-mapping and
remove iovmm.
Sounds like a plan.
I'd still prefer us to take small steps here, and not gate the omap
iommu cleanups with Marek's
On Thursday 09 June 2011 15:30:24 Peter Ujfalusi wrote:
Rename the driver, and header file from twl4030-codec to
twl4030-audio.
To avoid breakage change depending drivers at the same time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Misael Lopez Cruz misael.lo...@ti.com
---
Hi Ohad,
On Tuesday 21 June 2011, Ohad Ben-Cohen wrote:
This patch set adds a generic AMP/IPC framework which makes it possible to
control (power on, boot, power off) and communicate (simply send and receive
messages) with those remote processors.
This looks really nice overall, but I don't
On Wednesday 22 June 2011, Ohad Ben-Cohen wrote:
One point I noticed is the use of debugfs, which you should probably
replace at some point with a stable API, e.g. your own debugfs-like
file system, but there is no hurry to do that now.
debugfs is only being used to expose debugging info
On Thursday 23 June 2011 18:27:10 Grosen, Mark wrote:
First, we are not abandoning DSPLINK. We have many users of this, even
though it is out-of-tree, and we will continue to support it. That said, we
do intend to make this new design the basis for DSPLINK-like
functionality. It's designed to
On Wednesday 22 February 2012, Ohad Ben-Cohen wrote:
Hi Arnd,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
rpmsg-for-3.4
To get the very basic rpmsg+remoteproc core functionality for 3.4.
This is basically the same stuff I sent for 3.3, with an
On Thursday 23 February 2012, Mircea Gherzan wrote:
The PandaBoard features a Texas Instruments WiLink7 Bluetooth
chip, supported by the btwilink driver.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
No objections to the patch, but please send it to the maintainer,
not to me. You also
On Thursday 23 February 2012, Tony Lindgren wrote:
Please pull omap fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes
This contains a fix for omap4 to call memblck_steal() from
.reserve like it should be, and fixes a regression for smsc911x
using boards as
On Tuesday 28 February 2012, Ohad Ben-Cohen wrote:
On Tue, Feb 28, 2012 at 11:02 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
1. It selects OMAP_IOMMU which may not have its dependencies satisfied.
I'll select IOMMU_SUPPORT too (I prefer selecting here rather than
depending,
On Wednesday 29 February 2012, Tony Lindgren wrote:
This contains fixes for MMC platform init to allow marking
functions that should be __init as __init. Also included are
some randconfig fixes.
Regards,
Tony
The following changes since commit
On Wednesday 29 February 2012, Tony Lindgren wrote:
This contains two changes that were too late
for the previous merge window so let's get these
out of the way first.
Pulled into next/soc
Thanks,
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
On Wednesday 29 February 2012, Tony Lindgren wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap omap1
Janusz Krzysztofik (7):
ARM: OMAP1: ams-delta: register latch dependent devices later
ARM: OMAP1: ams-delta: convert latches to basic_mmio_gpio
ARM:
On Wednesday 29 February 2012, Tony Lindgren wrote:
Benoit Cousson (10):
arm/dts: OMAP: Remove bootargs node from board files
ARM: OMAP2+: kconfig: Enable devicetree by default for OMAP2+ systems
ARM: OMAP2+: board-generic: Remove un-needed .atag_offset for DT_MACHINE
On Wednesday 29 February 2012, Tony Lindgren wrote:
This is mostly changes needed for io.h removal, and one
patch to remove unused flag for McSPI. Note that these
are based on RMK's for-armsoc.
Also, these cause a minor merge conflict for mach-omap2/Kconfig
with the fixes-non-critical
On Saturday 03 March 2012, Tony Lindgren wrote:
Well 85631d2 builds fine, looks like now some more includes of
plat/hardware.h are now needed.Have not yet tracked down which
commit triggers the build errors. Eventually those should become
local headers too..
I've tried building
On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
On Tue, Mar 06, 2012 at 03:58:34PM +0100, Cousson, Benoit wrote:
We added that to avoid cluttering the drivers with a bunch of #ifdef
CONFIG_OF as proposed by Grant and Rob... and most drivers adaptation
were done having that
On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
On Tue, Feb 28, 2012 at 12:11:37PM +0200, Ohad Ben-Cohen wrote:
On Tue, Feb 28, 2012 at 12:01 PM, Arnd Bergmann a...@arndb.de wrote:
I think 'depends' would be better here, because selecting IOMMU_SUPPORT
has other side-effects
On Wednesday 14 March 2012, Tony Lindgren wrote:
* Olof Johansson o...@lixom.net [120310 10:26]:
On Thu, Mar 08, 2012 at 12:53:29PM -0800, Tony Lindgren wrote:
Hi Olof,
Here are two more pre-emptive fixes for upcoming merge
window to pull into arm-soc/next/fixes-non-critical.
On Thursday 15 March 2012, Tony Lindgren wrote:
* Cousson, Benoit b-cous...@ti.com [120314 16:41]:
Hi Tony,
Here are the remaining DTS patches for 3.4.
On top of the previous pull request, I just added the MMC DTS since the
driver adaptation just got queued.
It will be still
On Thursday 15 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 void *
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote:
This was done like IRQ on purpose, because an Interrupt ReQuest line and
a DMA Request line are really similar for the HW point of view at IP
level.
I'm not sure
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
Thank you both for missing my point.
#define OMAP24XX_DMA_SHA1MD5_RX 13 /* S_DMA_12 */
#define OMAP34XX_DMA_SHA2MD5_RX 13 /* S_DMA_12 */
#define OMAP242X_DMA_EXT_DMAREQ214 /* S_DMA_13 */
On Thursday 15 March 2012, Nicolas Ferre wrote:
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
+/**
+ * of_dma_to_resource - Decode a node's DMA and
On Friday 16 March 2012, Cousson, Benoit wrote:
And it seems that other ARM SoCs are using it for the same purpose.
There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the ones that don't use dmaengine but either the
ISA dma api or a platform specific variant
On Friday 16 March 2012, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley p...@pwsan.com wrote:
From: Paul Walmsley p...@pwsan.com
Date: Fri, 16 Mar 2012 16:06:30 -0600
Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
Mark the common clk code
On Saturday 17 March 2012, Grant Likely wrote:
On Thu, 15 Mar 2012 09:26:52 +, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve
On Saturday 17 March 2012, Turquette, Mike wrote:
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 2eaf17e..a0a83de 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV
menuconfig COMMON_CLK
- bool Common Clock
Author: Arnd Bergmann a...@arndb.de
Date: Sat Mar 17 21:10:51 2012 +
clk: make CONFIG_COMMON_CLK invisible
All platforms that use the common clk infrastructure should select
COMMON_CLK from platform code, and on all other platforms, it must
not be enabled, so
On Sunday 18 March 2012, Thierry Reding wrote:
Not enough information to check signature validity. Show Details
* Grant Likely wrote:
On Thu, 15 Mar 2012 11:27:36 +0100, Thierry Reding
thierry.red...@avionic-design.de wrote:
So if we decide to explicitly allow specifying names, then
201 - 300 of 749 matches
Mail list logo
