Re: [PATCH 07/12] davinci: add tnetv107x evm regulators

[Mark Brown]

On Thu, Oct 14, 2010 at 02:38:50PM -0400, Cyril Chemparathy wrote:

> + {
> + .num_consumer_supplies  = ARRAY_SIZE(usb_consumers),
> + .consumer_supplies  = usb_consumers,
> + .constraints= {
> + .name   = "USB",
> + .min_uV = 500,
> + .max_uV = 500,
> + .min_uA = 20,
> + .max_uA = 100,

Are you *sure* about the min_uA here - what would be the goal of
enforcing a minimum current draw?  For a voltage regulator current limit
usually only an upper limit would be specified.  The same applies to
several other machine drivers in the series.

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 06/12] regulator: add driver for tps6524x regulator

[Mark Brown]

On Thu, Oct 14, 2010 at 02:38:49PM -0400, Cyril Chemparathy wrote:
> TPS6524X provides three step-down converters and two general-purpose LDO
> voltage regulators.  This device is interfaced using SPI.
> 
> Signed-off-by: Cyril Chemparathy 

This looks mostly good but...

> +static int read(struct tps6524x *hw, int reg)
> +{

I suspect you may run into a namespace issue with this in the future.

> +static const int dcdc1_voltages[] = {
> +  80,  825000,  85,  875000,
> +  90,  925000,  95,  975000,
> + 100, 1025000, 105, 1075000,
> + 110, 1125000, 115, 1175000,
> + 120, 1225000, 125, 1275000,
> + 130, 1325000, 135, 1375000,
> + 140, 1425000, 145, 1475000,
> + 150, 1525000, 155, 1575000,

Looks like you could just do the maths for most of these tables, might
be a bit clearer/simpler?  Not a major issue either way, though.

> +static int list_voltage(struct regulator_dev *rdev, unsigned selector)
> +{
> + const struct supply_info *info;
> + struct tps6524x *hw;
> +
> + hw  = rdev_get_drvdata(rdev);
> + info= &supply_info[rdev_get_id(rdev)];
> +
> + if (info->flags & FIXED_VOLTAGE)
> + return selector ? -EINVAL : info->fixed_voltage;
> + else
> + return (selector < 0 || selector >= info->n_voltages) ?
> + -EINVAL : info->voltages[selector];

I'm not sure the ternery operator is helping legibility here - if
statements might be more legible.

> + ret = read_field(hw, &info->voltage);
> + if (ret < 0)
> + return ret;
> + if (ret >= info->n_voltages)
> + return -EINVAL;

Shouldn't this be warning somehow - if we can't understand the register
setting that'd be a driver bug, -EINVAL makes it sound like an invalid
parameter was supplied.  Similarly for the current limit.

> +static ssize_t show_reg(struct device *dev, struct device_attribute *attr,
> + char *buf);
> +static ssize_t store_reg(struct device *dev, struct device_attribute *attr,
> +  const char *buf, size_t size);
> +
> +static DEVICE_ATTR(ldo_set,  0664, show_reg, store_reg);
> +static DEVICE_ATTR(block_en, 0664, show_reg, store_reg);
> +static DEVICE_ATTR(dcdc_set, 0664, show_reg, store_reg);
> +static DEVICE_ATTR(dcdc_en,  0664, show_reg, store_reg);
> +static DEVICE_ATTR(usb,  0664, show_reg, store_reg);
> +static DEVICE_ATTR(alarm,0664, show_reg, store_reg);
> +static DEVICE_ATTR(int_enable,   0664, show_reg, store_reg);
> +static DEVICE_ATTR(int_status,   0664, show_reg, store_reg);
> +static DEVICE_ATTR(rev_id,   0664, show_reg, store_reg);
> +static DEVICE_ATTR(write_enable,   0664, show_reg, store_reg);
> +static DEVICE_ATTR(software_reset, 0664, show_reg, store_reg);

Large chunks of this looks like it's exporting functionality which is
part of the regulator API to userspace, replicating functionality which
the API provides.  Please either remove or replace with standard
functionality.

The USB setting should be integrated with the USB subsystem, assuming
it's changing a USB current limit.

> + init_data = dev->platform_data;
> + if (!init_data) {
> + dev_err(dev, "could not find regulator platform data\n");
> + return -EIO;
> + }

EIO doesn't look right here...

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 06/12] regulator: add driver for tps6524x regulator

[Mark Brown]

On Thu, Oct 14, 2010 at 02:38:49PM -0400, Cyril Chemparathy wrote:
> TPS6524X provides three step-down converters and two general-purpose LDO
> voltage regulators.  This device is interfaced using SPI.
> 
> Signed-off-by: Cyril Chemparathy 

My review comments from the previous posting do not appear to have been
addressed or responded to?

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v2 06/12] regulator: add driver for tps6524x regulator

[Mark Brown]

On Mon, Oct 18, 2010 at 03:25:16PM -0400, Cyril Chemparathy wrote:
> TPS6524X provides three step-down converters and two general-purpose LDO
> voltage regulators.  This device is interfaced using SPI.
> 
> Signed-off-by: Cyril Chemparathy 

Acked-by: Mark Brown 

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v5 04/12] spi: add ti-ssp spi master driver

[Mark Brown]

On Tue, Nov 16, 2010 at 12:47:04AM -0700, Grant Likely wrote:
> On Tue, Nov 16, 2010 at 12:22 AM, Grant Likely

> > Instead, it is now incumbent on the board support code to ensure that
> > any device that depends on another device (including i2c or spi
> > regulators) will defer registration until the prerequisite devices are
> > bound to drivers.

You did also say you were going to write helpers to make this easier - I
do fear that we're going to end up with far too much boiler plate code
in machine drivers if we have to open code this.  I guess device tree is
going to need the helpers anyway :)

> > I don't *think* this change will affect anything in this particular
> > patch series, but if it does then let me know and I'll help you work out
> > how to fix it using a bus notifier.

> Oh, wait, spoke too soon.  You do add a regulator in this series, so
> this change will require a fixup.  The solution is to register an
> bus_notifier to the spi bus type before you start registering devices.

> It also requires deferring the musb_hdrc.1 and tps6116x registrations
> until the bus_notifier callback gets called with an indication that
> the regulator is bound.  It will look something like this:

Did you come up with a way of handling situations like cpufreq where we
have no device to wait for?

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v5 04/12] spi: add ti-ssp spi master driver

[Mark Brown]

On Tue, Nov 16, 2010 at 01:45:54PM -0700, Grant Likely wrote:
> On Tue, Nov 16, 2010 at 11:34:09AM +0000, Mark Brown wrote:

> > You did also say you were going to write helpers to make this easier - I
> > do fear that we're going to end up with far too much boiler plate code
> > in machine drivers if we have to open code this.  I guess device tree is
> > going to need the helpers anyway :)

> Yup, and I will, but as can be seen the boilerplate required is
> actually pretty minimal, and I'd like to have a couple of platforms to
> work with before actually settling on what the helpers need to look
> like.

Yeah, but I do have a bit of nervousness about the scalability of open
coding and the possibility that we'll come up with a better approach so
I'd be a bit more comfortable if we didn't have code in random board
files as they're always the hardest thing to update.

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v5 04/12] spi: add ti-ssp spi master driver

[Mark Brown]

On Tue, Nov 16, 2010 at 07:17:18PM -0500, Cyril Chemparathy wrote:

> The ability to wait on multiple devices may come handy.  In this

This is essential for any helpers, otherwise we can't cope easily with
mixes of GPIO and power or with regulators from multiple chips (like an
extra DCDC, for example).

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v5 04/12] spi: add ti-ssp spi master driver

[Mark Brown]

On Wed, Nov 17, 2010 at 09:11:30AM -0700, Grant Likely wrote:

> To start, I'm not a fan of matching by name.  It's fragile because it
> makes assumptions about how devices will be names when they actually
> appear (ie. Sometimes .id is dynamically assigned).  Ideally I'd
> prefer to have direct references (ie. pointers) to the devices that
> need to be registered, which *shouldn't* be difficult to handle.  That

Pointers are a complete pain for buses where things are dynamically
instantiated, the things you have to point at in machine data aren't the
things that end up appearing during device registration when the struct
device gets dynamically allocated so you need some way of translating
them.  This is why everyone ends up using dev_name for this sort of
thing ATM, it's easy to put into the code and match against the actual
struct device at runtime without needing to know about bus types.

> guarantees that the correct device is always referenced.  (aside: the
> device-tree use case provides this information by having direct
> 'phandle' references between dependencies.)

Device tree makes this a lot easier.

> Option 1: Add a list of prerequisite devices to struct device and
> modify driver core so that it defers binding to a driver until all the
> prerequisites are already bound.  This can probably be implemented
> in a way that works for all bus types transparently.  Before binding
> a driver, the driver core would increase the ref count on each of the
> prereq devices, and decrease it again when the driver is removed.

> Option 2: On a per-bus_type basis have a separate registration and the
> bus type code would hold the device unregistered in a pending list.
> This option would also add a prerequisites list to struct device.

Per bus type sounds like a lot of hassle going through all the bus types
but we may need to do that to handle autoprobable buses like USB.  I do
like the idea that the core would know what's going on so that things do
become visible for the debuggabilty reasons you mention, though helpers
could also provide similar infrastructure.

> Option 3: Don't try to handle it in the bus_type or driver core code
> at all, but rather provide board support code with helpers to make
> waiting for other devices easy.  Even in this case I think it is
> probably still a good idea for the dependant devices to increment
> the refcount of the prereq devices.

Agreed on the refcounting.

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v6 08/12] gpio: add ti-ssp gpio driver

[Mark Brown]

On Sun, Nov 21, 2010 at 02:31:38PM -0700, Grant Likely wrote:
> On Sun, Nov 21, 2010 at 1:02 PM, Ryan Mallon  wrote:

> > Currently the code will allow you to install
> > several peripherals at once, which will lead to odd behaviour at
> > runtime. Maybe a better approach would be to have something like this in
> > drivers/mfd/ti-ssp.c:

> Only the ssp core itself is allowed to register the peripheral
> devices, and so using the parent pointer is perfectly valid.  I think
> Cyril's approach is fine.

This is very much a standard idiom for MFD children in Linux - if the
children are entirely reliant on working through a parent-specific API
anyway there's no issue with making the parent device be part of that
API.

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/9] spi/pxa2xx: don't use subys initcall for driver init

[Mark Brown]

On Wed, Nov 24, 2010 at 03:09:25PM +0100, Sebastian Andrzej Siewior wrote:

> I've been pointed out to this commit but I don't understand _why_.
> The part I don't get is "so it can be used with cpufreq". Is it
> refered to a driver or the subsystem as it?

We need the regulators for the CPU rails to start before the cpufreq
driver starts so cpufreq can talk to them, and since the regulators may
be SPI attached this means we also need the SPI controller to start
before cpufreq.  cpufreq starts at vanilla init time.

There's an approach being looked at for handling this for devices but
for deviceless stuff like cpufreq we've nothing.

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/9] spi/pxa2xx: don't use subys initcall for driver init

[Mark Brown]

On Wed, Nov 24, 2010 at 08:30:37AM -0700, Grant Likely wrote:

> It would be easy enough to defer cpufreq initialization based on some
> platform defined criteria.  It's just an initcall.  However, I don't

Though it'd be much better to fix the thing where cpufreq doesn't have a
device anyway.

> know what the impact area is for subsystems that depend on cpufreq.
> Are there drivers that depend on cpufreq before initialized?

OMAP?  It'd be fairly surprising if something were to have a strict
dependency, though - more likely to be notifiers I'd expect.  Usually
cpufreq comes up fairly late.

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v7 06/12] regulator: add driver for tps6524x regulator

[Mark Brown]

On Tue, Dec 07, 2010 at 09:51:56AM -0500, Cyril Chemparathy wrote:

> +static int set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV)
> +{

Updates in the regulator tree mean that this will no longer build in
-next.  Given the difficulty that this series seems to be having
perhaps it would make sense to split out drivers such as this which have
nothing to do with SSP itself and get them into the next merge window?

--
What happens now with your Lotus Notes apps - do you make another costly 
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus 
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v7 00/12] tnetv107x ssp drivers

[Mark Brown]

On Fri, Dec 10, 2010 at 04:19:48PM -0800, Kevin Hilman wrote:

> [PATCH v7 08/12] gpio: add ti-ssp gpio driver
> David Brownell?  (MAINTAINERS isn't clear here)

It's mostly abandoned at the minute.  Andrew Morton has been taking
patches.  Grant Likely said he might take it over so sending stuff his
way might prod him into action.

--
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCHv3 1/4] mc13xxx-core: Consolidate common code to prepare for separate i2c and spi

[Mark Brown]

On Mon, Dec 20, 2010 at 09:00:29PM +1100, Marc Reilly wrote:
> On Monday, December 20, 2010 07:31:20 pm Uwe Kleine-K?nig wrote:

> > This list isn't complete, but see below.

> Do you mean the list above is incomplete? I should have said "Changes to the 
> struct _include_". 
> I'm ignorant of "patch summary etiquette" (or what people otherwise like to 
> see) but I had just assumed that the patch comments were more like a 
> highlights reel - the real info is in the patch itself.

No, the patch summary should generally be complete - if your patch is
changing so many things that it's getting tedious to list them all then
that's usually a sign that it should be split up into a series of
changes.

--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi: Support dev_pm_ops

[Mark Brown]

Allow SPI drivers to use runtime PM and other dev_pm_ops features by
implementing dev_pm_ops for the bus. The existing bus specific suspend
and resume functions will be called if a driver does not provide dev_pm_ops
allowing for transition to the new model.

Signed-off-by: Mark Brown 
---

This depends on the patch 'PM: Prototype the pm_generic_ operations' I
posted recently to the PM and I2C lists, and has not exactly been
thoroughly tested yet.

 drivers/spi/spi.c |   92 -
 1 files changed, 84 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 709c836..85ad4b7 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void spidev_release(struct device *dev)
 {
@@ -100,9 +101,8 @@ static int spi_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
-#ifdef CONFIG_PM
-
-static int spi_suspend(struct device *dev, pm_message_t message)
+#ifdef CONFIG_PM_SLEEP
+static int spi_legacy_suspend(struct device *dev, pm_message_t message)
 {
int value = 0;
struct spi_driver   *drv = to_spi_driver(dev->driver);
@@ -117,7 +117,7 @@ static int spi_suspend(struct device *dev, pm_message_t 
message)
return value;
 }
 
-static int spi_resume(struct device *dev)
+static int spi_legacy_resume(struct device *dev)
 {
int value = 0;
struct spi_driver   *drv = to_spi_driver(dev->driver);
@@ -132,18 +132,94 @@ static int spi_resume(struct device *dev)
return value;
 }
 
+static int spi_pm_suspend(struct device *dev)
+{
+   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+
+   if (pm)
+   return pm_generic_suspend(dev);
+   else
+   return spi_legacy_suspend(dev, PMSG_SUSPEND);
+}
+
+static int spi_pm_resume(struct device *dev)
+{
+   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+
+   if (pm)
+   return pm_generic_resume(dev);
+   else
+   return spi_legacy_resume(dev);
+}
+
+static int spi_pm_freeze(struct device *dev)
+{
+   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+
+   if (pm)
+   return pm_generic_freeze(dev);
+   else
+   return spi_legacy_suspend(dev, PMSG_FREEZE);
+}
+
+static int spi_pm_thaw(struct device *dev)
+{
+   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+
+   if (pm)
+   return pm_generic_thaw(dev);
+   else
+   return spi_legacy_resume(dev);
+}
+
+static int spi_pm_poweroff(struct device *dev)
+{
+   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+
+   if (pm)
+   return pm_generic_poweroff(dev);
+   else
+   return spi_legacy_suspend(dev, PMSG_HIBERNATE);
+}
+
+static int spi_pm_restore(struct device *dev)
+{
+   const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+
+   if (pm)
+   return pm_generic_restore(dev);
+   else
+   return spi_legacy_resume(dev);
+}
 #else
-#define spi_suspendNULL
-#define spi_resume NULL
+#define spi_pm_suspend NULL
+#define spi_pm_resume  NULL
+#define spi_pm_freeze  NULL
+#define spi_pm_thawNULL
+#define spi_pm_poweroffNULL
+#define spi_pm_restore NULL
 #endif
 
+static const struct dev_pm_ops spi_pm = {
+   .suspend = spi_pm_suspend,
+   .resume = spi_pm_resume,
+   .freeze = spi_pm_freeze,
+   .thaw = spi_pm_thaw,
+   .poweroff = spi_pm_poweroff,
+   .restore = spi_pm_restore,
+   SET_RUNTIME_PM_OPS(
+   pm_generic_runtime_suspend,
+   pm_generic_runtime_resume,
+   pm_generic_runtime_idle
+   )
+};
+
 struct bus_type spi_bus_type = {
.name   = "spi",
.dev_attrs  = spi_dev_attrs,
.match  = spi_match_device,
.uevent = spi_uevent,
-   .suspend= spi_suspend,
-   .resume = spi_resume,
+   .pm = &spi_pm,
 };
 EXPORT_SYMBOL_GPL(spi_bus_type);
 
-- 
1.7.2.3


--
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months.  Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your 
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi: Support dev_pm_ops

[Mark Brown]

On Fri, Dec 24, 2010 at 01:52:55AM -0700, Grant Likely wrote:
> On Wed, Dec 22, 2010 at 02:28:23PM +0100, Rafael J. Wysocki wrote:

> > > Allow SPI drivers to use runtime PM and other dev_pm_ops features by
> > > implementing dev_pm_ops for the bus. The existing bus specific suspend
> > > and resume functions will be called if a driver does not provide 
> > > dev_pm_ops
> > > allowing for transition to the new model.
> > > 
> > > Signed-off-by: Mark Brown 

> > It looks good to me.

> I'll take that as an ack.

> picked up for -next, thanks.

Note that as mentioned it does depend on the patch prototyping the
generic ops so it might be better to merge via the PM tree or wait for
things to shake out in the merge window.

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/1] spi: intel_mid_ssp_spi: new SPI driver for intel Medfield platform

[Mark Brown]

On Wed, Feb 02, 2011 at 01:01:52PM -0800, Russ Gorby wrote:
> SPI master controller driver for the Intel MID platform Medfield
> This driver uses the Penwell SSP controller and configures it to
> be a SPI device (spibus 3). This bus supports a single device -
> the 3G SPI modem that can operate up to 25Mhz.

The same hardware is also used for audio I believe - how do the two
drivers share the hardware?

> +#define SSCR0_DSS   (0x000f) /* Data Size Select (mask) */
> +#define SSCR0_DataSize(x)  ((x) - 1) /* Data Size Select [4..16] */
> +#define SSCR0_FRF   (0x0030) /* FRame Format (mask) */
> +#define SSCR0_Motorola (0x0 << 4) /* Motorola's SPI mode 
> */
> +#define SSCR0_ECS   (1 << 6) /* External clock select */
> +#define SSCR0_SSE   (1 << 7) /* Synchronous Serial Port Enable */

There certainly looks to be overlap with the register definitions.

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/1] spi: intel_mid_ssp_spi: new SPI driver for intel Medfield platform

[Mark Brown]

On Wed, Feb 02, 2011 at 10:40:54PM +, Alan Cox wrote:

> And this is the unified one that handles all the devices, but I gather
> may need some fixing/test work on Medfield.

I've got the same question here as I had with Russ' patch: it looks like
there's some overlap with the SSP ports used for audio (it's just a
generic programmable serial port so even if it's not normally used for
audio that's a possiblity), how is that handled?

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/1] spi: intel_mid_ssp_spi: new SPI driver for intel Medfield platform

[Mark Brown]

On Thu, Feb 03, 2011 at 03:04:32PM +, Alan Cox wrote:
> Mark Brown  wrote:

> > I've got the same question here as I had with Russ' patch: it looks like
> > there's some overlap with the SSP ports used for audio (it's just a
> > generic programmable serial port so even if it's not normally used for
> > audio that's a possiblity), how is that handled?

> The SSP has PCI configuration indicating how it is being assigned, which
> is in vendor capability byte 6. The low 3 bits indicte the mode, where
> mode 1 is an SPI master/slave, and in that case bit 6 is set for a slave.

OK, cool - just checking as it's a common issue for these generic serial
ports.

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: mc13xxx-core, support for i2c, V4

[Mark Brown]

On Mon, Feb 14, 2011 at 11:21:34AM +0100, Philippe R?tornaz wrote:

> AFAIK the audio part of the mc13783 has still not been merged.

No, it hasn't.  Sacha posted something ages ago but it had a lot of
problems and I've not seen any subsequent spins.

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [RESEND PATCH 4/4] mmc_spi.c: add support for the regulator framework

[Mark Brown]

On Thu, Apr 21, 2011 at 02:27:53PM +0200, Antonio Ospite wrote:

> +#ifdef CONFIG_REGULATOR
> + host->vcc = regulator_get(mmc_dev(host->mmc), "vmmc");
> +
> + if (IS_ERR(host->vcc)) {
> + host->vcc = NULL;
> + } else {
> + host->mmc->ocr_avail = mmc_regulator_get_ocrmask(host->vcc);
> + if (host->pdata && host->pdata->ocr_mask)
> + dev_warn(mmc_dev(host->mmc),
> + "ocr_mask/setpower will not be used\n");
>   }
> +#endif

Why is this code conditional?  The regulator API will stub itself out
(by returning a null pointer, which plays well with your use of null) if
it's disabled.  I'm also not seeing any corresponding code to release
the regulator.

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi: Use void pointers for data in simple SPI I/O operations

[Mark Brown]

Currently the simple SPI I/O operations all take pointers to u8 * buffers
to operate on. This creates needless type compatibility issues and the
underlying spi_transfer structure uses void pointers anyway so convert the
API over to take void pointers too.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi.c   |4 ++--
 include/linux/spi/spi.h |8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 82b9a42..2e13a14 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1047,8 +1047,8 @@ static u8 *buf;
  * spi_{async,sync}() calls with dma-safe buffers.
  */
 int spi_write_then_read(struct spi_device *spi,
-   const u8 *txbuf, unsigned n_tx,
-   u8 *rxbuf, unsigned n_rx)
+   const void *txbuf, unsigned n_tx,
+   void *rxbuf, unsigned n_rx)
 {
static DEFINE_MUTEX(lock);
 
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index b4d7710..bb4f5fb 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -581,7 +581,7 @@ extern int spi_bus_unlock(struct spi_master *master);
  * Callable only from contexts that can sleep.
  */
 static inline int
-spi_write(struct spi_device *spi, const u8 *buf, size_t len)
+spi_write(struct spi_device *spi, const void *buf, size_t len)
 {
struct spi_transfer t = {
.tx_buf = buf,
@@ -605,7 +605,7 @@ spi_write(struct spi_device *spi, const u8 *buf, size_t len)
  * Callable only from contexts that can sleep.
  */
 static inline int
-spi_read(struct spi_device *spi, u8 *buf, size_t len)
+spi_read(struct spi_device *spi, void *buf, size_t len)
 {
struct spi_transfer t = {
.rx_buf = buf,
@@ -620,8 +620,8 @@ spi_read(struct spi_device *spi, u8 *buf, size_t len)
 
 /* this copies txbuf and rxbuf data; for small transfers only! */
 extern int spi_write_then_read(struct spi_device *spi,
-   const u8 *txbuf, unsigned n_tx,
-   u8 *rxbuf, unsigned n_rx);
+   const void *txbuf, unsigned n_tx,
+   void *rxbuf, unsigned n_rx);
 
 /**
  * spi_w8r8 - SPI synchronous 8 bit write followed by 8 bit read
-- 
1.7.5.1


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v3] mmc_spi.c: add support for the regulator framework

[Mark Brown]

On Wed, May 11, 2011 at 12:39:39PM +0200, Antonio Ospite wrote:
> Add support for powering up SD cards driven by regulators.
> This makes the mmc_spi driver work also with the Motorola A910 phone.
> 
> Signed-off-by: Antonio Ospite 

Reviwed-by: Mark Brown 

but

> + switch (power_mode) {
> + case MMC_POWER_OFF:
> + if (host->vcc) {
> + int ret = mmc_regulator_set_ocr(host->mmc,
> + host->vcc, 0);
> + if (ret)
> + return ret;
> + } else {
> + host->pdata->setpower(&host->spi->dev, vdd);
> + }
> + break;
> +
> + case MMC_POWER_UP:
> + if (host->vcc) {
> + int ret = mmc_regulator_set_ocr(host->mmc,
> + host->vcc, vdd);
> + if (ret)
> + return ret;
> + } else {
>   host->pdata->setpower(&host->spi->dev, vdd);
> - if (power_mode == MMC_POWER_UP)
> - msleep(host->powerup_msecs);
>   }
> + msleep(host->powerup_msecs);
> + break;

This stuff all looks like it should be factored out.

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v3] mmc_spi.c: add support for the regulator framework

[Mark Brown]

On Wed, May 11, 2011 at 10:53:37PM +0200, Antonio Ospite wrote:

> OK, avoiding some duplication will be good, I agree.

> I am resending a v4 with the equivalent code:
> 
>   if (host->vcc) {
>   int ret;
> 
>   if (power_mode == MMC_POWER_OFF)
>   vdd = 0;
> 

This isn't really what I meant - what I meant was that all this logic
looks like it's generic to multiple drivers.  We either set a regulator
or call a pdata callback to set power, both of which are completely
external to the controller.

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v3] mmc_spi.c: add support for the regulator framework

[Mark Brown]

On Wed, May 18, 2011 at 07:23:20PM +0200, Antonio Ospite wrote:

> So you mean something like the following:

> mmc_regulator_set_power(...)
> {

Yes.

>   2. Add a proper function with all the needed parameters to abstract
>  the actual var names, this would be something like:
>  mmc_regulator_set_power(mmc, power_mode, vdd, vcc, pdata)
>  and yet checking for pdata->setpower can be tricky as 'setpower' 
>  is an arbitrary name.

This would be good.

>   3. Move stuff from driver structures to subsystem structures, which I 
>  don't think is needed in this case.

Though this option is also common - often you get a mix of subsystem and
device specific things with for example a subsystem wide data structure
which the device keeps and passes into a function provided by the
subsystem at appropriate moments.

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v3] mmc_spi.c: add support for the regulator framework

[Mark Brown]

On Mon, May 30, 2011 at 11:07:49AM +0200, Antonio Ospite wrote:
> On Mon, 23 May 2011 17:10:23 +0200

> > +#define STRUCT_FIELD(s, f) ((s) && (s)->f ? (s)->f : NULL )

> Any opinion on this macro? See its use below. It is meant to deal with
> driver specific struct fields, which can have arbitrary names, I though
> that using some syntactic sugar to deal with those as arguments when
> calling the function was not that horrible.

> If that looks acceptable to you too I will submit the
> mmc_regulator_set_power () patch, otherwise I would ask to consider the
> simple patch to mmc_spi.c for now.

Would it not be simpler just to provide a standard generic struct that
people can embed into their pdata?

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v3] mmc_spi.c: add support for the regulator framework

[Mark Brown]

On Mon, May 30, 2011 at 12:57:57PM +0200, Antonio Ospite wrote:

> It is cleaner and more uniform indeed, but it does not solve the problem
> I am seeing, the issue is still there when pdata is NULL, we are at the
> same point as before (the current code checks for (pdata &&
> pdata->field)), and we cannot pass pdata directly as a function argument
> (can we?) as it is driver specific as well.

You can do a nasty type punning trick if the generic pdata is the first
member of the platform data, otherwise the easiest thing is usually to
provide a defualt pdata if the pdata is NULL.

I'd expect that in a lot of cases the standard platform data would be
the only platform data so for many drivers they wouldn't need to worry
about extra data but perhaps MMC isn't like that, I've never really
looked at the code.

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: kernel panic in spi_complete() on spitz (PXA270)

[Mark Brown]

On Thu, Jun 30, 2011 at 06:25:51PM +0300, Igor Grinberg wrote:
> On 06/30/11 17:45, Stanislav Brabec wrote:

> > from this thread. Without it, ADS7846 does not work on spitz (ADS7846
> > does not have any dedicated regulator there). I want to
> > add .needs_regulator bool to ads7846.c and send the patch again to the
> > list.

> Please, don't...
> I thought we've finished discussing the regulator issue...

> Instead of patching the driver and the platform data and the board file,
> you should do _either_ of the following:
> 1) add regulator definition for ads7846 into the board file
> 2) enable the CONFIG_REGULATOR_DUMMY in your kernel configuration
> 3) use regulator_use_dummy_regulator() call in the board file.

> Using either of the above, you will not need the patch for ads7846, only for 
> the board file.

Yes, we've been through this repeatedly.  None of these options take any
appreciable time to implement, it'd be much more productive to just do
so.

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: kernel panic in spi_complete() on spitz (PXA270)

[Mark Brown]

On Thu, Jun 30, 2011 at 08:40:40PM +0300, Igor Grinberg wrote:
> On 06/30/11 19:13, Stanislav Brabec wrote:
> > Igor Grinberg wrote:

> >> I thought we've finished discussing the regulator issue...

> > The discussion ended without a fix (at least for spitz).

> Well, the discussion was mainly about how the regulator API should be used.
> The proposed patch, used the regulator API incorrectly.
> If I recall correctly, in the end of the discussion,
> Mark provided another option for configuring the regulator API,
> which is number 3 below.

The discussion ended with you guys having the three different options
that would work, you just need to use one of them.

> >  I seen two
> > proposals:
> > - As ADS7846 hardware does not require dedicated regulator, don't
> >   require it in driver and fail only on platforms that have a dedicated
> >   regulator.

> The thing is that ads7846 chip itself just requires power supply

Right, and the regulator API hides the non-switchability of the supply
from the driver so there's no need for the driver to worry about how the
supplies are wired up.  It just turns the regulator on when it needs it
and turns it off when it doesn't.

> >> 1) add regulator definition for ads7846 into the board file
> > There is no dedicated regulator on spitz, ADS7846 uses common always-on
> > power supply.

> Is there a kind of regulator for this case (except dummy)?
> Some kind of fixed regulator which is not binded to any supply?

This is just a fixed voltage regulator, support for that has been in the
kernel since the regulator API was merged.  This is the best solution,
it ensures that you don't mistakenly activate dummy reglators for
supplies that really need software control.

> > i2c i2c-1: Retrying transmission
> > i2c i2c-1: setting to bus master
> > i2c i2c-1: state:i2c_pxa_handler:981: ISR=0045, ICR=07e1, IBMR=00
> > i2c i2c-1: state:i2c_pxa_irq_txempty:932: ISR=0005, ICR=17ee, 
> > IBMR=00
> > i2c i2c-1: state:i2c_pxa_handler:981: ISR=0087, ICR=17e6, IBMR=00

This looks like you've got I2C I/O issues talking to something.

> > print_constraints: vcc_core range: 850 <--> 1600 mV at 1350 mV 
> > print_constraints: vcc_core range: 1100 mV 

This looks like there's two definitions for vcc_core.

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi/s3c64xx: Log error interrupts

[Mark Brown]

Although the hardware supports interrupts we're not currently using them
at all since for small transfers the overhead is greater than that for
busy waiting and for large transfers we have interrupts from the DMA.
This means that if the hardware reports an error (especially one which
might not stall transfer) we might miss it.

Take a first pass at dealing with such errors by enabling the interrupt
if we can and logging the errors if they happen. Ideally we'd report the
error via the affected transfer but since we're in master mode it's very
difficult to trigger errors at present and this code is much simpler.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   57 +++-
 1 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index dcf7e10..8172173 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -153,6 +154,7 @@ struct s3c64xx_spi_dma_data {
  * @tx_dmach: Controller's DMA channel for Tx.
  * @sfr_start: BUS address of SPI controller regs.
  * @regs: Pointer to ioremap'ed controller registers.
+ * @irq: interrupt
  * @xfer_completion: To indicate completion of xfer task.
  * @cur_mode: Stores the active configuration of the controller.
  * @cur_bpw: Stores the active bits per word settings.
@@ -171,6 +173,7 @@ struct s3c64xx_spi_driver_data {
struct list_headqueue;
spinlock_t  lock;
unsigned long   sfr_start;
+   int irq;
struct completion   xfer_completion;
unsignedstate;
unsignedcur_mode, cur_bpw;
@@ -930,6 +933,33 @@ setup_exit:
return err;
 }
 
+static irqreturn_t s3c64xx_spi_irq(int irq, void *data)
+{
+   struct s3c64xx_spi_driver_data *sdd = data;
+   struct spi_master *spi = sdd->master;
+   unsigned int val;
+
+   val = readl(sdd->regs + S3C64XX_SPI_PENDING_CLR);
+
+   val &= S3C64XX_SPI_PND_RX_OVERRUN_CLR |
+   S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
+   S3C64XX_SPI_PND_TX_OVERRUN_CLR |
+   S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
+
+   writel(val, sdd->regs + S3C64XX_SPI_PENDING_CLR);
+
+   if (val & S3C64XX_SPI_PND_RX_OVERRUN_CLR)
+   dev_err(&spi->dev, "RX overrun\n");
+   if (val & S3C64XX_SPI_PND_RX_UNDERRUN_CLR)
+   dev_err(&spi->dev, "RX underrun\n");
+   if (val & S3C64XX_SPI_PND_TX_OVERRUN_CLR)
+   dev_err(&spi->dev, "TX overrun\n");
+   if (val & S3C64XX_SPI_PND_TX_UNDERRUN_CLR)
+   dev_err(&spi->dev, "TX underrun\n");
+
+   return IRQ_HANDLED;
+}
+
 static void s3c64xx_spi_hwinit(struct s3c64xx_spi_driver_data *sdd, int 
channel)
 {
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
@@ -970,7 +1000,7 @@ static int __init s3c64xx_spi_probe(struct platform_device 
*pdev)
struct s3c64xx_spi_driver_data *sdd;
struct s3c64xx_spi_info *sci;
struct spi_master *master;
-   int ret;
+   int ret, irq;
char clk_name[16];
 
if (pdev->id < 0) {
@@ -1006,6 +1036,12 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
return -ENXIO;
}
 
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   dev_warn(&pdev->dev, "Failed to get IRQ: %d\n", irq);
+   return irq;
+   }
+
master = spi_alloc_master(&pdev->dev,
sizeof(struct s3c64xx_spi_driver_data));
if (master == NULL) {
@@ -1100,10 +1136,21 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
INIT_WORK(&sdd->work, s3c64xx_spi_work);
INIT_LIST_HEAD(&sdd->queue);
 
+   ret = request_irq(sdd->irq, s3c64xx_spi_irq, 0, "spi-s3c64xx", sdd);
+   if (ret != 0) {
+   dev_err(&pdev->dev, "Failed to request IRQ: %d\n",
+   ret);
+   goto err8;
+   }
+
+   writel(S3C64XX_SPI_INT_RX_OVERRUN_EN | S3C64XX_SPI_INT_RX_UNDERRUN_EN |
+  S3C64XX_SPI_INT_TX_OVERRUN_EN | S3C64XX_SPI_INT_TX_UNDERRUN_EN,
+  sdd->regs + S3C64XX_SPI_INT_EN);
+
if (spi_register_master(master)) {
dev_err(&pdev->dev, "cannot register SPI master\n");
ret = -EBUSY;
-   goto err8;
+   goto err9;
}
 
dev_dbg(&pdev->dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d "
@@ -1115,6 +1162,8 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pde

[PATCH] spi/s3c64xx: Log error interrupts

[Mark Brown]

Although the hardware supports interrupts we're not currently using them
at all since for small transfers the overhead is greater than that for
busy waiting and for large transfers we have interrupts from the DMA.
This means that if the hardware reports an error (especially one which
might not stall transfer) we might miss it.

Take a first pass at dealing with such errors by enabling the interrupt
if we can and logging the errors if they happen. Ideally we'd report the
error via the affected transfer but since we're in master mode it's very
difficult to trigger errors at present and this code is much simpler.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   56 +++-
 1 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index dcf7e10..9b16406 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -153,6 +154,7 @@ struct s3c64xx_spi_dma_data {
  * @tx_dmach: Controller's DMA channel for Tx.
  * @sfr_start: BUS address of SPI controller regs.
  * @regs: Pointer to ioremap'ed controller registers.
+ * @irq: interrupt
  * @xfer_completion: To indicate completion of xfer task.
  * @cur_mode: Stores the active configuration of the controller.
  * @cur_bpw: Stores the active bits per word settings.
@@ -930,6 +932,33 @@ setup_exit:
return err;
 }
 
+static irqreturn_t s3c64xx_spi_irq(int irq, void *data)
+{
+   struct s3c64xx_spi_driver_data *sdd = data;
+   struct spi_master *spi = sdd->master;
+   unsigned int val;
+
+   val = readl(sdd->regs + S3C64XX_SPI_PENDING_CLR);
+
+   val &= S3C64XX_SPI_PND_RX_OVERRUN_CLR |
+   S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
+   S3C64XX_SPI_PND_TX_OVERRUN_CLR |
+   S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
+
+   writel(val, sdd->regs + S3C64XX_SPI_PENDING_CLR);
+
+   if (val & S3C64XX_SPI_PND_RX_OVERRUN_CLR)
+   dev_err(&spi->dev, "RX overrun\n");
+   if (val & S3C64XX_SPI_PND_RX_UNDERRUN_CLR)
+   dev_err(&spi->dev, "RX underrun\n");
+   if (val & S3C64XX_SPI_PND_TX_OVERRUN_CLR)
+   dev_err(&spi->dev, "TX overrun\n");
+   if (val & S3C64XX_SPI_PND_TX_UNDERRUN_CLR)
+   dev_err(&spi->dev, "TX underrun\n");
+
+   return IRQ_HANDLED;
+}
+
 static void s3c64xx_spi_hwinit(struct s3c64xx_spi_driver_data *sdd, int 
channel)
 {
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
@@ -970,7 +999,7 @@ static int __init s3c64xx_spi_probe(struct platform_device 
*pdev)
struct s3c64xx_spi_driver_data *sdd;
struct s3c64xx_spi_info *sci;
struct spi_master *master;
-   int ret;
+   int ret, irq;
char clk_name[16];
 
if (pdev->id < 0) {
@@ -1006,6 +1035,12 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
return -ENXIO;
}
 
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   dev_warn(&pdev->dev, "Failed to get IRQ: %d\n", irq);
+   return irq;
+   }
+
master = spi_alloc_master(&pdev->dev,
sizeof(struct s3c64xx_spi_driver_data));
if (master == NULL) {
@@ -1100,10 +1135,21 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
INIT_WORK(&sdd->work, s3c64xx_spi_work);
INIT_LIST_HEAD(&sdd->queue);
 
+   ret = request_irq(irq, s3c64xx_spi_irq, 0, "spi-s3c64xx", sdd);
+   if (ret != 0) {
+   dev_err(&pdev->dev, "Failed to request IRQ %d: %d\n",
+   irq, ret);
+   goto err8;
+   }
+
+   writel(S3C64XX_SPI_INT_RX_OVERRUN_EN | S3C64XX_SPI_INT_RX_UNDERRUN_EN |
+  S3C64XX_SPI_INT_TX_OVERRUN_EN | S3C64XX_SPI_INT_TX_UNDERRUN_EN,
+  sdd->regs + S3C64XX_SPI_INT_EN);
+
if (spi_register_master(master)) {
dev_err(&pdev->dev, "cannot register SPI master\n");
ret = -EBUSY;
-   goto err8;
+   goto err9;
}
 
dev_dbg(&pdev->dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d "
@@ -1115,6 +1161,8 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
 
return 0;
 
+err9:
+   free_irq(irq, sdd);
 err8:
destroy_workqueue(sdd->workqueue);
 err7:
@@ -1153,6 +1201,10 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 
spi_unregister_master(master);
 
+   writel(0, sdd->regs + S3C64XX_SPI_INT_EN);
+
+   free_irq(platform_get_irq(pdev, 0), sdd);
+
destroy_workqueue(sdd->workqueue

[PATCH 2/2] spi/s3c64xx: Implement runtime PM support

[Mark Brown]

Enable and disable the clocks to the SPI controller using runtime PM. This
serves the dual purpose of reducing power consumption a little and letting
the core know when the device is idle.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index fef1c90..9031783 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -782,6 +783,8 @@ static void s3c64xx_spi_work(struct work_struct *work)
while (!acquire_dma(sdd))
msleep(10);
 
+   pm_runtime_get_sync(&sdd->pdev->dev);
+
spin_lock_irqsave(&sdd->lock, flags);
 
while (!list_empty(&sdd->queue)
@@ -810,6 +813,8 @@ static void s3c64xx_spi_work(struct work_struct *work)
/* Free DMA channels */
sdd->ops->release(sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
sdd->ops->release(sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
+
+   pm_runtime_put(&sdd->pdev->dev);
 }
 
 static int s3c64xx_spi_transfer(struct spi_device *spi,
@@ -892,6 +897,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
goto setup_exit;
}
 
+   pm_runtime_get_sync(&sdd->pdev->dev);
+
/* Check if we can provide the requested rate */
if (!sci->clk_from_cmu) {
u32 psr, speed;
@@ -924,6 +931,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
err = -EINVAL;
}
 
+   pm_runtime_put(&sdd->pdev->dev);
+
 setup_exit:
 
/* setup() returns with device de-selected */
@@ -1159,6 +1168,8 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
mem_res->end, mem_res->start,
sdd->rx_dma.dmach, sdd->tx_dma.dmach);
 
+   pm_runtime_enable(&pdev->dev);
+
return 0;
 
 err9:
@@ -1192,6 +1203,8 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
struct resource *mem_res;
unsigned long flags;
 
+   pm_runtime_disable(&pdev->dev);
+
spin_lock_irqsave(&sdd->lock, flags);
sdd->state |= SUSPND;
spin_unlock_irqrestore(&sdd->lock, flags);
@@ -1272,8 +1285,34 @@ static int s3c64xx_spi_resume(struct device *dev)
 }
 #endif /* CONFIG_PM */
 
+#ifdef CONFIG_PM_RUNTIME
+static int s3c64xx_spi_runtime_suspend(struct device *dev)
+{
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
+
+   clk_disable(sdd->clk);
+   clk_disable(sdd->src_clk);
+
+   return 0;
+}
+
+static int s3c64xx_spi_runtime_resume(struct device *dev)
+{
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
+
+   clk_enable(sdd->src_clk);
+   clk_enable(sdd->clk);
+
+   return 0;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
 static struct dev_pm_ops s3c64xx_spi_pm = {
SET_SYSTEM_SLEEP_PM_OPS(s3c64xx_spi_suspend, s3c64xx_spi_resume)
+   SET_RUNTIME_PM_OPS(s3c64xx_spi_runtime_suspend,
+  s3c64xx_spi_runtime_resume, NULL)
 };
 
 static struct platform_driver s3c64xx_spi_driver = {
-- 
1.7.7.3


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 1/2] spi/s3c64xx: Convert to dev_pm_ops

[Mark Brown]

In preparation for the addition of runtime PM ops.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 9b16406..fef1c90 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1226,9 +1226,9 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 }
 
 #ifdef CONFIG_PM
-static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t 
state)
+static int s3c64xx_spi_suspend(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
unsigned long flags;
 
@@ -1248,9 +1248,10 @@ static int s3c64xx_spi_suspend(struct platform_device 
*pdev, pm_message_t state)
return 0;
 }
 
-static int s3c64xx_spi_resume(struct platform_device *pdev)
+static int s3c64xx_spi_resume(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+   struct platform_device *pdev = to_platform_device(dev);
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
unsigned long flags;
@@ -1269,19 +1270,19 @@ static int s3c64xx_spi_resume(struct platform_device 
*pdev)
 
return 0;
 }
-#else
-#define s3c64xx_spi_suspendNULL
-#define s3c64xx_spi_resume NULL
 #endif /* CONFIG_PM */
 
+static struct dev_pm_ops s3c64xx_spi_pm = {
+   SET_SYSTEM_SLEEP_PM_OPS(s3c64xx_spi_suspend, s3c64xx_spi_resume)
+};
+
 static struct platform_driver s3c64xx_spi_driver = {
.driver = {
.name   = "s3c64xx-spi",
.owner = THIS_MODULE,
+   .pm = &s3c64xx_spi_pm,
},
.remove = s3c64xx_spi_remove,
-   .suspend = s3c64xx_spi_suspend,
-   .resume = s3c64xx_spi_resume,
 };
 MODULE_ALIAS("platform:s3c64xx-spi");
 
-- 
1.7.7.3


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 2/3] spi/s3c64xx: Convert to dev_pm_ops

[Mark Brown]

In preparation for the addition of runtime PM ops.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 9b16406..d0c70f2 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1226,9 +1226,9 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 }
 
 #ifdef CONFIG_PM
-static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t 
state)
+static int s3c64xx_spi_suspend(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
unsigned long flags;
 
@@ -1248,9 +1248,10 @@ static int s3c64xx_spi_suspend(struct platform_device 
*pdev, pm_message_t state)
return 0;
 }
 
-static int s3c64xx_spi_resume(struct platform_device *pdev)
+static int s3c64xx_spi_resume(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+   struct platform_device *pdev = to_platform_device(dev);
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
unsigned long flags;
@@ -1269,19 +1270,19 @@ static int s3c64xx_spi_resume(struct platform_device 
*pdev)
 
return 0;
 }
-#else
-#define s3c64xx_spi_suspendNULL
-#define s3c64xx_spi_resume NULL
 #endif /* CONFIG_PM */
 
+static const struct dev_pm_ops s3c64xx_spi_pm = {
+   SET_SYSTEM_SLEEP_PM_OPS(s3c64xx_spi_suspend, s3c64xx_spi_resume)
+};
+
 static struct platform_driver s3c64xx_spi_driver = {
.driver = {
.name   = "s3c64xx-spi",
.owner = THIS_MODULE,
+   .pm = &s3c64xx_spi_pm,
},
.remove = s3c64xx_spi_remove,
-   .suspend = s3c64xx_spi_suspend,
-   .resume = s3c64xx_spi_resume,
 };
 MODULE_ALIAS("platform:s3c64xx-spi");
 
-- 
1.7.7.3


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 3/3] spi/s3c64xx: Implement runtime PM support

[Mark Brown]

Enable and disable the clocks to the SPI controller using runtime PM. This
serves the dual purpose of reducing power consumption a little and letting
the core know when the device is idle.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d0c70f2..b899af66 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -782,6 +783,8 @@ static void s3c64xx_spi_work(struct work_struct *work)
while (!acquire_dma(sdd))
msleep(10);
 
+   pm_runtime_get_sync(&sdd->pdev->dev);
+
spin_lock_irqsave(&sdd->lock, flags);
 
while (!list_empty(&sdd->queue)
@@ -810,6 +813,8 @@ static void s3c64xx_spi_work(struct work_struct *work)
/* Free DMA channels */
sdd->ops->release(sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
sdd->ops->release(sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
+
+   pm_runtime_put(&sdd->pdev->dev);
 }
 
 static int s3c64xx_spi_transfer(struct spi_device *spi,
@@ -892,6 +897,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
goto setup_exit;
}
 
+   pm_runtime_get_sync(&sdd->pdev->dev);
+
/* Check if we can provide the requested rate */
if (!sci->clk_from_cmu) {
u32 psr, speed;
@@ -924,6 +931,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
err = -EINVAL;
}
 
+   pm_runtime_put(&sdd->pdev->dev);
+
 setup_exit:
 
/* setup() returns with device de-selected */
@@ -1159,6 +1168,8 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
mem_res->end, mem_res->start,
sdd->rx_dma.dmach, sdd->tx_dma.dmach);
 
+   pm_runtime_enable(&pdev->dev);
+
return 0;
 
 err9:
@@ -1192,6 +1203,8 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
struct resource *mem_res;
unsigned long flags;
 
+   pm_runtime_disable(&pdev->dev);
+
spin_lock_irqsave(&sdd->lock, flags);
sdd->state |= SUSPND;
spin_unlock_irqrestore(&sdd->lock, flags);
@@ -1272,8 +1285,34 @@ static int s3c64xx_spi_resume(struct device *dev)
 }
 #endif /* CONFIG_PM */
 
+#ifdef CONFIG_PM_RUNTIME
+static int s3c64xx_spi_runtime_suspend(struct device *dev)
+{
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
+
+   clk_disable(sdd->clk);
+   clk_disable(sdd->src_clk);
+
+   return 0;
+}
+
+static int s3c64xx_spi_runtime_resume(struct device *dev)
+{
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
+
+   clk_enable(sdd->src_clk);
+   clk_enable(sdd->clk);
+
+   return 0;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
 static const struct dev_pm_ops s3c64xx_spi_pm = {
SET_SYSTEM_SLEEP_PM_OPS(s3c64xx_spi_suspend, s3c64xx_spi_resume)
+   SET_RUNTIME_PM_OPS(s3c64xx_spi_runtime_suspend,
+  s3c64xx_spi_runtime_resume, NULL)
 };
 
 static struct platform_driver s3c64xx_spi_driver = {
-- 
1.7.7.3


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 1/3] spi/s3c64xx: Log error interrupts

[Mark Brown]

Although the hardware supports interrupts we're not currently using them
at all since for small transfers the overhead is greater than that for
busy waiting and for large transfers we have interrupts from the DMA.
This means that if the hardware reports an error (especially one which
might not stall transfer) we might miss it.

Take a first pass at dealing with such errors by enabling the interrupt
if we can and logging the errors if they happen. Ideally we'd report the
error via the affected transfer but since we're in master mode it's very
difficult to trigger errors at present and this code is much simpler.

Signed-off-by: Mark Brown 
Acked-by: Linus Walleij 
---
 drivers/spi/spi-s3c64xx.c |   56 +++-
 1 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index dcf7e10..9b16406 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -153,6 +154,7 @@ struct s3c64xx_spi_dma_data {
  * @tx_dmach: Controller's DMA channel for Tx.
  * @sfr_start: BUS address of SPI controller regs.
  * @regs: Pointer to ioremap'ed controller registers.
+ * @irq: interrupt
  * @xfer_completion: To indicate completion of xfer task.
  * @cur_mode: Stores the active configuration of the controller.
  * @cur_bpw: Stores the active bits per word settings.
@@ -930,6 +932,33 @@ setup_exit:
return err;
 }
 
+static irqreturn_t s3c64xx_spi_irq(int irq, void *data)
+{
+   struct s3c64xx_spi_driver_data *sdd = data;
+   struct spi_master *spi = sdd->master;
+   unsigned int val;
+
+   val = readl(sdd->regs + S3C64XX_SPI_PENDING_CLR);
+
+   val &= S3C64XX_SPI_PND_RX_OVERRUN_CLR |
+   S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
+   S3C64XX_SPI_PND_TX_OVERRUN_CLR |
+   S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
+
+   writel(val, sdd->regs + S3C64XX_SPI_PENDING_CLR);
+
+   if (val & S3C64XX_SPI_PND_RX_OVERRUN_CLR)
+   dev_err(&spi->dev, "RX overrun\n");
+   if (val & S3C64XX_SPI_PND_RX_UNDERRUN_CLR)
+   dev_err(&spi->dev, "RX underrun\n");
+   if (val & S3C64XX_SPI_PND_TX_OVERRUN_CLR)
+   dev_err(&spi->dev, "TX overrun\n");
+   if (val & S3C64XX_SPI_PND_TX_UNDERRUN_CLR)
+   dev_err(&spi->dev, "TX underrun\n");
+
+   return IRQ_HANDLED;
+}
+
 static void s3c64xx_spi_hwinit(struct s3c64xx_spi_driver_data *sdd, int 
channel)
 {
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
@@ -970,7 +999,7 @@ static int __init s3c64xx_spi_probe(struct platform_device 
*pdev)
struct s3c64xx_spi_driver_data *sdd;
struct s3c64xx_spi_info *sci;
struct spi_master *master;
-   int ret;
+   int ret, irq;
char clk_name[16];
 
if (pdev->id < 0) {
@@ -1006,6 +1035,12 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
return -ENXIO;
}
 
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   dev_warn(&pdev->dev, "Failed to get IRQ: %d\n", irq);
+   return irq;
+   }
+
master = spi_alloc_master(&pdev->dev,
sizeof(struct s3c64xx_spi_driver_data));
if (master == NULL) {
@@ -1100,10 +1135,21 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
INIT_WORK(&sdd->work, s3c64xx_spi_work);
INIT_LIST_HEAD(&sdd->queue);
 
+   ret = request_irq(irq, s3c64xx_spi_irq, 0, "spi-s3c64xx", sdd);
+   if (ret != 0) {
+   dev_err(&pdev->dev, "Failed to request IRQ %d: %d\n",
+   irq, ret);
+   goto err8;
+   }
+
+   writel(S3C64XX_SPI_INT_RX_OVERRUN_EN | S3C64XX_SPI_INT_RX_UNDERRUN_EN |
+  S3C64XX_SPI_INT_TX_OVERRUN_EN | S3C64XX_SPI_INT_TX_UNDERRUN_EN,
+  sdd->regs + S3C64XX_SPI_INT_EN);
+
if (spi_register_master(master)) {
dev_err(&pdev->dev, "cannot register SPI master\n");
ret = -EBUSY;
-   goto err8;
+   goto err9;
}
 
dev_dbg(&pdev->dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d "
@@ -1115,6 +1161,8 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
 
return 0;
 
+err9:
+   free_irq(irq, sdd);
 err8:
destroy_workqueue(sdd->workqueue);
 err7:
@@ -1153,6 +1201,10 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 
spi_unregister_master(master);
 
+   writel(0, sdd->regs + S3C64XX_SPI_INT_EN);
+
+   free_irq(platform_get_irq(pdev, 0), sdd);
+
destroy_work

Re: [PATCH 2/2] spi/s3c64xx: Implement runtime PM support

[Mark Brown]

On Mon, Dec 05, 2011 at 10:41:21PM +0100, Linus Walleij wrote:

> Just wanted to mention that I had this discussion with Magnus Damm
> about how they do this in shmobile: in there their central runtime PM
> policy in arch/arm/mach-shmobile/pm_runtime.c adds in the
> pm_clk_notifier from drivers/base/power/clock_ops.c to gate/ungate
> the clocks centrally acting on bus notifiers without any per-driver
> hooks like these.

Yeah, I'm familiar with that - some other platforms were looking into a
similar scheme I think.

> I clearly see that in this platform it's *not* going to work since
> for this one driver atleast, there are two clocks, not just one,
> that need to be managed for the device.

Well, that's not something that's a blocker to central management - the
core can always work with two clocks.  What's more of an issue is when
devices need to work with their clocks independantly of the core, but
that's not insurmountable.

I do also think that if we do decide to move more platforms to central
management it's going to be easier to first transition all their drivers
to a repetitive style of clock management and then do a big factor out
once the pattern is clearly visible.  It's a big undertaking for things
like the Samsung family of processors where you've got a huge set of
chips to work with going all the way back to s3c24xx so anything we can
do to make it easier is going to be a win.

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: mc13xxx: add I2C support

[Mark Brown]

On Thu, Jan 19, 2012 at 12:12:31PM +0100, Arnaud Patard wrote:

> I've never looked at regmap deeply but can't it be done with regmap or is it
> just a bad idea ?

Glancing quickly at the existing code it should map on reasonably well,
though a new format definition may be required for the 25 bit shift that
would be trivial.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: mc13xxx: add I2C support

[Mark Brown]

On Fri, Jan 20, 2012 at 06:55:35PM +1100, Marc Reilly wrote:
> On Thursday, January 19, 2012 10:29:41 PM Mark Brown wrote:
> > On Thu, Jan 19, 2012 at 12:12:31PM +0100, Arnaud Patard wrote:

> > > I've never looked at regmap deeply but can't it be done with regmap or is
> > > it just a bad idea ?

> > Glancing quickly at the existing code it should map on reasonably well,
> > though a new format definition may be required for the 25 bit shift that
> > would be trivial.

> I'm sadly unfamiliar with regmap, is it a far superior solution? does it need 
> to used now? (ie. I'm relucant to totally rework this now. Please convince me 
> I need to if required.)

It shouldn't be a total rework - the conversion is usually just a case
of replacing the body of the current read/write functions (and ideally
also update_bits() if you've got a one of those) with the equivalent
regmap calls and adding the calls to initialise and free to the probe
functions.  This should be pretty quick and easy.

The benefit of doing the simple conversion is mostly just code sharing,
though you do also get some trace infrastructure for logging register
writes for free.  With a tiny bit more work (saying what the highest
register number is) you'd also get debugfs support for dumping the
register map which is handy for development.  With another small bit of
work (turning on a flag when registering the device and adding a
function which says which registers the chip can change itself) you can
get a register cache which gives a nice performance improvement on
read/modify/write updates as it cuts out the read.  This is useful for
things like DVFS where the regulator voltage change should be as quick
as possible.  None of this is earth shattering but it's very easy to
deploy once the infrastructure is shared.

I doubt Samuel would insist on doing this immediately, though given that
you're adding new bus support it'd be nice.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 0/3] spi/s3c64xx diagnostic and PM updates

[Mark Brown]

The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:

  Linux 3.2 (2012-01-04 15:55:44 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git spi/s3c64xx

They've all been posted several times before but seem to have got
dropped on the floor somewhere along the line.

Mark Brown (3):
  spi/s3c64xx: Log error interrupts
  spi/s3c64xx: Convert to dev_pm_ops
  spi/s3c64xx: Implement runtime PM support

 drivers/spi/spi-s3c64xx.c |  115 
 1 files changed, 104 insertions(+), 11 deletions(-)

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 1/3] spi/s3c64xx: Log error interrupts

[Mark Brown]

Although the hardware supports interrupts we're not currently using them
at all since for small transfers the overhead is greater than that for
busy waiting and for large transfers we have interrupts from the DMA.
This means that if the hardware reports an error (especially one which
might not stall transfer) we might miss it.

Take a first pass at dealing with such errors by enabling the interrupt
if we can and logging the errors if they happen. Ideally we'd report the
error via the affected transfer but since we're in master mode it's very
difficult to trigger errors at present and this code is much simpler.

Signed-off-by: Mark Brown 
Acked-by: Linus Walleij 
---
 drivers/spi/spi-s3c64xx.c |   57 +++-
 1 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 019a716..d56066b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -153,6 +154,7 @@ struct s3c64xx_spi_dma_data {
  * @tx_dmach: Controller's DMA channel for Tx.
  * @sfr_start: BUS address of SPI controller regs.
  * @regs: Pointer to ioremap'ed controller registers.
+ * @irq: interrupt
  * @xfer_completion: To indicate completion of xfer task.
  * @cur_mode: Stores the active configuration of the controller.
  * @cur_bpw: Stores the active bits per word settings.
@@ -930,6 +932,33 @@ setup_exit:
return err;
 }
 
+static irqreturn_t s3c64xx_spi_irq(int irq, void *data)
+{
+   struct s3c64xx_spi_driver_data *sdd = data;
+   struct spi_master *spi = sdd->master;
+   unsigned int val;
+
+   val = readl(sdd->regs + S3C64XX_SPI_PENDING_CLR);
+
+   val &= S3C64XX_SPI_PND_RX_OVERRUN_CLR |
+   S3C64XX_SPI_PND_RX_UNDERRUN_CLR |
+   S3C64XX_SPI_PND_TX_OVERRUN_CLR |
+   S3C64XX_SPI_PND_TX_UNDERRUN_CLR;
+
+   writel(val, sdd->regs + S3C64XX_SPI_PENDING_CLR);
+
+   if (val & S3C64XX_SPI_PND_RX_OVERRUN_CLR)
+   dev_err(&spi->dev, "RX overrun\n");
+   if (val & S3C64XX_SPI_PND_RX_UNDERRUN_CLR)
+   dev_err(&spi->dev, "RX underrun\n");
+   if (val & S3C64XX_SPI_PND_TX_OVERRUN_CLR)
+   dev_err(&spi->dev, "TX overrun\n");
+   if (val & S3C64XX_SPI_PND_TX_UNDERRUN_CLR)
+   dev_err(&spi->dev, "TX underrun\n");
+
+   return IRQ_HANDLED;
+}
+
 static void s3c64xx_spi_hwinit(struct s3c64xx_spi_driver_data *sdd, int 
channel)
 {
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
@@ -970,7 +999,8 @@ static int __init s3c64xx_spi_probe(struct platform_device 
*pdev)
struct s3c64xx_spi_driver_data *sdd;
struct s3c64xx_spi_info *sci;
struct spi_master *master;
-   int ret;
+   int ret, irq;
+   char clk_name[16];
 
if (pdev->id < 0) {
dev_err(&pdev->dev,
@@ -1010,6 +1040,12 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
return -ENXIO;
}
 
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   dev_warn(&pdev->dev, "Failed to get IRQ: %d\n", irq);
+   return irq;
+   }
+
master = spi_alloc_master(&pdev->dev,
sizeof(struct s3c64xx_spi_driver_data));
if (master == NULL) {
@@ -1104,10 +1140,21 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
INIT_WORK(&sdd->work, s3c64xx_spi_work);
INIT_LIST_HEAD(&sdd->queue);
 
+   ret = request_irq(irq, s3c64xx_spi_irq, 0, "spi-s3c64xx", sdd);
+   if (ret != 0) {
+   dev_err(&pdev->dev, "Failed to request IRQ %d: %d\n",
+   irq, ret);
+   goto err8;
+   }
+
+   writel(S3C64XX_SPI_INT_RX_OVERRUN_EN | S3C64XX_SPI_INT_RX_UNDERRUN_EN |
+  S3C64XX_SPI_INT_TX_OVERRUN_EN | S3C64XX_SPI_INT_TX_UNDERRUN_EN,
+  sdd->regs + S3C64XX_SPI_INT_EN);
+
if (spi_register_master(master)) {
dev_err(&pdev->dev, "cannot register SPI master\n");
ret = -EBUSY;
-   goto err8;
+   goto err9;
}
 
dev_dbg(&pdev->dev, "Samsung SoC SPI Driver loaded for Bus SPI-%d "
@@ -1119,6 +1166,8 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
 
return 0;
 
+err9:
+   free_irq(irq, sdd);
 err8:
destroy_workqueue(sdd->workqueue);
 err7:
@@ -1157,6 +1206,10 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 
spi_unregister_master(master);
 
+   writel(0, sdd->regs + S3C64XX_SPI_INT_EN);
+
+   free_irq(platform_g

[PATCH 3/3] spi/s3c64xx: Implement runtime PM support

[Mark Brown]

Enable and disable the clocks to the SPI controller using runtime PM. This
serves the dual purpose of reducing power consumption a little and letting
the core know when the device is idle.

Signed-off-by: Mark Brown 
Acked-by: Linus Walleij 
Acked-by: Heiko Stuebner 
---
 drivers/spi/spi-s3c64xx.c |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 56dbdf1..b0b843b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -782,6 +783,8 @@ static void s3c64xx_spi_work(struct work_struct *work)
while (!acquire_dma(sdd))
msleep(10);
 
+   pm_runtime_get_sync(&sdd->pdev->dev);
+
spin_lock_irqsave(&sdd->lock, flags);
 
while (!list_empty(&sdd->queue)
@@ -810,6 +813,8 @@ static void s3c64xx_spi_work(struct work_struct *work)
/* Free DMA channels */
sdd->ops->release(sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
sdd->ops->release(sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
+
+   pm_runtime_put(&sdd->pdev->dev);
 }
 
 static int s3c64xx_spi_transfer(struct spi_device *spi,
@@ -892,6 +897,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
goto setup_exit;
}
 
+   pm_runtime_get_sync(&sdd->pdev->dev);
+
/* Check if we can provide the requested rate */
if (!sci->clk_from_cmu) {
u32 psr, speed;
@@ -924,6 +931,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
err = -EINVAL;
}
 
+   pm_runtime_put(&sdd->pdev->dev);
+
 setup_exit:
 
/* setup() returns with device de-selected */
@@ -1164,6 +1173,8 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
mem_res->end, mem_res->start,
sdd->rx_dma.dmach, sdd->tx_dma.dmach);
 
+   pm_runtime_enable(&pdev->dev);
+
return 0;
 
 err9:
@@ -1197,6 +1208,8 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
struct resource *mem_res;
unsigned long flags;
 
+   pm_runtime_disable(&pdev->dev);
+
spin_lock_irqsave(&sdd->lock, flags);
sdd->state |= SUSPND;
spin_unlock_irqrestore(&sdd->lock, flags);
@@ -1277,8 +1290,34 @@ static int s3c64xx_spi_resume(struct device *dev)
 }
 #endif /* CONFIG_PM */
 
+#ifdef CONFIG_PM_RUNTIME
+static int s3c64xx_spi_runtime_suspend(struct device *dev)
+{
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
+
+   clk_disable(sdd->clk);
+   clk_disable(sdd->src_clk);
+
+   return 0;
+}
+
+static int s3c64xx_spi_runtime_resume(struct device *dev)
+{
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
+
+   clk_enable(sdd->src_clk);
+   clk_enable(sdd->clk);
+
+   return 0;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
 static const struct dev_pm_ops s3c64xx_spi_pm = {
SET_SYSTEM_SLEEP_PM_OPS(s3c64xx_spi_suspend, s3c64xx_spi_resume)
+   SET_RUNTIME_PM_OPS(s3c64xx_spi_runtime_suspend,
+  s3c64xx_spi_runtime_resume, NULL)
 };
 
 static struct platform_driver s3c64xx_spi_driver = {
-- 
1.7.7.3


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 2/3] spi/s3c64xx: Convert to dev_pm_ops

[Mark Brown]

In preparation for the addition of runtime PM ops.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   19 ++-
 1 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d56066b..56dbdf1 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1231,9 +1231,9 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 }
 
 #ifdef CONFIG_PM
-static int s3c64xx_spi_suspend(struct platform_device *pdev, pm_message_t 
state)
+static int s3c64xx_spi_suspend(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
unsigned long flags;
 
@@ -1253,9 +1253,10 @@ static int s3c64xx_spi_suspend(struct platform_device 
*pdev, pm_message_t state)
return 0;
 }
 
-static int s3c64xx_spi_resume(struct platform_device *pdev)
+static int s3c64xx_spi_resume(struct device *dev)
 {
-   struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+   struct platform_device *pdev = to_platform_device(dev);
+   struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
unsigned long flags;
@@ -1274,19 +1275,19 @@ static int s3c64xx_spi_resume(struct platform_device 
*pdev)
 
return 0;
 }
-#else
-#define s3c64xx_spi_suspendNULL
-#define s3c64xx_spi_resume NULL
 #endif /* CONFIG_PM */
 
+static const struct dev_pm_ops s3c64xx_spi_pm = {
+   SET_SYSTEM_SLEEP_PM_OPS(s3c64xx_spi_suspend, s3c64xx_spi_resume)
+};
+
 static struct platform_driver s3c64xx_spi_driver = {
.driver = {
.name   = "s3c64xx-spi",
.owner = THIS_MODULE,
+   .pm = &s3c64xx_spi_pm,
},
.remove = s3c64xx_spi_remove,
-   .suspend = s3c64xx_spi_suspend,
-   .resume = s3c64xx_spi_resume,
 };
 MODULE_ALIAS("platform:s3c64xx-spi");
 
-- 
1.7.7.3


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 3/3] spi/s3c64xx: Implement runtime PM support

[Mark Brown]

On Sat, Jan 21, 2012 at 02:41:59PM +0100, Bill Gatliff wrote:

> What about using autosuspend instead?  If a client is doing a lot of
> closely-spaced SPI transactions on a relatively flat device tree,
> might the resulting runtime suspend/resume overhead between each
> transaction become noticeable?

It seems very low overhead, particularly in the context of the overhead
of the SPI transactions themselves.  I have sometimes wondered if it
might be an idea to just make the core do something along these lines by
default as there should be very few cases where it's important to have
the suspend happen immediately.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 0/3] spi/s3c64xx diagnostic and PM updates

[Mark Brown]

On Sat, Jan 21, 2012 at 07:27:23AM -0700, Grant Likely wrote:

> Pushed out to git://git.secretlab.ca/git/linux-2.6.git spi/merge.
> I'll ask Linus to pull in a couple of days after it has hit
> linux-next.

Thanks.  Obviously it'd be nice to get it into 3.3 but I don't see a
huge rush and it did miss the merge window - it doesn't fix any bugs
and without a bunch of other work in cpuidle that's not been done yet
the power gains from the runtime PM are vanishingly small.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/3] spi/s3c64xx: Log error interrupts

[Mark Brown]

On Sat, Jan 21, 2012 at 04:27:16PM +0100, Sylwester Nawrocki wrote:
> On 01/21/2012 02:24 PM, Mark Brown wrote:

> > -   int ret;
> > +   int ret, irq;
> > +   char clk_name[16];

> clk_name seems to be unused, otherwise looks good.

That's git cherry-pick being too clever for me when I pulled this out of
my -next branch for Grant.  clk_name is used in -next by some updates
which I guess Kukjin is carrying, I hadn't noticed they weren't in the
SPI tree.  I don't know if it's better to just leave things as they are
for now given that it'll all come out in the merge window?

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/pl022: Add high priority message pump support

[Mark Brown]

On Tue, Jan 24, 2012 at 10:14:32PM +0100, Linus Walleij wrote:
> From: Chris Blair 
> 
> This switches the PL022 worker to a kthread in order to get
> hold of a mechanism to control the message pump priority. On
> low-latency systems elevating the message kthread to realtime
> priority give a real sleek response curve. This has been
> confirmed by measurements. Realtime priority elevation for
> a certain PL022 port can be requested from platform data.

It really feels like we should be pulling this into the core - lots of
drivers use a workqueue to drive data through the system and they're all
going to have exactly the same issue.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/pl022: Add high priority message pump support

[Mark Brown]

On Thu, Jan 26, 2012 at 03:48:59PM +0100, Linus Walleij wrote:
> On Wed, Jan 25, 2012 at 3:02 PM, Mark Brown  wrote:

> > It really feels like we should be pulling this into the core - lots of
> > drivers use a workqueue to drive data through the system and they're all
> > going to have exactly the same issue.

> That reads to me like the entire message queue and "transfer pump"
> mechanism from the PL022 driver should be made into generic
> code. That is the key ingredient from the PL022 driver that has
> allowed us to get real nice throughput on it.

> And that observation is correct, but a bit of upfront code.

Probably, yes - lots of drivers seem to have a workqueue of some kind
that drives the actual transfers and I strongly suspect that there's a
lot of generality there.  I have to confess that I had just thought that
"transfer pump" was an obscure bit of jargon in the changelog so it's
possible it's doing something device specific but it'd seem surprising
TBH.

> I would make it an opt-in for SPI drivers to have a generic
> message queue instead of treating messages in a one-by-one
> manner.

That'd certainly be nice - where things use a workqueue they do often
just pass the entire request from the caller off to it in one fell swoop
so that sounds compatible.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi-altera: Allow to explicitely override bus number via dts

[Mark Brown]

On Tue, Jan 31, 2012 at 04:54:06PM +0100, Tobias Klauser wrote:
> From: Frederic Lambert 
> 
> Until now we let the code in spi.c assign us the bus number if the platform
> device didn't specify its id. This patch adds the possibility to explicitely
> specify the bus number via device tree.

Why would this be required?  Bus numbers are a Linux specific thing...

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi-altera: Allow to explicitely override bus number via dts

[Mark Brown]

On Wed, Feb 01, 2012 at 03:01:53PM +0100, Frederic LAMBERT wrote:

Don't top post!

> Because this bus number is used to create the device name on
> /sys/bus/spi/..., name that the user app must know to work with.

Why must the user application know this?  What is missing to allow the
application to discover an appropriate device to work with automatically?

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi-altera: Allow to explicitely override bus number via dts

[Mark Brown]

On Wed, Feb 01, 2012 at 03:25:33PM +0100, Frederic LAMBERT wrote:

> > > Because this bus number is used to create the device name on
> > > /sys/bus/spi/..., name that the user app must know to work with.

> > Why must the user application know this?  What is missing to allow the
> > application to discover an appropriate device to work with automatically?

> Good question. I have a nvSRAM that I access using the AT25 driver, and I
> don't know how access it without its /sys/bus/ name. If there is another
> way, it is worse to consider it.

For this I'd expect the application to be able to enumerate all the SPI
devices and offer the user a selection of those with the appropriate
driver bound (though I can see that simple scripts might not have
bothered).

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi-altera: Allow to explicitely override bus number via dts

[Mark Brown]

On Wed, Feb 01, 2012 at 03:53:00PM +0100, Frederic LAMBERT wrote:

> I wrote a piece of code that uses this nvSRAM as a persistent storage.
> This runs in a softcore embedded in an FPGA, in an equipment.
> The PC version of this application uses a simple file to emulate this
> behavior.
> The simulated version, using an x86 port embedded in a VirtualBox uses a
> piece of virtual disk with /dev/sdb.

So it's just a basic block device?

> To sumarize, I have a same code that works for the 3 architecture, the
> single difference being in the device name:
> /sys/proc/spi/drivers/at25/spi0.0/eeprom for Nios2
> dataBase.dat on Linux
> /dev/sdb on the Virtual Machine

In this case surely the mechanisms used to identify regular disks (UUIDs
and so on) will also work (the .dat file will have to be an override,
but otherwise...)?  Names like sdb aren't stable either - they can
change with either software or hardware changes since they just come
from the order of discovery.

> Why should I have to break that, which work nice, to use a bus enumeration
> which would be specific to the real hardware version, because I'm using a
> new tools, DTS, which is supposed to simplify my life.
> Sorry to insist, but this incapacity to set the bus number is a *real*
> regression (for me).

> I know I could use the name chosen by the kernel (it mus be something like
> /sys/.../spi253.0/...), but I have no control on it. If tomorrow someone
> changes something in the spi bus number definition, a kernel upgrade will
> have an impact on the user stuff...

We went through exactly the same routine whenever people noticed that
the names for disks weren't as stable as people had been assuming, for
example with the SATA transition from IDE to SCSI, with network devices,
and in a few other places too.  Coming up with fixed names for things
that don't depend on implementation details is really rather hard and
tends to break down eventually either due to software changes or due to
newer hardware.

The other issue with your patch is that setting a bus number is
obviously not a device specific thing, it's something that will apply to
any SPI controller on Linux, and so shouldn't be something driver
specific but should instead be a change to the SPI core.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi-altera: Allow to explicitely override bus number via dts

[Mark Brown]

On Wed, Feb 01, 2012 at 04:29:25PM +0100, Frederic LAMBERT wrote:

> >  > To sumarize, I have a same code that works for the 3 architecture, the
> > > single difference being in the device name:
> > > /sys/proc/spi/drivers/at25/spi0.0/eeprom for Nios2
> > > dataBase.dat on Linux
> > > /dev/sdb on the Virtual Machine

> > In this case surely the mechanisms used to identify regular disks (UUIDs
> > and so on) will also work (the .dat file will have to be an override,
> > but otherwise...)?  Names like sdb aren't stable either - they can
> > change with either software or hardware changes since they just come
> > from the order of discovery.

> Sure there are mechanisms, but that means that the code must be either
> specific to the arch, either have the code for all of them. Not simple !

Well, something that walks all block devices on Linux is very
straightforward...  It sounds like you just want logic along the lines
of "find a block device and offer the option of overriding by providing
a specific path for use with a file", is that about right?

> The other issue with your patch is that setting a bus number is
> > obviously not a device specific thing, it's something that will apply to
> > any SPI controller on Linux, and so shouldn't be something driver
> > specific but should instead be a change to the SPI core.

> Although I tend to agree you on the fact that SPI bus num is a SPI core
> matter, but the fact is that, for now, it is the controller that must fill
> the spi_master structure to call spi_master_get(), and that this structure
> contains a field 'bus_num' that is always initialized to -1 since DTS...

This sounds like a simple matter of proramming to change.  Clearly
providing a standard feature of the SPI subsystem will involve
modification of the SPI core, for example to change the interpretation
of -1 to go look at the device tree and override it.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi-altera: Allow to explicitely override bus number via dts

[Mark Brown]

On Wed, Feb 01, 2012 at 04:52:14PM +0100, Frederic LAMBERT wrote:

> Yes, that seems simple said like that.
> It was thus more simple for me, at that time, to modify a specific driver
> for a specific port (Nios2), than to modify a core used by every one.
> Question of time, and confidence in my own capacities :-).
> The other point being the change acceptation (and the time it takes) by the
> community...

In this case doing something generic would be easier to get merged
(modulo the "don't do that" issue) - people are being a lot more wary
about driver specific changes that should be generic than they used to
be.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi/s3c64xx: Convert to using core message queue

[Mark Brown]

Convert the s3c64xx driver to using the new message queue factored out of
the pl022 driver by Linus Walleij, saving us a nice block of code and
getting the benefits of improvements implemented in the core.

Signed-off-by: Mark Brown 
---

Only lightly tested thus far.  Linus, it'd be really nice if you could
add this to your patch queue for this feature until it's merged by
Grant.

 drivers/spi/spi-s3c64xx.c |  125 -
 1 files changed, 22 insertions(+), 103 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index b899af66..1174d80 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -128,8 +128,6 @@
 
 #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
 
-#define SUSPND(1<<0)
-#define SPIBUSY   (1<<1)
 #define RXBUSY(1<<2)
 #define TXBUSY(1<<3)
 
@@ -144,10 +142,8 @@ struct s3c64xx_spi_dma_data {
  * @clk: Pointer to the spi clock.
  * @src_clk: Pointer to the clock used to generate SPI signals.
  * @master: Pointer to the SPI Protocol master.
- * @workqueue: Work queue for the SPI xfer requests.
  * @cntrlr_info: Platform specific data for the controller this driver manages.
  * @tgl_spi: Pointer to the last CS left untoggled by the cs_change hint.
- * @work: Work
  * @queue: To log SPI xfer requests.
  * @lock: Controller specific lock.
  * @state: Set of FLAGS to indicate status.
@@ -167,10 +163,8 @@ struct s3c64xx_spi_driver_data {
struct clk  *src_clk;
struct platform_device  *pdev;
struct spi_master   *master;
-   struct workqueue_struct *workqueue;
struct s3c64xx_spi_info  *cntrlr_info;
struct spi_device   *tgl_spi;
-   struct work_struct  work;
struct list_headqueue;
spinlock_t  lock;
unsigned long   sfr_start;
@@ -637,9 +631,10 @@ static void s3c64xx_spi_unmap_mssg(struct 
s3c64xx_spi_driver_data *sdd,
}
 }
 
-static void handle_msg(struct s3c64xx_spi_driver_data *sdd,
-   struct spi_message *msg)
+static int s3c64xx_spi_transfer_one_message(struct spi_master *master,
+   struct spi_message *msg)
 {
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
struct spi_device *spi = msg->spi;
struct s3c64xx_spi_csinfo *cs = spi->controller_data;
@@ -771,13 +766,15 @@ out:
 
if (msg->complete)
msg->complete(msg->context);
+
+   spi_finalize_current_message(master);
+
+   return 0;
 }
 
-static void s3c64xx_spi_work(struct work_struct *work)
+static int s3c64xx_spi_prepare_transfer(struct spi_master *spi)
 {
-   struct s3c64xx_spi_driver_data *sdd = container_of(work,
-   struct s3c64xx_spi_driver_data, work);
-   unsigned long flags;
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
/* Acquire DMA channels */
while (!acquire_dma(sdd))
@@ -785,61 +782,18 @@ static void s3c64xx_spi_work(struct work_struct *work)
 
pm_runtime_get_sync(&sdd->pdev->dev);
 
-   spin_lock_irqsave(&sdd->lock, flags);
-
-   while (!list_empty(&sdd->queue)
-   && !(sdd->state & SUSPND)) {
-
-   struct spi_message *msg;
-
-   msg = container_of(sdd->queue.next, struct spi_message, queue);
-
-   list_del_init(&msg->queue);
-
-   /* Set Xfer busy flag */
-   sdd->state |= SPIBUSY;
-
-   spin_unlock_irqrestore(&sdd->lock, flags);
-
-   handle_msg(sdd, msg);
-
-   spin_lock_irqsave(&sdd->lock, flags);
-
-   sdd->state &= ~SPIBUSY;
-   }
+   return 0;
+}
 
-   spin_unlock_irqrestore(&sdd->lock, flags);
+static int s3c64xx_spi_unprepare_transfer(struct spi_master *spi)
+{
+   struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(spi);
 
/* Free DMA channels */
sdd->ops->release(sdd->rx_dma.ch, &s3c64xx_spi_dma_client);
sdd->ops->release(sdd->tx_dma.ch, &s3c64xx_spi_dma_client);
 
pm_runtime_put(&sdd->pdev->dev);
-}
-
-static int s3c64xx_spi_transfer(struct spi_device *spi,
-   struct spi_message *msg)
-{
-   struct s3c64xx_spi_driver_data *sdd;
-   unsigned long flags;
-
-   sdd = spi_master_get_devdata(spi->master);
-
-   spin_lock_irqsave(&sdd->lock, flags);
-
-   if (sdd->state & SUSPND) {
-   spin_unlock_irqrestore(&sdd->lock, flags);
-   retur

[PATCH] spi: Mark spi_register_board_info() __devinit

[Mark Brown]

Some systems have SPI devices located on plugin modules which are
enumerated at runtime as devices. The drivers for these plugin modules
need to register their SPI devices at probe() time so want to be able
to call spi_register_board_info() but that function is currently marked
as __init rather than __devinit so this usage isn't legal. Change the
annotation to __devinit to handle this.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 909e303..0c833a9 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -484,7 +484,7 @@ static void spi_match_master_to_boardinfo(struct spi_master 
*master,
  * The board info passed can safely be __initdata ... but be careful of
  * any embedded pointers (platform_data, etc), they're copied as-is.
  */
-int __init
+int __devinit
 spi_register_board_info(struct spi_board_info const *info, unsigned n)
 {
struct boardinfo *bi;
-- 
1.7.9


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: mfd: mc13xxx: add I2C support, V2

[Mark Brown]

On Sun, Mar 11, 2012 at 12:50:18PM +0100, Wolfram Sang wrote:

> free, if this is desired. I think the regmap approach should have been tried
> before we go custom. sound/soc/codecs/ad193x.c might give an impression how
> regmap spi/i2c in one driver could look like.

There's a bunch of other examples in sound/soc and also the wm831x PMIC
driver in drivers/mfd.  For an initial conversion I'd not worry about
the cache, especially with some of the older PMICs hardware designers
were known to come up with some "innovative usability solutions" which
can cause hassle.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi: s3c64xx: Fix build

[Mark Brown]

Commit 054ebc (spi: Compatibility with direction which is used in samsung
DMA operation) does not build as one hunk adds a brace to the first branch
of an if statement without adding at least the correspoding close. Remove
the unwanted brace.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index c40d118..3180100 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -264,7 +264,7 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
struct s3c64xx_spi_driver_data *sdd;
struct samsung_dma_prep_info info;
 
-   if (dma->direction == DMA_DEV_TO_MEM) {
+   if (dma->direction == DMA_DEV_TO_MEM)
sdd = container_of((void *)dma,
struct s3c64xx_spi_driver_data, rx_dma);
else
-- 
1.7.9.1


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v4 2/4] mfd: mc13xxx-core: use regmap for register access

[Mark Brown]

On Mon, Mar 19, 2012 at 03:03:56PM +1100, Marc Reilly wrote:
> This change converts the mc13xxx core to use regmap rather than direct
> spi r/w.
> The spidev member of mc13xxx struct becomes redundant and is removed.
> Extra debugging aids are added to mc13xxx_reg_rmw.
> Mutex init is moved to before regmap init.

Reviewed-by: Mark Brown 

though like I said it'd be good to get the rmw trace into regmap - if
it's useful to you here similar trace is probably going to be useful to
other users.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH/RFC] ARM: amba: Remove AMBA level regulator support

[Mark Brown]

The AMBA bus regulator support is being used to model on/off switches
for power domains which isn't terribly idiomatic for modern kernels with
the generic power domain code and creates integration problems on platforms
which don't use regulators for their power domains as it's hard to tell
the difference between a regulator that is needed but failed to be provided
and one that isn't supposed to be there (though DT does make that easier).

Platforms that wish to use the regulator API to manage their power domains
can indirect via the power domain interface.

The impact should be minimal since currently there are no mainline
systems which actually provide a vcore regulator so none need updating.

Signed-off-by: Mark Brown 
---

RFC because there's some disagreement about this.

 drivers/amba/bus.c   |   42 +-
 drivers/spi/spi-pl022.c  |2 --
 include/linux/amba/bus.h |8 
 3 files changed, 1 insertions(+), 51 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 01c2cf4..cc27322 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -247,8 +247,7 @@ static int amba_pm_restore(struct device *dev)
 /*
  * Hooks to provide runtime PM of the pclk (bus clock).  It is safe to
  * enable/disable the bus clock at runtime PM suspend/resume as this
- * does not result in loss of context.  However, disabling vcore power
- * would do, so we leave that to the driver.
+ * does not result in loss of context.
  */
 static int amba_pm_runtime_suspend(struct device *dev)
 {
@@ -354,39 +353,6 @@ static void amba_put_disable_pclk(struct amba_device 
*pcdev)
clk_put(pclk);
 }
 
-static int amba_get_enable_vcore(struct amba_device *pcdev)
-{
-   struct regulator *vcore = regulator_get(&pcdev->dev, "vcore");
-   int ret;
-
-   pcdev->vcore = vcore;
-
-   if (IS_ERR(vcore)) {
-   /* It is OK not to supply a vcore regulator */
-   if (PTR_ERR(vcore) == -ENODEV)
-   return 0;
-   return PTR_ERR(vcore);
-   }
-
-   ret = regulator_enable(vcore);
-   if (ret) {
-   regulator_put(vcore);
-   pcdev->vcore = ERR_PTR(-ENODEV);
-   }
-
-   return ret;
-}
-
-static void amba_put_disable_vcore(struct amba_device *pcdev)
-{
-   struct regulator *vcore = pcdev->vcore;
-
-   if (!IS_ERR(vcore)) {
-   regulator_disable(vcore);
-   regulator_put(vcore);
-   }
-}
-
 /*
  * These are the device model conversion veneers; they convert the
  * device model structures to our more specific structures.
@@ -399,10 +365,6 @@ static int amba_probe(struct device *dev)
int ret;
 
do {
-   ret = amba_get_enable_vcore(pcdev);
-   if (ret)
-   break;
-
ret = amba_get_enable_pclk(pcdev);
if (ret)
break;
@@ -420,7 +382,6 @@ static int amba_probe(struct device *dev)
pm_runtime_put_noidle(dev);
 
amba_put_disable_pclk(pcdev);
-   amba_put_disable_vcore(pcdev);
} while (0);
 
return ret;
@@ -442,7 +403,6 @@ static int amba_remove(struct device *dev)
pm_runtime_put_noidle(dev);
 
amba_put_disable_pclk(pcdev);
-   amba_put_disable_vcore(pcdev);
 
return ret;
 }
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 96f0da6..09c925a 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2195,7 +2195,6 @@ static int pl022_runtime_suspend(struct device *dev)
struct pl022 *pl022 = dev_get_drvdata(dev);
 
clk_disable(pl022->clk);
-   amba_vcore_disable(pl022->adev);
 
return 0;
 }
@@ -2204,7 +2203,6 @@ static int pl022_runtime_resume(struct device *dev)
 {
struct pl022 *pl022 = dev_get_drvdata(dev);
 
-   amba_vcore_enable(pl022->adev);
clk_enable(pl022->clk);
 
return 0;
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 7847e19..63a59ac 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define AMBA_NR_IRQS   2
 #define AMBA_CID   0xb105f00d
@@ -30,7 +29,6 @@ struct amba_device {
struct device   dev;
struct resource res;
struct clk  *pclk;
-   struct regulator*vcore;
u64 dma_mask;
unsigned intperiphid;
unsigned intirq[AMBA_NR_IRQS];
@@ -75,12 +73,6 @@ void amba_release_regions(struct amba_device *);
 #define amba_pclk_disable(d)   \
do { if (!IS_ERR((d)->pclk)) clk_disable((d)->pclk); } while (0)
 
-#define amba_vcore_enable(d)   \
-   (IS_ERR((d)->vcore) ? 0 : regulator_enable((d)->vcore))
-
-#define amba_vcore_disable(d)  \
-   

[PATCH/RFC v2] ARM: amba: Remove AMBA level regulator support

[Mark Brown]

The AMBA bus regulator support is being used to model on/off switches
for power domains which isn't terribly idiomatic for modern kernels with
the generic power domain code and creates integration problems on platforms
which don't use regulators for their power domains as it's hard to tell
the difference between a regulator that is needed but failed to be provided
and one that isn't supposed to be there (though DT does make that easier).

Platforms that wish to use the regulator API to manage their power domains
can indirect via the power domain interface.

This feature is only used with the vape supply of the db8500 PRCMU
driver which supplies the UARTs and MMC controllers, none of which have
support for managing vcore at runtime in mainline (only pl022 SPI
controller does).  Update that supply to have an always_on constraint
until the power domain support for the system is updated so that it is
enabled for these users, this is likely to have no impact on practical
systems as probably at least one of these devices will be active and
cause AMBA to hold the supply on anyway.

Signed-off-by: Mark Brown 
---

Updated to add the always_on constraint for db8500-prcmu as discussed in
the changelog.

 drivers/amba/bus.c |   42 +-
 drivers/mfd/db8500-prcmu.c |1 +
 drivers/spi/spi-pl022.c|2 --
 include/linux/amba/bus.h   |8 
 4 files changed, 2 insertions(+), 51 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 01c2cf4..cc27322 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -247,8 +247,7 @@ static int amba_pm_restore(struct device *dev)
 /*
  * Hooks to provide runtime PM of the pclk (bus clock).  It is safe to
  * enable/disable the bus clock at runtime PM suspend/resume as this
- * does not result in loss of context.  However, disabling vcore power
- * would do, so we leave that to the driver.
+ * does not result in loss of context.
  */
 static int amba_pm_runtime_suspend(struct device *dev)
 {
@@ -354,39 +353,6 @@ static void amba_put_disable_pclk(struct amba_device 
*pcdev)
clk_put(pclk);
 }
 
-static int amba_get_enable_vcore(struct amba_device *pcdev)
-{
-   struct regulator *vcore = regulator_get(&pcdev->dev, "vcore");
-   int ret;
-
-   pcdev->vcore = vcore;
-
-   if (IS_ERR(vcore)) {
-   /* It is OK not to supply a vcore regulator */
-   if (PTR_ERR(vcore) == -ENODEV)
-   return 0;
-   return PTR_ERR(vcore);
-   }
-
-   ret = regulator_enable(vcore);
-   if (ret) {
-   regulator_put(vcore);
-   pcdev->vcore = ERR_PTR(-ENODEV);
-   }
-
-   return ret;
-}
-
-static void amba_put_disable_vcore(struct amba_device *pcdev)
-{
-   struct regulator *vcore = pcdev->vcore;
-
-   if (!IS_ERR(vcore)) {
-   regulator_disable(vcore);
-   regulator_put(vcore);
-   }
-}
-
 /*
  * These are the device model conversion veneers; they convert the
  * device model structures to our more specific structures.
@@ -399,10 +365,6 @@ static int amba_probe(struct device *dev)
int ret;
 
do {
-   ret = amba_get_enable_vcore(pcdev);
-   if (ret)
-   break;
-
ret = amba_get_enable_pclk(pcdev);
if (ret)
break;
@@ -420,7 +382,6 @@ static int amba_probe(struct device *dev)
pm_runtime_put_noidle(dev);
 
amba_put_disable_pclk(pcdev);
-   amba_put_disable_vcore(pcdev);
} while (0);
 
return ret;
@@ -442,7 +403,6 @@ static int amba_remove(struct device *dev)
pm_runtime_put_noidle(dev);
 
amba_put_disable_pclk(pcdev);
-   amba_put_disable_vcore(pcdev);
 
return ret;
 }
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index ebc1e86..5be3248 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -2788,6 +2788,7 @@ static struct regulator_init_data 
db8500_regulators[DB8500_NUM_REGULATORS] = {
.constraints = {
.name = "db8500-vape",
.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   .always_on = true,
},
.consumer_supplies = db8500_vape_consumers,
.num_consumer_supplies = ARRAY_SIZE(db8500_vape_consumers),
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 96f0da6..09c925a 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2195,7 +2195,6 @@ static int pl022_runtime_suspend(struct device *dev)
struct pl022 *pl022 = dev_get_drvdata(dev);
 
clk_disable(pl022->clk);
-   amba_vcore_disable(pl022->adev);
 
return 0;
 }
@@ -2204,7 +2203,6 @@ static int pl022_runtime_resume(struct dev

Re: [PATCH v5 2/4] mfd: mc13xxx-core: use regmap for register access

[Mark Brown]

On Sun, Apr 01, 2012 at 04:41:37PM +1000, Marc Reilly wrote:
> This change converts the mc13xxx core to use regmap rather than direct
> spi r/w.
> The spidev member of mc13xxx struct becomes redundant and is removed.
> Extra debugging aids are added to mc13xxx_reg_rmw.

To repeat what I've said on previous versions please push this down into
regmap.  There's already extensive diagnostic features there, let's not
have people open coding things that are missing.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 10/10] spi: s3c64xx: add device tree support

[Mark Brown]

On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:

> +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no
> +  particular order). The format of the gpio specifier depends on the gpio
> +  controller.

This seems odd...  This isn't a bitbanging controller, and surely the
driver will need to know which signal is which?  I suspect this is
actually for pinmux rather than to identify the signals but that should
at least be made clear and really should be being done using the pinmux
API.

> +  - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used 
> as
> +the slave select line by the spi controller. The format of the gpio
> +specifier depends on the gpio controller.

We should really have a binding for this at the SPI level (and ideally
some code to manage setting the GPIO too) - it's pretty common to use a
GPIO as /CS.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 06/10] ARM: Samsung: Modify s3c64xx_spi{0|1|2}_set_platdata function

[Mark Brown]

On Wed, May 09, 2012 at 03:34:50AM +0530, Thomas Abraham wrote:

> + s3c64xx_spi0_set_platdata("s3c6410-spi", NULL, 0, 1);

Shouldn't we just set the name in the struct platform_device rather than
requiring the machine to pass it through by hand?

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 05/10] ARM: Samsung: Update the device names for spi clock lookup

[Mark Brown]

On Wed, May 09, 2012 at 03:34:49AM +0530, Thomas Abraham wrote:
> With the addition of platform specific driver data in the spi-s3c64xx
> driver, the device name of spi controllers are changed. Accordingly,
> update the device name of spi clocks instances.

This should've been squashed into the patch that updated to use driver
data in order to avoid breaking bisection.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 1/2] spi/s3c64xx: Convert to devm_request_and_ioremap()

[Mark Brown]

Saves some error handling and a small amount of code.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index f4e2341..b7aeb5d 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1028,19 +1028,7 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
/* the spi->mode bits understood by this driver: */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
 
-   if (request_mem_region(mem_res->start,
-   resource_size(mem_res), pdev->name) == NULL) {
-   dev_err(&pdev->dev, "Req mem region failed\n");
-   ret = -ENXIO;
-   goto err0;
-   }
-
-   sdd->regs = ioremap(mem_res->start, resource_size(mem_res));
-   if (sdd->regs == NULL) {
-   dev_err(&pdev->dev, "Unable to remap IO\n");
-   ret = -ENXIO;
-   goto err1;
-   }
+   sdd->regs = devm_request_and_ioremap(&pdev->dev, mem_res);
 
if (sci->cfg_gpio == NULL || sci->cfg_gpio(pdev)) {
dev_err(&pdev->dev, "Unable to config gpio\n");
@@ -1124,10 +1112,6 @@ err4:
clk_put(sdd->clk);
 err3:
 err2:
-   iounmap((void *) sdd->regs);
-err1:
-   release_mem_region(mem_res->start, resource_size(mem_res));
-err0:
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
 
@@ -1138,7 +1122,6 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 {
struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-   struct resource *mem_res;
 
pm_runtime_disable(&pdev->dev);
 
@@ -1154,12 +1137,6 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
clk_disable(sdd->clk);
clk_put(sdd->clk);
 
-   iounmap((void *) sdd->regs);
-
-   mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (mem_res != NULL)
-   release_mem_region(mem_res->start, resource_size(mem_res));
-
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
 
-- 
1.7.10


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 2/2] spi/s3c64xx: Expand S3C64XX_SPI_{DE, }ACT macros at call sites

[Mark Brown]

They have very few users and they're both just doing a single register
write so the advantage of having the macro is a bit limited. An inline
function might make sense but it's as easy to just do the writes directly.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index b7aeb5d..3514ef9 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -74,11 +74,6 @@
 #define S3C64XX_SPI_SLAVE_AUTO (1<<1)
 #define S3C64XX_SPI_SLAVE_SIG_INACT(1<<0)
 
-#define S3C64XX_SPI_ACT(c) writel(0, (c)->regs + S3C64XX_SPI_SLAVE_SEL)
-
-#define S3C64XX_SPI_DEACT(c) writel(S3C64XX_SPI_SLAVE_SIG_INACT, \
-   (c)->regs + S3C64XX_SPI_SLAVE_SEL)
-
 #define S3C64XX_SPI_INT_TRAILING_EN(1<<6)
 #define S3C64XX_SPI_INT_RX_OVERRUN_EN  (1<<5)
 #define S3C64XX_SPI_INT_RX_UNDERRUN_EN (1<<4)
@@ -712,14 +707,15 @@ static int s3c64xx_spi_transfer_one_message(struct 
spi_master *master,
enable_cs(sdd, spi);
 
/* Start the signals */
-   S3C64XX_SPI_ACT(sdd);
+   writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
spin_unlock_irqrestore(&sdd->lock, flags);
 
status = wait_for_xfer(sdd, xfer, use_dma);
 
/* Quiese the signals */
-   S3C64XX_SPI_DEACT(sdd);
+   writel(S3C64XX_SPI_SLAVE_SIG_INACT,
+  sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
if (status) {
dev_err(&spi->dev, "I/O Error: "
@@ -923,7 +919,7 @@ static void s3c64xx_spi_hwinit(struct 
s3c64xx_spi_driver_data *sdd, int channel)
 
sdd->cur_speed = 0;
 
-   S3C64XX_SPI_DEACT(sdd);
+   writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
/* Disable Interrupts - we use Polling if not DMA mode */
writel(0, regs + S3C64XX_SPI_INT_EN);
-- 
1.7.10


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 1/2] spi/s3c64xx: Convert to devm_request_and_ioremap()

[Mark Brown]

Saves some error handling and a small amount of code.

Signed-off-by: Mark Brown 
Acked-by: Linus Walleij 
---
 drivers/spi/spi-s3c64xx.c |   25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index f4e2341..b7aeb5d 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1028,19 +1028,7 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
/* the spi->mode bits understood by this driver: */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
 
-   if (request_mem_region(mem_res->start,
-   resource_size(mem_res), pdev->name) == NULL) {
-   dev_err(&pdev->dev, "Req mem region failed\n");
-   ret = -ENXIO;
-   goto err0;
-   }
-
-   sdd->regs = ioremap(mem_res->start, resource_size(mem_res));
-   if (sdd->regs == NULL) {
-   dev_err(&pdev->dev, "Unable to remap IO\n");
-   ret = -ENXIO;
-   goto err1;
-   }
+   sdd->regs = devm_request_and_ioremap(&pdev->dev, mem_res);
 
if (sci->cfg_gpio == NULL || sci->cfg_gpio(pdev)) {
dev_err(&pdev->dev, "Unable to config gpio\n");
@@ -1124,10 +1112,6 @@ err4:
clk_put(sdd->clk);
 err3:
 err2:
-   iounmap((void *) sdd->regs);
-err1:
-   release_mem_region(mem_res->start, resource_size(mem_res));
-err0:
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
 
@@ -1138,7 +1122,6 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 {
struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-   struct resource *mem_res;
 
pm_runtime_disable(&pdev->dev);
 
@@ -1154,12 +1137,6 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
clk_disable(sdd->clk);
clk_put(sdd->clk);
 
-   iounmap((void *) sdd->regs);
-
-   mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (mem_res != NULL)
-   release_mem_region(mem_res->start, resource_size(mem_res));
-
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
 
-- 
1.7.10


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 2/2] spi/s3c64xx: Expand S3C64XX_SPI_{DE, }ACT macros at call sites

[Mark Brown]

They have very few users and they're both just doing a single register
write so the advantage of having the macro is a bit limited. An inline
function might make sense but it's as easy to just do the writes directly.

Signed-off-by: Mark Brown 
Acked-by: Linus Walleij 
---
 drivers/spi/spi-s3c64xx.c |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index b7aeb5d..3514ef9 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -74,11 +74,6 @@
 #define S3C64XX_SPI_SLAVE_AUTO (1<<1)
 #define S3C64XX_SPI_SLAVE_SIG_INACT(1<<0)
 
-#define S3C64XX_SPI_ACT(c) writel(0, (c)->regs + S3C64XX_SPI_SLAVE_SEL)
-
-#define S3C64XX_SPI_DEACT(c) writel(S3C64XX_SPI_SLAVE_SIG_INACT, \
-   (c)->regs + S3C64XX_SPI_SLAVE_SEL)
-
 #define S3C64XX_SPI_INT_TRAILING_EN(1<<6)
 #define S3C64XX_SPI_INT_RX_OVERRUN_EN  (1<<5)
 #define S3C64XX_SPI_INT_RX_UNDERRUN_EN (1<<4)
@@ -712,14 +707,15 @@ static int s3c64xx_spi_transfer_one_message(struct 
spi_master *master,
enable_cs(sdd, spi);
 
/* Start the signals */
-   S3C64XX_SPI_ACT(sdd);
+   writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
spin_unlock_irqrestore(&sdd->lock, flags);
 
status = wait_for_xfer(sdd, xfer, use_dma);
 
/* Quiese the signals */
-   S3C64XX_SPI_DEACT(sdd);
+   writel(S3C64XX_SPI_SLAVE_SIG_INACT,
+  sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
if (status) {
dev_err(&spi->dev, "I/O Error: "
@@ -923,7 +919,7 @@ static void s3c64xx_spi_hwinit(struct 
s3c64xx_spi_driver_data *sdd, int channel)
 
sdd->cur_speed = 0;
 
-   S3C64XX_SPI_DEACT(sdd);
+   writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
/* Disable Interrupts - we use Polling if not DMA mode */
writel(0, regs + S3C64XX_SPI_INT_EN);
-- 
1.7.10


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[spi-devel-general] [PATCH 1/2] spi/spi_s3c64xx: Make probe more robust against missing board config

[Mark Brown]

The S3C64xx SPI driver requires the machine to call s3c64xx_spi_set_info()
to select a few options, including the clock to use for the SPI controller.
If this is not done then a NULL will be passed as the clock name for
clk_get(), causing an obscure crash. Guard against this and other missing
configuration by validating that the clock name has been filled in in
the platform data that ets passed in.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi_s3c64xx.c |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 9736581..a0b63b7 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -919,6 +919,13 @@ static int __init s3c64xx_spi_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
+   sci = pdev->dev.platform_data;
+   if (!sci->src_clk_name) {
+   dev_err(&pdev->dev,
+   "Board init must call s3c64xx_spi_set_info()\n");
+   return -EINVAL;
+   }
+
/* Check for availability of necessary resource */
 
dmatx_res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
@@ -946,8 +953,6 @@ static int __init s3c64xx_spi_probe(struct platform_device 
*pdev)
return -ENOMEM;
}
 
-   sci = pdev->dev.platform_data;
-
platform_set_drvdata(pdev, master);
 
sdd = spi_master_get_devdata(master);
-- 
1.7.1


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[spi-devel-general] [PATCH 2/2] spi/spi_s3c64xx: Staticise non-exported functions

[Mark Brown]

Signed-off-by: Mark Brown 
---
 drivers/spi/spi_s3c64xx.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index a0b63b7..7e627f7 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -447,8 +447,8 @@ static void s3c64xx_spi_config(struct 
s3c64xx_spi_driver_data *sdd)
writel(val, regs + S3C64XX_SPI_CLK_CFG);
 }
 
-void s3c64xx_spi_dma_rxcb(struct s3c2410_dma_chan *chan, void *buf_id,
-   int size, enum s3c2410_dma_buffresult res)
+static void s3c64xx_spi_dma_rxcb(struct s3c2410_dma_chan *chan, void *buf_id,
+int size, enum s3c2410_dma_buffresult res)
 {
struct s3c64xx_spi_driver_data *sdd = buf_id;
unsigned long flags;
@@ -467,8 +467,8 @@ void s3c64xx_spi_dma_rxcb(struct s3c2410_dma_chan *chan, 
void *buf_id,
spin_unlock_irqrestore(&sdd->lock, flags);
 }
 
-void s3c64xx_spi_dma_txcb(struct s3c2410_dma_chan *chan, void *buf_id,
-   int size, enum s3c2410_dma_buffresult res)
+static void s3c64xx_spi_dma_txcb(struct s3c2410_dma_chan *chan, void *buf_id,
+int size, enum s3c2410_dma_buffresult res)
 {
struct s3c64xx_spi_driver_data *sdd = buf_id;
unsigned long flags;
-- 
1.7.1


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [spi-devel-general] [PATCH 1/2] spi/spi_s3c64xx: Make probe more robust against missing board config

[Mark Brown]

On Sat, Aug 21, 2010 at 10:45:56AM +0900, Jassi Brar wrote:
> On Sat, Aug 21, 2010 at 1:17 AM, Mark Brown
>  wrote:
> > The S3C64xx SPI driver requires the machine to call s3c64xx_spi_set_info()
> > to select a few options, including the clock to use for the SPI controller.
> > If this is not done then a NULL will be passed as the clock name for
> > clk_get(), causing an obscure crash. Guard against this and other missing
> > configuration by validating that the clock name has been filled in in
> > the platform data that ets passed in.

>  The movement of sci assignment and check doesn't make any
> difference because
>   we already check for presence of platform_data and DMA-Tx,Rx and
> IO base is
>   set irrespective of calling s3c64xx_spi_set_info()

While it does check for those things for at least the 6410 they're all
unconditionally set up by dev-spi.c so the tests all pass and we make it
down into to the clk_get() which then falls over horribly.

> Also, I think !sci->num_cs might be an even better check because
> the samsung clock
>api might be changed (IIRC Ben was already working it out) to make
> it redundant
>to pass clock name strings to clk_get. If that is the case, we might end up
>adding another foolproof check like !sci->num_cs

The problem with num_cs is that it gets interpreted by a custom function
provided by the board driver so we really can't say anything about what
it does.  If the clock API gets enhanced then we can always cope with
things then, but given the pace of development there I'd expect that
we'd need to continue checking for a while.

TBH I'm a bit surprised that the driver has to do custom stuff to
support gpiolib chip selects - my first thought when I saw that stuff
was that it seemed like something that lots of SPI controllers would be
able to share but I didn't look at the overall SPI code for long enough
to figure out what was going on there.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [spi-devel-general] [PATCH 1/2] spi/spi_s3c64xx: Make probe more robust against missing board config

[Mark Brown]

On Sat, Aug 21, 2010 at 10:58:36PM +0900, Jassi Brar wrote:
> On Sat, Aug 21, 2010 at 7:08 PM, Mark Brown
> > On Sat, Aug 21, 2010 at 10:45:56AM +0900, Jassi Brar wrote:

> >>      The movement of sci assignment and check doesn't make any
> >> difference because
> >>       we already check for presence of platform_data and DMA-Tx,Rx and
> >> IO base is
> >>       set irrespective of calling s3c64xx_spi_set_info()

> > While it does check for those things for at least the 6410 they're all
> > unconditionally set up by dev-spi.c so the tests all pass and we make it
> > down into to the clk_get() which then falls over horribly.

> Those parameters are SoC specific and hence will be always available to
> platform devices.
> Clock selection and num_cs(number of slaves attached to the SPI bus) are
> machine specific and hence responsibility of the machine developer to
> set appropriately via s3c64xx_spi_set_info()

Sure, the split does make sense - it's just that this means that we need
to do something to make sure that s3c64xx_spi_set_info() got called.

> > The problem with num_cs is that it gets interpreted by a custom function
> > provided by the board driver so we really can't say anything about what
> > it does.

> num_cs is passed on as such to the SPI core to master->num_chipselect
> which is strictly checked for before a master is created.

Ah, too many variables with similar functions.

> > support gpiolib chip selects - my first thought when I saw that stuff
> > was that it seemed like something that lots of SPI controllers would be
> > able to share but I didn't look at the overall SPI code for long enough
> > to figure out what was going on there.

> we have common spi bitbanging driver that takes only four gpio pins
> and work like a charm.

Though it does burn CPU rather a lot which makes them unsuitable for
some applications where SPI is used for bulk data transfers or CPU is
otherwise tight.  In general if you've got an actual SPI controller it's
much nicer to use it.

> In order to enable users use multiple CS per master, in spi_s3c64xx.c
> the single CS feature provided by the controller is deliberately left unused
> and the driver accepts a gpio per slave and manually controls it. Though
> the callbacks and arguments are designed so that a simple gpio number
> and gpio_set can be assigned by the machine code.

It did occur to me that a nice way of dealing with this would be to have
the driver default to using the built in chip select (even if driven as
a GPIO for the sake of code simplicity) but leave the current method
there as an override.  That way if people are using the IP block in the
"natural" manner they'd have less to set up.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [spi-devel-general] [PATCH 1/2] spi/spi_s3c64xx: Make probe more robust against missing board config

[Mark Brown]

On Sun, Aug 22, 2010 at 12:37:25PM +0900, Jassi Brar wrote:

> An immediate kernel crash ? :)
> I mean if the developer didn't even run-check the board init code, he ought
> to face a kernel crash.
> On a more lenient note, probably a check like yours or !sci->num_cs
> could be added.

I'd personally not actually be that upset with a BUG_ON(), my main
reason for changing the code was that it was non-obvious what the source
of the error was rather than the fact that things fell over.

> > It did occur to me that a nice way of dealing with this would be to have
> > the driver default to using the built in chip select (even if driven as
> > a GPIO for the sake of code simplicity) but leave the current method
> > there as an override.  That way if people are using the IP block in the
> > "natural" manner they'd have less to set up.

> I thought about it but decided against it, for that would complicate the
> driver by having to switch between two mechanism in runtime and there
> are some peculiarities in the controller about clocking and CS'ing.

Yeah, that's why I suggested driving it as a GPIO for simplicity - from
the user point of view it doesn't matter if that's what the controller
does so long as the driver figures out the chip select without external
help.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[spi-devel-general] [PATCH] spi/spi_s3c64xx: Warn if PIO transfers time out

[Mark Brown]

When using PIO we have a timeout for the TX and RX FIFOs to ensure that
the data actually gets transferred. Warn if we hit that timeout - it
should never happen, but this makes sure we'll find out if it does.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi_s3c64xx.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 7e627f7..f72e1c0 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -200,6 +200,9 @@ static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
val = readl(regs + S3C64XX_SPI_STATUS);
} while (TX_FIFO_LVL(val, sci) && loops--);
 
+   if (loops == 0)
+   dev_warn(&sdd->pdev->dev, "Timed out flushing TX FIFO\n");
+
/* Flush RxFIFO*/
loops = msecs_to_loops(1);
do {
@@ -210,6 +213,9 @@ static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
break;
} while (loops--);
 
+   if (loops == 0)
+   dev_warn(&sdd->pdev->dev, "Timed out flushing RX FIFO\n");
+
val = readl(regs + S3C64XX_SPI_CH_CFG);
val &= ~S3C64XX_SPI_CH_SW_RST;
writel(val, regs + S3C64XX_SPI_CH_CFG);
-- 
1.7.1


--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi/spi_s3c64xx: Move to subsys_initcall()

[Mark Brown]

Allow the use of the S3C64xx SPI controller with things like PMICs by
moving the init up to subsys_initcall().

Signed-off-by: Mark Brown 
---

Incidentally I don't seem to see anything in the current SPI tree for
-next - should the tree being used be updated or something?

 drivers/spi/spi_s3c64xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index f72e1c0..6e48ea9 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -1181,7 +1181,7 @@ static int __init s3c64xx_spi_init(void)
 {
return platform_driver_probe(&s3c64xx_spi_driver, s3c64xx_spi_probe);
 }
-module_init(s3c64xx_spi_init);
+subsys_initcall(s3c64xx_spi_init);
 
 static void __exit s3c64xx_spi_exit(void)
 {
-- 
1.7.1


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 1/2] spi/spi_s3c64xx: Fix timeout handling in wait_for_xfer()

[Mark Brown]

In wait_for_xfer() for PIO transfer we are using val as both a
counter variable to track the number of spins we've waited for
completion and the value we read from the controller, causing
us to fail to ever actually notice the timeout. Fix this by using
a separate value to hold the register readback.

Also warn when we hit the timeout.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi_s3c64xx.c |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 6e48ea9..03b28e4 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -321,7 +321,7 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data 
*sdd,
 {
struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
void __iomem *regs = sdd->regs;
-   unsigned long val;
+   unsigned long val, reg;
int ms;
 
/* millisecs to xfer 'len' bytes @ 'cur_speed' */
@@ -333,13 +333,16 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data 
*sdd,
val = wait_for_completion_timeout(&sdd->xfer_completion, val);
} else {
val = msecs_to_loops(ms);
+
do {
-   val = readl(regs + S3C64XX_SPI_STATUS);
-   } while (RX_FIFO_LVL(val, sci) < xfer->len && --val);
+   reg = readl(regs + S3C64XX_SPI_STATUS);
+   } while (RX_FIFO_LVL(reg, sci) < xfer->len && --val);
}
 
-   if (!val)
+   if (!val) {
+   dev_warn(&sdd->pdev->dev, "Transfer timeout\n");
return -EIO;
+   }
 
if (dma_mode) {
u32 status;
-- 
1.7.1


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 2/2] spi/spi_s3c64xx: Increase dead reckoning time in wait_for_xfer()

[Mark Brown]

For small transfers at high speeds the expected transfer time can easily
be well under 1ms, causing the delay in wait_for_xfer() to be only the
dead reckoning fudge factor of 5ms currently included. Experiments on
some of my systems shows that this is marginal for some transfers so
double it to 10ms.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi_s3c64xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 03b28e4..4abb441 100644
--- a/drivers/spi/spi_s3c64xx.c
+++ b/drivers/spi/spi_s3c64xx.c
@@ -326,7 +326,7 @@ static int wait_for_xfer(struct s3c64xx_spi_driver_data 
*sdd,
 
/* millisecs to xfer 'len' bytes @ 'cur_speed' */
ms = xfer->len * 8 * 1000 / sdd->cur_speed;
-   ms += 5; /* some tolerance */
+   ms += 10; /* some tolerance */
 
if (dma_mode) {
val = msecs_to_jiffies(ms) + 10;
-- 
1.7.1


--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/2] spi/spi_s3c64xx: Fix timeout handling in wait_for_xfer()

[Mark Brown]

On Wed, Sep 08, 2010 at 10:11:59AM +0900, Jassi Brar wrote:

> I have already submitted a patch a few days ago
> https://patchwork.kernel.org/patch/151941/
> (It's strange that Grant's id isn't there in the CC list, despite my writing 
> it)

Ah, excellent.  Now I see patchwork there look to be some other things
sitting in patchwork which might be handy for me as well.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi_s3c64xx: Move to subsys_initcall()

[Mark Brown]

On Wed, Sep 08, 2010 at 01:55:39PM +0900, Jassi Brar wrote:
> On Tue, Sep 7, 2010 at 7:29 PM, Mark Brown
>  wrote:
> > Allow the use of the S3C64xx SPI controller with things like PMICs by
> > moving the init up to subsys_initcall().

> Couldn't any user ever need to load it as a module?
> If no, we might as well drop the s3c64xx_spi_exit and s3c64xx_spi_remove

This doesn't prevent building as a module - when built as a module
subsys_initcall() is identical to module_init(), the change will only
affect the order in which things are done when the code is built into
the kernel otherwise it's a noop.

> as well and save space. Rather going a step further, shouldn't then all
> spi drivers be that way? Two steps further, why not every 'bus-driver' ?

Yes, we probably do need to do the same thing for all embedded SPI
controllers (as has already happened with embedded I2C controllers),
though it's less pressing since outside of a few CPUs it's much less
common for things like PMICs to be on SPI than I2C.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi_s3c64xx: Move to subsys_initcall()

[Mark Brown]

On Wed, Sep 08, 2010 at 10:12:45AM -0600, Grant Likely wrote:

[reflowed into 80 columns]

> ... but it seems to me that there is a systemic problem in the way the
> driver model is being used if SPI (and I2C) bus drivers need to be
> 'special' in this regard.  What are the ordering requirements on things
> like PMICs?  (My uneducated assumption is that other devices depend on
> them being enabled before being probed.)  Would it be better to have a

Pretty much this, yes - if you might want to turn on your supplies
when you're probed it's rather helpful if the subsystem needed to
control the regulators is available when you probe.

> mechanism to defer probing on certain devices until other devices are
> probed?  Then the relationships could be made explicit instead of the
> rather coarse-grained (and potentially fragile) approach of changing the
> init order.

That would be much nicer (and this is far from the only case where we
need to deal with it) but it's a substantial change to core kernel
infrastructure so it's being worked around like this.  Given how all the
discussions about sorting and dependencies for suspend and resume went
it might be an uphill struggle to do much more, especially while we are
able to continue to deal with things fairly easily using the current
infrastructure.

Doing dependencies could get pretty complicated, especially once you
handle optional dependencies ("is this missing because it didn't probe
yet or because it's just not there?") so it's not entirely clear to me
that it's worth the hassle.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/spi_s3c64xx: Move to subsys_initcall()

[Mark Brown]

On Wed, Sep 08, 2010 at 10:44:32AM -0600, Grant Likely wrote:
> On Wed, Sep 08, 2010 at 05:22:51PM +0100, Mark Brown wrote:

> > Doing dependencies could get pretty complicated, especially once you
> > handle optional dependencies ("is this missing because it didn't probe
> > yet or because it's just not there?") so it's not entirely clear to me
> > that it's worth the hassle.

> I think it might be doable.  I had a similar problem with Ethernet
> MACs and PHYs where the PHY was on a completely separate bus from the
> MAC with zero guarantees on probe order.  I had some code that made it
> simple to use a bus notifier to defer MAC initialization until the
> required phy turned up and was probed.  I eventually abandoned it
> because accessing the PHY could be deferred until .ndo_open() time.
> However, it would be easy to resurrect, and might be a reasonable
> solution.  At the very least it is worth an investigation.

If you've got stuff that'd be great - ASoC also has a deferral mechanism
implemented due to this song and dance.  Like I say, the main reason
I've never looked at it myself is that it's never been sufficiently much
of a practical problem for me to justify the effort.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH] spi/s3c64xx: Convert to devm_request_and_ioremap()

[Mark Brown]

Saves some error handling and a small amount of code.

Signed-off-by: Mark Brown 
Acked-by: Linus Walleij 
---
 drivers/spi/spi-s3c64xx.c |   19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index f4e2341..f62c13e 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1028,14 +1028,7 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
/* the spi->mode bits understood by this driver: */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
 
-   if (request_mem_region(mem_res->start,
-   resource_size(mem_res), pdev->name) == NULL) {
-   dev_err(&pdev->dev, "Req mem region failed\n");
-   ret = -ENXIO;
-   goto err0;
-   }
-
-   sdd->regs = ioremap(mem_res->start, resource_size(mem_res));
+   sdd->regs = devm_request_and_ioremap(&pdev->dev, mem_res);
if (sdd->regs == NULL) {
dev_err(&pdev->dev, "Unable to remap IO\n");
ret = -ENXIO;
@@ -1124,10 +1117,7 @@ err4:
clk_put(sdd->clk);
 err3:
 err2:
-   iounmap((void *) sdd->regs);
 err1:
-   release_mem_region(mem_res->start, resource_size(mem_res));
-err0:
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
 
@@ -1138,7 +1128,6 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 {
struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-   struct resource *mem_res;
 
pm_runtime_disable(&pdev->dev);
 
@@ -1154,12 +1143,6 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
clk_disable(sdd->clk);
clk_put(sdd->clk);
 
-   iounmap((void *) sdd->regs);
-
-   mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (mem_res != NULL)
-   release_mem_region(mem_res->start, resource_size(mem_res));
-
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
 
-- 
1.7.10


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH RFC] spi/gpio: start with CS non-active

[Mark Brown]

On Thu, Jul 05, 2012 at 09:45:40AM +0200, Uwe Kleine-K?nig wrote:
> On Thu, Feb 09, 2012 at 10:21:45PM +0100, Uwe Kleine-K?nig wrote:
> > The chip select line was configured as output with the initial value
> > being active explicitly. It was later deasserted during
> > spi_bitbang_setup() without any clock activity in between. So it makes
> > no sense to activate the device at all and the chip select line can
> > better start non-active.
> > 
> > Signed-off-by: Uwe Kleine-K?nig 
> > ---
> > Hello,
> > 
> > I'm not sure if an active chip select line without any clock activity can
> > confuse a device. If so, this patch might qualify as fix. But with my
> > limited knowledge about spi it's also possible that I just miss why the
> > active chip select is important. For the devices I have it doesn't seem
> > to make a difference.
> ping

You probably want to resend this with Linus W in the CCs.

> 
> > 
> > Best regards
> > Uwe
> > 
> >  drivers/spi/spi-gpio.c |3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
> > index 0094c64..0b56cfc 100644
> > --- a/drivers/spi/spi-gpio.c
> > +++ b/drivers/spi/spi-gpio.c
> > @@ -235,7 +235,8 @@ static int spi_gpio_setup(struct spi_device *spi)
> > status = gpio_request(cs, dev_name(&spi->dev));
> > if (status)
> > return status;
> > -   status = gpio_direction_output(cs, spi->mode & 
> > SPI_CS_HIGH);
> > +   status = gpio_direction_output(cs,
> > +   !(spi->mode & SPI_CS_HIGH));
> > }
> > }
> > if (!status)
> > -- 
> > 1.7.9
> > 
> > 
> 
> -- 
> Pengutronix e.K.   | Uwe Kleine-K?nig|
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> 
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> spi-devel-general mailing list
> spi-devel-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/spi-devel-general
> 

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH v4 5/6] spi: s3c64xx: Remove the 'set_level' callback from controller data

[Mark Brown]

On Tue, Jul 10, 2012 at 07:57:38PM +0530, Thomas Abraham wrote:
> The set_level callback in the controller data, which is used to configure
> the slave select line, cannot be supported when migrating the driver to
> device tree based discovery. Since all the platforms currently use gpio
> as the slave select line, this callback can be removed from the
> controller data and replaced with call to gpio_set_value in the driver.

This is currently buggy, BTW, as the driver never requests the GPIO.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 00/10] MXS SPI driver

[Mark Brown]

On Mon, Jul 16, 2012 at 02:09:47PM +0200, Marek Vasut wrote:
> This patchset adds SPI master support for Freescale i.MX233/i.MX28.
> This is rebased on top of next-20120713. Please consider applying,
> bugs shall now be squashed during the previous two review rounds.

Always CC maintainers, and in this case me as well (I'm collecting SPI
patches for this release since Grant's mostly offline).

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 00/10] MXS SPI driver

[Mark Brown]

On Wed, Jul 18, 2012 at 12:09:54AM +0200, Marek Vasut wrote:
> > On Mon, Jul 16, 2012 at 02:09:47PM +0200, Marek Vasut wrote:

> > Always CC maintainers, and in this case me as well (I'm collecting SPI
> > patches for this release since Grant's mostly offline).

> Ah, I wasn't aware you're the SPI maintainer now. Sorry about that. Will do 
> if 
> there's a rework requested.

I'm not, I'm just looking after things for this release (until Grant's
finished moving house and attending conferences).

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 4/4] spi/s3c64xx: Expand S3C64XX_SPI_{DE, }ACT macros at call sites

[Mark Brown]

They have very few users and they're both just doing a single register
write so the advantage of having the macro is a bit limited. An inline
function might make sense but it's as easy to just do the writes directly.

Signed-off-by: Mark Brown 
Acked-by: Linus Walleij 
---
 drivers/spi/spi-s3c64xx.c |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 1781365..d24ec80 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -79,11 +79,6 @@
 #define S3C64XX_SPI_SLAVE_AUTO (1<<1)
 #define S3C64XX_SPI_SLAVE_SIG_INACT(1<<0)
 
-#define S3C64XX_SPI_ACT(c) writel(0, (c)->regs + S3C64XX_SPI_SLAVE_SEL)
-
-#define S3C64XX_SPI_DEACT(c) writel(S3C64XX_SPI_SLAVE_SIG_INACT, \
-   (c)->regs + S3C64XX_SPI_SLAVE_SEL)
-
 #define S3C64XX_SPI_INT_TRAILING_EN(1<<6)
 #define S3C64XX_SPI_INT_RX_OVERRUN_EN  (1<<5)
 #define S3C64XX_SPI_INT_RX_UNDERRUN_EN (1<<4)
@@ -737,14 +732,15 @@ static int s3c64xx_spi_transfer_one_message(struct 
spi_master *master,
enable_cs(sdd, spi);
 
/* Start the signals */
-   S3C64XX_SPI_ACT(sdd);
+   writel(0, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
spin_unlock_irqrestore(&sdd->lock, flags);
 
status = wait_for_xfer(sdd, xfer, use_dma);
 
/* Quiese the signals */
-   S3C64XX_SPI_DEACT(sdd);
+   writel(S3C64XX_SPI_SLAVE_SIG_INACT,
+  sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
if (status) {
dev_err(&spi->dev, "I/O Error: "
@@ -1030,7 +1026,7 @@ static void s3c64xx_spi_hwinit(struct 
s3c64xx_spi_driver_data *sdd, int channel)
 
sdd->cur_speed = 0;
 
-   S3C64XX_SPI_DEACT(sdd);
+   writel(S3C64XX_SPI_SLAVE_SIG_INACT, sdd->regs + S3C64XX_SPI_SLAVE_SEL);
 
/* Disable Interrupts - we use Polling if not DMA mode */
writel(0, regs + S3C64XX_SPI_INT_EN);
-- 
1.7.10.4


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 1/4] spi/s3c64xx: Fix handling of errors in gpio_request()

[Mark Brown]

When gpio_request() fails the driver logged the failure but while it'd
try to print an error code in the non-DT case it didn't pass the error
code in so garbage would be logged and in the DT case the error wasn't
logged.

Further, in the non-DT case the error code was then overwritten with -EBUSY
depriving the caller of information and breaking automatic probe deferral
pushing back from the GPIO level.  Also reformat the non-DT log message
so it's not word wrapped and we can grep for it.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 999154a0..7258b18 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -894,9 +894,9 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
if (!spi_get_ctldata(spi)) {
err = gpio_request(cs->line, dev_name(&spi->dev));
if (err) {
-   dev_err(&spi->dev, "request for slave select gpio "
-   "line [%d] failed\n", cs->line);
-   err = -EBUSY;
+   dev_err(&spi->dev,
+   "Failed to get /CS gpio [%d]: %d\n",
+   cs->line, err);
goto err_gpio_req;
}
spi_set_ctldata(spi, cs);
@@ -1114,7 +1114,8 @@ static int s3c64xx_spi_parse_dt_gpio(struct 
s3c64xx_spi_driver_data *sdd)
 
ret = gpio_request(gpio, "spi-bus");
if (ret) {
-   dev_err(dev, "gpio [%d] request failed\n", gpio);
+   dev_err(dev, "gpio [%d] request failed: %d\n",
+   gpio, ret);
goto free_gpio;
}
}
-- 
1.7.10.4


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 3/4] spi/s3c64xx: Convert to devm_request_and_ioremap()

[Mark Brown]

Saves some error handling and a small amount of code.

Signed-off-by: Mark Brown 
Reviewed-by: Sylwester Nawrocki 
Acked-by: Linus Walleij 
---
 drivers/spi/spi-s3c64xx.c |   18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 6ed3ba8..1781365 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1278,14 +1278,7 @@ static int __init s3c64xx_spi_probe(struct 
platform_device *pdev)
/* the spi->mode bits understood by this driver: */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
 
-   if (request_mem_region(mem_res->start,
-   resource_size(mem_res), pdev->name) == NULL) {
-   dev_err(&pdev->dev, "Req mem region failed\n");
-   ret = -ENXIO;
-   goto err0;
-   }
-
-   sdd->regs = ioremap(mem_res->start, resource_size(mem_res));
+   sdd->regs = devm_request_and_ioremap(&pdev->dev, mem_res);
if (sdd->regs == NULL) {
dev_err(&pdev->dev, "Unable to remap IO\n");
ret = -ENXIO;
@@ -1379,9 +1372,7 @@ err3:
if (!sdd->cntrlr_info->cfg_gpio && pdev->dev.of_node)
s3c64xx_spi_dt_gpio_free(sdd);
 err2:
-   iounmap((void *) sdd->regs);
 err1:
-   release_mem_region(mem_res->start, resource_size(mem_res));
 err0:
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
@@ -1393,7 +1384,6 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
 {
struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
struct s3c64xx_spi_driver_data *sdd = spi_master_get_devdata(master);
-   struct resource *mem_res;
 
pm_runtime_disable(&pdev->dev);
 
@@ -1412,12 +1402,6 @@ static int s3c64xx_spi_remove(struct platform_device 
*pdev)
if (!sdd->cntrlr_info->cfg_gpio && pdev->dev.of_node)
s3c64xx_spi_dt_gpio_free(sdd);
 
-   iounmap((void *) sdd->regs);
-
-   mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (mem_res != NULL)
-   release_mem_region(mem_res->start, resource_size(mem_res));
-
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
 
-- 
1.7.10.4


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

[PATCH 2/4] spi/s3c64xx: Put the /CS GPIO into output mode

[Mark Brown]

No call was being made by the GPIO driver to put the GPIO into output
mode meaning that the calls to gpio_set_value() which were being done
were not valid. A similar issue appears to exist with the DT GPIO
requests but as they appear to be being used for pinmux it's less clear
to me that we want to configure them.

Without this fix Cragganmore systems can't talk to their SPI devices.

Signed-off-by: Mark Brown 
---
 drivers/spi/spi-s3c64xx.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 7258b18..6ed3ba8 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -892,7 +892,8 @@ static int s3c64xx_spi_setup(struct spi_device *spi)
}
 
if (!spi_get_ctldata(spi)) {
-   err = gpio_request(cs->line, dev_name(&spi->dev));
+   err = gpio_request_one(cs->line, GPIOF_OUT_INIT_HIGH,
+  dev_name(&spi->dev));
if (err) {
dev_err(&spi->dev,
"Failed to get /CS gpio [%d]: %d\n",
-- 
1.7.10.4


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure

[Mark Brown]

On Wed, Jul 25, 2012 at 01:44:11PM +0200, Daniel Mack wrote:
> The spi-gpio driver currently assumes the chipselect gpio number is
> stored in ->controller_data of the device's static board information.

Always CC maintainers on things...  you've not CCed Grant or Linus W,
and for now I'm handling SPI patches (though I'm not in MAINTAINERS so
missing me is less surprising).

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure

[Mark Brown]

On Wed, Jul 25, 2012 at 09:38:58PM +0200, Daniel Mack wrote:
> On 25.07.2012 21:33, Mark Brown wrote:

> > Always CC maintainers on things...  you've not CCed Grant or Linus W,
> > and for now I'm handling SPI patches (though I'm not in MAINTAINERS so
> > missing me is less surprising).

> I *did* Cc: Grant and all other people that get_maintainer.pl listed.
> For some reason, Grant was dropped from the list on Wolfram's reply, and
> I just did't see that.

Grant's not in the CCs for the message I replied to which was one of
your patches.

> Anyway - let's rather discuss about the patchset :)

Part of the reason I'm being grumpy is I'm not likely to look at it
right now and my workflow is heavily based on things hitting my inbox
(I use a totally different account for generic list mail I'm not CCed on
and it's annoying to move stuff from one to the other).

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure

[Mark Brown]

On Wed, Jul 25, 2012 at 10:00:18PM +0200, Daniel Mack wrote:

> I don't know what's wrong here, but clearly, the message in my inbox has

> To: spi-devel-general@lists.sourceforge.net
> Cc: grant.lik...@secretlab.ca,
>   rob.herr...@calxeda.com,
>   devicetree-disc...@lists.ozlabs.org,
>   Daniel Mack 

> And I sent them off with git "send-email --to
> spi-devel-general@lists.sourceforge.net --cc grant.lik...@secretlab.ca ..."

> Sorry if that's my mistake, I just don't see it.

I forwarded <1343216652-1463-1-git-send-email-zon...@gmail.com> to you
under separate cover.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 06/10 V2] spi: Add SPI driver for mx233/mx28

[Mark Brown]

On Mon, Jul 23, 2012 at 10:40:48PM +0200, Marek Vasut wrote:

> This is slightly reworked version of the SPI driver.
> Support for DT has been added and it's been converted
> to queued API.

Looks reasonable overall.

> + bits_per_word = dev->bits_per_word;
> + if (t && t->bits_per_word)
> + bits_per_word = t->bits_per_word;
> +
> + if (bits_per_word != 8) {
> + dev_err(&dev->dev, "%s, unsupported bits_per_word=%d\n",
> + __func__, bits_per_word);
> + return -EINVAL;
> + }

> + if (dev->max_speed_hz)
> + hz = dev->max_speed_hz;
> + if (t && t->speed_hz)
> + hz = t->speed_hz;
> + if (hz == 0) {
> + dev_err(&dev->dev, "Cannot continue with zero clock\n");
> + return -EINVAL;
> + }

These two blocks use a different style (the first does the first assign
unconditionally, the second uses initialisation with declaration).  I
prefer the first style but YMMV and it doesn't matter.

For the missing clock rate might it make sense to just use whatever the
clock happens to come out as?

> +static void mxs_spi_cleanup(struct spi_device *dev)
> +{
> + return;
> +}

Empty functions are generally a warning sign...  why do we need this
one?

> +static int __devexit mxs_spi_remove(struct platform_device *pdev)
> +{

> + clk_disable_unprepare(ssp->clk);

It'd be nice to only keep the clocks enabled while doing transfers but
again totally non-essential.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 08/10 RESEND] spi: Add DMA support into SPI driver

[Mark Brown]

On Mon, Jul 23, 2012 at 10:40:50PM +0200, Marek Vasut wrote:

> + /*
> +  * Small blocks can be transfered via PIO.
> +  * Measured by empiric means:
> +  *
> +  * dd if=/dev/mtdblock0 of=/dev/null bs=1024k count=1
> +  *
> +  * DMA only: 2.164808 seconds, 473.0KB/s
> +  * Combined: 1.676276 seconds, 610.9KB/s
> +  */

I've seen other devices end up using the FIFO length as the decision
point here which makes intuitive sense to me unless the FIFO is
extremely deep.

Not reviewed this properly yet but it looks OK from a first read
through.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure

[Mark Brown]

On Wed, Aug 01, 2012 at 10:45:19PM +0200, Daniel Mack wrote:

> could you have another look at these patches maybe? They aren't urgent,
> I just want to avoid the get lost.

Can you please resend them with me in the CCs?  My process for handling
patches is very heavily based on my inbox.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH 06/10 V2] spi: Add SPI driver for mx233/mx28

[Mark Brown]

On Thu, Aug 02, 2012 at 04:58:38PM +0200, Marek Vasut wrote:

> > It'd be nice to only keep the clocks enabled while doing transfers but
> > again totally non-essential.

> Hm, this is spread across mxs. Shawn, is there any plan for PM implementation 
> for MXS ?

Take a look at s3c64xx - I did something with runtime PM for this, it's
something that can reasonably be implemented in drivers and as far as I
can tell most framework implementations end up using runtime PM anyway.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH] spi/s3c64xx: Add missing static storage class specifiers

[Mark Brown]

On Fri, Aug 03, 2012 at 10:08:12AM +0530, Sachin Kamat wrote:
> Silences the following sparse warnings:
> drivers/spi/spi-s3c64xx.c:1482:32: warning:

Applied, thanks.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Re: [PATCH resend 1/2] SPI: spi-gpio: store chipselect information in private structure

[Mark Brown]

On Wed, Aug 01, 2012 at 10:57:17PM +0200, Daniel Mack wrote:
> The spi-gpio driver currently assumes the chipselect gpio number is
> stored in ->controller_data of the device's static board information.

Applied both, thanks.  It's a bit sad that we need an explict property
for num-chipselects though.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general