On Sun, Feb 03, 2013 at 02:30:24AM +0100, Tomasz Figa wrote:
> Hi Guenter,
>
> Some comments inline.
>
> On Saturday 02 of February 2013 16:59:40 Guenter Roeck wrote:
> > Provide bindings and parse OF data during initialization.
> >
> > Signed-off-by: Guenter Roeck
> > ---
> > - Documentation u
Hi Guenter,
Some comments inline.
On Saturday 02 of February 2013 16:59:40 Guenter Roeck wrote:
> Provide bindings and parse OF data during initialization.
>
> Signed-off-by: Guenter Roeck
> ---
> - Documentation update per feedback
> - Dropped io-channel-output-names from the bindings document
Provide bindings and parse OF data during initialization.
Signed-off-by: Guenter Roeck
---
- Documentation update per feedback
- Dropped io-channel-output-names from the bindings document. The property is
not used in the code, and it is not entirely clear what it would be used for.
If there i
For iio_channel_get to work with OF based configurations, it needs the
consumer device pointer instead of the consumer device name as argument.
Signed-off-by: Guenter Roeck
---
drivers/extcon/extcon-adc-jack.c|3 +--
drivers/iio/inkern.c| 11 ++-
drivers/power/g
Implement external reference voltage as regulator named "vref".
Signed-off-by: Guenter Roeck
---
v2: Use regulator API to specify vref instead of creating new devicetree
bindings.
Keep reference voltage internally in uV, as this is the scale provided
by the regulator subsystem. We nee
Signed-off-by: Guenter Roeck
---
drivers/iio/adc/max1363.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/iio/adc/max1363.c b/drivers/iio/adc/max1363.c
index ef868c9..1353fda 100644
--- a/drivers/iio/adc/max1363.c
+++ b/drivers/iio/ad
This patch set adds basic device tree support to the IIO subsystem. It is the
result of the [1] and [2] discussions.
The first two patches are actually updates to the MAX1363 driver. The first
patch updates the driver to use devm_ functions, and the second patch adds
support for an external refere
* Matt Porter [130202 11:51]:
> On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote:
> > * Matt Porter [130202 10:10]:
> > > If it doesn't work, work with Vinod to fix the api. It's expected,
> > > I'm working on dmaengine API changes right now to deal with a
> > > limitation of EDMA th
Hello.
On 02-02-2013 23:55, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in
On Sat, Feb 02, 2013 at 07:06:06PM +, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 22:07, Matt Porter wrote:
>
> >>> Move mach-davinci/dma.c to common/edma.c so it can be used
> >>> by OMAP (specifically AM33xx) as well.
>
> >> I think this should rather go to drivers/dma/?
On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote:
> * Matt Porter [130202 10:10]:
> > If it doesn't work, work with Vinod to fix the api. It's expected,
> > I'm working on dmaengine API changes right now to deal with a
> > limitation of EDMA that needs to be abstracted.
>
> Regarding
Hello.
On 02-02-2013 22:07, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.
I think this should rather go to drivers/dma/?
No, this is the private EDMA API. It's the analogous thing to
the private OMAP dma API that is in
* Matt Porter [130202 10:10]:
> If it doesn't work, work with Vinod to fix the api. It's expected,
> I'm working on dmaengine API changes right now to deal with a
> limitation of EDMA that needs to be abstracted.
Regarding the DMA API limitations, I'm only aware of lack of capability
to configure
On Sat, Feb 02, 2013 at 12:01:37AM +, Sergei Shtylyov wrote:
> Hello.
>
> On 01-02-2013 22:59, Matt Porter wrote:
>
> > Move mach-davinci/dma.c to common/edma.c so it can be used
> > by OMAP (specifically AM33xx) as well.
>
> I think this should rather go to drivers/dma/?
>
> >
Hello.
On 02-02-2013 16:45, Russell King - ARM Linux wrote:
Now, CPPI is brand new code to arch/arm - always has been. It post-dates
the DMA engine API. And it's been said many times about moving it to
drivers/dma. The problem is Sergei doesn't want to do it - he's anti the
I *can't* do
Hello.
On 02-02-2013 20:45, Russell King - ARM Linux wrote:
There are two people on this thread CC list who were also involved or
CC'd on the mails from the thread in 2010... Tony and Felipe.
Unfortunately, the person who agreed to do the work is no longer in the
land of the living. Yes I kno
Hello.
On 02-02-2013 16:17, Russell King - ARM Linux wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1 support
(in
arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the
patch. :-(
sticking
On Sat, Feb 02, 2013 at 08:27:42PM +0400, Sergei Shtylyov wrote:
>> There are two people on this thread CC list who were also involved or
>> CC'd on the mails from the thread in 2010... Tony and Felipe.
>> Unfortunately, the person who agreed to do the work is no longer in the
>> land of the livin
Hello.
On 02-02-2013 14:18, Russell King - ARM Linux wrote:
On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
good point, do you wanna send some patches ?
I have already sent them countless times and even stuck CPPI 4.1 support
(in
arch/arm/common/cppi41.c) in Russell'
On Sat, Feb 02, 2013 at 03:37:46PM +0100, Lars-Peter Clausen wrote:
> On 02/01/2013 08:42 PM, Guenter Roeck wrote:
> > On Fri, Feb 01, 2013 at 03:59:17PM +0100, Lars-Peter Clausen wrote:
> >> On 02/01/2013 03:33 PM, Guenter Roeck wrote:
> >>> On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Cla
On Sat, Feb 02, 2013 at 10:33:12AM +, Jonathan Cameron wrote:
> On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> > Signed-off-by: Guenter Roeck
> Mostly fine. Comments below are on the fact I'd prefer
> a reference voltage coming from a regulator than being
> a bit of platform data.
> > ---
> >
On Sat, Feb 02, 2013 at 10:29:02AM +, Jonathan Cameron wrote:
> On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> > Provide bindings, new API access functions, and parse OF data
> > during initialization.
> >
> Firstly thanks for working on this Guenter, it's been a big hole
> for a while largely
On Wed, Jan 30, 2013 at 1:28 PM, Andreas Larsson wrote:
> This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP core
> library.
>
> Signed-off-by: Andreas Larsson
OK...
> +#if defined(__BIG_ENDIAN)
> +static inline u32 grgpio_read_reg(u32 __iomem *reg)
> +{
> + return ior
On Saturday 02 February 2013 08:00:54 Padma Venkat wrote:
> > The result of this looks good, but I fear that changing the filter function
> > like this wil break all drivers that currently use the
> > plat-samsung/dma-ops.c
> > code. For migration purposes, I think the best way is to change
> > s
On Sat, Feb 02, 2013 at 12:49:06PM +, Russell King wrote:
> On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
> > * Matt Porter [130201 10:25]:
> > > Move mach-davinci/dma.c to common/edma.c so it can be used
> > > by OMAP (specifically AM33xx) as well.
> >
> > I think this shoul
On 02/01/2013 08:42 PM, Guenter Roeck wrote:
> On Fri, Feb 01, 2013 at 03:59:17PM +0100, Lars-Peter Clausen wrote:
>> On 02/01/2013 03:33 PM, Guenter Roeck wrote:
>>> On Fri, Feb 01, 2013 at 12:58:02PM +0100, Lars-Peter Clausen wrote:
013 10:43 PM, Guenter Roeck wrote:
> Provide bindings,
On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
> * Matt Porter [130201 10:25]:
> > Move mach-davinci/dma.c to common/edma.c so it can be used
> > by OMAP (specifically AM33xx) as well.
>
> I think this should rather go to drivers/dma/?
Yes, it should, but just like OMAP, there's
On Fri, Feb 01, 2013 at 01:59:59PM -0500, Matt Porter wrote:
> On Fri, Feb 01, 2013 at 07:52:46PM +, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 02/01/2013 09:49 PM, Matt Porter wrote:
> >
> > >>> Move mach-davinci/dma.c to common/edma.c so it can be used
> > >>> by OMAP (specifically AM33xx
On Sat, Feb 02, 2013 at 10:18:51AM +, Russell King - ARM Linux wrote:
> On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 02-02-2013 4:44, Russell King - ARM Linux wrote:
> >
> > On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
> >>>
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Signed-off-by: Guenter Roeck
Mostly fine. Comments below are on the fact I'd prefer
a reference voltage coming from a regulator than being
a bit of platform data.
> ---
> Documentation/devicetree/bindings/iio/max1363.txt | 54
> ++
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Provide bindings, new API access functions, and parse OF data
> during initialization.
>
Firstly thanks for working on this Guenter, it's been a big hole
for a while largely because non of our largest developers were
actually using development platfor
On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 4:44, Russell King - ARM Linux wrote:
>
> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>> good point, do you wanna send some patches ?
>
>> I have already sent them coun
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Instead of requiring the map to unregister, simply unregister all map entries
> associated with the given iio device. This simplifies map removal and also
> works
> for maps generated through devicetree.
>
> Signed-off-by: Guenter Roeck
Sensible cha
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Pass device pointer instead of device name as parameter to iio_channel_get_all
> and iio_channel_get_all_cb. This will enable us to use OF information to
> retrieve consumer channel information.
>
> Signed-off-by: Guenter Roeck
Applied with unused 'l
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> For chips with more than 8 bit ADC resolution, received data was always
> masked against 0xfff, ie with a 12 bit mask. This can result in bad data
> for chips with 10 bit resolution if those chips have higher bits set
> (seen with MAX1139).
>
> The re
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Signed-off-by: Guenter Roeck
Applied to togreg branch of iio.git
> ---
> drivers/iio/adc/max1363.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/iio/adc/max1363.c b/drivers/iio/adc/max1363.c
> index ca8bbc1..2c773b4 100644
> -
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Signed-off-by: Guenter Roeck
Applied to togreg branch of iio.git
A previous merge seems to have gone wrong in this driver and some
removed functions have reappeared. I'll post a patch for that in a few mins.
> ---
> drivers/iio/adc/max1363.c |
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Add 'iio-hwmon' OF compatibility table entry to enable OF matches.
>
> Signed-off-by: Guenter Roeck
Applied to togreg branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
Thanks,
> ---
> drivers/staging/iio/iio_hwmon.c |6 +
On 01/31/2013 09:42 PM, Guenter Roeck wrote:
> Signed-off-by: Guenter Roeck
This crossed with a little fix patch that changes one of the kzallocs
below. The same trivial fix applies here so I've applied this with the obvious
change.
Thanks,
> ---
> drivers/staging/iio/iio_hwmon.c | 70
> +++
On 01/31/2013 09:42 PM, Guenter Roeck wrote:
> The 'name' attribute is mandatory for hwmon devices.
>
> Signed-off-by: Guenter Roeck
Wow, that one character patch these crossed with manages to effect
this one as well. Applied with the obvious tiny fix.
Thanks,
> ---
> drivers/staging/iio/iio_h
On 01/31/2013 09:43 PM, Guenter Roeck wrote:
> Signed-off-by: Guenter Roeck
applied to togreg branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
> ---
> drivers/iio/adc/lp8788_adc.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/adc/lp8788_adc.c b/dri
41 matches
Mail list logo
