Re: [PATCH v4 2/2] iio: accel: mma8452: Rename config structs for readability
On 2017-11-05 19:00, Harinath Nampally wrote: > Rename structs holding event configuration registers > to more appropriate names. This naming is consistent > with the event config register names given in the > mma845x and fxls8471 datasheets. > > Signed-off-by: Harinath Nampally Makes sense to me. Acked-by: Martin Kepplinger Hey Harinath, I think it'd be great to have the "power_mode" iio ABI interface for mma8452 too, and I just found an old patch pf mine for this. If you say you could test it and check for correct API usage and ABI provisioning in sysfs, I'd be happy to publish it for you to make any necessary corrections and submit it after testing. Do we have a deal? thanks martin
Re: [PATCH v4 1/2] iio: accel: mma8452: Rename a struct for code readibility
On 2017-11-05 19:00, Harinath Nampally wrote: > Rename time step look up struct to generic name > as the values in the look table are same for all > the other events like pulse, transient etc. > > Signed-off-by: Harinath Nampally Acked-by: Martin Kepplinger
[PATCH] iio: mma8452: add power_mode sysfs configuration
This adds the power_mode sysfs interface to the device as documented in
sysfs-bus-iio.
---
Note that I explicitely don't sign off on this.
This is a starting point for anybody who can test it and check for correct
API usage, and ABI correctness, as documented in
Documentation/ABI/testing/sys-bus-iio
(grep it for "power_mode"). The ABI doc probably would need an addition
too, if the 4 power modes here seem generally useful (there are only
2 listed there)!
So, if you can test this, feel free to set up a proper patch or
two, and I'm happy to review.
Please note that this patch is quite old. It really should be that simple
as far as my understanding back then. We always list the available frequencies
of the given power mode we are in, for example, already, and everything
basically is in place except for the user interface.
thanks
martin
drivers/iio/accel/mma8452.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index bfd4bc806fc2..640bbd9872ab 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -1166,6 +1166,41 @@ static struct attribute_group
mma8452_event_attribute_group = {
.attrs = mma8452_event_attributes,
};
+static const char * const mma8452_power_modes[] = {"normal",
+ "low_noise_low_power",
+ "low_noise",
+ "low_power"};
+
+static int mma8452_get_power_mode_iio_enum(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan)
+{
+ struct mma8452_data *data = iio_priv(indio_dev);
+
+ return mma8452_get_power_mode(data);
+}
+
+static int mma8452_set_power_mode_iio_enum(struct iio_dev *indio_dev,
+ const struct iio_chan_spec *chan,
+ unsigned int mode)
+{
+ struct mma8452_data *data = iio_priv(indio_dev);
+
+ return mma8452_set_power_mode(data, mode);
+}
+
+static const struct iio_enum mma8452_power_mode_enum = {
+ .items = mma8452_power_modes,
+ .num_items = ARRAY_SIZE(mma8452_power_modes),
+ .get = mma8452_get_power_mode_iio_enum,
+ .set = mma8452_set_power_mode_iio_enum,
+};
+
+static const struct iio_chan_spec_ext_info mma8452_ext_info[] = {
+ IIO_ENUM("power_mode", true, _power_mode_enum),
+ IIO_ENUM_AVAILABLE("power_mode", _power_mode_enum),
+ { },
+};
+
#define MMA8452_FREEFALL_CHANNEL(modifier) { \
.type = IIO_ACCEL, \
.modified = 1, \
@@ -1204,6 +1239,7 @@ static struct attribute_group
mma8452_event_attribute_group = {
}, \
.event_spec = mma8452_transient_event, \
.num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
+ .ext_info = mma8452_ext_info, \
}
#define MMA8652_CHANNEL(axis, idx, bits) { \
@@ -1225,6 +1261,7 @@ static struct attribute_group
mma8452_event_attribute_group = {
}, \
.event_spec = mma8452_motion_event, \
.num_event_specs = ARRAY_SIZE(mma8452_motion_event), \
+ .ext_info = mma8452_ext_info, \
}
static const struct iio_chan_spec mma8451_channels[] = {
--
2.11.0
Re: [PATCH] iio: accel: mma8452: Add single pulse/tap event detection
On 2017-11-09 04:12, Harinath Nampally wrote:
> This patch adds following related changes:
> - defines pulse event related registers
> - enables and handles single pulse interrupt for fxls8471
> - handles IIO_EV_DIR_EITHER in read/write callbacks (because
> event direction for pulse is either rising or falling)
> - configures read/write event value for pulse latency register
> using IIO_EV_INFO_HYSTERESIS
> - adds multiple events like pulse and tranient event spec
> as elements of event_spec array named 'mma8452_accel_events'
>
> Except mma8653 chip all other chips like mma845x and
> fxls8471 have single tap detection feature.
> Tested thoroughly using iio_event_monitor application on
> imx6ul-evk board which has fxls8471.
>
> Signed-off-by: Harinath Nampally
> ---
What tree is this written against? It doesn't apply to the current -next
anyways.
> drivers/iio/accel/mma8452.c | 156
> ++--
> 1 file changed, 151 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 43c3a6b..36f1b56 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -72,6 +72,19 @@
> #define MMA8452_TRANSIENT_THS_MASK GENMASK(6, 0)
> #define MMA8452_TRANSIENT_COUNT 0x20
> #define MMA8452_TRANSIENT_CHAN_SHIFT 1
> +#define MMA8452_PULSE_CFG0x21
> +#define MMA8452_PULSE_CFG_CHAN(chan) BIT(chan * 2)
> +#define MMA8452_PULSE_CFG_ELEBIT(6)
> +#define MMA8452_PULSE_SRC0x22
> +#define MMA8452_PULSE_SRC_XPULSE BIT(4)
> +#define MMA8452_PULSE_SRC_YPULSE BIT(5)
> +#define MMA8452_PULSE_SRC_ZPULSE BIT(6)
> +#define MMA8452_PULSE_THS0x23
> +#define MMA8452_PULSE_THS_MASK GENMASK(6, 0)
> +#define MMA8452_PULSE_COUNT 0x26
> +#define MMA8452_PULSE_CHAN_SHIFT 2
> +#define MMA8452_PULSE_LTCY 0x27
> +
> #define MMA8452_CTRL_REG10x2a
> #define MMA8452_CTRL_ACTIVE BIT(0)
> #define MMA8452_CTRL_DR_MASKGENMASK(5, 3)
> @@ -91,6 +104,7 @@
>
> #define MMA8452_INT_DRDYBIT(0)
> #define MMA8452_INT_FF_MT BIT(2)
> +#define MMA8452_INT_PULSE BIT(3)
> #define MMA8452_INT_TRANS BIT(5)
>
I think the defintions would deserve to be in a separate patch, but
that's debatable.
> #define MMA8451_DEVICE_ID0x1a
> @@ -155,6 +169,16 @@ static const struct mma8452_event_regs trans_ev_regs = {
> .ev_count = MMA8452_TRANSIENT_COUNT,
> };
>
> +static const struct mma8452_event_regs pulse_ev_regs = {
> + .ev_cfg = MMA8452_PULSE_CFG,
> + .ev_cfg_ele = MMA8452_PULSE_CFG_ELE,
> + .ev_cfg_chan_shift = MMA8452_PULSE_CHAN_SHIFT,
> + .ev_src = MMA8452_PULSE_SRC,
> + .ev_ths = MMA8452_PULSE_THS,
> + .ev_ths_mask = MMA8452_PULSE_THS_MASK,
> + .ev_count = MMA8452_PULSE_COUNT,
> +};
> +
> /**
> * struct mma_chip_info - chip specific data
> * @chip_id: WHO_AM_I register's value
> @@ -784,6 +808,14 @@ static int mma8452_get_event_regs(struct mma8452_data
> *data,
> case IIO_EV_DIR_FALLING:
> *ev_reg = _mt_ev_regs;
> return 0;
> + case IIO_EV_DIR_EITHER:
> + if (!(data->chip_info->all_events
> + & MMA8452_INT_PULSE) ||
> + !(data->chip_info->enabled_events
> + & MMA8452_INT_PULSE))
> + return -EINVAL;
> + *ev_reg = _ev_regs;
> + return 0;
> default:
> return -EINVAL;
> }
> @@ -848,6 +880,25 @@ static int mma8452_read_event_value(struct iio_dev
> *indio_dev,
> return ret;
> }
>
> + case IIO_EV_INFO_HYSTERESIS:
> + if (!(data->chip_info->all_events & MMA8452_INT_PULSE) ||
> + !(data->chip_info->enabled_events & MMA8452_INT_PULSE))
> + return -EINVAL;
> +
> + ret = i2c_smbus_read_byte_data(data->client,
> + MMA8452_PULSE_LTCY);
> + if (ret < 0)
> + return ret;
> +
> + power_mode = mma8452_get_power_mode(data);
> + if (power_mode < 0)
> + return power_mode;
> +
> + us = ret * mma8452_time_step_us[power_mode][
> + mma8452_get_odr_index(data)];
> + *val = us / USEC_PER_SEC;
> + *val2 = us % USEC_PER_SEC;
> +
> return IIO_VAL_INT_PLUS_MICRO;
Re: [PATCH] iio: mma8452: add power_mode sysfs configuration
On 2017-11-11 01:33, Jonathan Cameron wrote: > On Mon, 6 Nov 2017 08:19:58 +0100 > Martin Kepplinger wrote: > >> This adds the power_mode sysfs interface to the device as documented in >> sysfs-bus-iio. >> >> --- >> >> Note that I explicitely don't sign off on this. >> >> This is a starting point for anybody who can test it and check for correct >> API usage, and ABI correctness, as documented in >> Documentation/ABI/testing/sys-bus-iio >> (grep it for "power_mode"). The ABI doc probably would need an addition >> too, if the 4 power modes here seem generally useful (there are only >> 2 listed there)! >> >> So, if you can test this, feel free to set up a proper patch or >> two, and I'm happy to review. >> >> Please note that this patch is quite old. It really should be that simple >> as far as my understanding back then. We always list the available >> frequencies >> of the given power mode we are in, for example, already, and everything >> basically is in place except for the user interface. > > Hmm. A lot of devices support something along these lines. The issue > has always been - how is userspace to figure out what to do with it? > It's all very vague... > > Funnily enough - this used to be really common, but is becoming less so > now - presumably because no one was using it much (or maybe I am reading > too much into that ;) > > Now the question is whether it can be tied to better defined things? > > Here low noise restricts the range to 4g. Issue is that we don't actually > have writeable _available attributes (which correspond to range in this case). > Does it? Isn't it merely less oversampling. > Low power mode... This one is apparently oversampling. If possible support > it as that as we have well defined interfaces for that. > > Jonathan. Ah, I remember; the oversampling settings was actually a reason why I hadn't submitted the patch :) The oversampling API would definitely be more accurate. I would like "oversampling" more than this "power_mode" too. For this driver it would be far more complicated to implement though. I doubt that it'll be done. power_mode is basically already there implicitely, and given that there *is* the ABI, we could offer it for free. But given your concerns, I would strip down this patch to only offer the already documented "low_noise" and "low_power" modes. It wouldn't be worth it to extend the ABI just because of this! Users would have a simple switch if they don't really *want* to know the details. I think it can be useful to just say "I don't care about power consuption. Be as accurate as possible" or "I just want this think to work. Use a little power as possible." Sure it's vage, but would it be useless?
Re: [PATCH] iio: accel: mma8452: Add single pulse/tap event detection
Am 14.11.2017 05:36 schrieb harinath Nampally:
> This patch adds following related changes:
> - defines pulse event related registers
> - enables and handles single pulse interrupt for fxls8471
> - handles IIO_EV_DIR_EITHER in read/write callbacks (because
> event direction for pulse is either rising or falling)
> - configures read/write event value for pulse latency register
> using IIO_EV_INFO_HYSTERESIS
> - adds multiple events like pulse and tranient event spec
> as elements of event_spec array named 'mma8452_accel_events'
>
> Except mma8653 chip all other chips like mma845x and
> fxls8471 have single tap detection feature.
> Tested thoroughly using iio_event_monitor application on
> imx6ul-evk board which has fxls8471.
>
> Signed-off-by: Harinath Nampally
> ---
What tree is this written against? It doesn't apply to the current
-next
anyways.
Thanks for the review.
It is actually against 'testing' branch, I think two of my earlier
patches are not yet applied to
any branch, that might be reason this patch is not good against
current -next or 'togreg'.
I think the defintions would deserve to be in a separate patch, but
that's debatable.
Yes, I would argue that definitions are not a logical change.
I would argue definitions don't break the build and maybe slightly
better
support features like bisect or revert :)
> .type = IIO_EV_TYPE_MAG,
> .dir = IIO_EV_DIR_RISING,
> .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> @@ -1139,6 +1274,15 @@ static const struct iio_event_spec
mma8452_transient_event[] = {
> BIT(IIO_EV_INFO_PERIOD) |
> BIT(IIO_EV_INFO_HIGH_PASS_FILTER_3DB)
> },
> + {
> + //pulse event
> + .type = IIO_EV_TYPE_MAG,
> + .dir = IIO_EV_DIR_EITHER,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> + .mask_shared_by_type = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_PERIOD) |
> + BIT(IIO_EV_INFO_HYSTERESIS)
> + },
> };
>
> static const struct iio_event_spec mma8452_motion_event[] = {
> @@ -1202,8 +1346,8 @@ static struct attribute_group
mma8452_event_attribute_group = {
> .shift = 16 - (bits), \
> .endianness = IIO_BE, \
> }, \
> - .event_spec = mma8452_transient_event, \
> - .num_event_specs = ARRAY_SIZE(mma8452_transient_event), \
> + .event_spec = mma8452_accel_events, \
> + .num_event_specs = ARRAY_SIZE(mma8452_accel_events), \
that would go in the mentioned separate renaming-patch
OK so I will make a patch set; patch 1/2 to just rename
'mma8452_transient_event[]'
to 'mma8452_accel_events[]'(without adding pulse event).
and everything else would go in 2/2. Does that makes sense?
It does to me.
Re: [PATCH] iio: mma8452: add power_mode sysfs configuration
Am 14.11.2017 05:56 schrieb harinath Nampally: Hi Martin, But given your concerns, I would strip down this patch to only offer the already documented "low_noise" and "low_power" modes. It wouldn't be worth it to extend the ABI just because of this! OK then we can map 'low_noise' to high resolution mode. But I am afraid I can't test the functionality because I don't have proper instruments to measure the current draw(in microAmps) accurately. I would like "oversampling" more than this "power_mode" too. For this driver it would be far more complicated to implement though. I doubt that it'll be done. power_mode is basically already there implicitely, and given that there *is* the ABI, we could offer it for free. I think 'oversampling' is already implemented, as I see 'case IIO_CHAN_INFO_OVERSAMPLING_RATIO:' being handled which is basically setting the all 4 different power modes. If we also add 'power_mode', I think it would be like having two different user interfaces for same functionality. So I don't see much of value adding 'power_mode' as well. Please correct me if I am wrong. Thanks, Harinath You're right. I should've looked more closely. oversampling is there and seems to work. No need to blow up this driver or let alone extend an ABI now. Let's drop this patch. thanks martin On Sun, Nov 12, 2017 at 7:28 AM, Martin Kepplinger wrote: On 2017-11-11 01:33, Jonathan Cameron wrote: On Mon, 6 Nov 2017 08:19:58 +0100 Martin Kepplinger wrote: This adds the power_mode sysfs interface to the device as documented in sysfs-bus-iio. --- Note that I explicitely don't sign off on this. This is a starting point for anybody who can test it and check for correct API usage, and ABI correctness, as documented in Documentation/ABI/testing/sys-bus-iio (grep it for "power_mode"). The ABI doc probably would need an addition too, if the 4 power modes here seem generally useful (there are only 2 listed there)! So, if you can test this, feel free to set up a proper patch or two, and I'm happy to review. Please note that this patch is quite old. It really should be that simple as far as my understanding back then. We always list the available frequencies of the given power mode we are in, for example, already, and everything basically is in place except for the user interface. Hmm. A lot of devices support something along these lines. The issue has always been - how is userspace to figure out what to do with it? It's all very vague... Funnily enough - this used to be really common, but is becoming less so now - presumably because no one was using it much (or maybe I am reading too much into that ;) Now the question is whether it can be tied to better defined things? Here low noise restricts the range to 4g. Issue is that we don't actually have writeable _available attributes (which correspond to range in this case). Does it? Isn't it merely less oversampling. Low power mode... This one is apparently oversampling. If possible support it as that as we have well defined interfaces for that. Jonathan. Ah, I remember; the oversampling settings was actually a reason why I hadn't submitted the patch :) The oversampling API would definitely be more accurate. I would like "oversampling" more than this "power_mode" too. For this driver it would be far more complicated to implement though. I doubt that it'll be done. power_mode is basically already there implicitely, and given that there *is* the ABI, we could offer it for free. But given your concerns, I would strip down this patch to only offer the already documented "low_noise" and "low_power" modes. It wouldn't be worth it to extend the ABI just because of this! Users would have a simple switch if they don't really *want* to know the details. I think it can be useful to just say "I don't care about power consuption. Be as accurate as possible" or "I just want this think to work. Use a little power as possible." Sure it's vage, but would it be useless?
[PATCH] kernel: replace FSF address with web source in license notices
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this still in our source files feels old and unmaintained. As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the postal address with "<http://www.gnu.org/licenses/>". Signed-off-by: Martin Kepplinger --- This is an attempt to sneak this in in one go for the kernel directory. I think it's important to take the license statement serious and to not confuse users. If this should go in as seperate patches, each to their lists, please say so. thanks martin kernel/audit.c | 3 +-- kernel/audit.h | 3 +-- kernel/audit_watch.c| 3 +-- kernel/auditfilter.c| 3 +-- kernel/auditsc.c| 3 +-- kernel/events/hw_breakpoint.c | 3 +-- kernel/events/uprobes.c | 3 +-- kernel/extable.c| 3 +-- kernel/futex.c | 3 +-- kernel/kprobes.c| 3 +-- kernel/module.c | 3 +-- kernel/params.c | 3 +-- kernel/time/timeconv.c | 3 +-- kernel/trace/trace_events_filter.c | 3 +-- kernel/trace/trace_events_trigger.c | 3 +-- kernel/trace/trace_kprobe.c | 3 +-- kernel/trace/trace_probe.c | 3 +-- kernel/trace/trace_probe.h | 3 +-- kernel/trace/trace_uprobe.c | 3 +-- kernel/tracepoint.c | 3 +-- 20 files changed, 20 insertions(+), 40 deletions(-) diff --git a/kernel/audit.c b/kernel/audit.c index 227db99b0f19..1aa743f21c0d 100644 --- a/kernel/audit.c +++ b/kernel/audit.c @@ -16,8 +16,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * Written by Rickard E. (Rik) Faith * diff --git a/kernel/audit.h b/kernel/audit.h index af5bc59487ed..27f01e30a0db 100644 --- a/kernel/audit.h +++ b/kernel/audit.h @@ -15,8 +15,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c index 9eb8b3511636..93cb46c5dbe1 100644 --- a/kernel/audit_watch.c +++ b/kernel/audit_watch.c @@ -15,8 +15,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c index 4a1758adb222..5e61702b06cd 100644 --- a/kernel/auditfilter.c +++ b/kernel/auditfilter.c @@ -15,8 +15,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt diff --git a/kernel/auditsc.c b/kernel/auditsc.c index e80459f7e132..7ef2078334b6 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -17,8 +17,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * Written by Rickard E. (Rik) Faith * diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c index 3f8cb1e14588..4aaf161870a1 100644 --- a/kernel/events/hw_breakpoint.c +++ b/kernel/events/hw_breakpoint.c @@ -10,8 +10,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * Copyright (C) 2007 Alan Stern * Copyright (C) IBM Corporation, 2009 diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 267f6ef91d97..5d9835116f08 100644 --- a/kernel/
[PATCH] crypto: replace FSF address with web source in license notices
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this still in our source files feels old and unmaintained. Let's take the license statement serious and not confuse users. As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the postal address with "<http://www.gnu.org/licenses/>". Signed-off-by: Martin Kepplinger --- crypto/ablk_helper.c | 4 +--- crypto/camellia_generic.c | 3 +-- crypto/cast5_generic.c| 3 +-- crypto/cast6_generic.c| 3 +-- crypto/simd.c | 4 +--- crypto/twofish_common.c | 5 ++--- crypto/twofish_generic.c | 5 ++--- crypto/xcbc.c | 3 +-- 8 files changed, 10 insertions(+), 20 deletions(-) diff --git a/crypto/ablk_helper.c b/crypto/ablk_helper.c index 1441f07d0a19..6e5d2f149b89 100644 --- a/crypto/ablk_helper.c +++ b/crypto/ablk_helper.c @@ -18,9 +18,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 - * USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * */ diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c index a02286bf319e..32ddd4836ff5 100644 --- a/crypto/camellia_generic.c +++ b/crypto/camellia_generic.c @@ -13,8 +13,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ /* diff --git a/crypto/cast5_generic.c b/crypto/cast5_generic.c index df5c72629383..66169c178314 100644 --- a/crypto/cast5_generic.c +++ b/crypto/cast5_generic.c @@ -16,8 +16,7 @@ * any later version. * * You should have received a copy of the GNU General Public License -* along with this program; if not, write to the Free Software -* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA +* along with this program. If not, see <http://www.gnu.org/licenses/>. */ diff --git a/crypto/cast6_generic.c b/crypto/cast6_generic.c index 058c8d755d03..c8e5ec69790e 100644 --- a/crypto/cast6_generic.c +++ b/crypto/cast6_generic.c @@ -13,8 +13,7 @@ * any later version. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ diff --git a/crypto/simd.c b/crypto/simd.c index 88203370a62f..208226d7f908 100644 --- a/crypto/simd.c +++ b/crypto/simd.c @@ -19,9 +19,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 - * USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * */ diff --git a/crypto/twofish_common.c b/crypto/twofish_common.c index 5f62c4f9f6e0..f3a0dd25f871 100644 --- a/crypto/twofish_common.c +++ b/crypto/twofish_common.c @@ -24,9 +24,8 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 - * USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. + * * * This code is a "clean room" implementation, written from the paper * _Twofish: A 128-Bit Block Cipher_ by Bruce Schneier, John Kelsey, diff --git a/crypto/twofish_generic.c b/crypto/twofish_generic.c index ebf7a3efb572..07e62433fbfb 100644 --- a/crypto/twofish_generic.c +++ b/crypto/twofish_generic.c @@ -23,9 +23,8 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 - * USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. + * * * This code is a "clean room" implementation, written from the paper * _Twofish: A 128-Bit Block Cipher_ by Bruce Schneier, John Kelsey, diff --git a/crypto/xcbc.c b/crypto/xcbc.c index df90b332554c..25c75af50d3f 100644 --- a/crypto/xcbc.c +++ b/crypto/xcbc.c @@ -12,8 +12,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to th
[PATCH] init: replace FSF address with web source in license notices
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this still in our source files feels old and unmaintained. Let's take the license statement serious and not confuse users. As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the postal address with "<http://www.gnu.org/licenses/>". Signed-off-by: Martin Kepplinger --- init/noinitramfs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/init/noinitramfs.c b/init/noinitramfs.c index 267739d85179..3ee9e3dbfbc4 100644 --- a/init/noinitramfs.c +++ b/init/noinitramfs.c @@ -14,8 +14,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include #include -- 2.11.0
[PATCH] lib: replace FSF address with web source in license notices
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this still in our source files feels old and unmaintained. Let's take the license statement serious and not confuse users. As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the postal address with "<http://www.gnu.org/licenses/>" in the lib directory. Signed-off-by: Martin Kepplinger --- This is an attempt to sneak this in for the lib subdirectory in one go. If you would rather have the changes individually go to the relevant people, please just say so. thanks martin lib/decompress_unlzo.c| 3 +-- lib/dma-debug.c | 3 +-- lib/flex_array.c | 3 +-- lib/llist.c | 3 +-- lib/mpi/generic_mpih-add1.c | 3 +-- lib/mpi/generic_mpih-lshift.c | 3 +-- lib/mpi/generic_mpih-mul1.c | 3 +-- lib/mpi/generic_mpih-mul2.c | 3 +-- lib/mpi/generic_mpih-mul3.c | 3 +-- lib/mpi/generic_mpih-rshift.c | 3 +-- lib/mpi/generic_mpih-sub1.c | 3 +-- lib/mpi/longlong.h| 5 ++--- lib/mpi/mpi-bit.c | 3 +-- lib/mpi/mpi-cmp.c | 3 +-- lib/mpi/mpi-inline.h | 3 +-- lib/mpi/mpi-internal.h| 3 +-- lib/mpi/mpi-pow.c | 3 +-- lib/mpi/mpicoder.c| 3 +-- lib/mpi/mpih-cmp.c| 3 +-- lib/mpi/mpih-div.c| 3 +-- lib/mpi/mpih-mul.c| 3 +-- lib/mpi/mpiutil.c | 3 +-- lib/rbtree.c | 3 +-- lib/timerqueue.c | 3 +-- 24 files changed, 25 insertions(+), 49 deletions(-) diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c index f4c158e3a022..fa71c4dc0542 100644 --- a/lib/decompress_unlzo.c +++ b/lib/decompress_unlzo.c @@ -22,8 +22,7 @@ * * You should have received a copy of the GNU General Public License * along with this program; see the file COPYING. - * If not, write to the Free Software Foundation, Inc., - * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * If not, see <http://www.gnu.org/licenses/>. * * Markus F.X.J. Oberhumer * diff --git a/lib/dma-debug.c b/lib/dma-debug.c index e5b4237da650..d76e5c1a495c 100644 --- a/lib/dma-debug.c +++ b/lib/dma-debug.c @@ -13,8 +13,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include diff --git a/lib/flex_array.c b/lib/flex_array.c index 2eed22fa507c..234895ab27d9 100644 --- a/lib/flex_array.c +++ b/lib/flex_array.c @@ -12,8 +12,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * Copyright IBM Corporation, 2009 * diff --git a/lib/llist.c b/lib/llist.c index 7062e931a7bb..a56ba9f0350e 100644 --- a/lib/llist.c +++ b/lib/llist.c @@ -19,8 +19,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include #include diff --git a/lib/mpi/generic_mpih-add1.c b/lib/mpi/generic_mpih-add1.c index c94c7dd344b3..3c3e94556adb 100644 --- a/lib/mpi/generic_mpih-add1.c +++ b/lib/mpi/generic_mpih-add1.c @@ -15,8 +15,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * Note: This code is heavily based on the GNU MP Library. * Actually it's the same code with only minor changes in the diff --git a/lib/mpi/generic_mpih-lshift.c b/lib/mpi/generic_mpih-lshift.c index 86318927231a..84d0d800996c 100644 --- a/lib/mpi/generic_mpih-lshift.c +++ b/lib/mpi/generic_mpih-lshift.c @@ -14,8 +14,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * Note: This code is heavily based on the GNU MP Library. * Actually it's
[PATCH] mm: replace FSF address with web source in license notices
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this still in our source files feels old and unmaintained. Let's take the license statement serious and not confuse users. As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the postal address with "<http://www.gnu.org/licenses/>" in the mm directory. Signed-off-by: Martin Kepplinger --- mm/kmemleak-test.c | 3 +-- mm/kmemleak.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/kmemleak-test.c b/mm/kmemleak-test.c index dd3c23a801b1..9a13ad2c0cca 100644 --- a/mm/kmemleak-test.c +++ b/mm/kmemleak-test.c @@ -14,8 +14,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #define pr_fmt(fmt) "kmemleak: " fmt diff --git a/mm/kmemleak.c b/mm/kmemleak.c index e4738d5e9b8c..e6d6d3c9f543 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -14,8 +14,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * * For more information on the algorithm and kmemleak usage, please see -- 2.11.0
[PATCH] samples: replace FSF address with web source in license notices
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this still in our source files feels old and unmaintained. Let's take the license statement serious and not confuse users. As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the postal address with "<http://www.gnu.org/licenses/>" in the samples directory. Signed-off-by: Martin Kepplinger --- samples/auxdisplay/cfag12864b-example.c | 3 +-- samples/configfs/configfs_sample.c | 6 ++ samples/connector/cn_test.c | 3 +-- samples/connector/ucon.c| 3 +-- samples/hw_breakpoint/data_breakpoint.c | 3 +-- 5 files changed, 6 insertions(+), 12 deletions(-) diff --git a/samples/auxdisplay/cfag12864b-example.c b/samples/auxdisplay/cfag12864b-example.c index e7823ffb1ca0..fc8b4c6c655f 100644 --- a/samples/auxdisplay/cfag12864b-example.c +++ b/samples/auxdisplay/cfag12864b-example.c @@ -17,8 +17,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * */ diff --git a/samples/configfs/configfs_sample.c b/samples/configfs/configfs_sample.c index 004a4e201476..43810e6c745d 100644 --- a/samples/configfs/configfs_sample.c +++ b/samples/configfs/configfs_sample.c @@ -15,10 +15,8 @@ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * - * You should have received a copy of the GNU General Public - * License along with this program; if not, write to the - * Free Software Foundation, Inc., 59 Temple Place - Suite 330, - * Boston, MA 021110-1307, USA. + * You should have received a copy of the GNU General Public License + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * Based on sysfs: * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel diff --git a/samples/connector/cn_test.c b/samples/connector/cn_test.c index 95cd06f4ec1e..48dfe47e65a5 100644 --- a/samples/connector/cn_test.c +++ b/samples/connector/cn_test.c @@ -15,8 +15,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #define pr_fmt(fmt) "cn_test: " fmt diff --git a/samples/connector/ucon.c b/samples/connector/ucon.c index 8a4da64e02a8..1943aba7e903 100644 --- a/samples/connector/ucon.c +++ b/samples/connector/ucon.c @@ -15,8 +15,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include diff --git a/samples/hw_breakpoint/data_breakpoint.c b/samples/hw_breakpoint/data_breakpoint.c index ef7f32291852..7ff5db0ccfe9 100644 --- a/samples/hw_breakpoint/data_breakpoint.c +++ b/samples/hw_breakpoint/data_breakpoint.c @@ -12,8 +12,7 @@ * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * along with this program. If not, see <http://www.gnu.org/licenses/>. * * usage: insmod data_breakpoint.ko ksym= * -- 2.11.0
Re: [PATCH] mm: replace FSF address with web source in license notices
Am 14.11.2017 10:49 schrieb Michal Hocko: On Tue 14-11-17 10:44:38, Martin Kepplinger wrote: A few years ago the FSF moved and "59 Temple Place" is wrong. Having this still in our source files feels old and unmaintained. Let's take the license statement serious and not confuse users. As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the postal address with "<http://www.gnu.org/licenses/>" in the mm directory. Why to change this now? Isn't there a general plan to move to SPDX? Shouldn't a move to SPDX only be additions to what we currently have? That's at least what the "reuse" project suggests, see https://reuse.software/practices/ with "Don’t remove existing headers, but only add to them." thanks martin
[PATCH] scripts: replace FSF address with web source in license notices
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.
Let's take the license statement serious and not confuse users.
As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "<http://www.gnu.org/licenses/>" in the scripts
directory.
Signed-off-by: Martin Kepplinger
---
scripts/dtc/checks.c| 4 +---
scripts/dtc/data.c | 4 +---
scripts/dtc/dtc-lexer.l | 4 +---
scripts/dtc/dtc-lexer.lex.c_shipped | 4 +---
scripts/dtc/dtc-parser.y| 4 +---
scripts/dtc/dtc.c | 4 +---
scripts/dtc/fdtget.c| 4 +---
scripts/dtc/fdtput.c| 4 +---
scripts/dtc/flattree.c | 4 +---
scripts/dtc/fstree.c| 4 +---
scripts/dtc/livetree.c | 4 +---
scripts/dtc/srcpos.c| 4 +---
scripts/dtc/srcpos.h| 4 +---
scripts/dtc/treesource.c| 4 +---
scripts/dtc/util.c | 4 +---
scripts/dtc/util.h | 4 +---
scripts/genksyms/genksyms.c | 4 ++--
scripts/genksyms/genksyms.h | 4 ++--
scripts/genksyms/lex.l | 4 ++--
scripts/genksyms/lex.lex.c_shipped | 4 ++--
scripts/genksyms/parse.y| 4 ++--
scripts/selinux/mdp/mdp.c | 3 +--
22 files changed, 27 insertions(+), 60 deletions(-)
diff --git a/scripts/dtc/checks.c b/scripts/dtc/checks.c
index e66138449886..27dd1e0de47a 100644
--- a/scripts/dtc/checks.c
+++ b/scripts/dtc/checks.c
@@ -13,9 +13,7 @@
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "dtc.h"
diff --git a/scripts/dtc/data.c b/scripts/dtc/data.c
index aa37a16c8891..ed6ab5817603 100644
--- a/scripts/dtc/data.c
+++ b/scripts/dtc/data.c
@@ -13,9 +13,7 @@
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "dtc.h"
diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
index fd825ebba69c..164798e6e9ce 100644
--- a/scripts/dtc/dtc-lexer.l
+++ b/scripts/dtc/dtc-lexer.l
@@ -13,9 +13,7 @@
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
%option noyywrap nounput noinput never-interactive
diff --git a/scripts/dtc/dtc-lexer.lex.c_shipped
b/scripts/dtc/dtc-lexer.lex.c_shipped
index 011bb9632ff2..fd5b12a283be 100644
--- a/scripts/dtc/dtc-lexer.lex.c_shipped
+++ b/scripts/dtc/dtc-lexer.lex.c_shipped
@@ -618,9 +618,7 @@ char *yytext;
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#define YY_NO_INPUT 1
diff --git a/scripts/dtc/dtc-parser.y b/scripts/dtc/dtc-parser.y
index affc81a8f9ab..e3a3b155ace8 100644
--- a/scripts/dtc/dtc-parser.y
+++ b/scripts/dtc/dtc-parser.y
@@ -13,9 +13,7 @@
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
- * USA
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
%{
#include
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index 5ed873c72ad1..da967e7a8050 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -13,9 +13,7 @@
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
- * along with this program; if not, write to
[PATCH] security: replace FSF address with web source in license notices
A few years ago the FSF moved and "59 Temple Place" is wrong. Having this still in our source files feels old and unmaintained. Let's take the license statement serious and not confuse users. As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the postal address with "<http://www.gnu.org/licenses/>" in the security directory. Signed-off-by: Martin Kepplinger --- security/selinux/include/netlabel.h | 3 +-- security/selinux/netlabel.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/security/selinux/include/netlabel.h b/security/selinux/include/netlabel.h index 75686d53df07..e77a5e307955 100644 --- a/security/selinux/include/netlabel.h +++ b/security/selinux/include/netlabel.h @@ -19,8 +19,7 @@ * the GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * */ diff --git a/security/selinux/netlabel.c b/security/selinux/netlabel.c index aaba6677ee2e..2c297b995b16 100644 --- a/security/selinux/netlabel.c +++ b/security/selinux/netlabel.c @@ -22,8 +22,7 @@ * the GNU General Public License for more details. * * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * along with this program. If not, see <http://www.gnu.org/licenses/>. * */ -- 2.11.0
Re: [PATCH] mm: replace FSF address with web source in license notices
Am 14.11.2017 11:02 schrieb Michal Hocko: On Tue 14-11-17 10:55:35, Martin Kepplinger wrote: Am 14.11.2017 10:49 schrieb Michal Hocko: > On Tue 14-11-17 10:44:38, Martin Kepplinger wrote: > > A few years ago the FSF moved and "59 Temple Place" is wrong. Having > > this > > still in our source files feels old and unmaintained. > > > > Let's take the license statement serious and not confuse users. > > > > As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace > > the > > postal address with "<http://www.gnu.org/licenses/>" in the mm > > directory. > > Why to change this now? Isn't there a general plan to move to SPDX? Shouldn't a move to SPDX only be additions to what we currently have? That's at least what the "reuse" project suggests, see https://reuse.software/practices/ with "Don’t remove existing headers, but only add to them." I thought the primary motivation was to unify _all_ headers and get rid of all the duplication. (aside from files which do not have any license which is under discussion elsewhere). I doubt that this can be fully accieved in the long run :) It'd be nice of course in some way. But I also doubt that it'd be so easy to remove the permission statements. The FSF who's license we use suggest to have them, but others do too. And as mentioned, "using SPDX" doesn't imply "not having permission statements". But I think that's off-topic actually. Moving to SPDX could still be done in any way whatsoever after this. This change fixes a *mistake* and can reduce confusion or even support license compliance, who knows :) thanks martin
[PATCH] media: coda: Fix definition of CODA_STD_MJPG
According to i.MX 6 VPU API Reference Manual Rev. L3.0.35_1.1.0, 01/2013 chapter 3.2.1.5, the MJPG video codec is refernced to by number 7, not 3. So change this accordingly. This isn't yet being used right now and therefore probably hasn't been noticed. Fixing this avoids causing trouble in the future. Signed-off-by: Martin Kepplinger --- drivers/media/platform/coda/coda_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/coda/coda_regs.h b/drivers/media/platform/coda/coda_regs.h index 38df5fd9a2fa..8d726faaf86e 100644 --- a/drivers/media/platform/coda/coda_regs.h +++ b/drivers/media/platform/coda/coda_regs.h @@ -254,7 +254,7 @@ #defineCODA9_STD_H264 0 #defineCODA_STD_H263 1 #defineCODA_STD_H264 2 -#defineCODA_STD_MJPG 3 +#defineCODA_STD_MJPG 7 #defineCODA9_STD_MPEG4 3 #define CODA_CMD_ENC_SEQ_SRC_SIZE 0x190 -- 2.11.0
[PATCH] media: coda: remove definition of CODA_STD_MJPG
According to i.MX VPU API Reference Manuals the MJPG video codec is refernced to by number 7, not 3. Also Philipp pointed out that this value is only meant to fill in CMD_ENC_SEQ_COD_STD for encoding, only on i.MX53. It was never written to any register, and even if defined correctly, wouldn't be needed for i.MX6. So avoid confusion and remove this definition. Signed-off-by: Martin Kepplinger --- drivers/media/platform/coda/coda_regs.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/media/platform/coda/coda_regs.h b/drivers/media/platform/coda/coda_regs.h index 38df5fd9a2fa..35e620c7f1f4 100644 --- a/drivers/media/platform/coda/coda_regs.h +++ b/drivers/media/platform/coda/coda_regs.h @@ -254,7 +254,6 @@ #defineCODA9_STD_H264 0 #defineCODA_STD_H263 1 #defineCODA_STD_H264 2 -#defineCODA_STD_MJPG 3 #defineCODA9_STD_MPEG4 3 #define CODA_CMD_ENC_SEQ_SRC_SIZE 0x190 -- 2.11.0
Re: [PATCH] iio: mma8452: add power_mode sysfs configuration
Am 09.11.2017 04:19 schrieb harinath Nampally: Hi Martin, Thanks for publishing the patch. I will work on it, but unfortunately I can't promise anything before 11/27. perfectly fine, this patch has been lying around here for at least a year, so there's no rush.
[PATCH] media: coda: fix comparision of decoded frames' indexes
At this point the driver looks the currently decoded frame's index
and compares is to VPU-specific state values. Directly before this
if and else statements the indexes are read (index for decoded and
for displayed frame).
Now what is saved in ctx->display_idx is an older value at this point!
During these index checks, the current values apply, so fix this by
taking display_idx instead of ctx->display_idx.
ctx->display_idx is updated later in the same function.
Signed-off-by: Martin Kepplinger
---
Please review this thoroughly, but in case I am wrong here, this is
at least very strange to read and *should* be accompanied with a
comment about what's going on with that index value!
I don't think it matter that much here because at least playing h264
worked before and works with this change, but I've tested it anyways.
thanks
martin
drivers/media/platform/coda/coda-bit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index bfc4ecf6f068..fe38527a90e2 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2089,7 +2089,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
/* no frame was decoded, but we might have a display frame */
if (display_idx >= 0 && display_idx < ctx->num_internal_frames)
ctx->sequence_offset++;
- else if (ctx->display_idx < 0)
+ else if (display_idx < 0)
ctx->hold = true;
} else if (decoded_idx == -2) {
/* no frame was decoded, we still return remaining buffers */
--
2.11.0
Re: [PATCH] samples: replace outdated permission statement with SPDX identifiers
On 2017-11-17 23:53, Jonathan Corbet wrote: > On Thu, 16 Nov 2017 12:41:10 +0100 > Greg KH wrote: > >>> I'll fold this in, in the thread here. I guess this change is what Greg >>> had in mind? Or would you prefer having including SPDX and removing >>> permission statement seperately? >> >> I have been doing them in 2 steps, but only because the files I modified >> were in different "chunks" (i.e. add missing SPDX identifiers to a bunch >> of files in a directory, and then the second patch would remove the >> license identifiers for all files in that directory). As that type of >> patch flow doesn't make sense here, I think what you did was just fine. > > So I'll confess to being a little worried about removing the boilerplate: > > And it's important to notice that while adding a SPDX line should > not really be controversial (as long as you get the license right, > of course - Greg have the CSV files for everything, in case you > want to check things you maintain), before removing the > boiler-plate you really need to feel like you "own" the file. > — Linus (https://lkml.org/lkml/2017/11/2/715) > > Are we sure that we're not going to get in trouble with the people who do > "own" those files if we rip out the boilerplate? It would be good to have > some clarity on when that can be done. > > Thanks, > > jon > Greg, I assume you are well aware that I initially simply wanted to correct an actual mistake in the permission statements with my proposed changed. I asked whether you know about any consesus met before doing something like removing people's permission statements. That's because the FSF's "reuse" project pushing SPDX, for example says "Don't remove any license texts", see https://reuse.software/practices/ and "Don’t remove existing headers, but only add to them." It may well be that that's not the all there's to it and that there's other ways. But Greg, people are listening to you. Please don't give advice in directions that are not clearly correct for Linux. You know you could have simply ack'd the initial mistake-fix in that case. It wouldn't have hurt anybody. just saying because it'd be nice to rely on things you say :) thanks martin
Re: [PATCH] samples: replace outdated permission statement with SPDX identifiers
On 2017-11-18 01:13, Jonathan Corbet wrote: > On Sat, 18 Nov 2017 00:43:46 +0100 > Martin Kepplinger wrote: > >> But Greg, people are listening to you. Please don't give advice in >> directions that are not clearly correct for Linux. You know you could >> have simply ack'd the initial mistake-fix in that case. It wouldn't have >> hurt anybody. > > Sigh, it wasn't my intent to get Greg in trouble. > > Martin... please don't blame Greg here. What's going on (IMO) is that > you've stumbled into something that we have just now begun to figure > out. We very much *want* to rip out all that boilerplate, but we don't > yet have a consensus on the proper way to do it. We haven't really even > had the discussion yet. You've just had the poor luck to wander in at > the wrong time and become part of that discussion. > > I'll confess that, when I saw your first patch, it crossed my mind to > answer much like Greg did. But Greg always gets there first :) > Alright, noone is in trouble already I hope. Maybe I was a little harsh; sorry Greg. I know less about law than about programming which might have made me a little nervous here; In the end I want things to work for Linux. > The files that you are touching mostly have listed copyright holders in > them. Should you feel like putting a bit more energy into this, one > thing to do could be to copy them on a new posting of the patch and ask > for acks. Assuming you get them, we should be able to clean up a bit of > cruft in a way that's clearly supported by the copyright holders. > Makes sense. Thanks for clearing this up a bit! So as fixing your "own" files is easier, I'll do that first :) martin
[PATCH] input: pegasus_notetaker: add license information
This adds an SPDX license identifier to this driver I wrote some time back. Signed-off-by: Martin Kepplinger --- drivers/input/tablet/pegasus_notetaker.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/tablet/pegasus_notetaker.c b/drivers/input/tablet/pegasus_notetaker.c index 47de5a81172f..cdf75c989469 100644 --- a/drivers/input/tablet/pegasus_notetaker.c +++ b/drivers/input/tablet/pegasus_notetaker.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Pegasus Mobile Notetaker Pen input tablet driver * -- 2.11.0
[PATCH v2] iio: mma8452: replace license description with SPDX specifier
This replaces the custom license information text with the appropriate SPDX identifier. While the information here stays the same, it is easier to read. Signed-off-by: Martin Kepplinger Acked-by: Peter Meerwald-Stadler --- Sorry I had forgotten to add the mailing lists and got Peter's Ack privately. -.- But thanks Peter for the quick response! Again, an Acked-by from Harinath would be good here too. thanks martin revision history v2: adds Peter's Acked-by and adds all mailing lists to CC drivers/iio/accel/mma8452.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c index bfd4bc806fc2..62c0d4646c16 100644 --- a/drivers/iio/accel/mma8452.c +++ b/drivers/iio/accel/mma8452.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * mma8452.c - Support for following Freescale / NXP 3-axis accelerometers: * @@ -13,9 +14,6 @@ * Copyright 2015 Martin Kepplinger * Copyright 2014 Peter Meerwald * - * This file is subject to the terms and conditions of version 2 of - * the GNU General Public License. See the file COPYING in the main - * directory of this archive for more details. * * TODO: orientation events */ -- 2.11.0
Re: [PATCH] samples: replace outdated permission statement with SPDX identifiers
On 2017-11-18 11:17, Greg KH wrote: > On Fri, Nov 17, 2017 at 03:53:53PM -0700, Jonathan Corbet wrote: >> On Thu, 16 Nov 2017 12:41:10 +0100 >> Greg KH wrote: >> I'll fold this in, in the thread here. I guess this change is what Greg had in mind? Or would you prefer having including SPDX and removing permission statement seperately? >>> >>> I have been doing them in 2 steps, but only because the files I modified >>> were in different "chunks" (i.e. add missing SPDX identifiers to a bunch >>> of files in a directory, and then the second patch would remove the >>> license identifiers for all files in that directory). As that type of >>> patch flow doesn't make sense here, I think what you did was just fine. >> >> So I'll confess to being a little worried about removing the boilerplate: >> >> And it's important to notice that while adding a SPDX line should >> not really be controversial (as long as you get the license right, >> of course - Greg have the CSV files for everything, in case you >> want to check things you maintain), before removing the >> boiler-plate you really need to feel like you "own" the file. >> — Linus (https://lkml.org/lkml/2017/11/2/715) >> >> Are we sure that we're not going to get in trouble with the people who do >> "own" those files if we rip out the boilerplate? It would be good to have >> some clarity on when that can be done. > > I have discussed this with many lawyers, and as SPDX is acknowledged as > a valid way to specify the license that a file is released under, > removing the "boilerplate" text is just fine according to all of them. > > As a backup to this, I have verification from at the legal department of > at least one very large corporate copyright holder in the kernel that > this is fine with them, and they are glad to see this happen, as now we > will not have 700+ different ways to say "released under the GPL v2" in > the tree. You can see one of the patch series on lkml where I say I got > their approval as proof. > > So yes, this should be fine, but of course, ask the copyright holder of > the file when doing this. I have been cc:ing the owners of the files > when I do this work, and have gotten no objections so far when doing > this work. Ok that's probably important. Even if not strictly necessary, at least when I get acks from all copyright holder, I feel this is safe to do for me or anybody. Thanks. That's annoying work and I appreciate it.
Re: [PATCH v4] iio: accel: mma8452: improvements to handle multiple events
Thanks. I may have missed something, but I'm concerned about only one
thing:
devices without transient event registers. See my comments below.
Am 20.08.2017 18:06 schrieb Harinath Nampally:
This driver supports multiple devices like mma8653,
mma8652, mma8452, mma8453 and fxls8471. Almost all
these devices have more than one event.
Current driver design hardcodes the event specific
information, so only one event can be supported by this
driver at any given time.
Also current design doesn't have the flexibility to
add more events.
This patch improves by detaching the event related
information from chip_info struct,and based on channel
type and event direction the corresponding event
configuration registers are picked dynamically.
Hence both transient and freefall events can be
handled in read/write callbacks.
Changes are thoroughly tested on fxls8471 device on imx6UL
Eval board using iio_event_monitor user space program.
After this fix both Freefall and Transient events are
handled by the driver without any conflicts.
Changes since v3 -> v4
-Add 'const struct ev_regs_accel_falling'
-Add 'const struct ev_regs_accel_rising'
-Refactor mma8452_get_event_regs function to
remove the fill in the struct and return above structs
-Condense the commit's subject message
Changes since v2 -> v3
-Fix typo in commit message
-Replace word 'Bugfix' with 'Improvements'
-Describe more accurate commit message
-Replace breaks with returns
-Initialise transient event threshold mask
-Remove unrelated change of IIO_ACCEL channel type
check in read/write event callbacks
Changes since v1 -> v2
-Fix indentations
-Remove unused fields in mma8452_event_regs struct
-Remove redundant return statement
-Remove unrelated changes like checkpatch.pl warning fixes
Signed-off-by: Harinath Nampally
---
drivers/iio/accel/mma8452.c | 277
1 file changed, 123 insertions(+), 154 deletions(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index eb6e3dc..7bfc257 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -59,7 +59,9 @@
#define MMA8452_FF_MT_THS 0x17
#define MMA8452_FF_MT_THS_MASK0x7f
#define MMA8452_FF_MT_COUNT0x18
+#define MMA8452_FF_MT_CHAN_SHIFT 3
#define MMA8452_TRANSIENT_CFG 0x1d
+#define MMA8452_TRANSIENT_CFG_CHAN(chan) BIT(chan + 1)
#define MMA8452_TRANSIENT_CFG_HPF_BYP BIT(0)
#define MMA8452_TRANSIENT_CFG_ELE BIT(4)
#define MMA8452_TRANSIENT_SRC 0x1e
@@ -69,6 +71,7 @@
#define MMA8452_TRANSIENT_THS 0x1f
#define MMA8452_TRANSIENT_THS_MASKGENMASK(6, 0)
#define MMA8452_TRANSIENT_COUNT0x20
+#define MMA8452_TRANSIENT_CHAN_SHIFT 1
#define MMA8452_CTRL_REG1 0x2a
#define MMA8452_CTRL_ACTIVE BIT(0)
#define MMA8452_CTRL_DR_MASK GENMASK(5, 3)
@@ -107,6 +110,42 @@ struct mma8452_data {
const struct mma_chip_info *chip_info;
};
+ /**
+ * struct mma8452_event_regs - chip specific data related to events
+ * @ev_cfg: event config register address
+ * @ev_src: event source register address
+ * @ev_ths: event threshold register address
+ * @ev_ths_mask: mask for the threshold value
+ * @ev_count: event count (period) register address
+ *
+ * Since not all chips supported by the driver support comparing high
pass
+ * filtered data for events (interrupts), different interrupt sources
are
+ * used for different chips and the relevant registers are included
here.
+ */
+struct mma8452_event_regs {
+ u8 ev_cfg;
+ u8 ev_src;
+ u8 ev_ths;
+ u8 ev_ths_mask;
+ u8 ev_count;
+};
+
+static const struct mma8452_event_regs ev_regs_accel_falling = {
+ .ev_cfg = MMA8452_FF_MT_CFG,
+ .ev_src = MMA8452_FF_MT_SRC,
+ .ev_ths = MMA8452_FF_MT_THS,
+ .ev_ths_mask = MMA8452_FF_MT_THS_MASK,
+ .ev_count = MMA8452_FF_MT_COUNT
+};
+
+static const struct mma8452_event_regs ev_regs_accel_rising = {
+ .ev_cfg = MMA8452_TRANSIENT_CFG,
+ .ev_src = MMA8452_TRANSIENT_SRC,
+ .ev_ths = MMA8452_TRANSIENT_THS,
+ .ev_ths_mask = MMA8452_TRANSIENT_THS_MASK,
+ .ev_count = MMA8452_TRANSIENT_COUNT,
+};
For devices without transient event registers, this cannot work. See
below.
+
/**
* struct mma_chip_info - chip specific data
* @chip_id: WHO_AM_I register's value
@@ -116,40 +155,12 @@ struct mma8452_data {
* @mma_scales:
Re: [PATCH v5] iio: accel: mma8452: improvements to handle multiple events
Am 28.08.2017 02:23 schrieb Harinath Nampally:
This driver supports multiple devices like mma8653,
mma8652, mma8452, mma8453 and fxls8471. Almost all
these devices have more than one event.
Current driver design hardcodes the event specific
information, so only one event can be supported by this
driver at any given time.
Also current design doesn't have the flexibility to
add more events.
This patch improves by detaching the event related
information from chip_info struct,and based on channel
type and event direction the corresponding event
configuration registers are picked dynamically.
Hence both transient and freefall events can be
handled in read/write callbacks.
Changes are thoroughly tested on fxls8471 device on imx6UL
Eval board using iio_event_monitor user space program.
After this fix both Freefall and Transient events are
handled by the driver without any conflicts.
Changes since v4 -> v5
-Add supported_events and enabled_events
in chip_info structure so that devices(mma865x)
which has no support for transient event will
fallback to freefall event. Hence this patch changes
won't break for devices that can't support
transient events
Changes since v3 -> v4
-Add 'const struct ev_regs_accel_falling'
-Add 'const struct ev_regs_accel_rising'
-Refactor mma8452_get_event_regs function to
remove the fill in the struct and return above structs
-Condense the commit's subject message
Changes since v2 -> v3
-Fix typo in commit message
-Replace word 'Bugfix' with 'Improvements'
-Describe more accurate commit message
-Replace breaks with returns
-Initialise transient event threshold mask
-Remove unrelated change of IIO_ACCEL channel type
check in read/write event callbacks
Changes since v1 -> v2
-Fix indentations
-Remove unused fields in mma8452_event_regs struct
-Remove redundant return statement
-Remove unrelated changes like checkpatch.pl warning fixes
Signed-off-by: Harinath Nampally
---
drivers/iio/accel/mma8452.c | 349
+++-
1 file changed, 183 insertions(+), 166 deletions(-)
diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
index eb6e3dc..0a97e61b 100644
--- a/drivers/iio/accel/mma8452.c
+++ b/drivers/iio/accel/mma8452.c
@@ -59,7 +59,9 @@
#define MMA8452_FF_MT_THS 0x17
#define MMA8452_FF_MT_THS_MASK0x7f
#define MMA8452_FF_MT_COUNT0x18
+#define MMA8452_FF_MT_CHAN_SHIFT 3
#define MMA8452_TRANSIENT_CFG 0x1d
+#define MMA8452_TRANSIENT_CFG_CHAN(chan) BIT(chan + 1)
#define MMA8452_TRANSIENT_CFG_HPF_BYP BIT(0)
#define MMA8452_TRANSIENT_CFG_ELE BIT(4)
#define MMA8452_TRANSIENT_SRC 0x1e
@@ -69,6 +71,7 @@
#define MMA8452_TRANSIENT_THS 0x1f
#define MMA8452_TRANSIENT_THS_MASKGENMASK(6, 0)
#define MMA8452_TRANSIENT_COUNT0x20
+#define MMA8452_TRANSIENT_CHAN_SHIFT 1
#define MMA8452_CTRL_REG1 0x2a
#define MMA8452_CTRL_ACTIVE BIT(0)
#define MMA8452_CTRL_DR_MASK GENMASK(5, 3)
@@ -107,6 +110,42 @@ struct mma8452_data {
const struct mma_chip_info *chip_info;
};
+ /**
+ * struct mma8452_event_regs - chip specific data related to events
+ * @ev_cfg: event config register address
+ * @ev_src: event source register address
+ * @ev_ths: event threshold register address
+ * @ev_ths_mask: mask for the threshold value
+ * @ev_count: event count (period) register address
+ *
+ * Since not all chips supported by the driver support comparing high
pass
+ * filtered data for events (interrupts), different interrupt sources
are
+ * used for different chips and the relevant registers are included
here.
+ */
+struct mma8452_event_regs {
+ u8 ev_cfg;
+ u8 ev_src;
+ u8 ev_ths;
+ u8 ev_ths_mask;
+ u8 ev_count;
+};
+
+static const struct mma8452_event_regs ev_regs_accel_falling = {
+ .ev_cfg = MMA8452_FF_MT_CFG,
+ .ev_src = MMA8452_FF_MT_SRC,
+ .ev_ths = MMA8452_FF_MT_THS,
+ .ev_ths_mask = MMA8452_FF_MT_THS_MASK,
+ .ev_count = MMA8452_FF_MT_COUNT
+};
+
+static const struct mma8452_event_regs ev_regs_accel_rising = {
+ .ev_cfg = MMA8452_TRANSIENT_CFG,
+ .ev_src = MMA8452_TRANSIENT_SRC,
+ .ev_ths = MMA8452_TRANSIENT_THS,
+ .ev_ths_mask = MMA8452_TRANSIENT_THS_MASK,
+ .ev_count = MMA8452_TRANSIENT_COUNT,
+};
+
/**
* struct mma_chip_info - chip specific data
* @chip_id: WHO_AM_I register's value
@@ -116,40
Re: [PATCH v4] iio: accel: mma8452: improvements to handle multiple events
Am 23.08.2017 02:29 schrieb Harinath Nampally:
If rising: use transient OR ff_mt device-dependent like before. But
now save it in a simple flag,
whether transient registers are available.
Ok, is it good idea to add the flag to struct mma_chip_info like below?
* @mma_scales:scale factors for converting
register values
* to m/s^2; 3 modes: 2g, 4g, 8g; 2
integers
* per mode: m/s^2 and micro m/s^2
+ * @transient_supported: flag indicating whether chip support
transient
+ * event, as not all chips support
transient event
*/
struct mma_chip_info {
u8 chip_id;
const struct iio_chan_spec *channels;
int num_channels;
const int mma_scales[3][2];
+ bool transient_supported;
};
I'd avoid boolean and use int and define EVENT_TYPE_TRANSIENT BIT(1) and
EVENT_TYPE_FF_MT BIT(0) for example. So something like
"supported_event_types"
can have all types supported.
But this has quite some implications on your implementation, so your
complete
solution would be more interesting to see. Keep it simple and focus on
only this one
issue of enabling freefall (FF_MT registers) for the devices that
currently use
transient registers.
thanks
If falling: switch to ff_mt in any case. (fixing freefall for the
transient-devices)
ok sure.
Thanks,
Hari
On 08/21/2017 04:47 AM, Martin Kepplinger wrote:
If rising: use transient OR ff_mt device-dependent like before. But
now save it in a simple flag,
whether transient registers are available.
If falling: switch to ff_mt in any case. (fixing freefall for the
transient-devices)
[PATCH] tools: firewire: nosy-dump: fix a resource leak in main()
If option_input and option_output is true two files are opened
consecutively. In case the second fopen() fails, let's fclose()
the first one before returning early.
Signed-off-by: Martin Kepplinger
---
tools/firewire/nosy-dump.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/firewire/nosy-dump.c b/tools/firewire/nosy-dump.c
index 3179c711bd65..228be406f206 100644
--- a/tools/firewire/nosy-dump.c
+++ b/tools/firewire/nosy-dump.c
@@ -960,6 +960,8 @@ int main(int argc, const char *argv[])
output = fopen(option_output, "w");
if (output == NULL) {
fprintf(stderr, "Could not open %s, %m\n",
option_output);
+ if (input)
+ fclose(input);
return -1;
}
}
--
2.11.0
[PATCH] tools: hv: hv_kvp_daemon: fix usage of realloc()
realloc() returns NULL in case it fails. Since we don't save the
pointer in question elsewhere, we leak memory by assigning NULL
to the original memory in the heap.
realloc() doesn't free memory in case of failure, so let's do
it manually.
Signed-off-by: Martin Kepplinger
---
tools/hv/hv_kvp_daemon.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index eaa3bec273c8..0b3b18d0a6e3 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -231,6 +231,7 @@ static int kvp_file_init(void)
size_t records_read;
char *fname;
struct kvp_record *record;
+ struct kvp_record *record_tmp;
struct kvp_record *readp;
int num_blocks;
int i;
@@ -284,12 +285,15 @@ static int kvp_file_init(void)
* We have more data to read.
*/
num_blocks++;
- record = realloc(record, alloc_unit *
+ record_tmp = realloc(record, alloc_unit *
num_blocks);
- if (record == NULL) {
+ if (!record_tmp) {
+ free(record);
fclose(filep);
close(fd);
return 1;
+ } else {
+ record = record_tmp;
}
continue;
}
@@ -355,6 +359,7 @@ static int kvp_key_add_or_modify(int pool, const __u8 *key,
int key_size,
int i;
int num_records;
struct kvp_record *record;
+ struct kvp_record *record_tmp;
int num_blocks;
if ((key_size > HV_KVP_EXCHANGE_MAX_KEY_SIZE) ||
@@ -387,11 +392,15 @@ static int kvp_key_add_or_modify(int pool, const __u8
*key, int key_size,
*/
if (num_records == (ENTRIES_PER_BLOCK * num_blocks)) {
/* Need to allocate a larger array for reg entries. */
- record = realloc(record, sizeof(struct kvp_record) *
+ record_tmp = realloc(record, sizeof(struct kvp_record) *
ENTRIES_PER_BLOCK * (num_blocks + 1));
- if (record == NULL)
+ if (!record_tmp) {
+ free(record);
return 1;
+ } else {
+ record = record_tmp;
+ }
kvp_file_info[pool].num_blocks++;
}
--
2.11.0
[PATCH] tools: objtool: fix memory leak in elf_create_rela_section()
Let's free the allocated char array relaname before returning
in order to avoid leaking memory.
Signed-off-by: Martin Kepplinger
---
tools/objtool/elf.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 6e9f980a7d26..6aacbc31316d 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -508,8 +508,12 @@ struct section *elf_create_rela_section(struct elf *elf,
struct section *base)
strcat(relaname, base->name);
sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0);
- if (!sec)
+ if (!sec) {
+ free(relaname);
return NULL;
+ }
+
+ free(relaname);
base->rela = sec;
sec->base = base;
--
2.11.0
[PATCH] tools: perf: fix leaking rec_argv in error cases
Let's free the allocated rec_argv in case we return early, in
order to avoid leaking memory.
This adds free() at a few very similar places across the tree
where it was missing.
Signed-off-by: Martin Kepplinger
---
tools/perf/builtin-c2c.c | 1 +
tools/perf/builtin-mem.c | 1 +
tools/perf/builtin-timechart.c | 4 +++-
tools/perf/builtin-trace.c | 1 +
4 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 475999e48f66..bb1ee22bd221 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -2732,6 +2732,7 @@ static int perf_c2c__record(int argc, const char **argv)
if (!perf_mem_events[j].supported) {
pr_err("failed: event '%s' not supported\n",
perf_mem_events[j].name);
+ free(rec_argv);
return -1;
}
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index 0f15634ef82c..6940490bc3f9 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -112,6 +112,7 @@ static int __cmd_record(int argc, const char **argv, struct
perf_mem *mem)
if (!perf_mem_events[j].supported) {
pr_err("failed: event '%s' not supported\n",
perf_mem_events__name(j));
+ free(rec_argv);
return -1;
}
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 4e2e61695986..01de01ca14f2 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -1732,8 +1732,10 @@ static int timechart__io_record(int argc, const char
**argv)
if (rec_argv == NULL)
return -ENOMEM;
- if (asprintf(, "common_pid != %d", getpid()) < 0)
+ if (asprintf(, "common_pid != %d", getpid()) < 0) {
+ free(rec_argv);
return -ENOMEM;
+ }
p = rec_argv;
for (i = 0; i < common_args_nr; i++)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 771ddab94bb0..dd8eec4c755c 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2078,6 +2078,7 @@ static int trace__record(struct trace *trace, int argc,
const char **argv)
rec_argv[j++] = "syscalls:sys_enter,syscalls:sys_exit";
else {
pr_err("Neither raw_syscalls nor syscalls events
exist.\n");
+ free(rec_argv);
return -1;
}
}
--
2.11.0
[PATCH v2] tools: objtool: fix memory leak in elf_create_rela_section()
Let's free the allocated char array relaname before returning in order to avoid leaking memory. Signed-off-by: Martin Kepplinger --- I should've allocated some brain resources before freeing some computer's. tools/objtool/elf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index 6e9f980a7d26..1e89a5f8bfc9 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -508,6 +508,7 @@ struct section *elf_create_rela_section(struct elf *elf, struct section *base) strcat(relaname, base->name); sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0); + free(relaname); if (!sec) return NULL; -- 2.11.0
[PATCH] Documentation: devices.rst: minor plural grammar fix
It's authors who request something here, no authors who requests. Let's fix this. Signed-off-by: Martin Kepplinger --- Documentation/admin-guide/devices.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/devices.rst b/Documentation/admin-guide/devices.rst index 7fadc05330dd..f781e80f342d 100644 --- a/Documentation/admin-guide/devices.rst +++ b/Documentation/admin-guide/devices.rst @@ -22,7 +22,7 @@ Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga platform only. Allocations marked (68k/Atari) apply to Linux/68k on the Atari platform only. -This document is in the public domain. The authors requests, however, +This document is in the public domain. The authors request, however, that semantically altered versions are not distributed without permission of the authors, assuming the authors can be contacted without an unreasonable effort. -- 2.16.2
[PATCH 1/2] Input: mk712: update documentation web link
At the mentioned address there's nothing found. By searching information on the controller chip still can be found, so update the link to the resulting page. Signed-off-by: Martin Kepplinger --- drivers/input/touchscreen/mk712.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/mk712.c b/drivers/input/touchscreen/mk712.c index bd5352824f77..c179060525ae 100644 --- a/drivers/input/touchscreen/mk712.c +++ b/drivers/input/touchscreen/mk712.c @@ -17,7 +17,7 @@ * found in Gateway AOL Connected Touchpad computers. * * Documentation for ICS MK712 can be found at: - * http://www.idt.com/products/getDoc.cfm?docID=18713923 + * https://www.idt.com/general-parts/mk712-touch-screen-controller */ /* -- 2.16.2
[PATCH 2/2] Documentation: devices.txt: remove the mk712 touchscreen device from the list
The input/touchscreen/mk712.c driver has been rewritten for the common input event system. in 2005. There shouldn't a special device node be created anymore. Signed-off-by: Martin Kepplinger --- Please review this by looking at the driver too. Thanks, martin Documentation/admin-guide/devices.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index 4ec843123cc3..fb39bbf0789a 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -259,7 +259,6 @@ 11 = /dev/vrtpanel Vr41xx embedded touch panel 13 = /dev/vpcmouse Connectix Virtual PC Mouse 14 = /dev/touchscreen/ucb1x00 UCB 1x00 touchscreen -15 = /dev/touchscreen/mk712MK712 touchscreen 128 = /dev/beep Fancy beep device 129 = 130 = /dev/watchdog Watchdog timer port -- 2.16.2
Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open
Martin Kepplinger | Entwicklung Software GINZINGER ELECTRONIC SYSTEMS GMBH Tel.: +43 7723 5422 157 Mail: martin.kepplin...@ginzinger.com Web: www.ginzinger.com On 2018-02-05 11:07, Christian Gmeiner wrote: > Hi all. > > 2017-04-27 14:22 GMT+02:00 Martin Kepplinger > : >> The device could as well be in command mode, in which this driver cannot >> handle the device. When opening the device, let's make sure the device >> will be in the mode we expect it to be for this driver. >> > > I run into issues caused by this change. It turns out that the device > is non-functional > after some warm-reboots and as a result I am not able to use xorg's > evdev driver. > So I have some questions about this change: > > * Should we enable irq before calling i2c_master_send(..) as the chip raises > an > irq if the command was processed? > > * Would it be enough to send this command only once during driver > lifetime? I can > see that on my system open gets called 3 times during boot-up. It would. See below for my thought on this change. > > * What are the circumstances the touch device would be in an other state? In > the > official kernel driver the userspace can send commands via sysfs. > Also the driver > does set the touch enable mode as this patch does. I did this change as the device was once non-functional unexpectedly because it wasn't in touch mode. We can set touch mode during open() or probe() but I figured during open() would keep the driver working even when others would use the device in command mode. Does your problem go away when you revert this change or put it into probe()? martin Ginzinger electronic systems GmbH Gewerbegebiet Pirath 16 4952 Weng im Innkreis www.ginzinger.com Firmenbuchnummer: FN 364958d Firmenbuchgericht: Ried im Innkreis UID-Nr.: ATU66521089
[PATCH 1/2] README: revise the top level readme texts
This improves the top level README situation a little: Instead of starting with historical information like "This file was moved to..." we add a short introductory description and point the reader to the documention in a direct way, avoiding phrases like "Please notice that there are...". Signed-off-by: Martin Kepplinger --- README | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/README b/README index b2ba4aaa3a71..b281213e7c6f 100644 --- a/README +++ b/README @@ -1,17 +1,27 @@ Linux kernel -This file was moved to Documentation/admin-guide/README.rst +Linux is a computer operating system kernel first released by Linus Torvalds +in September of 1991. It runs on a wide variety of hardware architectures and +has all expected features like multitasking, memory management, multistack +networking and so on. -Please notice that there are several guides for kernel developers and users. -These guides can be rendered in a number of formats, like HTML and PDF. +Device drivers are an integral part too, supporting the use of countless +devices. Documentation/process/howto.rst describes how to include a new one. -In order to build the documentation, use ``make htmldocs`` or -``make pdfdocs``. +Documentation +- -There are various text files in the Documentation/ subdirectory, -several of them using the Restructured Text markup notation. -See Documentation/00-INDEX for a list of what is contained in each file. +Linux is documented in the Documentation/ subdirectory. Several of the text +files use the Restructured Text markup notation. + +Documentation/admin-guide/README.rst may be what you are looking for and +Documentation/00-INDEX has a list of what is contained in each file. + +The included guides for kernel developers and users can be rendered in a number +of formats, like HTML and PDF. + +In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about -- 2.11.0
[PATCH 2/2] Documentation: admin-guide: remove redundant first paragraph of README.rst
"These are the release notes for Linux version 4." is what the header above says. There's no real need to say that again. "Read them carefully," Why would we advise people to read one file carefully but other file not? "they tell you what this is all about, explain how to install the kernel, and what to do if something goes wrong." That's just the chapters below. With rendered docs, the reader doesn't even have to scroll down to have this sentense's information :) Therefore let's remove the first paragraph, including the "What is Linux?" subheader, and start with telling what Linux is. This won't come as a surprise to the reader. Signed-off-by: Martin Kepplinger --- Documentation/admin-guide/README.rst | 7 --- 1 file changed, 7 deletions(-) diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst index b5343c5aa224..4810ae94dce1 100644 --- a/Documentation/admin-guide/README.rst +++ b/Documentation/admin-guide/README.rst @@ -1,13 +1,6 @@ Linux kernel release 4.x <http://kernel.org/> = -These are the release notes for Linux version 4. Read them carefully, -as they tell you what this is all about, explain how to install the -kernel, and what to do if something goes wrong. - -What is Linux? --- - Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specification compliance. -- 2.11.0
[PATCH] staging: vboxvideo: Kconfig: Fix typos in help text
This fixes typos in vboxvideo's help text. Signed-off-by: Martin Kepplinger --- drivers/staging/vboxvideo/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vboxvideo/Kconfig b/drivers/staging/vboxvideo/Kconfig index a52746f9a670..2b058d573cf1 100644 --- a/drivers/staging/vboxvideo/Kconfig +++ b/drivers/staging/vboxvideo/Kconfig @@ -6,7 +6,7 @@ config DRM_VBOXVIDEO This is a KMS driver for the virtual Graphics Card used in Virtual Box virtual machines. - Although it is possible to builtin this module, it is advised + Although it is possible to build in this module, it is advised to build this driver as a module, so that it can be updated - independently of the kernel. Select M to built this driver as a + independently of the kernel. Select M to build this driver as a module and add support for these devices via drm/kms interfaces. -- 2.11.0
[PATCH] Input: tsc200x-core - set INPUT_PROP_DIRECT
If INPUT_PROP_DIRECT is set, userspace doesn't have to fall back to old ways of identifying touchscreen devices. In order to identify a touchscreen device, Android for example, seems to already depend on INPUT_PROP_DIRECT to be present in drivers. udev still checks for either BTN_TOUCH or INPUT_PROP_DIRECT. Checking for BTN_TOUCH however can quite easily lead to false positives; it's a code that not only touchscreen device drivers use. According to the documentation, touchscreen drivers should have this property set and in order to make life easy for userspace, let's set it. Signed-off-by: Martin Kepplinger --- Still, as a paranoia measure, I'd not do a bulk-patchset adding this bit to every driver here. I'll add it to drivers I know of, by using them myself or people that report using tslib. Who knows what devices or usecases exist out there :) drivers/input/touchscreen/tsc200x-core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/touchscreen/tsc200x-core.c b/drivers/input/touchscreen/tsc200x-core.c index 542db26d7fd0..e0fde590df8e 100644 --- a/drivers/input/touchscreen/tsc200x-core.c +++ b/drivers/input/touchscreen/tsc200x-core.c @@ -531,6 +531,7 @@ int tsc200x_probe(struct device *dev, int irq, const struct input_id *tsc_id, input_set_drvdata(input_dev, ts); + __set_bit(INPUT_PROP_DIRECT, input_dev->propbit); input_set_capability(input_dev, EV_KEY, BTN_TOUCH); input_set_abs_params(input_dev, ABS_X, -- 2.11.0
Re: [PATCH] media: coda: fix comparision of decoded frames' indexes
Am 22.11.2017 14:43 schrieb Philipp Zabel:
Hi Martin,
On Fri, 2017-11-17 at 15:30 +0100, Martin Kepplinger wrote:
At this point the driver looks the currently decoded frame's index
and compares is to VPU-specific state values. Directly before this
if and else statements the indexes are read (index for decoded and
for displayed frame).
Now what is saved in ctx->display_idx is an older value at this point!
Yes. The rotator that copies out the decoded frame runs in parallel
with
the decoding of the next frame. So the decoder signals with display_idx
which decoded frame should be presented next, but it is only copied out
into the vb2 buffer during the following run. The same happens with the
VDOA, but manually, in prepare_decode.
That means that at this point display_idx is the index of the
previously
decoded internal frame that should be presented next, and ctx-
display_idx is the index of the internal frame that was just copied
into the externally visible vb2 buffer.
The logic reads someting like this:
if (no frame was decoded) {
if (a frame will be copied out next time) {
adapt sequence number offset;
} else if (no frame was copied out this time) {
hold until further input;
}
}
Basically, it will just wait one more run until it stops the stream,
assuming that there is really nothing useful in the bitstream
ringbuffer.
During these index checks, the current values apply, so fix this by
taking display_idx instead of ctx->display_idx.
display_idx is already checked later in the same function.
According to the i.MX6 VPU API document, it can be -2 (never seen) or
-3
during sequence start (if there is frame reordering, depending on
whether decoder skip is enabled), and I think I've seen -3 as prescan
failure on i.MX5. -1 means EOS according to that document, that's why
we
always hold in that case.
ctx->display_idx is updated later in the same function.
Signed-off-by: Martin Kepplinger
---
Please review this thoroughly, but in case I am wrong here, this is
at least very strange to read and *should* be accompanied with a
comment about what's going on with that index value!
Maybe it would be less confusing to move this into the display_idx
checks below, given that we already hold unconditionally
on display_idx == -1.
I don't think it matter that much here because at least playing h264
worked before and works with this change, but I've tested it anyways.
I think this shouldn't happen at all if you feed it a well formed h.264
stream. But if you have a skip because of broken data while there is
still no display frame at the beginning of the stream or after an IDR,
this might be hit.
Right. Let's leave it this way. In case of real changes, one can think
about
cleanup.
Thanks for clarification and helping to understand this thing! I
appreciate it.
martin
[PATCH v2] input: pegasus_notetaker: add license information
This adds an SPDX license identifier to this driver I wrote some time back. Signed-off-by: Martin Kepplinger --- Thanks for the feedback. GPL2+ was what I had in mind. My bad. And as I already see a lot of SPDX tags using /**/ comments, I'll use that too. I think if it is hand-written, it shouldn't look too ugly. And in case that's really a no-go, it seems that many many files need to be changed again in any case. martin patch revisions --- v2: use /**/ comments and fix the license tag to match MODULE_LICENSE() drivers/input/tablet/pegasus_notetaker.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/tablet/pegasus_notetaker.c b/drivers/input/tablet/pegasus_notetaker.c index 47de5a81172f..93fe8ecab767 100644 --- a/drivers/input/tablet/pegasus_notetaker.c +++ b/drivers/input/tablet/pegasus_notetaker.c @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ /* * Pegasus Mobile Notetaker Pen input tablet driver * -- 2.11.0
[PATCH v3] input: pegasus_notetaker: add license information
This adds an SPDX license identifier to this driver I wrote some time back. Signed-off-by: Martin Kepplinger --- ok. thanks for the license-cleanup efforts. I think it's important. martin patch revisions --- v3: use // comments v2: use /**/ comments and fix the license tag to match MODULE_LICENSE() drivers/input/tablet/pegasus_notetaker.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/input/tablet/pegasus_notetaker.c b/drivers/input/tablet/pegasus_notetaker.c index 47de5a81172f..6d8975f49e76 100644 --- a/drivers/input/tablet/pegasus_notetaker.c +++ b/drivers/input/tablet/pegasus_notetaker.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * Pegasus Mobile Notetaker Pen input tablet driver * -- 2.11.0
Re: [PATCH v6] iio: accel: mma8452: improvements to handle multiple events
On 2017-09-09 21:56, Harinath Nampally wrote:
> This driver supports multiple devices like mma8653,
> mma8652, mma8452, mma8453 and fxls8471. Almost all
> these devices have more than one event.
>
> Current driver design hardcodes the event specific
> information, so only one event can be supported by this
> driver at any given time.
> Also current design doesn't have the flexibility to
> add more events.
>
> This patch improves by detaching the event related
> information from chip_info struct,and based on channel
> type and event direction the corresponding event
> configuration registers are picked dynamically.
> Hence both transient and freefall events can be
> handled in read/write callbacks.
>
> Changes are thoroughly tested on fxls8471 device on imx6UL
> Eval board using iio_event_monitor user space program.
>
> After this fix both Freefall and Transient events are
> handled by the driver without any conflicts.
>
> Changes since v5 -> v6
> -Rename supported_events to all_events(short name)
> -Use get_event_regs function in read/write event
> config callbacks to pick appropriate config registers
> -Add ev_cfg_ele and ev_cfg_chan_shift in event_regs struct
> which are needed in read/write event callbacks
>
> Changes since v4 -> v5
> -Add supported_events and enabled_events
> in chip_info structure so that devices(mma865x)
> which has no support for transient event will
> fallback to freefall event. Hence this patch changes
> won't break for devices that can't support
> transient events
>
> Changes since v3 -> v4
> -Add 'const struct ev_regs_accel_falling'
> -Add 'const struct ev_regs_accel_rising'
> -Refactor mma8452_get_event_regs function to
> remove the fill in the struct and return above structs
> -Condense the commit's subject message
>
> Changes since v2 -> v3
> -Fix typo in commit message
> -Replace word 'Bugfix' with 'Improvements'
> -Describe more accurate commit message
> -Replace breaks with returns
> -Initialise transient event threshold mask
> -Remove unrelated change of IIO_ACCEL channel type
> check in read/write event callbacks
>
> Changes since v1 -> v2
> -Fix indentations
> -Remove unused fields in mma8452_event_regs struct
> -Remove redundant return statement
> -Remove unrelated changes like checkpatch.pl warning fixes
>
> Signed-off-by: Harinath Nampally
> ---
Alright, I didn't test it but I kind of like it now. The one minor
naming issue I had pointed out before is mentioned below. But if that's
no issue for Jon:
Reviewed-by: Martin Kepplinger
btw, Harianath: Would you point me to the imx6ul eval board you are
using? thanks
> @@ -740,6 +762,36 @@ static int mma8452_write_raw(struct iio_dev *indio_dev,
> return ret;
> }
>
> +static int mma8452_get_event_regs(struct mma8452_data *data,
> + const struct iio_chan_spec *chan, enum iio_event_direction dir,
> + const struct mma8452_event_regs **ev_reg)
> +{
> + if (!chan)
> + return -EINVAL;
> +
> + switch (chan->type) {
> + case IIO_ACCEL:
> + switch (dir) {
> + case IIO_EV_DIR_RISING:
> + if ((data->chip_info->all_events
> + & MMA8452_INT_TRANS) &&
> + (data->chip_info->enabled_events
> + & MMA8452_INT_TRANS))
> + *ev_reg = _regs_accel_rising;
> + else
> + *ev_reg = _regs_accel_falling;
> + return 0;
I know it's fine, only the naming seems odd here.
> + case IIO_EV_DIR_FALLING:
> + *ev_reg = _regs_accel_falling;
> + return 0;
> + default:
> + return -EINVAL;
> + }
> + default:
> + return -EINVAL;
> + }
> +}
> +
[PATCH] iio: adc: dln2-adc: initialize local struct before using it
struct data is defined and declared locally. Initiliazation has to be done
manually, so let's add that.
Signed-off-by: Martin Kepplinger
---
This is more of a question actually! Did you have in mind that data is
not initialized here? If so, please drop this patch. This is just in case
you implicitely expected data to be zero.
drivers/iio/adc/dln2-adc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/dln2-adc.c b/drivers/iio/adc/dln2-adc.c
index ab8d6aed5085..452330075b67 100644
--- a/drivers/iio/adc/dln2-adc.c
+++ b/drivers/iio/adc/dln2-adc.c
@@ -489,7 +489,7 @@ static irqreturn_t dln2_adc_trigger_h(int irq, void *p)
struct {
__le16 values[DLN2_ADC_MAX_CHANNELS];
int64_t timestamp_space;
- } data;
+ } data = { 0 };
struct dln2_adc_get_all_vals dev_data;
struct dln2_adc *dln2 = iio_priv(indio_dev);
const struct dln2_adc_demux_table *t;
--
2.11.0
Re: [PATCH v5] iio: accel: mma8452: improvements to handle multiple events
Am 10. September 2017 15:44:24 MESZ schrieb Jonathan Cameron : >On Mon, 4 Sep 2017 23:06:37 -0400 >harinath Nampally wrote: > >> > I agree with your understanding. It's a rising threshold, just >that the input >> > will only reflect high frequency changes in the signal. >> Thank you for the clarification. I am hoping this gets merged in the >> next window if no other issues. > >There is still the open question to Martin on what he meant in his >review to be addressed. > >Martin, any comments on this? > >I'm really looking for an OK from Martin before I take this one. >Plenty of time though given the merge window is still open! I had a look at v6 of this. > >I'm travelling this week so response may be a bit random depending >on conference wifi and how interesting the material is ;) enjoy, martin > >Jonathan > >> >> Thanks, >> Hari >> >> On Sun, Sep 3, 2017 at 12:24 PM, Jonathan Cameron >wrote: >> > On Tue, 29 Aug 2017 23:01:16 -0400 >> > harinath Nampally wrote: >> > >> >> > We should never say "transient is for rising >> >> > direction" or "ff_mt is for falling direction". any combination >is fine. >> >> >> >> Ok I agree that there is no hard and fast rule that "transient is >for rising >> >> direction" or "ff_mt is for falling direction". >> >> But in our case, datasheet for these chips define these events >based on >> >> acceleration magnitude rising or falling below a set threshold >value. >> >> >> >> For quick reference, below excerpts are from fxls8471 datasheet: >> >> Motion Event: "When the acceleration exceeds a set threshold for a >set >> >> amount of time, >> >> the motion interrupt is asserted." >> >> >> >> Freefall event: "The detection of “Freefall” involves the >monitoring >> >> of the X, Y, and Z axes >> >> for the condition where the acceleration magnitude is below a >> >> user-specified threshold >> >> for a user-definable amount of time" >> >> >> >> Transient event: "When the high-pass filter is bypassed, the >> >> functionality becomes >> >> similar to the motion-detection function; in this mode, >acceleration >> >> greater than >> >> a programmable threshold is detected (along an axis)." >> >> >> >> Therefore I think in this driver freefall event is defined as >> >> 'falling' event type and >> >> motion event is defined as 'rising' event type and Transient is >also defined as >> >> 'rising' event type. >> >> As you might already know that mma8562 and mma8563 doesn't have >> >> transient event support >> >> but they do have freefall and motion event support which are >defined >> >> as 'fall' and 'rise' >> >> event types respectively. Please note in this driver, motion event >is >> >> enabled/configured only >> >> for mma8652 and mma8653. >> >> Therefore if I read/write sysfs node for 'rise' it should use the >> >> FF_MT registers for mma8652 and mma853, but for all others like >> >> mma8451, mma8452 and >> >> mma8453 which has transient event support it picks the Transient >> >> registers if enabled. Also please >> >> note transient event is enabled(but not motion event) for mma8451, >> >> mma8452 and mma8453. >> >> The problem seems like we have two different events(motion and >> >> transient) that are defined >> >> as same event type 'rising' but in fact both motion and transient >are >> >> pretty much similar as they >> >> both raise interrupt flag when the acceleration magnitude rises >above >> >> the threshold. >> >> Only difference is transient event has its own event config >registers >> >> with High pass filter. >> >> If HPF bypassed using config register transient event acts like >motion >> >> detection event. >> > >> >> >> >> That was my understanding but please correct me if I am wrong. >> > >> > I agree with your understanding. It's a rising threshold, just >that the input >> > will only reflect high frequency changes in the signal. >> > >> >> >> >> > Only freefall mode needs one fix: remembering to which set of >registers to fall back when >> >> > disabling it. >> >> >> >> I don't quite understand what you mean by 'to fall back when >disabling >> >> it'. Please elaborate. I would >> >> appreciate if you could suggest your logic in the form of >pseudo-code. >> >> Thanks for your time >> >> >> > ... -- Martin Kepplinger http://martinkepplinger.com sent from mobile
Re: [PATCH] iio: adc: dln2-adc: initialize local struct before using it
Am 12.09.2017 03:32 schrieb kbuild test robot:
Hi Martin,
[auto build test WARNING on iio/togreg]
[also build test WARNING on next-20170911]
[cannot apply to v4.13]
[if your patch is applied to the wrong git tree, please drop us a note
to help improve the system]
url:
https://github.com/0day-ci/linux/commits/Martin-Kepplinger/iio-adc-dln2-adc-initialize-local-struct-before-using-it/20170912-064250
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
togreg
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile
All warnings (new ones prefixed by >>):
drivers/iio/adc/dln2-adc.c: In function 'dln2_adc_trigger_h':
drivers/iio/adc/dln2-adc.c:492:2: warning: missing braces around
initializer [-Wmissing-braces]
drivers/iio/adc/dln2-adc.c:492:2: warning: (near initialization for
'data.values') [-Wmissing-braces]
vim +492 drivers/iio/adc/dln2-adc.c
484
485 static irqreturn_t dln2_adc_trigger_h(int irq, void *p)
486 {
487 struct iio_poll_func *pf = p;
488 struct iio_dev *indio_dev = pf->indio_dev;
489 struct {
490 __le16 values[DLN2_ADC_MAX_CHANNELS];
491 int64_t timestamp_space;
> 492 } data = { 0 };
ok :) I guess
} data = {{ 0 }};
would be ok for gcc in this case. How far has this patch gone? Do you
want a fix
on top or the patch re-done? Or do you just do it yourself?
thanks,
martin
[PATCH] scsi: sd: print write through due to no caching mode page as warning
For SD cardreaders it's extremely common not to find cache on disk.
The following error messages are thus very common and don't point
to a real error one could try to fix but rather describe how the disk
works:
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
Print these messages as warnings instead of errors.
Signed-off-by: Martin Kepplinger
---
drivers/scsi/sd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index e7c52d6df4dc..db0171c81c5b 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2808,7 +2808,8 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char
*buffer)
}
}
- sd_first_printk(KERN_ERR, sdkp, "No Caching mode page found\n");
+ sd_first_printk(KERN_WARNING, sdkp,
+ "No Caching mode page found\n");
goto defaults;
Page_found:
@@ -2863,7 +2864,7 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char
*buffer)
"Assuming drive cache: write back\n");
sdkp->WCE = 1;
} else {
- sd_first_printk(KERN_ERR, sdkp,
+ sd_first_printk(KERN_WARNING, sdkp,
"Assuming drive cache: write through\n");
sdkp->WCE = 0;
}
--
2.20.1
[PATCH] scsi_logging: print cdb into new line after opcode
The current log message results in a line like the following where
the first byte is duplicated, giving a wrong impression:
sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 60 40 00 00 01 00
Print the cdb into a new line in any case, not only when cmd_len is
greater than 16. The above example error will then read:
sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28
28 00 01 c0 09 00 00 00 08 00
Signed-off-by: Martin Kepplinger
---
drivers/scsi/scsi_logging.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_logging.c b/drivers/scsi/scsi_logging.c
index 8ea44c6595ef..0081d3936f83 100644
--- a/drivers/scsi/scsi_logging.c
+++ b/drivers/scsi/scsi_logging.c
@@ -200,10 +200,11 @@ void scsi_print_command(struct scsi_cmnd *cmd)
if (off >= logbuf_len)
goto out_printk;
+ /* Print opcode in one line and use separate lines for CDB */
+ off += scnprintf(logbuf + off, logbuf_len - off, "\n");
+
/* print out all bytes in cdb */
if (cmd->cmd_len > 16) {
- /* Print opcode in one line and use separate lines for CDB */
- off += scnprintf(logbuf + off, logbuf_len - off, "\n");
dev_printk(KERN_INFO, >device->sdev_gendev, "%s", logbuf);
for (k = 0; k < cmd->cmd_len; k += 16) {
size_t linelen = min(cmd->cmd_len - k, 16);
@@ -224,7 +225,6 @@ void scsi_print_command(struct scsi_cmnd *cmd)
goto out;
}
if (!WARN_ON(off > logbuf_len - 49)) {
- off += scnprintf(logbuf + off, logbuf_len - off, " ");
hex_dump_to_buffer(cmd->cmnd, cmd->cmd_len, 16, 1,
logbuf + off, logbuf_len - off,
false);
--
2.20.1
[PATCH v4 2/5] arm64: dts: imx8mq: Add interconnect provider property
Add #interconnect-cells on main so that it will probe the interconnect
provider.
Signed-off-by: Martin Kepplinger
Acked-by: Georgi Djakov
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index dbe480a76aa1..89e7de2e7f7a 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1163,6 +1163,7 @@
reg = <0x3270 0x10>;
clocks = < IMX8MQ_CLK_NOC>;
fsl,ddrc = <>;
+ #interconnect-cells = <1>;
operating-points-v2 = <_opp_table>;
noc_opp_table: opp-table {
--
2.20.1
[PATCH v4 1/5] arm64: dts: imx8mq: Add NOC node
From: Leonard Crestez
Add initial support for dynamic frequency scaling of the main NOC
on imx8mq.
Make DDRC the parent of the NOC (using passive governor) so that the
main NOC is automatically scaled together with DDRC by default.
Support for proactive scaling via interconnect will come on top.
Signed-off-by: Leonard Crestez
Signed-off-by: Martin Kepplinger
Acked-by: Georgi Djakov
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 24 +++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index a841a023e8e0..dbe480a76aa1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1158,6 +1158,30 @@
};
};
+ noc: interconnect@3270 {
+ compatible = "fsl,imx8mq-noc", "fsl,imx8m-noc";
+ reg = <0x3270 0x10>;
+ clocks = < IMX8MQ_CLK_NOC>;
+ fsl,ddrc = <>;
+ operating-points-v2 = <_opp_table>;
+
+ noc_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-133M {
+ opp-hz = /bits/ 64 <1>;
+ };
+
+ opp-400M {
+ opp-hz = /bits/ 64 <4>;
+ };
+
+ opp-800M {
+ opp-hz = /bits/ 64 <8>;
+ };
+ };
+ };
+
bus@32c0 { /* AIPS4 */
compatible = "fsl,aips-bus", "simple-bus";
reg = <0x32c0 0x40>;
--
2.20.1
[PATCH v4 3/5] dt-bindings: mxsfb: Add interconnect bindings for LCDIF path
Add optional interconnect properties for the dram path requests. Signed-off-by: Martin Kepplinger --- Documentation/devicetree/bindings/display/mxsfb.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt index c985871c46b3..d494a2674290 100644 --- a/Documentation/devicetree/bindings/display/mxsfb.txt +++ b/Documentation/devicetree/bindings/display/mxsfb.txt @@ -15,6 +15,12 @@ Required properties: - "pix" for the LCDIF block clock - (MX6SX-only) "axi", "disp_axi" for the bus interface clock +Optional properties: +- interconnects : interconnect path specifier for LCDIF according to + Documentation/devicetree/bindings/interconnect/interconnect.txt. +- interconnect-names: the name describing the interconnect path. + Should be "dram" for i.MX8MQ. + Required sub-nodes: - port: The connection to an encoder chip. -- 2.20.1
[PATCH v4 4/5] arm64: dts: imx8mq: Add interconnect for lcdif
Add interconnect ports for lcdif to set bus capabilities.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 89e7de2e7f7a..9300be8c9b53 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -11,6 +11,7 @@
#include "dt-bindings/input/input.h"
#include
#include
+#include
#include "imx8mq-pinfunc.h"
/ {
@@ -522,6 +523,8 @@
< IMX8MQ_VIDEO_PLL1>,
< IMX8MQ_VIDEO_PLL1_OUT>;
assigned-clock-rates = <0>, <0>, <0>,
<59400>;
+ interconnects = < IMX8MQ_ICM_LCDIF
IMX8MQ_ICS_DRAM>;
+ interconnect-names = "dram";
status = "disabled";
port@0 {
--
2.20.1
[PATCH v4 0/5] imx8mq: updates for the interconnect fabric
revision history: v4: (thanks Shawn, Georgi and Greg) * reorder to have dt-bindings doc before code addition * add newline between dt nodes * removed "interconnect: imx8mq: Use icc_sync_state" from the patchset since it's part of gregkh/char-misc.git * Add acks v3: (thanks Krysztof and Georgi) * drop the defconfig cycling patch and fix the interconnect enable config * add the noc node to imx8mq only * add missing signed-off-by * https://lore.kernel.org/linux-arm-kernel/20201210100906.18205-1-martin.kepplin...@puri.sm/T/#t v2: (thanks Lucas) * reorder and clean up defconfig changes * use "dram" for the interconnect path name and document it * https://lore.kernel.org/linux-arm-kernel/20201201123932.12312-1-martin.kepplin...@puri.sm/T/#t v1: * https://lore.kernel.org/linux-arm-kernel/20201201100124.4676-1-martin.kepplin...@puri.sm/T/#t thanks, martin Leonard Crestez (1): arm64: dts: imx8mq: Add NOC node Martin Kepplinger (4): arm64: dts: imx8mq: Add interconnect provider property dt-bindings: mxsfb: Add interconnect bindings for LCDIF path arm64: dts: imx8mq: Add interconnect for lcdif arm64: defconfig: Enable interconnect for imx8mq .../devicetree/bindings/display/mxsfb.txt | 6 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 28 +++ arch/arm64/configs/defconfig | 2 ++ 3 files changed, 36 insertions(+) -- 2.20.1
[PATCH v4 5/5] arm64: defconfig: Enable interconnect for imx8mq
Enable INTERCONNECT_IMX8MQ in order to make interconnect more widely available. Signed-off-by: Martin Kepplinger Acked-by: Georgi Djakov --- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 3ca9d03d5cb3..0095df536f74 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1078,6 +1078,8 @@ CONFIG_SLIM_QCOM_CTRL=m CONFIG_SLIM_QCOM_NGD_CTRL=m CONFIG_MUX_MMIO=y CONFIG_INTERCONNECT=y +CONFIG_INTERCONNECT_IMX=m +CONFIG_INTERCONNECT_IMX8MQ=m CONFIG_INTERCONNECT_QCOM=y CONFIG_INTERCONNECT_QCOM_MSM8916=m CONFIG_INTERCONNECT_QCOM_OSM_L3=m -- 2.20.1
Re: [PATCH] Revert "clk: imx: fix composite peripheral flags"
On 04.01.21 13:05, Abel Vesa wrote: On 20-12-31 17:33:40, Fabio Estevam wrote: Hi Martin, On Thu, Dec 31, 2020 at 11:22 AM Martin Kepplinger wrote: This reverts commit 936c383673b9e3007432f17140ac62de53d87db9. It breaks clock reparenting via devfreq on the imx8mq used in the Librem 5 phone. When switching dram frequency (which worked before) the system now hangs after this where the dram_apb clock cannot be set: [ 129.391755] imx8m-ddrc-devfreq 3d40.memory-controller: failed to set dram_apb parent: -16 [ 129.391959] imx8m-ddrc-devfreq 3d40.memory-controller: ddrc failed freq switch to 2500 from 8: error -16. now at 2500 [ 129.406133] imx8m-ddrc-devfreq 3d40.memory-controller: failed to update frequency from PM QoS (-16) I am wondering whether IMX8MQ_CLK_DRAM_ALT should also be marked as CLK_IS_CRITICAL. Hmm, the way the DRAM clocks are right registered right now is a real mess. The DRAM clocks on i.MX8M are changed in TF-A, but the kernel still needs to register them to keep track of the clock tree. Martin, I already have a patchset waiting to be shipped which doesn't only fix the 8MQ, but all the 8M platforms. Unfortunately, I haven't had the time to work on that in the last couple of weeks but I intend to switch back to it soon. Fabio, marking the DRAM clocks as critical will not allow the set_parent to be done, as CLK_IS_CRITICAL flag and set_parent do not go together. As of now the devfreq tries to reparent to be consistent with TF-A configuration. My approach here was to make the DRAM clocks read-only. This means adding some stuff in the clock core subsystem too. Hi Abel, thanks a lot for the update. I'm looking forward to seeing your patchset. martin
Re: [PATCH v4 4/5] arm64: dts: imx8mq: Add interconnect for lcdif
On 15.01.21 10:47, Shawn Guo wrote:
On Thu, Jan 07, 2021 at 01:17:53PM +0100, Martin Kepplinger wrote:
Add interconnect ports for lcdif to set bus capabilities.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 89e7de2e7f7a..9300be8c9b53 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -11,6 +11,7 @@
#include "dt-bindings/input/input.h"
#include
#include
+#include
#include "imx8mq-pinfunc.h"
/ {
@@ -522,6 +523,8 @@
< IMX8MQ_VIDEO_PLL1>,
< IMX8MQ_VIDEO_PLL1_OUT>;
assigned-clock-rates = <0>, <0>, <0>,
<59400>;
+ interconnects = < IMX8MQ_ICM_LCDIF
IMX8MQ_ICS_DRAM>;
+ interconnect-names = "dram";
Hmm, two interconnect phandles but only one name?
Well it's one interconnect path that would more accurately be named
"lcdif-dram" if that's what you mean. I removed "lcdif-" because it's
the lcdif node, but maybe we should name it lcdif-dram after all. at
least that's how others describe it.
martin
Re: [PATCH] scsi_logging: print cdb into new line after opcode
On 23.01.21 04:09, Martin K. Petersen wrote: Ewan, sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 60 40 00 00 01 00 Print the cdb into a new line in any case, not only when cmd_len is greater than 16. The above example error will then read: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 01 c0 09 00 00 00 08 00 I'd rather we not change this. I agree. While the current format is suboptimal, there are lots of things out there parsing these error messages. hi Ewan, hi Martin, That's totally fine. I had this on my list since Douglas suggested to change this during a discussion back in july and I basically wanted to get opinions: https://lore.kernel.org/linux-scsi/31f1ec62-7047-a34b-fdcb-5ea2a2104...@interlog.com/ thanks, martin
[PATCH v2 2/9] arm64: dts: imx8mq-librem5: Mark charger IRQ as High-Z
From: Guido Günther
This is consistent with other IRQs and makes keeps currents low.
Signed-off-by: Guido Günther
Signed-off-by: Martin Kepplinger
Reviewed-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index f85d30a0c2cb..9928e941ee21 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -276,7 +276,7 @@
pinctrl_charger_in: chargeringrp {
fsl,pins = <
/* CHRG_INT */
- MX8MQ_IOMUXC_NAND_CE2_B_GPIO3_IO3 0x00
+ MX8MQ_IOMUXC_NAND_CE2_B_GPIO3_IO3 0x80
/* CHG_STATUS_B */
MX8MQ_IOMUXC_NAND_ALE_GPIO3_IO0 0x80
>;
--
2.20.1
[PATCH v2 6/9] arm64: dts: imx8mq-librem5: enable the LCD panel
This enables the Librem5's ft8006p based LCD panel driven by the
imx8mq's Northwest Logic DSI IP core and mxsfb display controller.
Signed-off-by: Martin Kepplinger
---
.../boot/dts/freescale/imx8mq-librem5.dtsi| 53 ++-
1 file changed, 51 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index f77b51d3c132..bf86402cda30 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -310,6 +310,17 @@
>;
};
+ pinctrl_dsirst: dsirstgrp {
+ fsl,pins = <
+ /* DSI_RST */
+ MX8MQ_IOMUXC_ENET_RD3_GPIO1_IO290x83
+ /* DSI_TE */
+ MX8MQ_IOMUXC_ENET_RD2_GPIO1_IO280x83
+ /* TP_RST */
+ MX8MQ_IOMUXC_ENET_RX_CTL_GPIO1_IO24 0x83
+ >;
+ };
+
pinctrl_ecspi1: ecspigrp {
fsl,pins = <
MX8MQ_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI0x83
@@ -817,12 +828,12 @@
compatible = "tps65132";
reg = <0x3e>;
- outp {
+ reg_lcd_avdd: outp {
regulator-name = "LCD_AVDD";
vin-supply = <_lcd_3v4>;
};
- outn {
+ reg_lcd_avee: outn {
regulator-name = "LCD_AVEE";
vin-supply = <_lcd_3v4>;
};
@@ -947,6 +958,44 @@
};
};
+ {
+ status = "okay";
+};
+
+_dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ lcd_panel: panel@0 {
+ compatible = "mantix,mlaf057we51-x";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_dsirst>;
+ avdd-supply = <_lcd_avdd>;
+ avee-supply = <_lcd_avee>;
+ vddi-supply = <_lcd_1v8>;
+ backlight = <_dsi>;
+ reset-gpios = < 29 GPIO_ACTIVE_LOW>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_dsi_out>;
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ reg = <1>;
+
+ mipi_dsi_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
+};
+
_gpu {
power-supply = <_reg>;
};
--
2.20.1
[PATCH v2 5/9] arm64: dts: imx8mq-librem5: Add LCD_1V8 regulator
From: Guido Günther
It's a supply for to touch and LCD.
Signed-off-by: Guido Günther
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index d7d807cd72b3..f77b51d3c132 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -82,6 +82,20 @@
enable-active-high;
};
+ reg_lcd_1v8: regulator-lcd-1v8 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_dsien>;
+ regulator-name = "LCD_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <_vdd_1v8>;
+ gpio = < 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ /* Otherwise i2c3 is not functional */
+ regulator-always-on;
+ };
+
reg_lcd_3v4: regulator-lcd-3v4 {
compatible = "regulator-fixed";
regulator-name = "LCD_3V4";
@@ -892,6 +906,7 @@
interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
touchscreen-size-x = <720>;
touchscreen-size-y = <1440>;
+ vcc-supply = <_lcd_1v8>;
};
};
--
2.20.1
[PATCH v2 0/9] Config and devicetree updates for the Librem 5 phone
This is another set of updates in order to maintain support for the Librem 5 phone: revision history v2: thanks Shawn and Krzysztof * fix dts style issues in "enable the LCD panel" * reorder for the bindings to go before the dts usage * add ack and review tags v1: https://lore.kernel.org/linux-arm-kernel/20210112095151.4995-1-martin.kepplin...@puri.sm/ Guido Günther (5): arm64: defconfig: Enable vibra-pwm arm64: dts: imx8mq-librem5: Mark charger IRQ as High-Z arm64: dts: imx8mq-librem5: Don't mark buck3 as always on arm64: dts: imx8mq-librem5: Add usb-c chip as supplier for the charger arm64: dts: imx8mq-librem5: Add LCD_1V8 regulator Martin Kepplinger (4): arm64: dts: imx8mq-librem5: enable the LCD panel arm64: dts: imx8mq-librem5: set regulators boot-on dt-bindings: arm: fsl: Add the librem 5 Evergreen revision arm64: dts: Add Librem5 Evergreen .../devicetree/bindings/arm/fsl.yaml | 1 + arch/arm64/boot/dts/freescale/Makefile| 1 + .../boot/dts/freescale/imx8mq-librem5-r4.dts | 35 .../boot/dts/freescale/imx8mq-librem5.dtsi| 85 ++- arch/arm64/configs/defconfig | 1 + 5 files changed, 119 insertions(+), 4 deletions(-) create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5-r4.dts -- 2.20.1
[PATCH v2 9/9] arm64: dts: Add Librem5 Evergreen
Add librem5-r4 with specifics to that revision like the near-level,
battery and charger properties. For schematics and more information,
see https://developer.puri.sm/Librem5/Hardware_Reference/Evergreen.html
Signed-off-by: Martin Kepplinger
Reviewed-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/Makefile| 1 +
.../boot/dts/freescale/imx8mq-librem5-r4.dts | 35 +++
2 files changed, 36 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5-r4.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile
b/arch/arm64/boot/dts/freescale/Makefile
index 38559943c15d..e814ee98fecf 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r3.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r4.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-nitrogen.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-phanbell.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-pico-pi.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r4.dts
b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r4.dts
new file mode 100644
index ..cbfb49aa2563
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r4.dts
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Purism SPC
+
+/dts-v1/;
+
+#include "imx8mq-librem5.dtsi"
+
+/ {
+ model = "Purism Librem 5r4";
+ compatible = "purism,librem5r4", "purism,librem5", "fsl,imx8mq";
+};
+
+_gyro {
+ mount-matrix = "1", "0", "0",
+ "0", "1", "0",
+ "0", "0", "-1";
+};
+
+ {
+ maxim,rsns-microohm = <1667>;
+};
+
+ {
+ ti,battery-regulation-voltage = <420>; /* uV */
+ ti,charge-current = <150>; /* uA */
+ ti,termination-current = <144000>; /* uA */
+};
+
+_backlight {
+ led-max-microamp = <25000>;
+};
+
+ {
+ proximity-near-level = <10>;
+};
--
2.20.1
[PATCH v2 1/9] arm64: defconfig: Enable vibra-pwm
From: Guido Günther The haptic motor for the Librem 5 uses this. Signed-off-by: Guido Günther Signed-off-by: Martin Kepplinger Reviewed-by: Krzysztof Kozlowski --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 15fe99544c67..91a034924a70 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -392,6 +392,7 @@ CONFIG_TOUCHSCREEN_EDT_FT5X06=m CONFIG_INPUT_MISC=y CONFIG_INPUT_PM8941_PWRKEY=y CONFIG_INPUT_PM8XXX_VIBRATOR=m +CONFIG_INPUT_PWM_VIBRA=m CONFIG_INPUT_HISI_POWERKEY=y # CONFIG_SERIO_SERPORT is not set CONFIG_SERIO_AMBAKMI=y -- 2.20.1
[PATCH v2 8/9] dt-bindings: arm: fsl: Add the librem 5 Evergreen revision
Add an entry for the Librem 5 phone, Evergreen revision which is supported by "r4". Schematics and more information can be found at https://developer.puri.sm/Librem5/Hardware_Reference/Evergreen.html Signed-off-by: Martin Kepplinger Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 2ae66407e2aa..aaac7ef78b38 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -738,6 +738,7 @@ properties: - enum: - purism,librem5r2 # Purism Librem5 phone "Chestnut" - purism,librem5r3 # Purism Librem5 phone "Dogwood" + - purism,librem5r4 # Purism Librem5 phone "Evergreen" - const: purism,librem5 - const: fsl,imx8mq -- 2.20.1
[PATCH v2 7/9] arm64: dts: imx8mq-librem5: set regulators boot-on
Expect all those regulators to be turned on initially. Signed-off-by: Martin Kepplinger --- arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi index bf86402cda30..06a4799b6aeb 100644 --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi @@ -682,6 +682,7 @@ regulator-name = "buck1"; regulator-min-microvolt = <70>; regulator-max-microvolt = <130>; + regulator-boot-on; regulator-ramp-delay = <1250>; rohm,dvs-run-voltage = <90>; rohm,dvs-idle-voltage = <85>; @@ -693,6 +694,7 @@ regulator-name = "buck2"; regulator-min-microvolt = <70>; regulator-max-microvolt = <130>; + regulator-boot-on; regulator-ramp-delay = <1250>; rohm,dvs-run-voltage = <100>; rohm,dvs-idle-voltage = <90>; @@ -703,6 +705,7 @@ regulator-name = "buck3"; regulator-min-microvolt = <70>; regulator-max-microvolt = <130>; + regulator-boot-on; rohm,dvs-run-voltage = <90>; }; @@ -717,6 +720,7 @@ regulator-name = "buck5"; regulator-min-microvolt = <70>; regulator-max-microvolt = <135>; + regulator-boot-on; regulator-always-on; }; @@ -724,6 +728,7 @@ regulator-name = "buck6"; regulator-min-microvolt = <300>; regulator-max-microvolt = <330>; + regulator-boot-on; regulator-always-on; }; @@ -731,6 +736,7 @@ regulator-name = "buck7"; regulator-min-microvolt = <1605000>; regulator-max-microvolt = <1995000>; + regulator-boot-on; regulator-always-on; }; @@ -738,6 +744,7 @@ regulator-name = "buck8"; regulator-min-microvolt = <80>; regulator-max-microvolt = <140>; + regulator-boot-on; regulator-always-on; }; @@ -745,6 +752,7 @@ regulator-name = "ldo1"; regulator-min-microvolt = <300>; regulator-max-microvolt = <330>; + regulator-boot-on; /* leave on for snvs power button */ regulator-always-on; }; @@ -753,6 +761,7 @@ regulator-name = "ldo2"; regulator-min-microvolt = <90>; regulator-max-microvolt = <90>; + regulator-boot-on; /* leave on for snvs power button */ regulator-always-on; }; @@ -761,6 +770,7 @@ regulator-name = "ldo3"; regulator-min-microvolt = <180>; regulator-max-microvolt = <330>; + regulator-boot-on; regulator-always-on; }; @@ -768,6 +778,7 @@ regulator-name = "ldo4"; regulator-min-microvolt = <90>; regulator-max-microvolt = <180>; + regulator-boot-on; regulator-always-on; }; @@ -784,6 +795,7 @@
[PATCH v2 4/9] arm64: dts: imx8mq-librem5: Add usb-c chip as supplier for the charger
From: Guido Günther The tps65982 feeds the bq25895 charge controller on the Librem 5. Signed-off-by: Guido Günther Signed-off-by: Martin Kepplinger --- arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi index 95d710831f28..d7d807cd72b3 100644 --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi @@ -928,6 +928,7 @@ ti,use-vinmin-threshold = <1>; /* enable VINDPM */ ti,vinmin-threshold = <390>; /* uV */ monitored-battery = <>; + power-supplies = <_pd>; }; }; -- 2.20.1
[PATCH v2 3/9] arm64: dts: imx8mq-librem5: Don't mark buck3 as always on
From: Guido Günther
With the pmic driver fixed we can now shut off the regulator in the gpc.
Signed-off-by: Guido Günther
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index 9928e941ee21..95d710831f28 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -679,7 +679,6 @@
regulator-min-microvolt = <70>;
regulator-max-microvolt = <130>;
rohm,dvs-run-voltage = <90>;
- regulator-always-on;
};
buck4_reg: BUCK4 {
--
2.20.1
Re: [PATCH] scsi: sd: add runtime pm to open / release
On 30.07.20 17:10, Alan Stern wrote:
> On Thu, Jul 30, 2020 at 10:52:14AM +0200, Martin Kepplinger wrote:
>> Maybe I should just start a new discussion with a patch, but the below
>> is what makes sense to me (when I understand you correctly) and seems to
>> work. I basically add a new flag, so that the old flags behave unchanged
>> and only call it during *runtime* resume for SD cards:
>>
>>
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -553,15 +553,21 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
>> * information that we should pass up to the upper-level
>> driver
>> * so that we can deal with it there.
>> */
>> - if (scmd->device->expecting_cc_ua) {
>> + if (scmd->device->expecting_cc_ua ||
>> + scmd->device->expecting_media_change) {
>> /*
>> * Because some device does not queue unit
>> * attentions correctly, we carefully check
>> * additional sense code and qualifier so as
>> -* not to squash media change unit attention.
>> +* not to squash media change unit attention;
>> +* unless expecting_media_change is set, indicating
>> +* that the media (most likely) didn't change
>> +* but a device only believes so (for example
>> +* because of suspend/resume).
>> */
>> - if (sshdr.asc != 0x28 || sshdr.ascq != 0x00) {
>> - scmd->device->expecting_cc_ua = 0;
>> + if ((sshdr.asc != 0x28 || sshdr.ascq != 0x00) ||
>> + scmd->device->expecting_media_change) {
>> + scmd->device->expecting_media_change = 0;
>> return NEEDS_RETRY;
>> }
>> }
>> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
>> index d90fefffe31b..b647fab2b663 100644
>> --- a/drivers/scsi/sd.c
>> +++ b/drivers/scsi/sd.c
>> @@ -114,6 +114,7 @@ static void sd_shutdown(struct device *);
>> static int sd_suspend_system(struct device *);
>> static int sd_suspend_runtime(struct device *);
>> static int sd_resume(struct device *);
>> +static int sd_resume_runtime(struct device *);
>> static void sd_rescan(struct device *);
>> static blk_status_t sd_init_command(struct scsi_cmnd *SCpnt);
>> static void sd_uninit_command(struct scsi_cmnd *SCpnt);
>> @@ -574,7 +575,7 @@ static const struct dev_pm_ops sd_pm_ops = {
>> .poweroff = sd_suspend_system,
>> .restore= sd_resume,
>> .runtime_suspend= sd_suspend_runtime,
>> - .runtime_resume = sd_resume,
>> + .runtime_resume = sd_resume_runtime,
>> };
>>
>> static struct scsi_driver sd_template = {
>> @@ -3652,6 +3653,21 @@ static int sd_resume(struct device *dev)
>> return ret;
>> }
>>
>> +static int sd_resume_runtime(struct device *dev)
>> +{
>> + struct scsi_disk *sdkp = dev_get_drvdata(dev);
>> +
>> + /* Some SD cardreaders report media change when resuming from
>> suspend
>> +* because they can't keep track during suspend. */
>> +
>> + /* XXX This is not unproblematic though: We won't notice when a card
>> +* was really changed during runtime suspend! We basically rely
>> on users
>> +* to unmount or suspend before doing so. */
>> + sdkp->device->expecting_media_change = 1;
>> +
>> + return sd_resume(dev);
>> +}
>> +
>> /**
>> * init_sd - entry point for this driver (both when built in or when
>> * a module).
>> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
>> index bc5909033d13..8c8f053f71c8 100644
>> --- a/include/scsi/scsi_device.h
>> +++ b/include/scsi/scsi_device.h
>> @@ -169,6 +169,8 @@ struct scsi_device {
>> * this device */
>> unsigned expecting_cc_ua:1; /* Expecting a CHECK_CONDITION/UNIT_ATTN
>> * because we did a bus reset. */
>> + unsigned expecting_media_change:1; /* Expecting media change
>> ASC/ASCQ
>> + wh
Re: [PATCH] scsi: sd: add runtime pm to open / release
On 08.08.20 17:05, Alan Stern wrote: > On Sat, Aug 08, 2020 at 08:59:09AM +0200, Martin Kepplinger wrote: >> On 07.08.20 16:30, Alan Stern wrote: >>> On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote: >>>> it's really strange: below is the change I'm trying. Of course that's >>>> only for testing the functionality, nothing how a patch could look like. >>>> >>>> While I remember it had worked, now (weirdly since I tried that mounting >>>> via fstab) it doesn't anymore! >>>> >>>> What I understand (not much): I handle the error with "retry" via the >>>> new flag, but scsi_decide_disposition() returns SUCCESS because of "no >>>> more retries"; but it's the first and only time it's called. >>> >>> Are you saying that scmd->allowed is set to 0? Or is scsi_notry_cmd() >>> returning a nonzero value? Whichever is true, why does it happen that >>> way? >> >> scsi_notry_cmd() is returning 1. (it's retry 1 of 5 allowed). >> >> why is it returning 1? REQ_FAILFAST_DEV is set. It's DID_OK, then "if >> (status_byte(scmd->result) != CHECK_CONDITION)" appearently is not true, >> then at the end it returns 1 because of REQ_FAILFAST_DEV. >> >> that seems to come from the block layer. why and when? could I change >> that so that the scsi error handling stays in control? > > The only place I see where that flag might get set is in > blk_mq_bio_to_request() in block/blk-mq.c, which does: > > if (bio->bi_opf & REQ_RAHEAD) > rq->cmd_flags |= REQ_FAILFAST_MASK; > > So apparently read-ahead reads are supposed to fail fast (i.e., without > retries), presumably because they are optional after all. > >>> What is the failing command? Is it a READ(10)? >> >> Not sure how I'd answer that, but here's the test to trigger the error: >> >> mount /dev/sda1 /mnt >> cd /mnt >> ls >> cp file ~/ (if ls "works" and doesn't yet trigger the error) >> >> and that's the (familiar looking) logs when doing so. again: despite the >> mentioned workaround in scsi_error and the new expected_media_change >> flag *is* set and gets cleared, as it should be. REQ_FAILFAST_DEV seems >> to override what I want to do is scsi_error: >> >> [ 55.557629] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: >> hostbyte=0x00 driverbyte=0x08 cmd_age=0s >> [ 55.557639] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current] >> [ 55.557646] sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0 >> [ 55.557657] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 08 fc >> e0 00 00 01 00 > > Yes, 0x28 is READ(10). Likely this is a read-ahead request, although I > don't know how we can tell for sure. > >> [ 55.557666] blk_update_request: I/O error, dev sda, sector 589024 op >> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 >> [ 55.568899] sd 0:0:0:0: [sda] tag#0 device offline or changed >> [ 55.574691] blk_update_request: I/O error, dev sda, sector 589025 op >> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 >> [ 55.585756] sd 0:0:0:0: [sda] tag#0 device offline or changed >> [ 55.591562] blk_update_request: I/O error, dev sda, sector 589026 op >> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 >> [ 55.602274] sd 0:0:0:0: [sda] tag#0 device offline or changed >> (... goes on with the same) > > Is such a drastic response really appropriate for the failure of a > read-ahead request? It seems like a more logical response would be to > let the request fail but keep the device online. > > Of course, that would only solve part of your problem -- your log would > still get filled with those "I/O error" messages even though they > wouldn't be fatal. Probably a better approach would be to make the new > expecting_media_change flag override scsi_no_retry_cmd(). > > But this is not my area of expertise. Maybe someone else will have more > to say. > > Alan Stern > Hey Alan, I'm really glad for that, I suspected some of this but I have little experience in scsi/block layers, so that is super helpful. I'd appreciate an opinion on the below workaround that *seems* to work now (let's see, I had thought so before :) Whether or not this helps to find a real solution, let's see. But integration of such a flag in the error handling paths is what's interesting for now: --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -565,6 +565,17 @@ int scsi_check_sense(struct scsi_cmnd *scmd) return NEE
Re: [PATCH] scsi: sd: add runtime pm to open / release
On 09.08.20 17:26, Alan Stern wrote:
> On Sun, Aug 09, 2020 at 11:20:22AM +0200, Martin Kepplinger wrote:
>> Hey Alan, I'm really glad for that, I suspected some of this but I have
>> little experience in scsi/block layers, so that is super helpful.
>>
>> I'd appreciate an opinion on the below workaround that *seems* to work
>> now (let's see, I had thought so before :)
>>
>> Whether or not this helps to find a real solution, let's see. But
>> integration of such a flag in the error handling paths is what's
>> interesting for now:
>>
>>
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -565,6 +565,17 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
>> return NEEDS_RETRY;
>> }
>> }
>> +if (scmd->device->expecting_media_change) {
>> +if (sshdr.asc == 0x28 && sshdr.ascq == 0x00) {
>> +/* clear expecting_media_change in
>> + * scsi_noretry_cmd() because we need
>> + * to override possible "failfast" overrides
>> + * that block readahead can cause.
>> + */
>> +return NEEDS_RETRY;
>
> This is a somewhat fragile approach. You don't know for certain that
> scsi_noretry_cmd will be called. Also, scsi_noretry_cmd can be called
> from other places.
>
> It would be better to clear the expecting_media_change flag just before
> returning from scsi_decide_disposition. That way its use is localized
> to one routine, not spread out between two.
>
> Alan Stern
>
Hi Alan,
maybe you're right. I initially just thought that I'd allow for specific
error codes in scsi_noretry_cmd() to return non-NULL (BUS_BUSY, PARITY,
ERROR) despite having the flag set.
The below version works equally fine for me but I'm not sure if it's
actually more safe.
James, when exposing a new writable sysfs option like
"suspend_no_media_change"(?) that drivers can check before setting the
new "expecting_media_change" flag (during resume), would this addition
make sense to you?
thanks,
martin
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -565,6 +565,18 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
return NEEDS_RETRY;
}
}
+ if (scmd->device->expecting_media_change) {
+ if (sshdr.asc == 0x28 && sshdr.ascq == 0x00) {
+ /*
+* clear the expecting_media_change in
+* scsi_decide_disposition() because we
+* need to catch possible "fail fast" overrides
+* that block readahead can cause.
+*/
+ return NEEDS_RETRY;
+ }
+ }
+
/*
* we might also expect a cc/ua if another LUN on the target
* reported a UA with an ASC/ASCQ of 3F 0E -
@@ -1944,9 +1956,19 @@ int scsi_decide_disposition(struct scsi_cmnd *scmd)
* the request was not marked fast fail. Note that above,
* even if the request is marked fast fail, we still requeue
* for queue congestion conditions (QUEUE_FULL or BUSY) */
- if ((++scmd->retries) <= scmd->allowed
- && !scsi_noretry_cmd(scmd)) {
- return NEEDS_RETRY;
+ if ((++scmd->retries) <= scmd->allowed) {
+ /*
+* but scsi_noretry_cmd() cannot override the
+* expecting_media_change flag.
+*/
+ if (!scsi_noretry_cmd(scmd) ||
+ scmd->device->expecting_media_change) {
+ scmd->device->expecting_media_change = 0;
+ return NEEDS_RETRY;
+ } else {
+ /* marked fast fail and not expected. */
+ return SUCCESS;
+ }
} else {
/*
* no more retries - report this one back to upper level.
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index d90fefffe31b..bb583e403b81 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3642,6 +3642,8 @@ static int sd_resume(struct device *dev)
if (!sdkp) /* E.g.: runtime resume at the start of sd_probe() */
return 0;
+ sdkp->device->expecting_media_change = 1;
+
if (!sdkp->device->manage_start_stop)
return
Re: [PATCH] scsi: sd: add runtime pm to open / release
On 10.08.20 16:13, Alan Stern wrote:
> On Mon, Aug 10, 2020 at 02:03:17PM +0200, Martin Kepplinger wrote:
>> On 09.08.20 17:26, Alan Stern wrote:
>>> This is a somewhat fragile approach. You don't know for certain that
>>> scsi_noretry_cmd will be called. Also, scsi_noretry_cmd can be called
>>> from other places.
>>>
>>> It would be better to clear the expecting_media_change flag just before
>>> returning from scsi_decide_disposition. That way its use is localized
>>> to one routine, not spread out between two.
>>>
>>> Alan Stern
>>>
>>
>> Hi Alan,
>>
>> maybe you're right. I initially just thought that I'd allow for specific
>> error codes in scsi_noretry_cmd() to return non-NULL (BUS_BUSY, PARITY,
>> ERROR) despite having the flag set.
>>
>> The below version works equally fine for me but I'm not sure if it's
>> actually more safe.
>>
>> James, when exposing a new writable sysfs option like
>> "suspend_no_media_change"(?) that drivers can check before setting the
>> new "expecting_media_change" flag (during resume), would this addition
>> make sense to you?
>>
>> thanks,
>>
>> martin
>>
>>
>>
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -565,6 +565,18 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
>> return NEEDS_RETRY;
>> }
>> }
>> +if (scmd->device->expecting_media_change) {
>> +if (sshdr.asc == 0x28 && sshdr.ascq == 0x00) {
>> +/*
>> + * clear the expecting_media_change in
>> + * scsi_decide_disposition() because we
>> + * need to catch possible "fail fast" overrides
>> + * that block readahead can cause.
>> + */
>> +return NEEDS_RETRY;
>> +}
>> +}
>> +
>> /*
>> * we might also expect a cc/ua if another LUN on the target
>> * reported a UA with an ASC/ASCQ of 3F 0E -
>> @@ -1944,9 +1956,19 @@ int scsi_decide_disposition(struct scsi_cmnd *scmd)
>> * the request was not marked fast fail. Note that above,
>> * even if the request is marked fast fail, we still requeue
>> * for queue congestion conditions (QUEUE_FULL or BUSY) */
>> -if ((++scmd->retries) <= scmd->allowed
>> -&& !scsi_noretry_cmd(scmd)) {
>> -return NEEDS_RETRY;
>> +if ((++scmd->retries) <= scmd->allowed) {
>> +/*
>> + * but scsi_noretry_cmd() cannot override the
>> + * expecting_media_change flag.
>> + */
>> +if (!scsi_noretry_cmd(scmd) ||
>> +scmd->device->expecting_media_change) {
>> +scmd->device->expecting_media_change = 0;
>> +return NEEDS_RETRY;
>> +} else {
>> +/* marked fast fail and not expected. */
>> +return SUCCESS;
>> +}
>> } else {
>
> This may not matter... but it's worth pointing out that
> expecting_media_change doesn't get cleared if ++scmd->retries >
> scmd->allowed.
absolutely worth pointing out and I'm not yet sure about that one.
>
> It also doesn't get cleared in cases where the device _doesn't_
> report a Unit Attention.
true. but don't we set the flag for a future UA we don't yet know of? If
we would want to clear it outside of a UA, I think we'd need to keep
track of a suspend/resume cycle and if we see that we *had* successfully
"done requests" after resuming, we could clear it...
>
> Alan Stern
>
Re: [PATCH v5 1/3] arm64: dts: Add a device tree for the Librem 5 phone
On 31.07.20 10:27, Martin Kepplinger wrote:
> From: "Angus Ainslie (Purism)"
>
> Add a devicetree description for the Librem 5 phone. 4 hardware revisions
> have been available. Some revisions include changes that need different
> software to be run. So far, r3 ("Dogwood") is one such example, see:
>
> "Aspen" r0 not supported (very few devices exist)
> "Birch" r1 supported by r2
> "Chestnut" r2 added by this patch
> "Dogwood" r3 added by this patch
> "Evergreen" r4 tba / most likely supported by r3
>
> See https://puri.sm/products/librem-5/ for more information.
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Angus Ainslie (Purism)
> Signed-off-by: Guido Günther
> For audio related part:
> Reviewed-by: Daniel Baluta
> ---
>
>
> revision history
>
> v5:
> thanks a lot Pavel for reviewing again
> * remove pwmleds (no stable interface yet)
>
> v4:
> thanks a lot Shawn for reviewing
> * rename to dtsi and split out r2 and r3 dts with revision specifics
> * add the USB2642 hard-wired Hub
> * fix charge controller boost-max-current
> * disable pullup on CHRG_INT (not needed due to external one)
> * add documentation for the boards' compatible strings
> * fix led-backlight propery usage
> * coding style fixes
> https://lore.kernel.org/linux-devicetree/20200721153225.7593-1-martin.kepplin...@puri.sm/T/
>
> v3:
> thanks a lot Mark for reviewing! changes since v2:
> * nicer audio cards names
> * squash unneeded audio_pwr regulator
> * remove the susphy_quirk from dwc3_1 after more testing
> * add usdhc2 card detect via gpio
> * add headphone detect for audio card
> https://lore.kernel.org/linux-arm-kernel/20200617073821.16737-1-martin.kepplin...@puri.sm/T/
>
> v2:
> thanks a lot Marco, Daniel and Pavel for reviewing. changes since v1:
> * alphabetical sortings / more consistent node names
> * remove unused regulator and pinctrl descriptions
> * generic labels for leds, backlight, flash and torch
> * audio clk settings moved to sai2 node
> https://lore.kernel.org/linux-arm-kernel/20200604084756.586-1-martin.kepplin...@puri.sm/T/
>
> v1:
> https://lore.kernel.org/linux-arm-kernel/20200514155737.12160-1-martin.kepplin...@puri.sm/
>
hi Shawn, hi all,
the merge window is basically over and maybe you'll then find time to
review whether you still find problems with this addition. In case
you've looked at an older version of this, all changes should be listed
in the revision history above.
thanks again,
martin
Re: [PATCH v5 3/3] dt-bindings: arm: fsl: Add the librem 5 phone
On 31.07.20 21:35, Rob Herring wrote: > On Fri, 31 Jul 2020 10:27:25 +0200, Martin Kepplinger wrote: >> Add entries for the imx8mq based Librem 5 phone. The "Birch" and >> "Chestnut" hardware revisions are supported by r2. The "Dogwood" >> revision by r3. >> See https://puri.sm/products/librem-5/ and https://developer.puri.sm/Librem5/ >> for the schematics and more information. >> >> Signed-off-by: Martin Kepplinger >> --- >> Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ >> 1 file changed, 2 insertions(+) >> > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. > I'm very sorry. I forgot to add to this patch: Acked-by: Rob Herring It was not done on purposes and I'll add it to a next series and equally hope that this note would make a maintainer add it in case this series turns out to be ready. thanks for the explanation and again, sorry. martin
[PATCH v3 4/6] dt-bindings: mxsfb: Add interconnect bindings for LCDIF path
Add optional interconnect properties for the dram path requests. Signed-off-by: Martin Kepplinger --- Documentation/devicetree/bindings/display/mxsfb.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt index c985871c46b3..d494a2674290 100644 --- a/Documentation/devicetree/bindings/display/mxsfb.txt +++ b/Documentation/devicetree/bindings/display/mxsfb.txt @@ -15,6 +15,12 @@ Required properties: - "pix" for the LCDIF block clock - (MX6SX-only) "axi", "disp_axi" for the bus interface clock +Optional properties: +- interconnects : interconnect path specifier for LCDIF according to + Documentation/devicetree/bindings/interconnect/interconnect.txt. +- interconnect-names: the name describing the interconnect path. + Should be "dram" for i.MX8MQ. + Required sub-nodes: - port: The connection to an encoder chip. -- 2.20.1
[PATCH v3 0/6] imx8mq: updates for the interconnect fabric
revision history: v3: (thanks Krysztof and Georgi) * drop the defconfig cycling patch and fix the interconnect enable config * add the noc node to imx8mq only and use correct properties * add missing signed-off-by v2: (thanks Lucas) * reorder and clean up defconfig changes * use "dram" for the interconnect path name and document it * https://lore.kernel.org/linux-arm-kernel/20201201123932.12312-1-martin.kepplin...@puri.sm/T/#t v1: * link: https://lore.kernel.org/linux-arm-kernel/20201201100124.4676-1-martin.kepplin...@puri.sm/T/ thanks, martin Leonard Crestez (1): arm64: dts: imx8mq: Add NOC node Martin Kepplinger (5): arm64: dts: imx8mq: Add interconnect provider property arm64: dts: imx8mq: Add interconnect for lcdif dt-bindings: mxsfb: Add interconnect bindings for LCDIF path interconnect: imx8mq: Use icc_sync_state arm64: defconfig: Enable interconnect for imx8mq .../devicetree/bindings/display/mxsfb.txt | 6 + arch/arm64/boot/dts/freescale/imx8mq.dtsi | 26 +++ arch/arm64/configs/defconfig | 2 ++ drivers/interconnect/imx/imx8mq.c | 2 ++ 4 files changed, 36 insertions(+) -- 2.20.1
[PATCH v3 1/6] arm64: dts: imx8mq: Add NOC node
From: Leonard Crestez
Add initial support for dynamic frequency scaling of the main NOC
on imx8mq.
Make DDRC the parent of the NOC (using passive governor) so that the
main NOC is automatically scaled together with DDRC by default.
Support for proactive scaling via interconnect will come on top.
Signed-off-by: Leonard Crestez
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index a841a023e8e0..9c9d68a14e69 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1158,6 +1158,28 @@
};
};
+ noc: interconnect@3270 {
+ compatible = "fsl,imx8mq-noc", "fsl,imx8m-noc";
+ reg = <0x3270 0x10>;
+ clocks = < IMX8MQ_CLK_NOC>;
+ fsl,ddrc = <>;
+ operating-points-v2 = <_opp_table>;
+
+ noc_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-133M {
+ opp-hz = /bits/ 64 <1>;
+ };
+ opp-400M {
+ opp-hz = /bits/ 64 <4>;
+ };
+ opp-800M {
+ opp-hz = /bits/ 64 <8>;
+ };
+ };
+ };
+
bus@32c0 { /* AIPS4 */
compatible = "fsl,aips-bus", "simple-bus";
reg = <0x32c0 0x40>;
--
2.20.1
[PATCH v3 2/6] arm64: dts: imx8mq: Add interconnect provider property
Add #interconnect-cells on main so that it will probe the interconnect
provider.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 9c9d68a14e69..3617b7238952 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1163,6 +1163,7 @@
reg = <0x3270 0x10>;
clocks = < IMX8MQ_CLK_NOC>;
fsl,ddrc = <>;
+ #interconnect-cells = <1>;
operating-points-v2 = <_opp_table>;
noc_opp_table: opp-table {
--
2.20.1
[PATCH v3 5/6] interconnect: imx8mq: Use icc_sync_state
Add the icc_sync_state callback to notify the framework when consumers
are probed and the bandwidth doesn't have to be kept at maximum anymore.
Signed-off-by: Martin Kepplinger
Suggested-by: Georgi Djakov
---
drivers/interconnect/imx/imx8mq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/interconnect/imx/imx8mq.c
b/drivers/interconnect/imx/imx8mq.c
index ba43a15aefec..d7768d3c6d8a 100644
--- a/drivers/interconnect/imx/imx8mq.c
+++ b/drivers/interconnect/imx/imx8mq.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include "imx.h"
@@ -94,6 +95,7 @@ static struct platform_driver imx8mq_icc_driver = {
.remove = imx8mq_icc_remove,
.driver = {
.name = "imx8mq-interconnect",
+ .sync_state = icc_sync_state,
},
};
--
2.20.1
[PATCH v3 3/6] arm64: dts: imx8mq: Add interconnect for lcdif
Add interconnect ports for lcdif to set bus capabilities.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 3617b7238952..7c4b68bda6fa 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -11,6 +11,7 @@
#include "dt-bindings/input/input.h"
#include
#include
+#include
#include "imx8mq-pinfunc.h"
/ {
@@ -522,6 +523,8 @@
< IMX8MQ_VIDEO_PLL1>,
< IMX8MQ_VIDEO_PLL1_OUT>;
assigned-clock-rates = <0>, <0>, <0>,
<59400>;
+ interconnects = < IMX8MQ_ICM_LCDIF
IMX8MQ_ICS_DRAM>;
+ interconnect-names = "dram";
status = "disabled";
port@0 {
--
2.20.1
[PATCH v3 6/6] arm64: defconfig: Enable interconnect for imx8mq
Enable INTERCONNECT_IMX8MQ in order to make interconnect more widely available. Signed-off-by: Martin Kepplinger --- arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index c8ca76751a34..f25748b0fa95 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1074,6 +1074,8 @@ CONFIG_SLIM_QCOM_CTRL=m CONFIG_SLIM_QCOM_NGD_CTRL=m CONFIG_MUX_MMIO=y CONFIG_INTERCONNECT=y +CONFIG_INTERCONNECT_IMX=m +CONFIG_INTERCONNECT_IMX8MQ=m CONFIG_INTERCONNECT_QCOM=y CONFIG_INTERCONNECT_QCOM_MSM8916=m CONFIG_INTERCONNECT_QCOM_OSM_L3=m -- 2.20.1
[PATCH v2 0/4] small Librem 5 phone dts updates
revision history v2: (thanks Krzysztof) add Fixes tags and improve commit messages v1: https://lore.kernel.org/linux-arm-kernel/20201218103131.22013-1-martin.kepplin...@puri.sm/ Martin Kepplinger (4): arm64: dts: imx8mq-librem5: add vin-supply to VDD_1V8 arm64: dts: imx8mq-librem5: add pinctrl for the touchscreen description arm64: dts: imx8mq-librem5: Move usdhc clocks assignment to board DT arm64: dts: imx8mq-librem5-r3: workaround i2c1 issue with 1GHz cpu voltage .../boot/dts/freescale/imx8mq-librem5-r3.dts | 6 .../boot/dts/freescale/imx8mq-librem5.dtsi| 28 ++- 2 files changed, 27 insertions(+), 7 deletions(-) -- 2.20.1
[PATCH v2 2/4] arm64: dts: imx8mq-librem5: add pinctrl for the touchscreen description
In order for the touchscreen interrupt line to work, describe it properly.
Otherwise it can work if defaults are ok, but we cannot be sure.
Fixes: 8f0216b006e5 ("arm64: dts: Add a device tree for the Librem 5 phone")
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index 55268fc0622e..a60df09d90f7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -459,6 +459,13 @@
>;
};
+ pinctrl_touch: touchgrp {
+ fsl,pins = <
+ /* TP_INT */
+ MX8MQ_IOMUXC_ENET_RD1_GPIO1_IO270x80
+ >;
+ };
+
pinctrl_typec: typecgrp {
fsl,pins = <
/* TYPEC_MUX_EN */
@@ -880,6 +887,8 @@
touchscreen@38 {
compatible = "edt,edt-ft5506";
reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_touch>;
interrupt-parent = <>;
interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
touchscreen-size-x = <720>;
--
2.20.1
[PATCH v2 4/4] arm64: dts: imx8mq-librem5-r3: workaround i2c1 issue with 1GHz cpu voltage
This is a workaround for a hardware bug in the r3 revision that basically would
stop the system due to traffic on the i2c1 bus. A cpu voltage change would
trigger such traffic and that's what is avoided in order to work around it.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
index 6704ea2c72a3..0d38327043f8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
@@ -10,6 +10,12 @@
compatible = "purism,librem5r3", "purism,librem5", "fsl,imx8mq";
};
+_opp_table {
+ opp-10 {
+ opp-microvolt = <100>;
+ };
+};
+
_gyro {
mount-matrix = "1", "0", "0",
"0", "1", "0",
--
2.20.1
[PATCH v2 3/4] arm64: dts: imx8mq-librem5: Move usdhc clocks assignment to board DT
According to commit e045f044e84e ("arm64: dts: imx8mq: Move usdhc clocks
assignment to board DT") add the clocks assignment to imx8mq-librem5.dtsi
too.
Fixes: e045f044e84e ("arm64: dts: imx8mq: Move usdhc clocks assignment to board
DT")
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index a60df09d90f7..47e70ba4e4f1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -1082,6 +1082,8 @@
};
{
+ assigned-clocks = < IMX8MQ_CLK_USDHC1>;
+ assigned-clock-rates = <4>;
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc1>;
pinctrl-1 = <_usdhc1_100mhz>;
@@ -1094,6 +1096,8 @@
};
{
+ assigned-clocks = < IMX8MQ_CLK_USDHC2>;
+ assigned-clock-rates = <2>;
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc2>;
pinctrl-1 = <_usdhc2_100mhz>;
--
2.20.1
[PATCH v2 1/4] arm64: dts: imx8mq-librem5: add vin-supply to VDD_1V8
buck7 is the supply here. Also, fix alphabetical ordering.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index 64fc546b110f..55268fc0622e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -99,6 +99,14 @@
regulator-max-microvolt = <330>;
};
+ reg_vdd_1v8: regulator-vdd-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <_reg>;
+ };
+
reg_vdd_3v3: regulator-vdd-3v3 {
compatible = "regulator-fixed";
regulator-name = "VDD_3V3";
@@ -106,13 +114,6 @@
regulator-max-microvolt = <330>;
};
- reg_vdd_1v8: regulator-vdd-1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- };
-
reg_vsys_3v4: regulator-vsys-3v4 {
compatible = "regulator-fixed";
regulator-name = "VSYS_3V4";
--
2.20.1
[PATCH 1/4] arm64: dts: imx8mq-librem5: add vin-supply to VDD_1V8
buck7 is the supply here. Also, fix alphabetical ordering.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index 64fc546b110f..55268fc0622e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -99,6 +99,14 @@
regulator-max-microvolt = <330>;
};
+ reg_vdd_1v8: regulator-vdd-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <_reg>;
+ };
+
reg_vdd_3v3: regulator-vdd-3v3 {
compatible = "regulator-fixed";
regulator-name = "VDD_3V3";
@@ -106,13 +114,6 @@
regulator-max-microvolt = <330>;
};
- reg_vdd_1v8: regulator-vdd-1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- };
-
reg_vsys_3v4: regulator-vsys-3v4 {
compatible = "regulator-fixed";
regulator-name = "VSYS_3V4";
--
2.20.1
[PATCH 4/4] arm64: dts: imx8mq-librem5-r3: workaround i2c1 issue with 1GHz cpu voltage
This is a workaround for a hardware bug in the r3 revision that basically would
stop the system due to traffic on the i2c1 bus. A cpu voltage change would
trigger such traffic and that's what is avoided in order to work around it.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
index 6704ea2c72a3..0d38327043f8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
@@ -10,6 +10,12 @@
compatible = "purism,librem5r3", "purism,librem5", "fsl,imx8mq";
};
+_opp_table {
+ opp-10 {
+ opp-microvolt = <100>;
+ };
+};
+
_gyro {
mount-matrix = "1", "0", "0",
"0", "1", "0",
--
2.20.1
[PATCH 2/4] arm64: dts: imx8mq-librem5: add pinctrl for the touchscreen description
Add the pinctrl description for the interrupt.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index 55268fc0622e..a60df09d90f7 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -459,6 +459,13 @@
>;
};
+ pinctrl_touch: touchgrp {
+ fsl,pins = <
+ /* TP_INT */
+ MX8MQ_IOMUXC_ENET_RD1_GPIO1_IO270x80
+ >;
+ };
+
pinctrl_typec: typecgrp {
fsl,pins = <
/* TYPEC_MUX_EN */
@@ -880,6 +887,8 @@
touchscreen@38 {
compatible = "edt,edt-ft5506";
reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_touch>;
interrupt-parent = <>;
interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
touchscreen-size-x = <720>;
--
2.20.1
[PATCH 0/4] small Librem 5 phone dts updates
Some minor updates for the current hardware descriptions: Martin Kepplinger (4): arm64: dts: imx8mq-librem5: add vin-supply to VDD_1V8 arm64: dts: imx8mq-librem5: add pinctrl for the touchscreen description arm64: dts: imx8mq-librem5: Move usdhc clocks assignment to board DT arm64: dts: imx8mq-librem5-r3: workaround i2c1 issue with 1GHz cpu voltage .../boot/dts/freescale/imx8mq-librem5-r3.dts | 6 .../boot/dts/freescale/imx8mq-librem5.dtsi| 28 ++- 2 files changed, 27 insertions(+), 7 deletions(-) -- 2.20.1
[PATCH 3/4] arm64: dts: imx8mq-librem5: Move usdhc clocks assignment to board DT
According to commit e045f044e84e ("arm64: dts: imx8mq: Move usdhc clocks
assignment to board DT") add the clocks assignment to imx8mq-librem5.dtsi
too.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index a60df09d90f7..47e70ba4e4f1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -1082,6 +1082,8 @@
};
{
+ assigned-clocks = < IMX8MQ_CLK_USDHC1>;
+ assigned-clock-rates = <4>;
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc1>;
pinctrl-1 = <_usdhc1_100mhz>;
@@ -1094,6 +1096,8 @@
};
{
+ assigned-clocks = < IMX8MQ_CLK_USDHC2>;
+ assigned-clock-rates = <2>;
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc2>;
pinctrl-1 = <_usdhc2_100mhz>;
--
2.20.1
[PATCH] Revert "clk: imx: fix composite peripheral flags"
This reverts commit 936c383673b9e3007432f17140ac62de53d87db9. It breaks clock reparenting via devfreq on the imx8mq used in the Librem 5 phone. When switching dram frequency (which worked before) the system now hangs after this where the dram_apb clock cannot be set: [ 129.391755] imx8m-ddrc-devfreq 3d40.memory-controller: failed to set dram_apb parent: -16 [ 129.391959] imx8m-ddrc-devfreq 3d40.memory-controller: ddrc failed freq switch to 2500 from 8: error -16. now at 2500 [ 129.406133] imx8m-ddrc-devfreq 3d40.memory-controller: failed to update frequency from PM QoS (-16) Note that on the Librem 5 devkit that uses a different revision of the imx8mq SoC, the added flag does *not* break said clock reparenting so there might be subtle differences here. Signed-off-by: Martin Kepplinger --- drivers/clk/imx/clk-composite-8m.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/clk/imx/clk-composite-8m.c b/drivers/clk/imx/clk-composite-8m.c index 2c309e3dc8e3..78fb7e52a42a 100644 --- a/drivers/clk/imx/clk-composite-8m.c +++ b/drivers/clk/imx/clk-composite-8m.c @@ -216,7 +216,6 @@ struct clk_hw *imx8m_clk_hw_composite_flags(const char *name, div->width = PCG_PREDIV_WIDTH; divider_ops = _clk_composite_divider_ops; mux_ops = _mux_ops; - flags |= CLK_SET_PARENT_GATE; } div->lock = _ccm_lock; -- 2.20.1
[PATCH 2/6] arm64: dts: imx8mq: Add interconnect provider property
Add #interconnect-cells on main so that it will probe the interconnect
provider.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index d139a46ee8ce..244e28e54b35 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1163,6 +1163,7 @@
reg = <0x3270 0x10>;
clocks = < IMX8MQ_CLK_NOC>;
devfreq = <>;
+ #interconnect-cells = <1>;
operating-points-v2 = <_opp_table>;
noc_opp_table: opp-table {
--
2.20.1
[PATCH 1/6] arm64: dts: imx8m: Add NOC nodes
From: Leonard Crestez
Add initial support for dynamic frequency scaling of main NOC.
Make DDRC the parent of the NOC (using passive governor) so that the
main NOC is automatically scaled together with DDRC by default.
Support for proactive scaling via interconnect will come on top.
Signed-off-by: Leonard Crestez
Tested-by: Martin Kepplinger (imx8mq)
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 22 ++
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 22 ++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 22 ++
3 files changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index c824f2615fe8..835b19f0ea42 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -921,6 +921,28 @@
};
+ noc: interconnect@3270 {
+ compatible = "fsl,imx8mm-noc", "fsl,imx8m-noc";
+ reg = <0x3270 0x10>;
+ clocks = < IMX8MM_CLK_NOC>;
+ devfreq = <>;
+ operating-points-v2 = <_opp_table>;
+
+ noc_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-150M {
+ opp-hz = /bits/ 64 <15000>;
+ };
+ opp-375M {
+ opp-hz = /bits/ 64 <37500>;
+ };
+ opp-750M {
+ opp-hz = /bits/ 64 <75000>;
+ };
+ };
+ };
+
aips4: bus@32c0 {
compatible = "fsl,aips-bus", "simple-bus";
reg = <0x32c0 0x40>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index a06d2a6268e6..8e2d413f97d4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -772,6 +772,28 @@
};
+ noc: interconnect@3270 {
+ compatible = "fsl,imx8mn-noc", "fsl,imx8m-noc";
+ reg = <0x3270 0x10>;
+ clocks = < IMX8MN_CLK_NOC>;
+ devfreq = <>;
+ operating-points-v2 = <_opp_table>;
+
+ noc_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-100M {
+ opp-hz = /bits/ 64 <1>;
+ };
+ opp-600M {
+ opp-hz = /bits/ 64 <6>;
+ };
+ opp-800M {
+ opp-hz = /bits/ 64 <8>;
+ };
+ };
+ };
+
aips4: bus@32c0 {
compatible = "fsl,aips-bus", "simple-bus";
reg = <0x32c0 0x40>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index a841a023e8e0..d139a46ee8ce 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1158,6 +1158,28 @@
};
};
+ noc: interconnect@3270 {
+ compatible = "fsl,imx8mq-noc", "fsl,imx8m-noc";
+ reg = <0x3270 0x10>;
+ clocks = < IMX8MQ_CLK_NOC>;
+ devfreq = <>;
+ operating-points-v2 = <_opp_table>;
+
+ noc_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-133M {
+ opp-hz = /bits/ 64 <1>;
+ };
+ opp-400M {
+ opp-hz = /bits/ 64 <4>;
+ };
+ opp-800M {
+ opp-hz = /bits/ 64 <8>;
+ };
+ };
+ };
+
bus@32c0 { /* AIPS4 */
compatible = "fsl,aips-bus", "simple-bus";
reg = <0x32c0 0x40>;
--
2.20.1
[PATCH 0/6] imx8mq: updates for the interconnect fabric
Small updates for using interconnect on the imx8mq. In case you add icc_sync_state yourself, just let me know Georgi, and I can drop it here. Thanks again for your help. The last patch of course is optional and just cycles the defconfig. thanks, martin Leonard Crestez (1): arm64: dts: imx8m: Add NOC nodes Martin Kepplinger (5): arm64: dts: imx8mq: Add interconnect provider property arm64: dts: imx8mq: Add interconnect for lcdif interconnect: imx8mq: Use icc_sync_state arm64: defconfig: Enable interconnect for imx8mq arm64: defconfig: updates for 5.10 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 22 ++ arch/arm64/boot/dts/freescale/imx8mn.dtsi | 22 ++ arch/arm64/boot/dts/freescale/imx8mq.dtsi | 26 +++ arch/arm64/configs/defconfig | 85 +++ drivers/interconnect/imx/imx8mq.c | 2 + 5 files changed, 98 insertions(+), 59 deletions(-) -- 2.20.1
[PATCH 3/6] arm64: dts: imx8mq: Add interconnect for lcdif
Add interconnect ports for lcdif to set bus capabilities.
Signed-off-by: Martin Kepplinger
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 244e28e54b35..7384a69ed36c 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -11,6 +11,7 @@
#include "dt-bindings/input/input.h"
#include
#include
+#include
#include "imx8mq-pinfunc.h"
/ {
@@ -522,6 +523,8 @@
< IMX8MQ_VIDEO_PLL1>,
< IMX8MQ_VIDEO_PLL1_OUT>;
assigned-clock-rates = <0>, <0>, <0>,
<59400>;
+ interconnects = < IMX8MQ_ICM_LCDIF
IMX8MQ_ICS_DRAM>;
+ interconnect-names = "lcdif-dram";
status = "disabled";
port@0 {
--
2.20.1
[PATCH 4/6] interconnect: imx8mq: Use icc_sync_state
Add the icc_sync_state callback to notify the framework when consumers
are probed and the bandwidth doesn't have to be kept at maximum anymore.
Signed-off-by: Martin Kepplinger
Suggested-by: Georgi Djakov
---
drivers/interconnect/imx/imx8mq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/interconnect/imx/imx8mq.c
b/drivers/interconnect/imx/imx8mq.c
index ba43a15aefec..d7768d3c6d8a 100644
--- a/drivers/interconnect/imx/imx8mq.c
+++ b/drivers/interconnect/imx/imx8mq.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include "imx.h"
@@ -94,6 +95,7 @@ static struct platform_driver imx8mq_icc_driver = {
.remove = imx8mq_icc_remove,
.driver = {
.name = "imx8mq-interconnect",
+ .sync_state = icc_sync_state,
},
};
--
2.20.1
[PATCH 5/6] arm64: defconfig: Enable interconnect for imx8mq
Enable INTERCONNECT_IMX8MQ in order to make interconnect more widely available for testing. Signed-off-by: Martin Kepplinger --- arch/arm64/configs/defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 867cc4a5f00f..57cf2f50b5f7 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -1051,10 +1051,11 @@ CONFIG_OF_FPGA_REGION=m CONFIG_TEE=y CONFIG_OPTEE=y CONFIG_SLIMBUS=m +CONFIG_MUX_MMIO=y CONFIG_SLIM_QCOM_CTRL=m CONFIG_SLIM_QCOM_NGD_CTRL=m -CONFIG_MUX_MMIO=y -CONFIG_INTERCONNECT=y +CONFIG_INTERCONNECT_IMX=m +CONFIG_INTERCONNECT_IMX8MQ=m CONFIG_INTERCONNECT_QCOM=y CONFIG_INTERCONNECT_QCOM_MSM8916=m CONFIG_INTERCONNECT_QCOM_OSM_L3=m -- 2.20.1
