On Mon, Nov 16, 2015 at 01:23:59PM +0100, Boris Brezillon wrote:
> Mark Brown wrote:
> > On Mon, Nov 16, 2015 at 09:56:32AM +0100, Boris Brezillon wrote:
> > > - pwm_reg_period = pwm_get_period(drvdata->pwm);
> > > + pwm_reg_period = pwm_get_default_period(drvdata
On Mon, Nov 16, 2015 at 09:56:32AM +0100, Boris Brezillon wrote:
> +++ b/drivers/regulator/pwm-regulator.c
> @@ -56,7 +56,7 @@ static int pwm_regulator_set_voltage_sel(struct
> regulator_dev *rdev,
> int dutycycle;
> int ret;
>
> - pwm_reg_period = pwm_get_period(drvdata->pwm);
On Thu, Oct 29, 2015 at 03:23:31PM -0700, Dmitry Torokhov wrote:
> However, you have regmap in the driver core already. Mark, is it
> possible to have regmap API also allow doing raw underlying protocol
> transfer so that consumers could issue command requests without needing
> to know if they nee
Neither myself or Liam is especially interested in this driver any more
and the devices are already covered by the general ex-Wolfson entry so
just remove this.
Signed-off-by: Mark Brown
Acked-by: Liam Girdwood
---
This depends on an update to all the Wolfson entries in the ASoC tree so
I&#x
On Fri, Aug 21, 2015 at 06:27:08PM +0200, Takashi Iwai wrote:
> Mark, did you already put into your tree? Otherwise I'm going to take
> it to for-next branch.
No, and I discarded the previous version so should be good for your tree.
signature.asc
Description: Digital signature
On Fri, Aug 21, 2015 at 10:25:59AM +0200, Takashi Iwai wrote:
> Lars-Peter Clausen wrote:
> > This patch touches code in both ALSA and the input subsystem. Ideally this
> > patch will be merged via the ALSA tree. Given that the wm97xx touchscreen
> > driver is not seeing too many changes these day
On Thu, Aug 20, 2015 at 06:35:24PM +0200, Lars-Peter Clausen wrote:
> On 08/20/2015 06:33 PM, Mark Brown wrote:
> > Just discussed this in person with Dmitry: I'll apply the patch just now
> > for v4.3 and we can incrementally improve the ifdef handling after.
> Great,
On Fri, Aug 07, 2015 at 09:32:13AM -0700, Dmitry Torokhov wrote:
> On Fri, Aug 07, 2015 at 10:13:48AM +0200, Lars-Peter Clausen wrote:
> > We know that it is used when CONFIG_PM_SLEEP is defined and we know that it
> > is unused CONFIG_PM_SLEEP is not defined. Marking the function as
> > __maybe_u
On Fri, Aug 07, 2015 at 09:30:29AM -0700, Dmitry Torokhov wrote:
> On Fri, Aug 07, 2015 at 02:30:05PM +0100, Mark Brown wrote:
> > Indeed, a major goal of disabling PM support is to save space.
> Then maybe we should adjust dev_pm_ops definition to omit members that
> are not used
On Fri, Aug 07, 2015 at 10:13:48AM +0200, Lars-Peter Clausen wrote:
> On 08/07/2015 12:55 AM, Dmitry Torokhov wrote:
> > Pull this out of #ifdef block and kill entire #else/endif along with
> > WM97XX_PM_OPS define: SIMPLE_DEV_PM_OPS will result in an empty
> > structure if CONFIG_PM_SLEEP is not
On Tue, May 19, 2015 at 02:10:30PM +0100, S Twiss wrote:
> From: S Twiss
>
> Add BUCK and LDO regulator driver support for DA9062
Applied, thanks.
signature.asc
Description: Digital signature
On Wed, Apr 29, 2015 at 07:58:29PM +0900, Krzysztof Kozlowski wrote:
> Add support for different configurations of charger's registers so the
> same driver could be used on other devices (e.g. MAX77843).
Acked-by: Mark Brown
signature.asc
Description: Digital signature
On Tue, Apr 28, 2015 at 02:55:46AM +0300, Dmitry Eremin-Solenikov wrote:
> +static int locomospi_reg_open(struct locomospi_dev *spidev)
> +{
> +static int locomospi_reg_release(struct locomospi_dev *spidev)
> +{
These are a bit weird - as far as I can tell they're just doing some
init done on pr
On Mon, Apr 27, 2015 at 12:56:02PM +0530, Rajeev Kumar wrote:
> .mailmap |1 +
> arch/arm/mach-spear/generic.h|2 +-
> arch/arm/mach-spear/include/mach/irqs.h |2 +-
> arch/arm/mach-spear/include/mach/spear.h |2 +-
> ar
On Fri, Apr 24, 2015 at 02:47:06PM +, Opensource [Steve Twiss] wrote:
> On 18 April 2015 12:48 Mark Brown wrote:
> Okay. I think I am getting this.
> As of v3.18 there are newer parts to regulator_desc from the commit
> a0c7b16 "regulator: of: Provide simplified DT pars
On Fri, Apr 17, 2015 at 03:23:32PM +0100, S Twiss wrote:
> +/* Regulator interrupt handlers */
> +static irqreturn_t da9062_ldo_lim_event(int irq, void *data)
> +{
> + struct da9062_regulators *regulators = data;
> + struct da9062 *hw = regulators->regulator[0].hw;
> + struct da9062_re
On Tue, Mar 31, 2015 at 02:57:35PM -0500, Thor Thayer wrote:
> Which brings up my next question. Can the gpio_keys framework be used with a
> regmapped gpio? I haven't been able to find any examples of gpio_keys with
> an external gpio expander and maybe this isn't valid usage.
Why would there be
On Fri, Nov 14, 2014 at 04:47:00PM +0400, Dmitry Eremin-Solenikov wrote:
> I'm actually looking at the regulator interface. Since this DAC serves mostly
> like a (semi-)constant voltage interface, would it be rather logical to use
> regulator subsystem to drive it?
Possibly... it's mostly a func
On Tue, Nov 11, 2014 at 05:16:38PM +0400, Dmitry Eremin-Solenikov wrote:
> Just to better understand your suggestions: do you want me to convert
> to regmap only gpio driver or do you suggest to convert all LoCoMo drivers?
> That is doable, of course, but the amount of changes is overwhelming.
> A
On Thu, Nov 06, 2014 at 01:33:24AM +0400, Dmitry Eremin-Solenikov wrote:
> 2014-11-03 16:43 GMT+03:00 Linus Walleij :
> > Yes that's the point: if you use regmap mmio you get the RMW-locking
> > for free, with the regmap implementation.
> Just to be more concrete. Currently locomo_gpio_ack_irq()
On Thu, Nov 06, 2014 at 12:02:49AM +0400, Dmitry Eremin-Solenikov wrote:
> 2014-11-03 16:41 GMT+03:00 Linus Walleij :
> > The point is still the same: no unrelated code in drivers/mfd,
> > then either use IIO DAC as a middle layer or sink the DAC handling
> > into respective subdriver, i.e. push i
ere. Otherwise this looks
fine - ideally it'd move to gpiod but moving to gpiolib is a clear win
so no need to block on this.
Acked-by: Mark Brown
with at least the subject line fixed.
signature.asc
Description: Digital signature
On Tue, Oct 28, 2014 at 03:02:08AM +0300, Dmitry Eremin-Solenikov wrote:
> LoCoMo chip has a built-in simple SPI controller. On Sharp SL-5500 PDDAs
> it is connected to external MMC slot.
> +config SPI_LOCOMO
> + tristate "Locomo SPI master"
> + depends on MFD_LOCOMO
> + select SPI_BIT
On Tue, Oct 28, 2014 at 12:13:39AM +, Russell King - ARM Linux wrote:
> On Tue, Oct 28, 2014 at 03:01:53AM +0300, Dmitry Eremin-Solenikov wrote:
> > Sharp Zaurus SL-5500 and SL-5600 use special companion Gate Array. Current
> > drivers present in Linux kernel has some problems:
> > * It uses
On Wed, Oct 08, 2014 at 01:32:33PM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 08, 2014 at 09:04:26PM +0100, Mark Brown wrote:
> > On Wed, Oct 08, 2014 at 11:20:58AM -0700, Stephen Boyd wrote:
> > > Srini/Mark, any reason why the regmap_field structure is opaque?
> > S
On Wed, Oct 08, 2014 at 11:20:58AM -0700, Stephen Boyd wrote:
> On 10/08/2014 11:13 AM, Dmitry Torokhov wrote:
> >>>Oops. struct regmap_field is opaque. It seems that the allocation
> >>>is the only way that I could have instance of it.
> >>Maybe we can add an API to allocate an array of fields?
On Tue, Aug 12, 2014 at 10:01:49AM -0700, Dmitry Torokhov wrote:
> On Mon, Aug 11, 2014 at 04:42:10PM +0100, Mark Brown wrote:
> > As with ARM the ARMv8 architecture provides a cycle counter which can be
> > used to provide a high resolution time for the joystick driver and silenc
From: Mark Brown
As with ARM the ARMv8 architecture provides a cycle counter which can be
used to provide a high resolution time for the joystick driver and silence
the build warning that results from not having a precise timer on ARMv8,
making allmodconfig and allyesconfig quieter.
Signed-off
On Mon, May 19, 2014 at 09:47:41PM +0200, Carlo Caione wrote:
> This set of patches introduces the core driver and support for two different
> subsystems:
> - Regulators
> .../ABI/testing/sysfs-driver-input-axp-pek | 11 +
> Documentation/devicetree/bindings/mfd/axp20x.txt | 93
On Thu, May 15, 2014 at 08:03:06PM +0200, Boris BREZILLON wrote:
> I know I'm late, and this patch has already been applied, but shouldn't
> we use of_get_child_by_name instead of of_find_node_by_name.
> This might lead to wrong regulators node parsing if other regulators are
> defined in the DT a
On Thu, May 08, 2014 at 08:56:04PM +0100, Nick Dyer wrote:
> Thanks! I had wondered why you had left it, you never communicated this to
> me unfortunately. Would it be preferable for me to switch to
> request_firmware_nowait() and complete the probe asynchronously after it
> returns?
Another comm
From: Liviu Dudau
Recent ARM boards have the KMI devices share one interrupt line rather
than having dedicated IRQs. Update the driver to take that into account.
Signed-off-by: Liviu Dudau
Signed-off-by: Mark Brown
---
drivers/input/serio/ambakmi.c | 3 ++-
1 file changed, 2 insertions(+), 1
On Thu, May 01, 2014 at 02:16:27AM +, Austin, Brian wrote:
> Apparently not.
> I would like to come up with a better solution than making INPUT a
> requirement. I just need some time.
> In the meantime I suppose it’s OK to apply it?
Yeah. Realistically it's probably not going to ever be a
On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote:
> I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP
> Generator but when I disable CONFIG_INPUT I do not get an error. Is there
> any information available on what the error is?
I suspect it's ASoC built in and
Applied, but...
> Cc: Mark Brown
> Cc: Liam Girdwood
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: Sangbeom Kim
> Cc: Lars-Peter Clausen
> Cc: Timur Tabi
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-input@vger.kernel.org
On Thu, Apr 24, 2014 at 05:58:47PM +0100, Charles Keepax wrote:
> Ah ok seems I am getting an error but for some reason for me it
> shows up looking very unrelated to the supply mapping. In that it
> shows up much later in the log and doesn't seem to mention the
> MFD at all:
If you look at the w
On Wed, Apr 23, 2014 at 10:25:46PM +0200, Carlo Caione wrote:
> I'm having a really hard time with this problem, so any hint is welcome
> :) The small modification I'm using on top of the patches in this series
> is here: http://bpaste.net/show/228330/
> Unfortunately as I said I got this when bo
On Tue, Apr 22, 2014 at 05:39:28PM -0700, Dmitry Torokhov wrote:
> On Tue, Apr 22, 2014 at 10:18:21PM +0100, Mark Brown wrote:
> > Remove the bitrotted comment, though in actual fact the use case mentioned
> > is a great use for spi_async() since it would cut down on latency h
From: Mark Brown
While searching for users of spi_async() I got a false positive in the
ads7846 driver, fix that.
Signed-off-by: Mark Brown
---
drivers/input/touchscreen/ads7846.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b
From: Mark Brown
While searching for users of spi_async() I found a reference in the ad7877
driver to using it to initiate data transfer from the interrupt handler.
However there is no code for this, instead the interrupt handler is a
threaded handler and uses spi_sync() instead.
Remove the
On Thu, Apr 17, 2014 at 12:06:34PM +0200, Carlo Caione wrote:
> I'm fighting with a small issue when using the
> regulator_bulk_register_supply_alias(). Problem is that when using the
> .parent_supplies entry in the MFD driver, I hit the
>
> WARN_ON(!list_empty(&dev->devres_head));
>
> in linux/
On Mon, Apr 14, 2014 at 12:20:32PM +0200, Hans de Goede wrote:
Please fix your mailer to word wrap at less than 80 columns.
> As Mark has also mentioned we should probably pin the regulators to a
> certain voltage, except for those which we expect to be controlled by
> a driver, so basically all
On Fri, Apr 11, 2014 at 03:04:32PM +0200, Carlo Caione wrote:
> On Fri, Apr 11, 2014 at 2:29 PM, Mark Brown wrote:
> >> + regulators {
> >> + compatible = "x-powers,axp20x-reg";
> > This compat
On Fri, Apr 11, 2014 at 11:38:11AM +0200, Carlo Caione wrote:
> In all the DTs the min and max microvolt allowed for each regulator are
> actually
> the min and max voltage possible for the regulator itself. This is not safe
> but
> we do not have the ranges allowed for each board and the origin
On Fri, Apr 11, 2014 at 11:38:10AM +0200, Carlo Caione wrote:
> AXP202 and AXP209 come with two synchronous step-down DC-DCs and five
> LDOs. This patch introduces basic support for those regulators.
Applied, thanks, but I had to resolve some trivial add/add conflicts
with the Broadcom regulator d
On Fri, Apr 11, 2014 at 01:25:03PM +0200, Arnd Bergmann wrote:
> Why do you have to enumerate the interrupts here? Can't you just
> put all the numbers into the DT nodes of the devices using them?
> In general, I would say that the mfd driver should not care about
> what is connected to it.
This
On Sat, Mar 29, 2014 at 06:52:01PM +0100, Carlo Caione wrote:
> On Fri, Mar 28, 2014 at 01:39:34PM +0000, Mark Brown wrote:
> > This is fairly obviously broken - it's overwriting the normal runtime
> > value, this will disrupt the running system if we want the value we u
On Thu, Mar 27, 2014 at 10:29:20PM +0100, Carlo Caione wrote:
> +static int axp20x_set_suspend_voltage(struct regulator_dev *rdev, int uV)
> +{
> + int sel = regulator_map_voltage_iterate(rdev, uV, uV);
> +
> + if (sel < 0)
> + return sel;
> +
> + return regulator_set_volta
On Thu, Mar 27, 2014 at 10:29:21PM +0100, Carlo Caione wrote:
> This dtsi describes the axp209 PMIC, and is to be included from inside
> the i2c controller node to which the axp209 is connected.
> arch/arm/boot/dts/x-powers-axp209.dtsi | 54
> ++
Something is wron
On Fri, Mar 28, 2014 at 01:54:12PM +0100, Maxime Ripard wrote:
> On Fri, Mar 28, 2014 at 11:38:39AM +0000, Mark Brown wrote:
> > Hang on, what is an include file setting up regulators for?
> Look at patch 7. To share the regulators declaration across all boards
> and avoid d
On Fri, Mar 28, 2014 at 11:11:46AM +0100, Maxime Ripard wrote:
> Here, you would just include the dtsi at the top of the file, and in
> the DTSI, you would have something like:
> &axp209 {
>regulators {
> ...
>}
> }
Hang on, what is an include file setting up regulators for?
sign
On Sat, Mar 22, 2014 at 08:08:03PM +0100, Carlo Caione wrote:
> On Sat, Mar 22, 2014 at 11:42:01AM -0700, Dmitry Torokhov wrote:
> > > drivers/mfd/axp20x.c:172:18: warning: assignment makes integer
> > > frompointer without a cast [enabled by default]
> > You need to cast to long, otherwise you w
On Sat, Mar 22, 2014 at 05:51:32PM +0100, Carlo Caione wrote:
> On Tue, Mar 18, 2014 at 03:59:19PM +, Lee Jones wrote:
> > > + of_id = of_match_device(axp20x_of_match, &i2c->dev);
> > > + if (!of_id) {
> > > + dev_err(&i2c->dev, "Unable to setup AXP20X data\n");
> > > + return
On Sat, Mar 15, 2014 at 04:43:42PM +0100, Carlo Caione wrote:
> AXP202 and AXP209 come with two synchronous step-down DC-DCs and five
> LDOs. This patch introduces basic support for those regulators.
This is mostly fine apart from the things Krzysztof mentioned and...
> +static int axp20x_set_dcd
On Thu, Mar 13, 2014 at 12:55:04PM +, Lee Jones wrote:
> > Is it necessary? If previous mfd driver has various i2c line, previous mfd
> > driver
> > initialize regmap/i2c setting on mfd driver.
> > I'm not sure that regmap/i2c setting code move from mfd driver to each
> > driver.
> >
> > Dea
On Tue, Mar 11, 2014 at 10:06:59PM +0100, Carlo Caione wrote:
> On Tue, Mar 11, 2014 at 07:29:40PM +0000, Mark Brown wrote:
> > With the above code the driver will return an error and never get as far
> > as registering the regulator.
> I agree, but if I register the regulat
On Tue, Mar 11, 2014 at 08:24:11PM +0100, Carlo Caione wrote:
> On Mon, Mar 03, 2014 at 10:56:16AM +0900, Mark Brown wrote:
> > > + regulators = of_find_node_by_name(np, "regulators");
> > > + if (!regulators) {
> > > + dev_err(
On Sat, Mar 08, 2014 at 12:43:04PM +0100, Carlo Caione wrote:
> On Fri, Mar 7, 2014 at 7:22 PM, Maxime Ripard
> > On Sat, Mar 01, 2014 at 05:45:51PM +0100, Carlo Caione wrote:
> >> + return platform_driver_register(&axp20x_regulator_driver);
> > I thought the AXP was only connected through I2
On Wed, Mar 05, 2014 at 10:54:39AM -0800, Dmitry Torokhov wrote:
> On Wed, Mar 05, 2014 at 03:58:17PM +0100, Robert Baldyga wrote:
> > -int max8997_write_reg(struct i2c_client *i2c, u8 reg, u8 value)
> > +int max8997_write_reg(struct regmap *map, u8 reg, u8 value)
> Why don't you make read/write
On Sat, Mar 01, 2014 at 05:45:51PM +0100, Carlo Caione wrote:
> index d59c826..0cef101 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -69,3 +69,4 @@ CONFIG_NFS_FS=y
> CONFIG_ROOT_NFS=y
> CONFIG_NLS=y
> CONFIG_PRINTK_TIME=y
> +CONFIG_REGULATOR_AXP20
On Thu, Jan 02, 2014 at 11:17:57AM -0800, Dmitry Torokhov wrote:
> On Thu, Jan 02, 2014 at 06:49:59PM +0000, Mark Brown wrote:
> > On Sun, Dec 15, 2013 at 03:33:37AM -0800, Dmitry Torokhov wrote:
> > > > + regmap = dev_get_regmap(pdev->dev.parent, NULL);
>
On Sun, Dec 15, 2013 at 03:33:37AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 10, 2013 at 03:43:11PM -0800, Stephen Boyd wrote:
> > + regmap = dev_get_regmap(pdev->dev.parent, NULL);
> > + if (!regmap)
> > + return -ENODEV;
> And you are leaking memory here...
He's not, dev_get_re
On Fri, Oct 25, 2013 at 03:29:51PM +0900, Hyunhee Kim wrote:
> From: Hyunhee Kim
> Date: Wed, 9 Oct 2013 16:21:36 +0900
> Subject: [PATCH] Input: add regulator haptic driver
This is OK from a regulator point of view though there's still a lot of
use of regulator devm_ and input devm_ that could h
On Fri, Oct 11, 2013 at 11:22:00AM +0900, hyunhee.kim wrote:
> + if (enable && !haptic->enabled) {
> + haptic->enabled = true;
> + ret = regulator_enable(haptic->regulator);
> + if (ret)
> + pr_err("haptic: %s failed to enable regulator\n
On Thu, Jul 11, 2013 at 08:41:41AM +0100, Nick Dyer wrote:
> Mark Brown wrote:
> > On Fri, Jun 21, 2013 at 09:16:16AM -0700, Nick Dyer wrote:
> >> For some operations it does. For example updating the whole chip config
> >> (which is a common thing to want to do), it w
On Thu, Jul 04, 2013 at 11:02:41AM +0200, Sebastian Andrzej Siewior wrote:
> The driver here does not use atomic updates but read followed by write
> so your locking here is futile. So the API/regmap alone does not make
Doesn't that sound like the driver ought to be using a r/m/w primitive
though
On Fri, Jun 21, 2013 at 09:16:16AM -0700, Nick Dyer wrote:
> Mark Brown wrote:
> > Yes, to be honest. I'd hope it wouldn't be increasing the number of
> > read/write operations...
> For some operations it does. For example updating the whole chip config
> (which
On Tue, Jun 11, 2013 at 01:16:31PM +0100, Nick Dyer wrote:
> Without being able to name all of the registers (which would require a
> large amount of architecture to keep up-to-date and would probably turn
> into an unmaintainable mess), you can only split up the register map into
> separate parts
On Mon, Jun 17, 2013 at 01:41:40PM +0200, Sebastian Andrzej Siewior wrote:
> On 06/14/2013 03:53 PM, Mark Brown wrote:
> > It does give you tracepoints and debugfs. If it's making things at
> > all complicated we need to look at why that is and figure out how
> > to fi
On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote:
> On 06/11/2013 04:23 PM, Samuel Ortiz wrote:
> > Please fix your commit logs, and your subject lines. It should be e.g.
> > mfd: input: ti_am335x_adc: Blablabla
> > if it's mostly an mfd patch that also touches an input d
On Tue, Jun 11, 2013 at 04:34:53PM +0200, Sebastian Andrzej Siewior wrote:
> >> Therefore this patch removes regmap part of the driver.
> > NAK. Using regmap is better than open coding your register accesses, and
> > the children not using this API is not a reason for the MFD driver to do
> > the
On Tue, Jun 11, 2013 at 11:39:37AM +0100, Nick Dyer wrote:
> Mark Brown wrote:
> > I don't think you're using the usual definition of "register map" here.
> > You seem to be switching between talking about this object model the
> > device has and device
On Fri, Jun 07, 2013 at 05:11:28PM +0100, Nick Dyer wrote:
> Mark Brown wrote:
> > I thought there was this protocol you're concerned aboout, not raw
> > registers? Presenting the actual data in binary form seems sane, how
> > one gets to the data is the issue.
>
On Fri, Jun 07, 2013 at 04:12:25PM +0100, Nick Dyer wrote:
> Mark Brown wrote:
> > Who said anything about names? I'd assume the userspace stuff is
> > eventually talking to the device based on numbers of some kind and I'd
> > expect that this would be what ends up
On Thu, Jun 06, 2013 at 05:13:32PM +0100, Nick Dyer wrote:
> I am not a legal expert, but I have described what you suggest to people
> who are more expert in the NDA terms and they say I cannot implement a
> solution which exposes the names of all the parameters. In any case,
Who said anything a
On Thu, Jun 06, 2013 at 12:34:57PM +0100, Nick Dyer wrote:
> Mark Brown wrote:
> > This is yet another reason for implementing the protocol properly
> > instead of trying to bodge around the kernel. It really seems like
> > the biggest problem here is the decision to tr
On Thu, Jun 06, 2013 at 12:17:56PM +0100, Nick Dyer wrote:
> Mark Brown wrote:
> > If that's a big problem just put the data table in a section of the
> > firmware (or a separate file that gets requested as a firmware). Or
> > have the firmware be able to enumerate
On Thu, Jun 06, 2013 at 12:00:54PM +0100, Nick Dyer wrote:
> Mark Brown wrote:
> > The retries can just be done further up the stack? All regmap is doing
> > with I/O errors is punting them straight back up to the caller so the
> > caller can retry just as well using regma
On Thu, Jun 06, 2013 at 11:31:57AM +0100, Nick Dyer wrote:
> Having to define every parameter in each object (there are thousands) in
> the kernel driver would be impractically technically, since it would result
> in a huge, and constantly updating API, which would be always out-of-date,
> and imp
On Thu, Jun 06, 2013 at 11:40:50AM +0100, Nick Dyer wrote:
> I am more worried about the address pointer handling and the I2C retries.
The retries can just be done further up the stack? All regmap is doing
with I/O errors is punting them straight back up to the caller so the
caller can retry jus
On Wed, Jun 05, 2013 at 10:36:45PM +0100, Nick Dyer wrote:
> Dmitry Torokhov wrote:
> > What other purposes does it serve? I'd expect you need it during new
> > board bringup.
> Run-time examples would be adjusting noise suppression or touch suppression
> parameters based on something going on in
On Wed, Jun 05, 2013 at 02:07:15PM -0700, Dmitry Torokhov wrote:
> On Wed, Jun 05, 2013 at 09:31:39PM +0100, Nick Dyer wrote:
> > It's partly path dependence - it was implemented like this because regmap
> > wasn't in mainline at the point when I wrote it. Having a dependency on
> > regmap would n
On Wed, May 29, 2013 at 10:46:42AM +0200, Sebastian Andrzej Siewior wrote:
> Without this, devm_regmap_init_mmio() creates & uses a simple
> spin_lock() and this should be enough. Within the probe function the
> registers are read and written in process context. Later they are
> accessed from the I
On Mon, May 06, 2013 at 12:34:23PM +0200, Daniel Mack wrote:
> But I can browse my reflog and switch back to the other approach if
> that's preferred. The only concern I have is what I already mentioned:
> the allocation of function pointers which are definitely unused for DT.
I don't particularl
On Sun, May 05, 2013 at 08:24:44PM -0700, Dmitry Torokhov wrote:
> On Thu, Apr 25, 2013 at 01:33:52PM +0200, Daniel Mack wrote:
> > In preparation for DT bindings, we have to store all runtime information
> > inside struct ads7846. Add more variable to struct ads7846 and refactor
> > some code so
On Mon, Apr 29, 2013 at 09:52:34PM +0300, Leon Romanovsky wrote:
> Mark, please take my apologies, I was mislead by the following comment
> on the code:
No problem, thanks for taking the time to check into this.
signature.asc
Description: Digital signature
On Sat, Mar 09, 2013 at 03:53:36PM -0800, Dmitry Torokhov wrote:
> On Mon, Dec 24, 2012 at 04:18:27PM +0000, Mark Brown wrote:
> > I'm a bit nervous about the fact that currently both the pen down IRQ
> > and the coordinate read are pushed through a single workqueue so ar
an see the sort of issue that
might mean this is needed and if it improves performance in your
testing:
Acked-by: Mark Brown
signature.asc
Description: Digital signature
On Fri, Mar 08, 2013 at 05:15:09PM +0100, Markus Pargmann wrote:
> dev_dbg should end with a new line.
Acked-by: Mark Brown
signature.asc
Description: Digital signature
On Fri, Mar 08, 2013 at 05:15:07PM +0100, Markus Pargmann wrote:
> Instead of interpreting a wrong measurement as pen up, we should try to read
> again.
Acked-by: Mark Brown
signature.asc
Description: Digital signature
abs_y[0] > (data.y & 0xfff)
> + || abs_y[1] < (data.y & 0xfff)) {
> + dev_dbg(wm->dev, "Measurement out of range, dropping
> it\n");
> + rc = RC_AGAIN;
> + goto out;
The change is good but
On Tue, Mar 05, 2013 at 09:17:27AM +0530, Sachin Kamat wrote:
> On 5 March 2013 09:06, Mark Brown wrote:
> >I know the existing code does this, it's not
> > clear to me that that's a good idea either.
> However, if your question is why return platform_driver
On Tue, Mar 05, 2013 at 08:53:47AM +0530, Sachin Kamat wrote:
> module_platform_driver_probe() eliminates the boilerplate and simplifies
> the code.
Is there really any great reason to use this as opposed to
module_platform_driver()? I know the existing code does this, it's not
clear to me that t
unconditional and
add appropriate error handling, including adding cleanup of the
regulators if setup_reg() fails.
Signed-off-by: Mark Brown
---
drivers/input/touchscreen/mms114.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers
On Sat, Mar 02, 2013 at 05:11:00PM +0900, Joonyoung Shim wrote:
> On 03/02/2013 04:00 PM, Mark Brown wrote:
> > mdelay(MMS114_POWERON_DELAY);
> > error = mms114_setup_regs(data);
> If error, we will have to disable regulators here.
That's a preex
unconditional and
add appropriate error handling.
Signed-off-by: Mark Brown
---
drivers/input/touchscreen/mms114.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/input/touchscreen/mms114.c
b/drivers/input/touchscreen/mms114.c
index
At least print a warning if we can't power the device up.
Signed-off-by: Mark Brown
---
drivers/input/touchscreen/ads7846.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index 4f
On Sun, Dec 23, 2012 at 01:54:50AM -0800, Dmitry Torokhov wrote:
> This is not 100% equivalent transformation as now we schedule first and
> disable IRQ later... Anyway, I think the driver shoudl be converted to
> threaded IRQ instead. Mark, does the patch below make any sense to you?
I'm a bit n
Signed-off-by: Mark Brown
---
drivers/input/misc/wm831x-on.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/input/misc/wm831x-on.c b/drivers/input/misc/wm831x-on.c
index 558767d..caa2c406 100644
--- a/drivers/input/misc/wm831x-on.c
+++ b/drivers/input/misc
Signed-off-by: Mark Brown
---
drivers/input/touchscreen/wm831x-ts.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/wm831x-ts.c
b/drivers/input/touchscreen/wm831x-ts.c
index f88fab5..6be2eb6 100644
--- a/drivers/input/touchscreen/wm831x-ts.c
1 - 100 of 204 matches
Mail list logo
