On Tue, Dec 01, 2015 at 08:03:13PM +0200, Dmitry Lifshitz wrote:
> SBC-AM57x is a single board computer designed for industrial and
> embedded applications. It is based on the Texas Instruments Sitara AM57x
> system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x
>
* Peter Ujfalusi [151202 02:01]:
> On 12/01/2015 07:00 PM, Tony Lindgren wrote:
> >> I see. The dm81xx basically am33xx/am43xx?
> >
> > Yeah similar to am33xx with different clocks and with a bunch of
> > accelerators.
> >
> >> Actually I would prefer to use the
On Tue, Dec 01, 2015 at 08:03:03PM +0200, Dmitry Lifshitz wrote:
> Add support for CompuLab CM-SOM-AM57X board.
>
> CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
> TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.
>
>
On Wed, Dec 2, 2015 at 3:59 PM, Peter Ujfalusi wrote:
> Hi,
>
> I keep this still as RFC.
>
> Changes since RFC v02:
> - Using has_acpi_companion() instead ACPI_HANDLE()
> - mask matching change within private_candidate()
> - Fallback in dma_request_chan() when DT/ACPI
On Wed, Dec 2, 2015 at 3:59 PM, Peter Ujfalusi wrote:
> The two API function can cover most, if not all current APIs used to
> request a channel. With minimal effort dmaengine drivers, platforms and
> dmaengine user drivers can be converted to use the two function.
>
>
* Tony Lindgren [151201 17:23]:
> * Matthijs van Duin [151201 17:15]:
> > On 2 December 2015 at 01:46, Tony Lindgren wrote:
> > > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> > > dts macros that ensure
* Matthijs van Duin [151201 17:23]:
> On 2 December 2015 at 01:46, Tony Lindgren wrote:
> > We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> > dts macros that ensure that?
>
> I'm in general no fan of such macros: it feels really
On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote:
> * Roger Quadros [151201 21:13]:
> > On 02/12/15 08:56, Brian Norris wrote:
> > >
> > > I'll take another pass over your patch set, but if things are looking
> > > better, how do you expect to merge this? There are
Hi Roger,
On Wed, Dec 02, 2015 at 10:42:12AM +0530, Roger Quadros wrote:
> On 02/12/15 08:56, Brian Norris wrote:
> > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote:
> >> On 30/11/15 21:54, Brian Norris wrote:
> >>> But anyway, I'm not sure that completely answered my question. My
* Brian Norris [151202 10:14]:
> On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote:
> > * Roger Quadros [151201 21:13]:
> > > On 02/12/15 08:56, Brian Norris wrote:
> > > >
> > > > I'll take another pass over your patch set, but if things
On Mon, Nov 30, 2015 at 10:45:11AM +0530, Vignesh R wrote:
> In addition to providing direct access to SPI bus, some spi controller
> hardwares (like ti-qspi) provide special port (like memory mapped port)
> that are optimized to improve SPI flash read performance.
I'm reasonably OK with this
Hi,
On 10/20/2015 11:18 AM, Tony Lindgren wrote:
Hi all,
* Dave Gerlach [150922 17:20]:
Hi,
This series is version 3 of the code to introduce a wkup_m3_ipc driver
to handle communication between the MPU and Cortex M3 present on TI AM335x
and AM437x SoCs. v2 of this series
On Wednesday 02 December 2015 10:22:09 Vinod Koul wrote:
> >
> > > > This legacy mode needs changes in platform code, in dmaengine drivers
> > > > and
> > > > finally the dmaengine user drivers can be converted:
> > >
> > > Are you marking the current APIs as dericated in the end of this series
mtd_to_nand() now uses the container_of() approach to transform an
mtd_info pointer into a nand_chip one. Drop useless mtd->priv
assignments from NAND controller drivers.
Signed-off-by: Boris Brezillon
---
Patch generated with the following coccinelle script:
Hi Brian,
On Tue, 1 Dec 2015 14:17:47 -0800
Brian Norris wrote:
> On Tue, Dec 01, 2015 at 12:03:14PM +0100, Boris Brezillon wrote:
> > mtd_to_nand() now uses the container_of() approach to transform an
> > mtd_info pointer into a nand_chip one. Drop useless
Hi Roger,
On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
> Move NAND specific device tree parsing to NAND driver.
>
> The NAND controller node must have a compatible id, register space
> resource and interrupt resource.
>
> Signed-off-by: Roger Quadros
This
Brian,
On 03/12/15 10:39, Brian Norris wrote:
> Hi,
>
> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> We do a couple of things in this series which result in
>> cleaner device tree implementation, faster perfomance and
>> multi-platform support. As an added bonus we
On Thu, Dec 03, 2015 at 11:27:13AM +0530, Roger Quadros wrote:
> On 03/12/15 09:59, Brian Norris wrote:
> > On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
> >> arch/arm/mach-omap2/gpmc-nand.c | 5 +-
> >> drivers/memory/omap-gpmc.c | 143
> >>
Hi,
On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> Hi,
>
> We do a couple of things in this series which result in
> cleaner device tree implementation, faster perfomance and
> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> for use in the system.
>
>
Brian,
On 03/12/15 09:59, Brian Norris wrote:
> Hi Roger,
>
> On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
>> Move NAND specific device tree parsing to NAND driver.
>>
>> The NAND controller node must have a compatible id, register space
>> resource and interrupt resource.
>>
(to be clear, this branch of discussion isn't directly regarding the TI
changes; we can handle any generic handling afterward, as long as we get
the DT binding right now)
On Tue, Oct 27, 2015 at 09:28:32AM +0100, Boris Brezillon wrote:
> On Mon, 26 Oct 2015 13:49:00 -0700
> Brian Norris
On Fri, Sep 18, 2015 at 05:53:26PM +0300, Roger Quadros wrote:
> Deprecate nand register passing via platform data and use
> gpmc_omap_get_nand_ops() instead.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/gpmc-nand.c | 2 --
> drivers/mtd/nand/omap2.c
Hi,
On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote:
> On 03/12/15 10:39, Brian Norris wrote:
> > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
> >> We do a couple of things in this series which result in
> >> cleaner device tree implementation, faster perfomance
On 12/02/2015 06:37 AM, Vinod Koul wrote:
> On Tue, Dec 01, 2015 at 09:20:28PM +0100, Arnd Bergmann wrote:
>> On Tuesday 01 December 2015 22:52:12 Vinod Koul wrote:
>>> On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote:
Add support for providing device to filter_fn mapping so
Hi Tony,
On 11/30/2015 09:51 PM, Tony Lindgren wrote:
* Uri Mashiach [151124 06:03]:
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
...
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+};
+
FYI, the
On 12/01/2015 07:00 PM, Tony Lindgren wrote:
>> I see. The dm81xx basically am33xx/am43xx?
>
> Yeah similar to am33xx with different clocks and with a bunch of accelerators.
>
>> Actually I would prefer to use the dmaengine's event router framework and we
>> do have support for the am33xx/am43xx
On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
static struct dma_filter_map da830_edma_map[] = {
DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
DMA_FILTER_ENTRY("davinci-mcasp.0", "tx",
On 12/01/2015 10:17 PM, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote:
>> On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
>>> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
>>> it will use a filter lookup table and retrieves
On Wednesday 02 December 2015 12:51:43 Peter Ujfalusi wrote:
> On 12/01/2015 04:24 PM, Arnd Bergmann wrote:
> > On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote:
> static struct dma_filter_map da830_edma_map[] = {
> DMA_FILTER_ENTRY("davinci-mcasp.0", "rx",
If mask is NULL skip the mask matching against the DMA device capabilities.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/dmaengine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index
The drivers are now converted to not use the DMA resource.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/devices-da8xx.c | 49 ---
1 file changed, 49 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
The driver is converted to not use the DMA resource.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/dm365.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index e794bff7d589..664ee6bbef22
With the new dma_request_chan() the clinet driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the davinci_mmc driver can now support deferred
probing against DMA.
Signed-off-by: Peter Ujfalusi
---
The driver is converted to not use the DMA resource.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/dm355.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index ee7656fa0c52..bed8f49eb60c
Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/dm355.c | 20
1 file
Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/dm646x.c | 11 +++
1 file changed, 11
Add support for providing device to filter_fn mapping so client drivers
can switch to use the dma_request_chan() API.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/edma.c | 6 ++
include/linux/platform_data/edma.h | 7 +++
2 files changed, 13
Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/dm365.c | 22 ++
1 file
Hi,
I keep this still as RFC.
Changes since RFC v02:
- Using has_acpi_companion() instead ACPI_HANDLE()
- mask matching change within private_candidate()
- Fallback in dma_request_chan() when DT/ACPI lookup fails.
- Rename dma_get_channel() -> find_candidate()
- Arch code changes as suggested by
Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/devices-da8xx.c | 46
Provide the dma_filter_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/dm644x.c | 12
1 file changed, 12
The driver is converted to not use the DMA resource.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-davinci/devices.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index
With the new dma_request_chan() the clinet driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the davinci_mmc driver can now support deferred
probing against DMA.
Signed-off-by: Peter Ujfalusi
---
Channel matching with private_candidate() is used in two paths, the error
checking is slightly different in them and they are duplicating code also.
Move the code under find_candidate() to provide consistent execution and
going to allow us to reuse this mode of channel lookup later.
The two API function can cover most, if not all current APIs used to
request a channel. With minimal effort dmaengine drivers, platforms and
dmaengine user drivers can be converted to use the two function.
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
To request any
Hi all,
Here's a clock driver for the ADPLL on dm814x. It's still in read-only
mode for the PLL, but is already usable with the gates and dividers
and allows us to add devices like MMC and USB.
To test this please apply the patches from below on v4.4-rc3:
These use the standard clock bindings and now we can make some
of the fixed clocks into real clocks.
Cc: Tero Kristo
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/dm814x-clocks.dtsi | 256 ++-
1 file changed, 225
On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
ADPLLs have several dividers and muxes controlled by a shared
control register for each PLL.
Note that for the clocks to work as device drivers for booting on
dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
levels to
48 matches
Mail list logo