On Thursday 22 August 2013 05:07 PM, Daniel Mack wrote:
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support
Hi,
On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
maps crossbar number- to interrupt number and
calls request_irq(int_no, crossbar_handler,..)
So will this mapping happen based on some data passed from DT or
just based on
On Friday 23 August 2013 11:00 AM, Sekhar Nori wrote:
@@ -728,6 +736,44 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
u32 mac_control = 0;
u32 slave_port;
+ if (priv-gmii_sel_reg of_machine_is_compatible(ti,am33xx)) {
This
On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
Hi,
On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
maps crossbar number- to interrupt number and
calls request_irq(int_no, crossbar_handler,..)
So will this mapping
On 08/23/2013 01:48 PM, Tony Lindgren wrote:
* Chen Gang F T chen.gang.flying.transfor...@gmail.com [130822 02:08]:
Hmm... I guess: for our case, what your meaning is fixes-none-urgent,
not fixes-none-critical, is it correct ? :-)
Right, that naming might be actually better :)
Tony
On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
Hi,
On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
maps crossbar number- to interrupt number and
calls request_irq(int_no, crossbar_handler,..)
So will this mapping
On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
Hi,
On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
maps crossbar number- to interrupt number and
calls
On 08/23/2013 01:51 PM, Tony Lindgren wrote:
* Chen Gang gang.c...@asianux.com [130822 20:20]:
The related error:
/tmp/ccOMIprI.s: Assembler messages:
/tmp/ccOMIprI.s:507: Error: selected processor does not support ARM mode
`isb '
/tmp/ccOMIprI.s:513: Error: selected processor does
On 08/23/2013 03:02 PM, Chen Gang wrote:
On 08/23/2013 01:51 PM, Tony Lindgren wrote:
* Chen Gang gang.c...@asianux.com [130822 20:20]:
The related error:
/tmp/ccOMIprI.s: Assembler messages:
/tmp/ccOMIprI.s:507: Error: selected processor does not support ARM mode
`isb '
On 08/23/2013 04:02 PM, Chen Gang wrote:
When vexpress kernel is compiled for v6, it still can support armv7
instructions (hardware still support), so need let compiler know about
it for related inline assembly code, or compiling will fail.
Hmm... need change compiled for v6, it still can to
On 23.08.2013 08:14, Mugunthan V N wrote:
On Friday 23 August 2013 11:00 AM, Sekhar Nori wrote:
@@ -728,6 +736,44 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
u32 mac_control = 0;
u32 slave_port;
+ if (priv-gmii_sel_reg
On Friday 23 August 2013 12:23 PM, Sricharan R wrote:
On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
Hi,
On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
maps
When vexpress kernel is compiled for v6, it still can support armv7
instructions (hardware still support), so need let compiler know about
it for related inline assembly code, or compiling will fail.
The related failure command:
arm-linux-gnueabi-gcc -Wp,-MD,arch/arm/mach-vexpress/.dcscb.o.d
v1 - v2:
* combine devm_request_mem_region() and devm_ioremap() and use
devm_ioremap_resource() (reported by Sergei Shtylyov)
* fix multi-line comment style (reported by Sergei Shtylyov)
* fix ti,rmii-clock-ext property name (reported by Sekhar)
* rebased
This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.
Also update the compatible string to make use of the am335x specific
features of the cpsw driver.
Signed-off-by: Daniel Mack
In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.
Signed-off-by: Daniel Mack zon...@gmail.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 3 ++-
drivers/net/ethernet/ti/cpsw.c | 32
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c | 145
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this
At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.
I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.
Signed-off-by: Daniel Mack
On Thu, Aug 22, 2013 at 06:00:14PM +0200, Wolfram Sang wrote:
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
that it is much cleaner to have this in the core. This also removes a
circular dependency between the helpers and the core, and so we can
finally register child
Hi Benoit,
Did you get a chance to think about this, I have provided some replies
below.
On Friday 16 August 2013 10:03 PM, Benoit Cousson wrote:
Hi Sekhar,
On 16/08/2013 17:41, Sekhar Nori wrote:
On 8/16/2013 7:45 PM, Benoit Cousson wrote:
Hi Gururaja,
On 16/08/2013 13:36, Hebbar,
On Friday 23 August 2013 02:13 PM, Daniel Mack wrote:
This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.
Also update the compatible string to make use of the am335x
On 23.08.2013 11:28, Sekhar Nori wrote:
On Friday 23 August 2013 02:13 PM, Daniel Mack wrote:
This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.
Also update the compatible
On Friday 23 August 2013 03:04 PM, Daniel Mack wrote:
On 23.08.2013 11:28, Sekhar Nori wrote:
On Friday 23 August 2013 02:13 PM, Daniel Mack wrote:
This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
Hi,
On Friday 23 August 2013 02:20 AM, Stephen Warren wrote:
On 08/22/2013 02:31 AM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VBUS-ID detector, so added a
compatible type *ti,palmas-usb-vid*. Didn't remove the existing compatible
types for backward compatibility.
On 23.08.2013 11:40, Sekhar Nori wrote:
On Friday 23 August 2013 03:04 PM, Daniel Mack wrote:
On 23.08.2013 11:28, Sekhar Nori wrote:
Ok, thanks. Given that this last patch will be merged through another
tree, can I just resend it separately, while David takes the rest as it is?
Ideally
v2 - v3:
* swap ti,am3352-cpsw and ti,cpsw to work around a matching
bug (reported by Sekhar)
v1 - v2:
* combine devm_request_mem_region() and devm_ioremap() and use
devm_ioremap_resource() (reported by Sergei Shtylyov)
* fix multi-line comment style
This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.
Also update the compatible string to make use of the am335x specific
features of the cpsw driver.
Signed-off-by: Daniel Mack
In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.
Signed-off-by: Daniel Mack zon...@gmail.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 3 ++-
drivers/net/ethernet/ti/cpsw.c | 32
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this
At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.
I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.
Signed-off-by: Daniel Mack
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c | 145
On 11/08/13 14:25, Mark Jackson wrote:
NanoBone Specification:
---
CPU:
TI AM335x
Memory:
256MB DDR3
128MB NOR flash
128KB FRAM
Ethernet:
2 x 10/100 connected to SMSC LAN8710 PHY
USB:
1 x USB2.0 Type A
I2C:
2Kbit EEPROM (Microchip 24AA02)
On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote:
On Friday 23 August 2013 12:23 PM, Sricharan R wrote:
On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
Hi,
On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
On Thursday 22
On Sun, Aug 11, 2013 at 6:17 PM, Sebastian Reichel s...@debian.org wrote:
From: Sebastian Reichel s...@ring0.de
This patch adds an OMAP SSI driver to the HSI framework.
The Synchronous Serial Interface (SSI) is a legacy version
of HSI. As in the case of HSI, it is mainly used to connect
On Mon, Aug 12, 2013 at 10:30 AM, Tony Lindgren t...@atomide.com wrote:
* Sebastian Reichel s...@debian.org [130811 09:25]:
From: Sebastian Reichel s...@ring0.de
This patch configures and activates the OMAP SSI driver on the RX-51.
Hmm, I'd rather see this be DT only driver at this point.
Hello.
On 23-08-2013 12:43, Daniel Mack wrote:
At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.
I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered
On 23.08.2013 16:03, Sergei Shtylyov wrote:
On 23-08-2013 12:43, Daniel Mack wrote:
+dev_err(priv-dev, unable to map control i/o region\n);
devm_ioremap_resource() prints out the error messages itself, so you
don't
have to.
Right. Thanks. Will send a v4.
Best,
Daniel
In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.
Signed-off-by: Daniel Mack zon...@gmail.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 3 ++-
drivers/net/ethernet/ti/cpsw.c | 32
v3 - v4:
* use IS_ERR() to check for failed devm_ioremap_resource()
calls (reported by Sergei Shtylyov)
v2 - v3:
* swap ti,am3352-cpsw and ti,cpsw to work around a matching
bug (reported by Sekhar)
v1 - v2:
* combine devm_request_mem_region() and
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this
At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.
I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.
Signed-off-by: Daniel Mack
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c | 147
This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.
Also update the compatible string to make use of the am335x specific
features of the cpsw driver.
Signed-off-by: Daniel Mack
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.
Signed-off-by: Daniel Mack zon...@gmail.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 3 ++-
On 08/20/2013 05:48 PM, Paul Walmsley wrote:
Hi folks,
catching up on this thread.
On 08/06/2013 12:49 PM, Dave Gerlach wrote:
+
+static int am33xx_pm_suspend(void)
+{
+ int i, j, ret = 0;
+
+ int status = 0;
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+
On 23-08-2013 18:16, Daniel Mack wrote:
At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.
I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional
Hi Sekhar,
On 23/08/2013 10:50, Sekhar Nori wrote:
Hi Benoit,
Did you get a chance to think about this, I have provided some
replies below.
On Friday 16 August 2013 10:03 PM, Benoit Cousson wrote:
Hi Sekhar,
On 16/08/2013 17:41, Sekhar Nori wrote:
On 8/16/2013 7:45 PM, Benoit Cousson
Hi Santosh,
[...]
+static const struct of_device_id cpsw_of_mtable[] = {
+ {
+ .compatible = ti,am3352-cpsw,
I didn't notice this earlier, but can't you use the IP version
as a compatible instead of using a SOC name. Whats really SOC specific
on this IP ? Sorry i have
On 08/22/2013 07:17 PM, Richard Zhao wrote:
On Fri, Aug 23, 2013 at 04:36:53AM +0800, Stephen Warren wrote:
On 08/22/2013 12:43 AM, Richard Zhao wrote:
DMA client device driver usually needs to know at probe time whether
dma controller has been registered to deffer probe. So add a help
On 08/22/2013 07:29 PM, Richard Zhao wrote:
On Fri, Aug 23, 2013 at 04:18:27AM +0800, Stephen Warren wrote:
On 08/21/2013 11:19 PM, Richard Zhao wrote:
On Fri, Aug 02, 2013 at 10:00:00AM +0800, Richard Zhao wrote:
pass of_phandle_args dma_spec to dma_request_channel in
of_dma_simple_xlate,
On Friday 23 August 2013 11:22 AM, Benoit Cousson wrote:
Hi Santosh,
[...]
+static const struct of_device_id cpsw_of_mtable[] = {
+{
+.compatible= ti,am3352-cpsw,
I didn't notice this earlier, but can't you use the IP version
as a compatible instead of using a SOC name.
On 8/23/2013 8:40 PM, Benoit Cousson wrote:
There is no assumption about the lost of functionality by using the
generic version of the driver. How the user is supposed to know the
amount of functionality he will lose, and if this is acceptable to
him.
I suppose the generic driver would
On 23.08.2013 16:59, Sergei Shtylyov wrote:
On 23-08-2013 18:16, Daniel Mack wrote:
+priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+if (IS_ERR(priv-gmii_sel_reg)) {
+dev_err(priv-dev, unable to map control i/o region\n);
You didn't actually seem to heed
On 8/23/2013 7:08 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote:
On Friday 23 August 2013 12:23 PM, Sricharan R wrote:
On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
Hi,
On Friday 23 August 2013
On 23.08.2013 16:23, Santosh Shilimkar wrote:
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
+static const struct of_device_id cpsw_of_mtable[] = {
+{
+.compatible = ti,am3352-cpsw,
I didn't notice this earlier, but can't you use the IP version
as a compatible
On 8/23/2013 7:53 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.
Signed-off-by: Daniel Mack zon...@gmail.com
---
On Friday 23 August 2013 02:13 PM, Daniel Mack wrote:
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support
+ OMAP mailing list
Tony,
Can you pick up this minor cleanup patch?
regards
Suman
On 08/21/2013 09:10 PM, Jingoo Han wrote:
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
On Friday 23 August 2013 07:53 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.
Signed-off-by: Daniel Mack zon...@gmail.com
---
On Friday 23 August 2013 07:46 PM, Daniel Mack wrote:
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support
On 08/22/2013 04:24 PM, Mark A. Greer wrote:
On Thu, Aug 22, 2013 at 10:34:06AM +0200, Benoit Cousson wrote:
Hi Lokesh,
On 22/08/2013 05:50, Lokesh Vutla wrote:
Hi Benoit,
On Wednesday 21 August 2013 07:11 PM, Benoit Cousson wrote:
Hi Mark,
In fact I cannot even apply these patches since
On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
On 23.08.2013 16:23, Santosh Shilimkar wrote:
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
+static const struct of_device_id cpsw_of_mtable[] = {
+ {
+ .compatible = ti,am3352-cpsw,
I didn't notice this
Tony, Benoit,
This is an updated series for adding the device tree support to
the OMAP mailbox driver. The series is based on 3.11-rc4 and now
includes the support for AM335 WkupM3 mailbox.
The support for WkupM3 mailbox is essential for achieving the PM
Suspend on AM335 devices, and this
On Friday 23 August 2013 12:45 PM, Mugunthan V N wrote:
On Friday 23 August 2013 07:53 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible
On 8/13/2013 7:01 PM, Santosh Shilimkar wrote:
On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote:
On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote:
On Friday 02 August 2013 11:48 AM, Will Deacon wrote:
I think this an A9-specific register, which reads as 0 on UP A9 and
On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
On 23.08.2013 16:23, Santosh Shilimkar wrote:
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
+static const struct of_device_id cpsw_of_mtable[] = {
+ {
+ .compatible
On 23.08.2013 19:09, Sekhar Nori wrote:
On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
If this could be handled using IP version then the right way would be to
just read the IP version from hardware and use it. No need of DT
On Friday 23 August 2013 01:08 PM, Sekhar Nori wrote:
On 8/13/2013 7:01 PM, Santosh Shilimkar wrote:
On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote:
On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote:
On Friday 02 August 2013 11:48 AM, Will Deacon wrote:
I think this an
On Friday 23 August 2013 10:26 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
On 23.08.2013 16:23, Santosh Shilimkar wrote:
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
+static const struct of_device_id cpsw_of_mtable[] = {
+ {
+
On 23.08.2013 19:19, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
If this could be handled using IP version then the right way would be to
just
On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
On 23.08.2013 16:23, Santosh Shilimkar wrote:
On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
+static const struct
On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
On 23.08.2013 19:19, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
If this could be handled
On 08/23/2013 08:21 PM, Daniel Mack wrote:
+ priv-gmii_sel_reg = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(priv-gmii_sel_reg)) {
+ dev_err(priv-dev, unable to map control i/o region\n);
You didn't actually seem to heed my words about error message.
On 8/23/2013 10:58 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
On 23.08.2013 19:19, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
So just stick the IP version or call it
On 8/23/2013 10:47 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:08 PM, Sekhar Nori wrote:
On 8/13/2013 7:01 PM, Santosh Shilimkar wrote:
On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote:
On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote:
On Friday 02 August
On Friday 23 August 2013 01:39 PM, Sekhar Nori wrote:
On 8/23/2013 10:58 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
On 23.08.2013 19:19, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
On 8/23/2013 10:26 PM, Santosh
Hi,
On Fri, Aug 23, 2013 at 03:57:05PM +0200, Linus Walleij wrote:
The HSI subsystem is lacking an active maintainer, interested?
Given that you can apparently test the OMAP HSI driver you're
one of the few applicable candidates.
I don't think I'm a good candidate for that. At least not yet.
On Fri, Aug 23, 2013 at 03:58:30PM +0200, Linus Walleij wrote:
On Mon, Aug 12, 2013 at 10:30 AM, Tony Lindgren t...@atomide.com wrote:
* Sebastian Reichel s...@debian.org [130811 09:25]:
From: Sebastian Reichel s...@ring0.de
This patch configures and activates the OMAP SSI driver on the
Hi Paul,
On Wed, Aug 21, 2013 at 01:22:09AM +, Paul Walmsley wrote:
From: Sebastian Reichel s...@ring0.de
This patch adds Synchronous Serial Interface (SSI) hwmod support for
OMAP34xx SoCs.
a few comments:
- please add your Signed-off-by: to the patch description, per
On Friday 23 August 2013 11:40 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:39 PM, Sekhar Nori wrote:
On 8/23/2013 10:58 PM, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
On 23.08.2013 19:19, Santosh Shilimkar wrote:
On Friday 23 August 2013 01:09
Benoit Cousson bcous...@baylibre.com writes:
Hi Kevin Olof,
I've just updated the branch with the few USB3 patches I missed from Felipe.
So here is a new pull-request.
Thanks,
Benoit
Add the minimal DTS support for
On 23.08.2013 20:10, Sergei Shtylyov wrote:
On 08/23/2013 06:16 PM, Daniel Mack wrote:
priv-coal_intvl = 0;
priv-bus_freq_mhz = clk_get_rate(priv-clk) / 100;
-priv-cpsw_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-if (!priv-cpsw_res) {
+ss_res =
On 08/23/2013 06:16 PM, Daniel Mack wrote:
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack zon...@gmail.com
---
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c | 153
Hi
On Fri, 23 Aug 2013, Sebastian Reichel wrote:
On Wed, Aug 21, 2013 at 01:22:09AM +, Paul Walmsley wrote:
From: Sebastian Reichel s...@ring0.de
This patch adds Synchronous Serial Interface (SSI) hwmod support for
OMAP34xx SoCs.
a few comments:
- please add your
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed in the past. In suspend
mode though, this
This third memory region just denotes one single register in the CONTROL
module block. The driver uses that in order to set the correct physical
ethernet interface modes.
Also update the compatible string to make use of the am335x specific
features of the cpsw driver.
Signed-off-by: Daniel Mack
Hi,
this is the 5th version of my patch set, the version history is below.
Note that for personal reasons, I won't be able to work on that patch
set for two weeks, starting from a few hours from now. If there are any
more objections or comments, I'll catch up after that period. Or if
anyone
In order to support features that are specific to the AM335x IP, we have
to add hardware types and another compatible string.
Signed-off-by: Daniel Mack zon...@gmail.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 3 ++-
drivers/net/ethernet/ti/cpsw.c | 32
At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.
I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is considered optional for now.
Signed-off-by: Daniel Mack
On Fri, Aug 23, 2013 at 6:28 PM, Sekhar Nori nsek...@ti.com wrote:
On 8/23/2013 7:08 PM, Santosh Shilimkar wrote:
The whole point we are moving to domain is not have any default
mapping(connection done) at DT level. Rather DT only specifies the
peripherals and their cross-bar connection
From: Matt Porter m...@ti.com
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Joel: Drop DT entries that are non-hardware-description for now as discussed in
[1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony
The following changes since commit cf470a1b1a741bca00080ebc70968b4f22d9b1ea:
Merge tag 'dra7-core-support-minus-dt' of git://github.com/rrnayak/linux into
omap-for-v3.12/soc (2013-08-14 01:01:41 -0700)
are available in the git repository
Hello.
On 08/23/2013 10:53 PM, Daniel Mack wrote:
At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.
I'm not sure whether all SoCs which feature the cpsw block have such a
register, so that third memory region is
On 23.08.2013 21:10, Sergei Shtylyov wrote:
Hello.
On 08/23/2013 10:53 PM, Daniel Mack wrote:
At least the AM33xx SoC has a control module register to configure
details such as the hardware ethernet interface mode.
I'm not sure whether all SoCs which feature the cpsw block have such a
On Saturday 24 August 2013 12:23 AM, Daniel Mack wrote:
Note that for personal reasons, I won't be able to work on that patch
set for two weeks, starting from a few hours from now. If there are any
more objections or comments, I'll catch up after that period. Or if
anyone wants to make minor
On 08/23/2013 05:28 AM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 23 August 2013 02:20 AM, Stephen Warren wrote:
On 08/22/2013 02:31 AM, Kishon Vijay Abraham I wrote:
The Palmas device contains only a USB VBUS-ID detector, so added a
compatible type *ti,palmas-usb-vid*. Didn't remove the
On 08/23/2013 10:53 PM, Daniel Mack wrote:
The cpsw currently lacks code to properly set up the hardware interface
mode on AM33xx. Other platforms might be equally affected.
Usually, the bootloader will configure the control module register, so
probably that's why such support wasn't needed
This patch cleans up the allocation and error unwind paths, which
allows us to carry less information in struct cpsw_priv and reduce the
amount of jump labels in the probe functions.
Signed-off-by: Daniel Mack zon...@gmail.com
Acked-by: Mugunthan V N mugunthan...@ti.com
---
1 - 100 of 123 matches
Mail list logo
