On Friday 22 October 2010 14:39:33 Cyril Chemparathy wrote:
+/* Register Access Helpers */
+static inline u32 ssp_read(struct ti_ssp *ssp, int reg)
+{
+return __raw_readl(ssp-regs + reg);
+}
+
+static inline void ssp_write(struct ti_ssp *ssp, int reg, u32 val)
+{
+
On Friday 11 February 2011, Subhasish Ghosh wrote:
This patch adds support for the CAN device emulated on PRUSS.
Hi Subhasish,
This is a detailed walk through the can driver. The pruss_can.c
file mostly looks good, there are very tiny changes that I'm
suggesting to improve the code. I assume
On Friday 18 February 2011, Pratheesh Gangadhar wrote:
Signed-off-by: Pratheesh Gangadhar prathe...@ti.com
This patch implements PRUSS (Programmable Real-time Unit Sub System)
UIO driver which exports SOC resources associated with PRUSS like
I/O, memories and IRQs to user space. PRUSS is
On Friday 18 February 2011, Thomas Gleixner wrote:
On Fri, 18 Feb 2011, Arnd Bergmann wrote:
On Friday 18 February 2011, Pratheesh Gangadhar wrote:
Signed-off-by: Pratheesh Gangadhar prathe...@ti.com
+static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
+{
+ return
On Friday 18 February 2011 19:23:49 Thomas Gleixner wrote:
On Fri, 18 Feb 2011, Alan Cox wrote:
On Fri, 18 Feb 2011 19:17:38 +0530
Subhasish Ghosh subhas...@mistralsolutions.com wrote:
Hello,
Regarding the semaphore to mutex migration.
We are using down_trylock in interrupt
On Tuesday 22 February 2011, Subhasish Ghosh wrote:
@@ -122,13 +122,10 @@ static void omapl_pru_tx_chars(struct omapl_pru_suart
*soft_uart, u32 uart_no)
if (!(suart_get_duplex(soft_uart, uart_no) ePRU_SUART_HALF_TX))
return;
- if
On Wednesday 02 March 2011, Pratheesh Gangadhar wrote:
+
+static struct clk *pruss_clk;
+static struct uio_info *info;
+static dma_addr_t sram_paddr, ddr_paddr;
+static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
+
To my initial comment about these being single-instance
variables, you
On Wednesday 02 March 2011 21:09:56 Hans J. Koch wrote:
+static struct uio_info *info;
+static dma_addr_t sram_paddr, ddr_paddr;
+static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
So the correct thing would be
static void __iomem *prussio_vaddr;
static void *sram_vaddr, *ddr_vaddr;
On Thursday 03 March 2011 19:07:57 Pratheesh Gangadhar wrote:
+struct uio_pruss_dev {
+ struct uio_info *info;
+ struct clk *pruss_clk;
+ dma_addr_t sram_paddr;
+ dma_addr_t ddr_paddr;
+ void __iomem *prussio_vaddr;
+ void *sram_vaddr;
+ void
critical industrial
communication data link layer and communicates with application stack
running in user space via shared memory and IRQs.
Looks good
Signed-off-by: Pratheesh Gangadhar prathe...@ti.com
Reviewed-by: Thomas Gleixner t...@linutronix.de
Reviewed-by: Arnd Bergmann a...@arndb.de
On Friday 04 March 2011, Nori, Sekhar wrote:
On Fri, Mar 04, 2011 at 19:50:28, Hans J. Koch wrote:
On Fri, Mar 04, 2011 at 10:12:52AM +0530, Pratheesh Gangadhar wrote:
diff --git a/include/linux/uio_pruss.h b/include/linux/uio_pruss.h
new file mode 100644
index 000..8c9b2c9
---
On Tuesday 08 March 2011, Thomas Gleixner wrote:
+static irqreturn_t pruss_handler(int irq, struct uio_info *info) {
+ struct pruss_priv *priv = info-priv;
+ struct uio_pruss_dev *gdev = priv-pupdev;
Note that info is a pointer to array supporting 8 interrupts. This allows to
On Tuesday 08 March 2011, Subhasish Ghosh wrote:
+struct da8xx_pruss {
+ struct device *dev;
+ spinlock_t lock;
+ struct resource *res;
+ struct clk *clk;
+ u32 clk_freq;
+ void __iomem *ioaddr;
+};
+s32 pruss_disable(struct device *dev, u8 pruss_num)
+{
+
introduced which gets initialized during
the initialization of each relevant SoC
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
The change looks good, it's definitely a step in the right
direction.
Acked-by: Arnd Bergmann a...@arndb.de
I think you can go even further:
* A straightforward
On Tuesday 15 March 2011 07:00:44 Nori, Sekhar wrote:
* If you need to access sysmod in multiple places, a nicer
way would be to make the virtual address pointer static,
and export the accessor functions for it, rather than
having a global pointer.
Seems like opinion is divided
On Wednesday 30 March 2011, Subhasish Ghosh wrote:
+s32 pruss_disable(struct device *dev, u8 pruss_num)
+{
+ struct da8xx_pruss *pruss = dev_get_drvdata(dev-parent);
+ struct da8xx_prusscore_regs *h_pruss;
+ struct pruss_map *pruss_mmap = (struct pruss_map *)pruss-ioaddr;
+ u32
On Wednesday 30 March 2011, Subhasish Ghosh wrote:
I am using a .setup to initialize pin mux etc. To use the mfd_cells directly
should I
use .enable and .disable of the mfd_cells instead of the .setup.
I think it would be best not to define any per-board functions that
are needed to set up
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 22 April 2011, Subhasish Ghosh wrote:
This patch adds the pruss MFD driver and associated include files.
For details regarding the PRUSS please refer the folowing link:
http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem
The rational behind the MFD driver
On Wednesday 27 April 2011, Subhasish Ghosh wrote:
- Use just one value per sysfs file
SG - I felt adding entry for each mbx_id will clutter the sysfs.
Is it ok to do that.
That is probably not much better either.
Note also that every sysfs file needs to come with associated
On Wednesday 27 April 2011, Subhasish Ghosh wrote:
If I read your code correctly, you hardwire the usage of the two
PRUs in the da850 board code, which makes it impossible to use
them in different ways even if the hardware supports it. If this is
indeed the case, using an MFD device
On Thursday 28 April 2011 09:17:21 Subhasish Ghosh wrote:
You can easily do that by adding a small header to the firmware
format and interpret that header by the MFD driver. When the name
of the subdevice is part of that header, the MFD driver does not
need to understand the difference,
On Thursday 28 April 2011 09:22:49 Subhasish Ghosh wrote:
On 04/27/2011 03:18 PM, Subhasish Ghosh wrote:
My problem is, I am doing something like this:
s32 pruss_writel_multi(struct device *dev, u32 offset,
u32 *pdatatowrite, u16 wordstowrite)
{
struct pruss_priv
On Wednesday 04 May 2011, Subhasish Ghosh wrote:
CAN requires mail box IDs to be programmed in. But, the socket
CAN subsystem supports only software filtering of the mail box IDs.
So, the mail box IDs programmed into socket CAN during initialization
does not propagate into the hardware. This
On Wednesday 04 May 2011, Subhasish Ghosh wrote:
How about just doing something like:
# echo da8xx_pruss_uart firmware.bin
i.e just append the device name (from the board file) into the firmware
file.
That sounds fine to me. I would put a header in the beginning, but feel free
to use
On Wednesday 04 May 2011, Wolfgang Grandegger wrote:
On 05/04/2011 03:11 PM, Arnd Bergmann wrote:
Wolfgang, I'm a bit worried by the API being split between sockets and
sysfs.
The problem is that once the sysfs API is established, users will start
relying on it, and you can no longer
On Thursday 05 May 2011, Subhasish Ghosh wrote:
I am a bit lost,
If I understand correctly, there are two problems
1. In case of udev based driver loading, we will end up
loading both the drivers and the associated firmware.
This is not acceptable because both UART CAN
use PRU0 PRU1.
On Tuesday 10 May 2011, Subhasish Ghosh wrote:
Instead of passing a configuration file into the MFD driver and
calling it a firmware, I can see three other options that I believe
would be nicer:
1. have a single firmware blob that describes the child devices
and the code that is to be
On Wednesday 11 May 2011, Subhasish Ghosh wrote:
Please look into implementing one of the three I suggested before
you go off in another direction. In case of the third one, the idea
was to configure the name of the device for each pru using sysfs,
which then gets bound to the driver,
On Tuesday 10 May 2011, Subhasish Ghosh wrote:
Yes, In case if we allow the ALL implementation, it hogs the CPU.
In that case we do not need the PRU. The whole purpose of the PRU
is to offload the processor for any such implementations.
So the kernel presumably needs to switch
On Wednesday 11 May 2011, Arnd Bergmann wrote:
If that interpretation is right, I would seriously recommend rethinking
the design of the CAN firmware for pruss, so you can start doing something
useful with the offload engine that fits into the Socket CAN API, or that
would be a useful
On Thursday 12 May 2011, Wolfgang Grandegger wrote:
Well, that seems sophisticated resulting in a complex implementation
(may code line) also because hardware filters are very hardware
dependent. Usually just one global filter can be defined. I think that's
overkill. A simple interface using:
On Saturday 14 May 2011, Mark Brown wrote:
Will a misc device be a better choice.
In that case I can remove the MFD cell from the board_file and add an array
of platform_device for the UART CAN.
I think that for me so long as it can simultaneously do two unrelated
functions which need
On Sunday 15 May 2011, Mark Brown wrote:
My whole point has been that you register them from the main pruss driver
based on run-time data instead of compile-time pre-configured stuff in the
board file.
I'm not so sure - if the usage is fixed as a result of the pins on the
device being
On Friday 20 May 2011 16:14:01 Manjunath Hadli wrote:
remove the code from individual platform header files for
dm365, dm355, dm644x and dm646x and consolidate it into a
single and common header file dmx.h.
Include the new header file in individual platform header
files as a pre-cursor for
On Friday 20 May 2011 20:14:10 Nori, Sekhar wrote:
Well, it started with the need to get rid of using IO_ADDRESS()
on system module which is a bunch of SoC specific registers
found on dm365, dm355, dm644x and dm646x SoCs (all at the same
base address, but having different SoC specific register
On Thursday 12 May 2011 16:41:58 Oliver Hartkopp wrote:
E.g. assume you need the CAN-IDs 0x100, 0x200 and 0x300 in your application
and for that reason you configure these IDs in the pruss CAN driver.
What if someone generates a 100% CAN busload exactly on CAN-ID 0x100 then?
Worst case
Hi Samuel,
On Sunday 22 May 2011, Samuel Ortiz wrote:
On Wed, May 11, 2011 at 10:03:54PM +0200, Arnd Bergmann wrote:
On Wednesday 11 May 2011, Subhasish Ghosh wrote:
We had a little discussion at the Linaro Developer Summit about your
driver and mfd drivers in general. There was a general
On Monday 16 May 2011, Subhasish Ghosh wrote:
I earlier had an implementation where I used a pruss_devices structure
in the board file.
http://linux.omap.com/pipermail/davinci-linux-open-source/
2011-March/022339.html.
We can use this implementation along with the sysfs to load the
On Tuesday 24 May 2011, Subhasish Ghosh wrote:
Would it be a good approach to first get a basic sensible
driver into the tree and then work towards improving and
adjusting for future compatibilities.
The main problem with that is that you cannot really change
user-visible interfaces after the
On Monday 30 May 2011, Subhasish Ghosh wrote:
Ah, forgot the TODO on the list of rules, I'll have to add that next
time.
How do I handle the headers. I have two header files in the
include/linux/mfd.
Should I submit them as a separate patch into mfd.
These headers are also used by
On Monday 30 May 2011, Subhasish Ghosh wrote:
During the time when the drivers are in staging, all files need to
be in the same directory, including the header and the drivers using it.
They can get moved at the time when the driver gets turned into
a regular non-staging driver.
OK,
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 Friday 24 June 2011, Nori, Sekhar wrote:
This series of 4 patches added SATA support on DaVinci
DA850 platform. This was ready for last merge window,
but was not queued because of the negative diffstat
rule.
Is there a possibility of queuing this for the v3.1 merge?
Here is the
On Monday 27 June 2011, Nori, Sekhar wrote:
On Sat, Jun 25, 2011 at 23:18:19, Arnd Bergmann wrote:
On Friday 24 June 2011, Nori, Sekhar wrote:
Please make sure the patches apply on top of 2.6.39 and resubmit
them, separating out the first cleanup patch from the others.
Is it 2.6.39
On Wednesday 29 June 2011, Ohad Ben-Cohen wrote:
On Wed, Jun 29, 2011 at 2:44 AM, Randy Dunlap rdun...@xenotime.net wrote:
+hardware accelerators, and therefore are often used to offload
cpu-intensive
prefer: CPU-
throughout.
On Friday 08 July 2011, Nori, Sekhar wrote:
are available in the git repository at:
git://gitorious.org/linux-davinci/linux-davinci.git cleanup
Pulled, thanks!
Arnd
___
Davinci-linux-open-source mailing list
On Friday 08 July 2011, Nori, Sekhar wrote:
Please pull the following DaVinci features for v3.1.
This pull request depends on the patch davinci: dm6467/T EVM: fix setting
up of reference clock rate in clean-up pull request for successful build.
Pulling this after the earlier clean-up pull
On Tuesday 19 July 2011, Nori, Sekhar wrote:
Can you please pull these DaVinci fixes for v3.0?
Thanks,
Sekhar
The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc:
Linus Torvalds (1):
Linux 3.0-rc7
are available in the git repository at:
On Wednesday 07 September 2011, Nori, Sekhar wrote:
Can you please pull the following fixes for v3.1-rc6?
These are not regression fixes in the strict sense since
none of the bugs were actually introduced in v3.1 and have
been around for a while. But I hope we don't have to wait
till v3.2
On Saturday 17 September 2011, Nori, Sekhar wrote:
Please pull the following two fixes for the v3.2
merge window. They are not applicable to stable
tree and hence the stable tag has not been added.
Thanks,
Sekhar
The following changes since commit
On Saturday 17 September 2011, Nori, Sekhar wrote:
Please pull the following feature for v3.2 merge
window. It adds TI WLAN support on AM18x board.
Thanks,
Sekhar
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linus Torvalds (1):
Linux 3.1-rc6
On Monday 05 December 2011, Nori, Sekhar wrote:
Please pull the following DaVinci fixes for
the next v3.2-rc release. None of these are
v3.2 regressions, but I have marked only two
of these with stable tag since rest are not
very critical.
Ok, thanks for the info!
The following changes
On Thursday 08 December 2011, Nori, Sekhar wrote:
DaVinci AEMIF is an async memory interface peripheral implemented
in arch/arm/mach-davinci/aemif.c. It helps interface to NAND, NOR
and other asynchronous memories. Currently it just provides an API
for timing value configuration. The API is
On Wednesday 14 December 2011, Nori, Sekhar wrote:
I have this lone patch queued for DaVinci clean-up so far.
Can you please pull this?
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linus Torvalds (1):
Linux 3.2-rc3
are available in the git
On Friday 24 February 2012, Nori, Sekhar wrote:
Can you please pull the following DaVinci fix for v3.4?
It has no conflicts with rmk/for-armsoc branch of the
arm-soc tree or with latest linux-next.
Pulled into fixes/non-critical, thanks!
ARnd
added the patch below on top
of your series.
Arnd
commit 6ea96e111e6a7f06ef62227bf64e8cd65bd705b3
Author: Arnd Bergmann a...@arndb.de
Date: Mon Feb 27 14:55:22 2012 +
ARM: davinci: add back dummy header files
The mach/dm365.h and mach/dm646xh headers are currently being
On Tuesday 28 February 2012, Nori, Sekhar wrote:
I guess the cleanest way to do that would have been to let
these patches go through my tree with appropriate maintainer
acks (but that obviously didn't happen - will try and fix
that for future). Per my understanding, it is encouraged that
a
On Wednesday 14 March 2012, Nori, Sekhar wrote:
Hi Arnd, Olof,
Can you please pull the following DaVinci fixes for v3.3.
They fix a build and section mismatch warning.
Thanks,
Sekhar
The following changes since commit fde7d9049e55ab85a390be7f415d74c9f62dd0f9:
Linus Torvalds (1):
conflict, see the resolution below.
Arnd
commit e594a97c8c74533ec105b2ac9194217e918f172f
Merge: f66f9bd d5be5f5
Author: Arnd Bergmann a...@arndb.de
Date: Thu Mar 15 20:33:47 2012 +
Merge branch 'v3.4/features' of
git://gitorious.org/linux-davinci/linux-davinci into next/drivers
On Thursday 05 July 2012, Vaibhav Hiremath wrote:
On 7/4/2012 7:57 PM, Mark Brown wrote:
On Wed, Jul 04, 2012 at 02:17:48PM +, Hebbar, Gururaja wrote:
On Wed, Jul 04, 2012 at 19:31:18, Mark Brown wrote:
If these are totally different boards they should have different machine
IDs
On Thursday 05 July 2012, Daniel Mack wrote:
None of the dma engines are ported yet, because the generic binding for dma
engines is still under debate. So far, all DMA channels are described using
auxdata on platforms that use DT, with the exception of exynos, but that one
will have to
On Monday 09 July 2012, Sekhar Nori wrote:
The following changes since commit 485802a6c524e62b5924849dd727ddbb1497cc71:
Linux 3.5-rc3 (2012-06-16 17:25:17 -0700)
are available in the git repository at:
git://gitorious.org/linux-davinci/linux-davinci.git tags/davinci-v3.6-fixes
On Friday 13 July 2012, Sekhar Nori wrote:
Hi Arnd, Olof,
Can you please pull the following patch adding DT support for DaVinci
for v3.6?
Sorry for the late request, I was waiting for an ack from either Grant
or Rob but looks like both are busy. Grant has reviewed earlier versions
of
On Monday 16 July 2012, Sekhar Nori wrote:
Patches 4-6 of his series are driver patches. While I am
reviewing/testing and acking those patches, I will still be depending on
the driver maintainers to merge those through their trees. So after I am
done reviewing and testing, I am asking Heiko to
On Wednesday 12 September 2012, Hebbar, Gururaja wrote:
On Tue, Sep 11, 2012 at 18:29:36, Arnd Bergmann wrote:
drivers/usb/musb/da8xx.c |2 +-
.../asp.h = include/linux/platform_data/asoc-davinci-evm.h |0
This will clash with patch ASoC
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 Thursday 04 October 2012, Matt Porter wrote:
Passes the DA850 shared SRAM gen_pool to the McASP driver
and enables the ping-pong buffer DMA support.
Signed-off-by: Matt Porter mpor...@ti.com
---
It seems this is in linux-next now, but the patch it depends on
(ARM: davinci: add platform
On Friday 11 January 2013, Matt Porter wrote:
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime
On Friday 11 January 2013, Matt Porter wrote:
We have tightly coupled the link-time dependency for
omap_dma_filter_fn by going down the path of using
dma_request_slave_channel_compat() as Tony suggested to avoid extra
ifdefry.
That dependency will go away naturally if all the legacy OMAP
On Tuesday 15 January 2013, Matt Porter wrote:
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
On Monday 28 January 2013, Andy Shevchenko wrote:
On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter mpor...@ti.com wrote:
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
...@atomide.com
Acked-by: Arnd Bergmann a...@arndb.de
@@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct
dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y
On Wednesday 30 January 2013, Matt Porter wrote:
+ dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+ of_dma_controller_register(dev-of_node,
+ of_dma_simple_xlate,
+
On Thursday 31 January 2013, Matt Porter wrote:
On Wed, Jan 30, 2013 at 09:32:58AM +, Arnd Bergmann wrote:
On Wednesday 30 January 2013, Matt Porter wrote:
+ dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+ of_dma_controller_register(dev-of_node
On Saturday 02 February 2013 04:07:59 Sergei Shtylyov wrote:
On 02-02-2013 1:30, Russell King - ARM Linux wrote:
because it doesn't make sense to support multiple DMA APIs. We can check
from MUSB's registers if it was configured with Inventra DMA support and
based on that we can register
On Monday 04 February 2013, Linus Walleij wrote:
So I think the above concerns are moot. The callback we can
set on cookies is entirely optional, and it's even implemented by
each DMA engine, and some may not even support it but require
polling, and then it won't even be implemented by the
On Tuesday 05 February 2013, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [130204 07:46]:
Current DMA abstraction is quite poor, for example there's no way to
compile support for multiple DMA engines. Code also makes certain, IMO
unnecessary, assumptions about the underlying DMA
On Tuesday 05 March 2013, Manjunathappa, Prakash wrote:
On Mon, Mar 04, 2013 at 21:59:16, Arnd Bergmann wrote:
On Monday 04 March 2013 18:29:12 Manjunathappa, Prakash wrote:
+- reg: Offset and length of SPI controller register space
+- num-cs: Number of chip selects
+- ti,davinci-spi
On Tuesday 12 March 2013, Sekhar Nori wrote:
Hi Arnd, Olof,
Can you please pull the following fix for v3.9-rc?
Pulled into the fixes branch, but I only saw it after I sent the pull request
to Linus,
so it will have to wait for another -rc.
Arnd
On Wednesday 20 March 2013, Manjunathappa, Prakash wrote:
Adds device tree support for davinci_mmc. Also add binding documentation.
As of now in non-dma PIO mode and without GPIO card_detect/write_protect
option because of dependencies on EDMA and GPIO module DT support.
Shouldn't the binding
On Wednesday 27 March 2013, Manjunathappa, Prakash wrote:
On Wed, Mar 20, 2013 at 18:56:09, Arnd Bergmann wrote:
On Wednesday 20 March 2013, Manjunathappa, Prakash wrote:
Adds device tree support for davinci_mmc. Also add binding documentation.
As of now in non-dma PIO mode and without
in pdata.
Applies on top of below patch series under community review:
Enable SPI flash support on da850-evm DT kernel
http://www.spinics.net/lists/arm-kernel/msg231546.html
This series is reviewed and tested by Sekhar Nori, with and
without DT on da850 EVM.
Very nice!
Acked-by: Arnd
As of commit 5f9296ba i2c: Add bus recovery infrastructure, there
is now a global function with the same name, which clashes with
the davinci specific one. The obvious solution is to rename the
function with a davinci prefix.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Viresh Kumar viresh.ku
On Friday 05 April 2013, Sekhar Nori wrote:
Here are the DT updates for v3.10. This depends on the
SoC updates from previous pull request.
I've pulled both into the next/soc branch now, which is slightly wrong, but
your two branches belong conceptually together, and the order is fixed
now for
On Friday 05 April 2013, Sekhar Nori wrote:
The following changes since commit a937536b868b8369b98967929045f1df54234323:
Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
On Thursday 02 May 2013 08:55:18 Sascha Hauer wrote:
+#if defined(CONFIG_OF)
+static struct mt9p031_platform_data *
+ mt9p031_get_pdata(struct i2c_client *client)
+
+{
+ if (client-dev.of_node) {
By inverting the logic here and returning immediately you can safe an
On Friday 03 May 2013, Prabhakar Lad wrote:
+static struct mt9p031_platform_data *
+mt9p031_get_pdata(struct i2c_client *client)
+{
+ struct device_node *np;
+ struct mt9p031_platform_data *pdata;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
+
On Monday 17 June 2013, Fernandes, Joel A wrote:
[Joel] Thanks for the suggestion, I updated it and it looks like this now:
Required properties:
On Friday 21 June 2013, Joel A Fernandes wrote:
I haven't come across this problem but- are you saying there is a
shortcoming in Kbuild/Kconfig that selects an option even if its
dependency is not met?
Well, the shortcoming is that it lets you specify impossible
contraints. You get a warning
The tnetv107x platform is getting removed, so this driver
is not needed any more.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/Kconfig | 11 --
drivers/mfd/Makefile | 1 -
drivers/mfd/ti-ssp.c | 465
On Thursday 06 March 2014, Sekhar Nori wrote:
This pull request removes da8xx_omapl_defconfig
enabling all ARMv5 davinci devices to be built
using davinci_all_defconfig
Pulled into next/soc, thanks!
Arnd
___
Davinci-linux-open-source
The tnetv107x platform is getting removed, so this driver
will not be needed any more.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Sekhar Nori nsek...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Cc: Mark Brown broo...@kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/spi/Kconfig
The tnetv107x platform is getting removed, so this driver
is not needed any more.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Sekhar Nori nsek...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
---
drivers/mfd
I have applied the platform removal patch with the Ack
from Kevin and Sekhar. Please apply these other patches
through the input/mfd/spi trees.
Arnd Bergmann (3):
spi: remove obsolete spi-ti-ssp driver
mfd: remove obsolete ti-ssp driver
input: remove obsolete tnetv107x drivers
drivers
The tnetv107x platform is getting removed, so the touchscreen
and keypad drivers for this platform will no longer be needed
either.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Sekhar Nori nsek...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Cc: Dmitry Torokhov dmitry.torok
in the cases where it cannot work.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: davinci-linux-open-source@linux.davincidsp.com
---
arch/arm/mach-davinci/board-dm644x-evm.c | 11 ++-
1 file changed, 6 insertions(+), 5
1 - 100 of 113 matches
Mail list logo
