The OMAP2_MCSPI_CHCONF_FORCE must be toggled even when using GPIO
chip selects. This patch conditionally calls the omap2_mcspi_set_cs
function to do so when using GPIO chip selects.
Signed-off-by: Michael Welling
---
drivers/spi/spi-omap2-mcspi.c |6 ++
1 file changed, 6 insertions
of the
OMAP2_MCSPI_CHCONF_FORCE bit in omap2_mcspi_set_cs.
Signed-off-by: Michael Welling
---
drivers/spi/spi-omap2-mcspi.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 304b427..502db29 100644
--- a/drivers/spi/spi-omap2
The core spi driver handles the delay between transactions.
This is a remanant from the transfer_one conversion.
Signed-off-by: Michael Welling
---
drivers/spi/spi-omap2-mcspi.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2
If a valid GPIO is specified but cannot be requested by the driver, print a
message and error out of omap2_mcspi_setup.
Signed-off-by: Michael Welling
---
drivers/spi/spi-omap2-mcspi.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c
The recent update of the OMAP2 McSPI driver left some unresolved issues.
These patches should take care them and again allow for GPIO chip selects
and native chip selects.
Michael Welling (4):
spi: omap2-mcspi: Remove unnecessary delay
spi: omap2-mcspi: Fix set_cs function for active high
The recent update of the OMAP2 McSPI driver left some unresolved issues.
These patches should take care them and again allow for GPIO chip selects
and native chip selects.
Michael Welling (4):
spi: omap2-mcspi: Remove unnecessary delay
spi: omap2-mcspi: Fix set_cs function for active high
of the
OMAP2_MCSPI_CHCONF_FORCE bit in omap2_mcspi_set_cs.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 304b427..502db29 100644
--- a/drivers/spi
The core spi driver handles the delay between transactions.
This is a remanant from the transfer_one conversion.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi
The OMAP2_MCSPI_CHCONF_FORCE must be toggled even when using GPIO
chip selects. This patch conditionally calls the omap2_mcspi_set_cs
function to do so when using GPIO chip selects.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |6 ++
1 file changed
If a valid GPIO is specified but cannot be requested by the driver, print a
message and error out of omap2_mcspi_setup.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/spi
On Fri, May 22, 2015 at 01:25:44PM +0100, Mark Brown wrote:
> On Thu, May 21, 2015 at 06:48:33PM -0500, Michael Welling wrote:
>
> > So after reverting this patch I found there is a issue in that it is
> > difficult
> > to determine when a transfer is complete to prope
On Fri, May 22, 2015 at 01:25:44PM +0100, Mark Brown wrote:
On Thu, May 21, 2015 at 06:48:33PM -0500, Michael Welling wrote:
So after reverting this patch I found there is a issue in that it is
difficult
to determine when a transfer is complete to properly drive the chipselect
from
On Thu, May 21, 2015 at 10:16:38PM +0100, Mark Brown wrote:
> On Thu, May 21, 2015 at 04:04:11PM -0500, Michael Welling wrote:
>
> > Do you want to revert the patch and apply a new one or should I provide a
> > patch that reverts the changes and fixes it all in one?
>
>
On Thu, May 21, 2015 at 11:18:57AM +0100, Mark Brown wrote:
> On Wed, May 20, 2015 at 09:07:09PM -0500, Michael Welling wrote:
>
> > My guess is that the set_cs needs to be called even when toggling as GPIO.
>
> > How should I handle this?
>
> It shouldn't be p
On Thu, May 21, 2015 at 11:18:57AM +0100, Mark Brown wrote:
On Wed, May 20, 2015 at 09:07:09PM -0500, Michael Welling wrote:
My guess is that the set_cs needs to be called even when toggling as GPIO.
How should I handle this?
It shouldn't be part of a set_cs() operation but rather part
On Thu, May 21, 2015 at 10:16:38PM +0100, Mark Brown wrote:
On Thu, May 21, 2015 at 04:04:11PM -0500, Michael Welling wrote:
Do you want to revert the patch and apply a new one or should I provide a
patch that reverts the changes and fixes it all in one?
Can you please send me separate
On Tue, May 12, 2015 at 08:17:58PM +0100, Mark Brown wrote:
> On Tue, May 12, 2015 at 12:38:57PM -0500, Michael Welling wrote:
> > GPIO chip select patch series appears to have broken the native chip select
> > support. This patch pulls the manual native chip sele
On Tue, May 12, 2015 at 08:17:58PM +0100, Mark Brown wrote:
On Tue, May 12, 2015 at 12:38:57PM -0500, Michael Welling wrote:
GPIO chip select patch series appears to have broken the native chip select
support. This patch pulls the manual native chip select toggling out of
the transfer_one
GPIO chip select patch series appears to have broken the native chip select
support. This patch pulls the manual native chip select toggling out of
the transfer_one routine and adds a set_cs routine.
Tested natively on AM3354 with SPI serial flash on spi0cs0.
Signed-off-by: Michael Welling
GPIO chip select patch series appears to have broken the native chip select
support. This patch pulls the manual native chip select toggling out of
the transfer_one routine and adds a set_cs routine.
Tested natively on AM3354 with SPI serial flash on spi0cs0.
Signed-off-by: Michael Welling mwell
If GPIO chip select is specified, request the GPIO in the setup function
and release it in the cleanup function.
Signed-off-by: Michael Welling
---
v2: Adds gpio_free to cleanup function.
Broken out of patch series because the other patch in the series was applied.
commit
On Fri, May 08, 2015 at 06:09:16PM +0100, Mark Brown wrote:
> On Thu, May 07, 2015 at 06:36:54PM -0500, Michael Welling wrote:
>
> > + if (gpio_is_valid(spi->cs_gpio)) {
> > + if (gpio_request(spi->cs_gpio, dev_name(>dev)) == 0)
> > +
On Fri, May 08, 2015 at 06:09:16PM +0100, Mark Brown wrote:
On Thu, May 07, 2015 at 06:36:54PM -0500, Michael Welling wrote:
+ if (gpio_is_valid(spi-cs_gpio)) {
+ if (gpio_request(spi-cs_gpio, dev_name(spi-dev)) == 0)
+ gpio_direction_output(spi-cs_gpio
If GPIO chip select is specified, request the GPIO in the setup function
and release it in the cleanup function.
Signed-off-by: Michael Welling mwell...@ieee.org
---
v2: Adds gpio_free to cleanup function.
Broken out of patch series because the other patch in the series was applied.
commit
On Fri, May 01, 2015 at 10:17:35AM +0200, Sebastian Hesselbarth wrote:
> On 01.05.2015 00:36, Michael Welling wrote:
> >On Fri, May 01, 2015 at 12:21:20AM +0200, Sebastian Hesselbarth wrote:
> >>On 30.04.2015 23:20, Michael Welling wrote:
> >>>On Thu, Apr 30, 2015
On Thu, May 07, 2015 at 11:13:15AM +0100, Jonathan Cameron wrote:
> On 06/05/15 17:49, Michael Welling wrote:
> > Without the cacheline alignment, the readings will occasionally incorrectly
> > return 0.
> >
> > Signed-off-by: Michael Welling
> Applied to the
If GPIO chipselects are specified initialise the GPIO in the setup function.
Signed-off-by: Michael Welling
---
drivers/spi/spi-omap2-mcspi.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 3ac06ad..370c333 100644
Switches from transfer_one_message to transfer_one to prepare driver for
use of GPIO chip selects.
Signed-off-by: Michael Welling
---
drivers/spi/spi-omap2-mcspi.c | 244 +++--
1 file changed, 110 insertions(+), 134 deletions(-)
diff --git a/drivers/spi/spi
selects if specified.
v2: Considers the possible use of SPI_CS_HIGH during chip select activation.
Michael Welling (2):
spi: omap2-mcspi: Switch driver to use transfer_one
spi: omap2-mcspi: Add gpio_request and init CS
drivers/spi/spi-omap2-mcspi.c | 251
On Thu, May 07, 2015 at 08:27:58PM +0100, Mark Brown wrote:
> On Thu, May 07, 2015 at 02:20:19PM -0500, Michael Welling wrote:
> > On Thu, May 07, 2015 at 07:58:31PM +0100, Mark Brown wrote:
>
> > > makes things easier to review and helps people trying to understand the
&
On Thu, May 07, 2015 at 07:58:31PM +0100, Mark Brown wrote:
> On Wed, May 06, 2015 at 06:37:52PM -0500, Michael Welling wrote:
> > This patch allows for GPIOs specified in the devicetree to be used as SPI
> > chipselects on TI OMAP2 SoCs.
> >
> > Tested on the
On Thu, May 07, 2015 at 07:58:31PM +0100, Mark Brown wrote:
On Wed, May 06, 2015 at 06:37:52PM -0500, Michael Welling wrote:
This patch allows for GPIOs specified in the devicetree to be used as SPI
chipselects on TI OMAP2 SoCs.
Tested on the AM3354.
Signed-off-by: Michael Welling
On Thu, May 07, 2015 at 08:27:58PM +0100, Mark Brown wrote:
On Thu, May 07, 2015 at 02:20:19PM -0500, Michael Welling wrote:
On Thu, May 07, 2015 at 07:58:31PM +0100, Mark Brown wrote:
makes things easier to review and helps people trying to understand the
Do you have any other
selects if specified.
v2: Considers the possible use of SPI_CS_HIGH during chip select activation.
Michael Welling (2):
spi: omap2-mcspi: Switch driver to use transfer_one
spi: omap2-mcspi: Add gpio_request and init CS
drivers/spi/spi-omap2-mcspi.c | 251
Switches from transfer_one_message to transfer_one to prepare driver for
use of GPIO chip selects.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c | 244 +++--
1 file changed, 110 insertions(+), 134 deletions(-)
diff --git
If GPIO chipselects are specified initialise the GPIO in the setup function.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index
On Thu, May 07, 2015 at 11:13:15AM +0100, Jonathan Cameron wrote:
On 06/05/15 17:49, Michael Welling wrote:
Without the cacheline alignment, the readings will occasionally incorrectly
return 0.
Signed-off-by: Michael Welling mwell...@ieee.org
Applied to the fixes-togreg branch
On Fri, May 01, 2015 at 10:17:35AM +0200, Sebastian Hesselbarth wrote:
On 01.05.2015 00:36, Michael Welling wrote:
On Fri, May 01, 2015 at 12:21:20AM +0200, Sebastian Hesselbarth wrote:
On 30.04.2015 23:20, Michael Welling wrote:
On Thu, Apr 30, 2015 at 10:44:07PM +0200, Sebastian Hesselbarth
This patch allows for GPIOs specified in the devicetree to be used as SPI
chipselects on TI OMAP2 SoCs.
Tested on the AM3354.
Signed-off-by: Michael Welling
---
v3: Switches driver to use transfer_one instead of transfer_one_message
allowing the spi core to handle toggling GPIO chip selects
Without the cacheline alignment, the readings will occasionally incorrectly
return 0.
Signed-off-by: Michael Welling
---
v2: Moved buffers to the end of the mcp320x struct per suggestion to keep
them on their own cacheline.
drivers/iio/adc/mcp320x.c |6 +++---
1 file changed, 3 insertions
This patch allows for GPIOs specified in the devicetree to be used as SPI
chipselects on TI OMAP2 SoCs.
Tested on the AM3354.
Signed-off-by: Michael Welling mwell...@ieee.org
---
v3: Switches driver to use transfer_one instead of transfer_one_message
allowing the spi core to handle toggling GPIO
Without the cacheline alignment, the readings will occasionally incorrectly
return 0.
Signed-off-by: Michael Welling mwell...@ieee.org
---
v2: Moved buffers to the end of the mcp320x struct per suggestion to keep
them on their own cacheline.
drivers/iio/adc/mcp320x.c |6 +++---
1 file
Without the cacheline alignment, the readings will occasionally incorrectly
return 0.
Signed-off-by: Michael Welling
---
drivers/iio/adc/mcp320x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/mcp320x.c b/drivers/iio/adc/mcp320x.c
index efbfd12..46b98cf
Without the cacheline alignment, the readings will occasionally incorrectly
return 0.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/iio/adc/mcp320x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/mcp320x.c b/drivers/iio/adc/mcp320x.c
index
On Fri, May 01, 2015 at 12:21:20AM +0200, Sebastian Hesselbarth wrote:
> On 30.04.2015 23:20, Michael Welling wrote:
> >On Thu, Apr 30, 2015 at 10:44:07PM +0200, Sebastian Hesselbarth wrote:
> [...]
> >>What I noticed about your clk2 that you always measure as 0 Hz is
> &g
On Thu, Apr 30, 2015 at 10:44:07PM +0200, Sebastian Hesselbarth wrote:
> On 30.04.2015 21:33, Michael Welling wrote:
> >On Thu, Apr 30, 2015 at 07:45:50PM +0200, Sebastian Hesselbarth wrote:
> >>For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported
> >
On Thu, Apr 30, 2015 at 07:45:50PM +0200, Sebastian Hesselbarth wrote:
> For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported
> issues with recent v4.x kernels due to broken/missing/wrong parent clock
> claming. This patch set now deals with the issues reported.
>
c: Stephen Boyd
> Cc: Jean-Francois Moine
> Cc: Michael Welling
> Cc: Russell King
> Cc: devicet...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/clk/clk-si5351.c | 29 +++
On Thu, Apr 30, 2015 at 07:45:50PM +0200, Sebastian Hesselbarth wrote:
> For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported
> issues with recent v4.x kernels due to broken/missing/wrong parent clock
> claming. This patch set now deals with the issues reported.
>
On Thu, Apr 30, 2015 at 03:20:38PM -0300, Fabio Estevam wrote:
> On Thu, Apr 30, 2015 at 2:45 PM, Sebastian Hesselbarth
> wrote:
>
> > * property silabs,pll-source : , [<..>]
> > * allow to selectively set pll source
> > @@ -1328,8 +1321,17 @@ static int si5351_i2c_probe(struct
On Thu, Apr 30, 2015 at 03:20:38PM -0300, Fabio Estevam wrote:
On Thu, Apr 30, 2015 at 2:45 PM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
* property silabs,pll-source : num src, [..]
* allow to selectively set pll source
@@ -1328,8 +1321,17 @@ static
On Thu, Apr 30, 2015 at 10:44:07PM +0200, Sebastian Hesselbarth wrote:
On 30.04.2015 21:33, Michael Welling wrote:
On Thu, Apr 30, 2015 at 07:45:50PM +0200, Sebastian Hesselbarth wrote:
For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported
issues with recent v4.x kernels
On Thu, Apr 30, 2015 at 07:45:50PM +0200, Sebastian Hesselbarth wrote:
For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported
issues with recent v4.x kernels due to broken/missing/wrong parent clock
claming. This patch set now deals with the issues reported.
Patch 1 amends
On Thu, Apr 30, 2015 at 07:45:50PM +0200, Sebastian Hesselbarth wrote:
For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported
issues with recent v4.x kernels due to broken/missing/wrong parent clock
claming. This patch set now deals with the issues reported.
Patch 1 amends
mturque...@linaro.org
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Jean-Francois Moine moin...@free.fr
Cc: Michael Welling mwell...@ieee.org
Cc: Russell King rmk+li...@arm.linux.org.uk
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux
On Fri, May 01, 2015 at 12:21:20AM +0200, Sebastian Hesselbarth wrote:
On 30.04.2015 23:20, Michael Welling wrote:
On Thu, Apr 30, 2015 at 10:44:07PM +0200, Sebastian Hesselbarth wrote:
[...]
What I noticed about your clk2 that you always measure as 0 Hz is
that none of your clocks
On Tue, Apr 28, 2015 at 03:34:25PM +0100, Mark Brown wrote:
> On Mon, Apr 27, 2015 at 08:21:50PM -0500, Michael Welling wrote:
>
> > Before I send another patch how does this look?
>
> > if (gpio_is_valid(spi->cs_gpio)) {
> > if (cs_active)
> >
On Tue, Apr 28, 2015 at 11:04:09AM -0300, Ezequiel Garcia wrote:
> On 04/27/2015 10:21 PM, Michael Welling wrote:
> > On Mon, Apr 27, 2015 at 08:55:50PM +0100, Mark Brown wrote:
> >> On Sun, Apr 26, 2015 at 10:44:30PM -0500, Michael Welling wrote:
> >>
> >&g
On Tue, Apr 28, 2015 at 07:32:21AM +0200, Martin Sperl wrote:
>
> > On 28.04.2015, at 03:21, Michael Welling wrote:
> > If I were to attempt to convert the driver to use the core chipselect
> > support,
> > how would I go about doing it?
> >
> >
On Tue, Apr 28, 2015 at 07:32:21AM +0200, Martin Sperl wrote:
On 28.04.2015, at 03:21, Michael Welling mwell...@ieee.org wrote:
If I were to attempt to convert the driver to use the core chipselect
support,
how would I go about doing it?
Is there another driver that I can use
On Tue, Apr 28, 2015 at 11:04:09AM -0300, Ezequiel Garcia wrote:
On 04/27/2015 10:21 PM, Michael Welling wrote:
On Mon, Apr 27, 2015 at 08:55:50PM +0100, Mark Brown wrote:
On Sun, Apr 26, 2015 at 10:44:30PM -0500, Michael Welling wrote:
+ if (gpio_is_valid(spi-cs_gpio
On Tue, Apr 28, 2015 at 03:34:25PM +0100, Mark Brown wrote:
On Mon, Apr 27, 2015 at 08:21:50PM -0500, Michael Welling wrote:
Before I send another patch how does this look?
if (gpio_is_valid(spi-cs_gpio)) {
if (cs_active)
gpio_set_value(spi-cs_gpio
On Mon, Apr 27, 2015 at 08:55:50PM +0100, Mark Brown wrote:
> On Sun, Apr 26, 2015 at 10:44:30PM -0500, Michael Welling wrote:
>
> > + if (gpio_is_valid(spi->cs_gpio)) {
> > + gpio_set_value(spi->cs_gpio, (cs_active) ?
> > +
On Mon, Apr 27, 2015 at 08:55:50PM +0100, Mark Brown wrote:
On Sun, Apr 26, 2015 at 10:44:30PM -0500, Michael Welling wrote:
+ if (gpio_is_valid(spi-cs_gpio)) {
+ gpio_set_value(spi-cs_gpio, (cs_active) ?
+ !!(spi-mode SPI_CS_HIGH
This patch allows for GPIOs specified in the devicetree to be used as SPI
chipselects on TI OMAP2 SoCs.
Tested on the AM3354.
Signed-off-by: Michael Welling
---
v2: Considers the possible use of SPI_CS_HIGH during chip select activation.
drivers/spi/spi-omap2-mcspi.c | 13 +
1
This patch allows for GPIOs specified in the devicetree to be used as SPI
chipselects on TI OMAP2 SoCs.
Tested on the AM3354.
Signed-off-by: Michael Welling mwell...@ieee.org
---
v2: Considers the possible use of SPI_CS_HIGH during chip select activation.
drivers/spi/spi-omap2-mcspi.c | 13
On Fri, Apr 17, 2015 at 11:18:33AM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 17, 2015 at 11:12:03AM +0200, Sebastian Hesselbarth wrote:
> > On 17.04.2015 04:00, Michael Welling wrote:
> > >On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote:
> &g
On Fri, Apr 17, 2015 at 11:12:03AM +0200, Sebastian Hesselbarth wrote:
> On 17.04.2015 04:00, Michael Welling wrote:
> >On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote:
> >>On 17.04.2015 00:09, Michael Welling wrote:
> >>>On Thu, Apr 16, 2015
On Fri, Apr 17, 2015 at 11:12:03AM +0200, Sebastian Hesselbarth wrote:
On 17.04.2015 04:00, Michael Welling wrote:
On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote:
On 17.04.2015 00:09, Michael Welling wrote:
On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth
On Fri, Apr 17, 2015 at 11:18:33AM +0100, Russell King - ARM Linux wrote:
On Fri, Apr 17, 2015 at 11:12:03AM +0200, Sebastian Hesselbarth wrote:
On 17.04.2015 04:00, Michael Welling wrote:
On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote:
On 17.04.2015 00:09, Michael
On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote:
> On 17.04.2015 00:09, Michael Welling wrote:
> >On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote:
> >>On 16.04.2015 18:17, Michael Welling wrote:
> >>>On Thu, Apr 16, 2015 at
On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote:
> On 16.04.2015 18:17, Michael Welling wrote:
> >On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
> >>On 04/15/2015 11:51 PM, Michael Welling wrote:
> >>>On Wed, Apr 15, 2015 at 01
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
> On 04/15/2015 11:51 PM, Michael Welling wrote:
> >On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
> >>On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling wrote:
> >>>On Wed, Apr 15, 2015 at
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
On 04/15/2015 11:51 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero
On Fri, Apr 17, 2015 at 01:23:50AM +0200, Sebastian Hesselbarth wrote:
On 17.04.2015 00:09, Michael Welling wrote:
On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote:
On 16.04.2015 18:17, Michael Welling wrote:
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote
On Thu, Apr 16, 2015 at 10:37:19PM +0200, Sebastian Hesselbarth wrote:
On 16.04.2015 18:17, Michael Welling wrote:
On Thu, Apr 16, 2015 at 07:32:32AM +0300, Tero Kristo wrote:
On 04/15/2015 11:51 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
> On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling wrote:
> > On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
> >> On 04/15/2015 05:09 PM, Michael Welling wrote:
> >> >On Wed, Apr 15,
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
> On 04/15/2015 05:09 PM, Michael Welling wrote:
> >On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
> >>On 04/15/2015 12:17 AM, Michael Welling wrote:
> >>>Greetings,
> >>>
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
> On 04/15/2015 12:17 AM, Michael Welling wrote:
> >Greetings,
> >
> >I have developed an AM3354 based SoM and it uses an external SI5351 clock
> >generator to drive the clock inputs for an external duart an
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock
On Wed, Apr 15, 2015 at 01:45:53PM -0700, Mike Turquette wrote:
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator
is initialized to -ENOENT in spi_alloc_device:
http://lxr.free-electrons.com/source/drivers/spi/spi.c#L353
If there are GPIOs specified in the devicetree the value is updated:
http://lxr.free-electrons.com/source/drivers/spi/spi.c#L440
On Wed, Apr 08, 2015 at 04:36:01PM -0500, Michael Welling wrote
is initialized to -ENOENT in spi_alloc_device:
http://lxr.free-electrons.com/source/drivers/spi/spi.c#L353
If there are GPIOs specified in the devicetree the value is updated:
http://lxr.free-electrons.com/source/drivers/spi/spi.c#L440
On Wed, Apr 08, 2015 at 04:36:01PM -0500, Michael Welling wrote
This patch allows for GPIOs specified in the devicetree to be used as SPI
chipselects
on TI OMAP2 SoCs.
Tested on the AM3354.
Signed-off-by: Michael Welling
---
drivers/spi/spi-omap2-mcspi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b
This patch allows for GPIOs specified in the devicetree to be used as SPI
chipselects
on TI OMAP2 SoCs.
Tested on the AM3354.
Signed-off-by: Michael Welling mwell...@ieee.org
---
drivers/spi/spi-omap2-mcspi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spi
On Wed, Feb 18, 2015 at 11:23:42AM -0600, Benoit Parrot wrote:
> Gentle ping.
>
> Is there any chance this will make it in 3.21?
>
> Benoit
>
Is there a reason that the pin has to be "hogged"?
Couldn't the pin be released after configuration for eventual use in the
userspace?
> Parrot,
On Wed, Feb 18, 2015 at 11:23:42AM -0600, Benoit Parrot wrote:
Gentle ping.
Is there any chance this will make it in 3.21?
Benoit
Is there a reason that the pin has to be hogged?
Couldn't the pin be released after configuration for eventual use in the
userspace?
Parrot, Benoit
On Sat, Jan 03, 2015 at 02:12:06PM +0100, Alexandre Courbot wrote:
> Hi Michael, sorry for the delayed reply on this interesting issue.
>
> On Wed, Dec 24, 2014 at 10:53 PM, Michael Welling
> wrote:
> > All,
> >
> > For years now EMAC has provided an out-o
On Sat, Jan 03, 2015 at 02:12:06PM +0100, Alexandre Courbot wrote:
Hi Michael, sorry for the delayed reply on this interesting issue.
On Wed, Dec 24, 2014 at 10:53 PM, Michael Welling mwell...@emacinc.com
wrote:
All,
For years now EMAC has provided an out-of-tree series of class
All,
For years now EMAC has provided an out-of-tree series of class drivers
for accessing various devices. The EMAC GPIO class and character
interfaces predate the introduction of the gpiolib interface and have
been ported across several kernel versions.
All,
For years now EMAC has provided an out-of-tree series of class drivers
for accessing various devices. The EMAC GPIO class and character
interfaces predate the introduction of the gpiolib interface and have
been ported across several kernel versions.
On Tue, Oct 07, 2014 at 04:09:45PM +0200, Linus Walleij wrote:
> On Fri, Sep 26, 2014 at 10:04 PM, Michael Welling
> wrote:
> > On Fri, Sep 26, 2014 at 10:16:51AM -0700, Florian Fainelli wrote:
> >>
> >> Yes and no, this might feel like the wrong place, but ult
On Tue, Oct 07, 2014 at 04:04:27PM +0200, Linus Walleij wrote:
> On Thu, Sep 25, 2014 at 9:17 PM, Michael Welling wrote:
>
> > How do I register a GPIO for use in the PHY suspend and resume code?
> > Can it be handled outside of the PHY driver?
>
> Nominally these day
On Tue, Oct 07, 2014 at 04:04:27PM +0200, Linus Walleij wrote:
On Thu, Sep 25, 2014 at 9:17 PM, Michael Welling mwell...@emacinc.com wrote:
How do I register a GPIO for use in the PHY suspend and resume code?
Can it be handled outside of the PHY driver?
Nominally these days you should
On Tue, Oct 07, 2014 at 04:09:45PM +0200, Linus Walleij wrote:
On Fri, Sep 26, 2014 at 10:04 PM, Michael Welling mwell...@emacinc.com
wrote:
On Fri, Sep 26, 2014 at 10:16:51AM -0700, Florian Fainelli wrote:
Yes and no, this might feel like the wrong place, but ultimately, the
Ethernet
On Thu, Oct 02, 2014 at 01:05:53PM -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, Sep 30, 2014 at 04:22:04PM -0500, Felipe Balbi wrote:
> > On Mon, Sep 29, 2014 at 06:41:59PM -0500, Michael Welling wrote:
> > > On Mon, Sep 29, 2014 at 05:46:38PM -0500, Felipe
On Fri, Oct 03, 2014 at 01:03:05PM -0700, David Miller wrote:
> From: Michael Welling
> Date: Wed, 1 Oct 2014 21:32:05 -0500
>
> > The code currently checks the mac_addr variable that is clearly
> > zero'd out during allocation.
> >
> > Further code is
201 - 300 of 356 matches
Mail list logo
