* [PATCH v3 3/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
From: Guillaume Tucker @ 2017-04-19 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492588180.git.guillaume.tucker@collabora.com>
Add reference to the Mali GPU device tree node on the
rk3288-rock2-som platform. Tested on a Radxa Rock2 Square board.
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288-rock2-som.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-rock2-som.dtsi b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
index 1c0bbc9b928b..f694867fa46a 100644
--- a/arch/arm/boot/dts/rk3288-rock2-som.dtsi
+++ b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
@@ -301,3 +301,8 @@
&wdt {
status = "okay";
};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 4/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly
From: Guillaume Tucker @ 2017-04-19 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492588180.git.guillaume.tucker@collabora.com>
Add reference to the Mali GPU device tree node on rk3288-firefly.
Tested on Firefly board.
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288-firefly.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 10793ac18599..f520589493b4 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -594,3 +594,8 @@
&wdt {
status = "okay";
};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 5/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron
From: Guillaume Tucker @ 2017-04-19 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492588180.git.guillaume.tucker@collabora.com>
From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Add reference to the Mali GPU device tree node on rk3288-veyron.
Tested on Minnie and Jerry boards.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 5d1eb0a25827..9847d5c6db3b 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -447,6 +447,11 @@
status = "okay";
};
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
&wdt {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] iio: adc: sama5d2_adc hw triggers and buffers
From: Eugen Hristev @ 2017-04-19 8:20 UTC (permalink / raw)
To: linux-arm-kernel
This patch implements the hardware triggers support and
buffer management for sama5d2.
The DT modifications ( [PATCH 1/3] ARM: dts: at91: sama5d2_xplained:
enable ADTRG pin) are for demonstration purposes of the feature,
setting the pinctrl for the ADC hw trigger pin,should go through at91
maintainers.
I also increased the buffer size for the trigger name in the generic_buffer
application to cope with longer names and avoid stack smashing problem.
This is in patch [PATCH 3/3] iio: tools: generic_buffer: increase trigger length
Eugen Hristev (3):
ARM: dts: at91: sama5d2_xplained: enable ADTRG pin
iio: adc: at91-sama5d2_adc: add hw trigger and buffer support
iio: tools: generic_buffer: increase trigger length
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 16 ++-
drivers/iio/adc/at91-sama5d2_adc.c | 208 +++++++++++++++++++++++++++-
tools/iio/iio_utils.h | 2 +-
3 files changed, 220 insertions(+), 6 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] ARM: dts: at91: sama5d2_xplained: enable ADTRG pin
From: Eugen Hristev @ 2017-04-19 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492590045-17329-1-git-send-email-eugen.hristev@microchip.com>
Enable pinctrl for ADTRG pin (PD31) for ADC hardware trigger support.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 0bef9e0..04754b1 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -303,7 +303,7 @@
vddana-supply = <&vdd_3v3_lp_reg>;
vref-supply = <&vdd_3v3_lp_reg>;
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_adc_default>;
+ pinctrl-0 = <&pinctrl_adc_default &pinctrl_adtrg_default>;
status = "okay";
};
@@ -322,6 +322,20 @@
bias-disable;
};
+ /*
+ * The ADTRG pin can work on any edge type.
+ * In here it's being pulled up, so need to
+ * connect it to ground to get an edge e.g.
+ * Trigger can be configured on falling, rise
+ * or any edge, and the pull-up can be changed
+ * to pull-down or left floating according to
+ * needs.
+ */
+ pinctrl_adtrg_default: adtrg_default {
+ pinmux = <PIN_PD31__ADTRG>;
+ bias-pull-up;
+ };
+
pinctrl_charger_chglev: charger_chglev {
pinmux = <PIN_PA12__GPIO>;
bias-disable;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support
From: Eugen Hristev @ 2017-04-19 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492590045-17329-1-git-send-email-eugen.hristev@microchip.com>
Added support for the external hardware trigger on pin ADTRG,
integrated the three possible edge triggers into the subsystem
and created buffer management for data retrieval
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/iio/adc/at91-sama5d2_adc.c | 207 ++++++++++++++++++++++++++++++++++++-
1 file changed, 204 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
index e10dca3..09a8c3d 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -23,8 +23,15 @@
#include <linux/platform_device.h>
#include <linux/sched.h>
#include <linux/wait.h>
+#include <linux/slab.h>
+
#include <linux/iio/iio.h>
#include <linux/iio/sysfs.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+#include <linux/iio/triggered_buffer.h>
+
#include <linux/regulator/consumer.h>
/* Control Register */
@@ -132,6 +139,17 @@
#define AT91_SAMA5D2_PRESSR 0xbc
/* Trigger Register */
#define AT91_SAMA5D2_TRGR 0xc0
+/* Mask for TRGMOD field of TRGR register */
+#define AT91_SAMA5D2_TRGR_TRGMOD_MASK GENMASK(2, 0)
+/* No trigger, only software trigger can start conversions */
+#define AT91_SAMA5D2_TRGR_TRGMOD_NO_TRIGGER 0
+/* Trigger Mode external trigger rising edge */
+#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_RISE 1
+/* Trigger Mode external trigger falling edge */
+#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL 2
+/* Trigger Mode external trigger any edge */
+#define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY 3
+
/* Correction Select Register */
#define AT91_SAMA5D2_COSR 0xd0
/* Correction Value Register */
@@ -145,14 +163,20 @@
/* Version Register */
#define AT91_SAMA5D2_VERSION 0xfc
+#define AT91_SAMA5D2_HW_TRIG_CNT 3
+#define AT91_SAMA5D2_SINGLE_CHAN_CNT 12
+#define AT91_SAMA5D2_DIFF_CHAN_CNT 6
+
#define AT91_SAMA5D2_CHAN_SINGLE(num, addr) \
{ \
.type = IIO_VOLTAGE, \
.channel = num, \
.address = addr, \
+ .scan_index = num, \
.scan_type = { \
.sign = 'u', \
.realbits = 12, \
+ .storagebits = 16, \
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
@@ -168,9 +192,11 @@
.channel = num, \
.channel2 = num2, \
.address = addr, \
+ .scan_index = num + AT91_SAMA5D2_SINGLE_CHAN_CNT, \
.scan_type = { \
.sign = 's', \
.realbits = 12, \
+ .storagebits = 16, \
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
@@ -188,18 +214,26 @@ struct at91_adc_soc_info {
unsigned max_sample_rate;
};
+struct at91_adc_trigger {
+ char *name;
+ unsigned int trgmod_value;
+};
+
struct at91_adc_state {
void __iomem *base;
int irq;
struct clk *per_clk;
struct regulator *reg;
struct regulator *vref;
+ u16 *buffer;
int vref_uv;
const struct iio_chan_spec *chan;
bool conversion_done;
u32 conversion_value;
struct at91_adc_soc_info soc_info;
wait_queue_head_t wq_data_available;
+ struct iio_trigger **trig;
+ const struct at91_adc_trigger *trigger_list;
/*
* lock to prevent concurrent 'single conversion' requests through
* sysfs.
@@ -207,6 +241,21 @@ struct at91_adc_state {
struct mutex lock;
};
+static const struct at91_adc_trigger at91_adc_trigger_list[] = {
+ {
+ .name = "external-rising",
+ .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_RISE,
+ },
+ {
+ .name = "external-falling",
+ .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL,
+ },
+ {
+ .name = "external-any",
+ .trgmod_value = AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY,
+ },
+};
+
static const struct iio_chan_spec at91_adc_channels[] = {
AT91_SAMA5D2_CHAN_SINGLE(0, 0x50),
AT91_SAMA5D2_CHAN_SINGLE(1, 0x54),
@@ -226,8 +275,141 @@ static const struct iio_chan_spec at91_adc_channels[] = {
AT91_SAMA5D2_CHAN_DIFF(6, 7, 0x68),
AT91_SAMA5D2_CHAN_DIFF(8, 9, 0x70),
AT91_SAMA5D2_CHAN_DIFF(10, 11, 0x78),
+ IIO_CHAN_SOFT_TIMESTAMP(AT91_SAMA5D2_SINGLE_CHAN_CNT
+ + AT91_SAMA5D2_DIFF_CHAN_CNT + 1),
};
+static int at91_adc_configure_trigger(struct iio_trigger *trig, bool state)
+{
+ struct iio_dev *indio = iio_trigger_get_drvdata(trig);
+ struct at91_adc_state *st = iio_priv(indio);
+ u32 status = at91_adc_readl(st, AT91_SAMA5D2_TRGR);
+ u8 bit;
+ int i;
+
+ /* clear TRGMOD */
+ status &= ~AT91_SAMA5D2_TRGR_TRGMOD_MASK;
+
+ /* if we are disabling the trigger, it's enough to clear TRGMOD */
+ if (!state) {
+ at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
+ kfree(st->buffer);
+ return 0;
+ }
+
+ st->buffer = kmalloc(indio->scan_bytes, GFP_KERNEL);
+ if (!st->buffer)
+ return -ENOMEM;
+
+ for (i = 0; i < AT91_SAMA5D2_HW_TRIG_CNT; i++) {
+ if (!strstr(trig->name, st->trigger_list[i].name)) {
+ status |= st->trigger_list[i].trgmod_value;
+ break;
+ }
+ }
+
+ /* setup hw trigger */
+ at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
+
+ for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
+ struct iio_chan_spec const *chan = indio->channels + bit;
+
+ at91_adc_writel(st, AT91_SAMA5D2_CHER, BIT(chan->channel));
+ at91_adc_writel(st, AT91_SAMA5D2_IER, BIT(chan->channel));
+ }
+
+ return 0;
+}
+
+static const struct iio_trigger_ops at91_adc_trigger_ops = {
+ .owner = THIS_MODULE,
+ .set_trigger_state = &at91_adc_configure_trigger,
+};
+
+static struct iio_trigger *at91_adc_allocate_trigger(struct iio_dev *indio,
+ char *trigger_name)
+{
+ struct iio_trigger *trig;
+ int ret;
+
+ trig = devm_iio_trigger_alloc(&indio->dev, "%s-dev%d-%s", indio->name,
+ indio->id, trigger_name);
+ if (!trig)
+ return NULL;
+
+ trig->dev.parent = indio->dev.parent;
+ iio_trigger_set_drvdata(trig, indio);
+ trig->ops = &at91_adc_trigger_ops;
+
+ ret = devm_iio_trigger_register(&indio->dev, trig);
+
+ if (ret)
+ return NULL;
+
+ return trig;
+}
+
+static int at91_adc_trigger_init(struct iio_dev *indio)
+{
+ struct at91_adc_state *st = iio_priv(indio);
+ int i;
+
+ st->trig = devm_kzalloc(&indio->dev,
+ AT91_SAMA5D2_HW_TRIG_CNT * sizeof(*st->trig),
+ GFP_KERNEL);
+
+ if (!st->trig) {
+ dev_err(&indio->dev, "could not allocate trig list memory\n");
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < AT91_SAMA5D2_HW_TRIG_CNT; i++) {
+ st->trig[i] = at91_adc_allocate_trigger(indio,
+ st->trigger_list[i].name);
+ if (!st->trig[i]) {
+ dev_err(&indio->dev,
+ "could not allocate trigger %d\n", i);
+ return -ENOMEM;
+ }
+ }
+
+ return 0;
+}
+
+static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
+{
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio = pf->indio_dev;
+ struct at91_adc_state *st = iio_priv(indio);
+ int i = 0;
+ u8 bit;
+
+ for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
+ struct iio_chan_spec const *chan = indio->channels + bit;
+
+ st->buffer[i] = at91_adc_readl(st, chan->address);
+ i++;
+ }
+
+ iio_push_to_buffers_with_timestamp(indio, st->buffer, pf->timestamp);
+
+ iio_trigger_notify_done(indio->trig);
+
+ /* Needed to ACK the DRDY interruption */
+ at91_adc_readl(st, AT91_SAMA5D2_LCDR);
+
+ enable_irq(st->irq);
+
+ return IRQ_HANDLED;
+}
+
+static int at91_adc_buffer_init(struct iio_dev *indio)
+{
+ return devm_iio_triggered_buffer_setup(&indio->dev, indio,
+ &iio_pollfunc_store_time,
+ &at91_adc_trigger_handler, NULL);
+}
+
static unsigned at91_adc_startup_time(unsigned startup_time_min,
unsigned adc_clk_khz)
{
@@ -293,14 +475,19 @@ static irqreturn_t at91_adc_interrupt(int irq, void *private)
u32 status = at91_adc_readl(st, AT91_SAMA5D2_ISR);
u32 imr = at91_adc_readl(st, AT91_SAMA5D2_IMR);
- if (status & imr) {
+ if (!(status & imr))
+ return IRQ_NONE;
+
+ if (iio_buffer_enabled(indio)) {
+ disable_irq_nosync(irq);
+ iio_trigger_poll(indio->trig);
+ } else {
st->conversion_value = at91_adc_readl(st, st->chan->address);
st->conversion_done = true;
wake_up_interruptible(&st->wq_data_available);
- return IRQ_HANDLED;
}
- return IRQ_NONE;
+ return IRQ_HANDLED;
}
static int at91_adc_read_raw(struct iio_dev *indio_dev,
@@ -406,6 +593,8 @@ static int at91_adc_probe(struct platform_device *pdev)
st = iio_priv(indio_dev);
+ st->trigger_list = at91_adc_trigger_list;
+
ret = of_property_read_u32(pdev->dev.of_node,
"atmel,min-sample-rate-hz",
&st->soc_info.min_sample_rate);
@@ -499,6 +688,18 @@ static int at91_adc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, indio_dev);
+ ret = at91_adc_buffer_init(indio_dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "couldn't initialize the buffer.\n");
+ goto per_clk_disable_unprepare;
+ }
+
+ ret = at91_adc_trigger_init(indio_dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "couldn't setup the triggers.\n");
+ goto per_clk_disable_unprepare;
+ }
+
ret = iio_device_register(indio_dev);
if (ret < 0)
goto per_clk_disable_unprepare;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] iio: tools: generic_buffer: increase trigger length
From: Eugen Hristev @ 2017-04-19 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492590045-17329-1-git-send-email-eugen.hristev@microchip.com>
Increased trigger length to 50 in order to cope with trigger names like
fc030000.adc-dev0-external-rising
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
tools/iio/iio_utils.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/iio/iio_utils.h b/tools/iio/iio_utils.h
index 780f201..9d59771 100644
--- a/tools/iio/iio_utils.h
+++ b/tools/iio/iio_utils.h
@@ -13,7 +13,7 @@
#include <stdint.h>
/* Made up value to limit allocation sizes */
-#define IIO_MAX_NAME_LENGTH 30
+#define IIO_MAX_NAME_LENGTH 50
#define FORMAT_SCAN_ELEMENTS_DIR "%s/scan_elements"
#define FORMAT_TYPE_FILE "%s_type"
--
2.7.4
^ permalink raw reply related
* [PATCH] iio: stm32 trigger: fix sampling_frequency read
From: Benjamin Gaignard @ 2017-04-19 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491566026-302-1-git-send-email-fabrice.gasnier@st.com>
2017-04-07 13:53 GMT+02:00 Fabrice Gasnier <fabrice.gasnier@st.com>:
> When prescaler (PSC) is 0, it means div factor is 1: counter clock
> frequency is equal to input clk / (PSC + 1).
> When reload value is 8 for example, counter counts 9 cycles, from 0 to 8.
> This is handled in frequency write routine, by writing respectively:
> - prescaler - 1 to PSC
> - reload value - 1 to ARR
> This fix does the opposite when reading the frequency from PSC and ARR:
> - prescaler is PSC + 1
> - reload value is ARR + 1
>
> Thus, PSC may be 0, depending on requested sampling frequency (div 1).
> In this case, reading freq wrongly reports 0, instead of computing and
> reporting correct value.
> Remove test on !psc and !arr.
>
> Small test on stm32f4 (example on tim1_trgo), before this fix:
> $ cd /sys/bus/iio/devices/triggerX
> $ echo 10000 > sampling_frequency
> $ cat sampling_frequency
> 0
>
> After this fix:
> $ echo 10000 > sampling_frequency
> $ cat sampling_frequency
> 10000
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> drivers/iio/trigger/stm32-timer-trigger.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/trigger/stm32-timer-trigger.c b/drivers/iio/trigger/stm32-timer-trigger.c
> index 994b96d..5ee362b 100644
> --- a/drivers/iio/trigger/stm32-timer-trigger.c
> +++ b/drivers/iio/trigger/stm32-timer-trigger.c
> @@ -152,10 +152,10 @@ static ssize_t stm32_tt_read_frequency(struct device *dev,
> regmap_read(priv->regmap, TIM_PSC, &psc);
> regmap_read(priv->regmap, TIM_ARR, &arr);
>
> - if (psc && arr && (cr1 & TIM_CR1_CEN)) {
> + if (cr1 & TIM_CR1_CEN) {
> freq = (unsigned long long)clk_get_rate(priv->clk);
> - do_div(freq, psc);
> - do_div(freq, arr);
> + do_div(freq, psc + 1);
> + do_div(freq, arr + 1);
> }
>
> return sprintf(buf, "%d\n", (unsigned int)freq);
> --
> 1.9.1
>
Acked-by: Benjamin Gaignard <benjamin.gaignard@st.com>
^ permalink raw reply
* [Linaro-mm-sig] [PATCHv4 05/12] staging: android: ion: Break the ABI in the name of forward progress
From: Daniel Vetter @ 2017-04-19 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492540034-5466-6-git-send-email-labbott@redhat.com>
On Tue, Apr 18, 2017 at 11:27:07AM -0700, Laura Abbott wrote:
> Several of the Ion ioctls were designed in such a way that they
> necessitate compat ioctls. We're breaking a bunch of other ABIs and
> cleaning stuff up anyway so let's follow the ioctl guidelines and clean
> things up while everyone is busy converting things over anyway. As part
> of this, also remove the useless alignment field from the allocation
> structure.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/staging/android/ion/Makefile | 3 -
> drivers/staging/android/ion/compat_ion.c | 152 -------------------------------
> drivers/staging/android/ion/compat_ion.h | 29 ------
> drivers/staging/android/ion/ion-ioctl.c | 1 -
> drivers/staging/android/ion/ion.c | 5 +-
> drivers/staging/android/uapi/ion.h | 19 ++--
> 6 files changed, 11 insertions(+), 198 deletions(-)
> delete mode 100644 drivers/staging/android/ion/compat_ion.c
> delete mode 100644 drivers/staging/android/ion/compat_ion.h
>
> diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
> index 66d0c4a..a892afa 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -2,6 +2,3 @@ obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
> ion_page_pool.o ion_system_heap.o \
> ion_carveout_heap.o ion_chunk_heap.o
> obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
> -ifdef CONFIG_COMPAT
> -obj-$(CONFIG_ION) += compat_ion.o
> -endif
> diff --git a/drivers/staging/android/ion/compat_ion.c b/drivers/staging/android/ion/compat_ion.c
> deleted file mode 100644
> index 5037ddd..0000000
> --- a/drivers/staging/android/ion/compat_ion.c
> +++ /dev/null
> @@ -1,152 +0,0 @@
> -/*
> - * drivers/staging/android/ion/compat_ion.c
> - *
> - * Copyright (C) 2013 Google, Inc.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - */
> -
> -#include <linux/compat.h>
> -#include <linux/fs.h>
> -#include <linux/uaccess.h>
> -
> -#include "ion.h"
> -#include "compat_ion.h"
> -
> -/* See drivers/staging/android/uapi/ion.h for the definition of these structs */
> -struct compat_ion_allocation_data {
> - compat_size_t len;
> - compat_size_t align;
> - compat_uint_t heap_id_mask;
> - compat_uint_t flags;
> - compat_int_t handle;
> -};
> -
> -struct compat_ion_handle_data {
> - compat_int_t handle;
> -};
> -
> -#define COMPAT_ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
> - struct compat_ion_allocation_data)
> -#define COMPAT_ION_IOC_FREE _IOWR(ION_IOC_MAGIC, 1, \
> - struct compat_ion_handle_data)
> -
> -static int compat_get_ion_allocation_data(
> - struct compat_ion_allocation_data __user *data32,
> - struct ion_allocation_data __user *data)
> -{
> - compat_size_t s;
> - compat_uint_t u;
> - compat_int_t i;
> - int err;
> -
> - err = get_user(s, &data32->len);
> - err |= put_user(s, &data->len);
> - err |= get_user(s, &data32->align);
> - err |= put_user(s, &data->align);
> - err |= get_user(u, &data32->heap_id_mask);
> - err |= put_user(u, &data->heap_id_mask);
> - err |= get_user(u, &data32->flags);
> - err |= put_user(u, &data->flags);
> - err |= get_user(i, &data32->handle);
> - err |= put_user(i, &data->handle);
> -
> - return err;
> -}
> -
> -static int compat_get_ion_handle_data(
> - struct compat_ion_handle_data __user *data32,
> - struct ion_handle_data __user *data)
> -{
> - compat_int_t i;
> - int err;
> -
> - err = get_user(i, &data32->handle);
> - err |= put_user(i, &data->handle);
> -
> - return err;
> -}
> -
> -static int compat_put_ion_allocation_data(
> - struct compat_ion_allocation_data __user *data32,
> - struct ion_allocation_data __user *data)
> -{
> - compat_size_t s;
> - compat_uint_t u;
> - compat_int_t i;
> - int err;
> -
> - err = get_user(s, &data->len);
> - err |= put_user(s, &data32->len);
> - err |= get_user(s, &data->align);
> - err |= put_user(s, &data32->align);
> - err |= get_user(u, &data->heap_id_mask);
> - err |= put_user(u, &data32->heap_id_mask);
> - err |= get_user(u, &data->flags);
> - err |= put_user(u, &data32->flags);
> - err |= get_user(i, &data->handle);
> - err |= put_user(i, &data32->handle);
> -
> - return err;
> -}
> -
> -long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> -{
> - long ret;
> -
> - if (!filp->f_op->unlocked_ioctl)
> - return -ENOTTY;
> -
> - switch (cmd) {
> - case COMPAT_ION_IOC_ALLOC:
> - {
> - struct compat_ion_allocation_data __user *data32;
> - struct ion_allocation_data __user *data;
> - int err;
> -
> - data32 = compat_ptr(arg);
> - data = compat_alloc_user_space(sizeof(*data));
> - if (!data)
> - return -EFAULT;
> -
> - err = compat_get_ion_allocation_data(data32, data);
> - if (err)
> - return err;
> - ret = filp->f_op->unlocked_ioctl(filp, ION_IOC_ALLOC,
> - (unsigned long)data);
> - err = compat_put_ion_allocation_data(data32, data);
> - return ret ? ret : err;
> - }
> - case COMPAT_ION_IOC_FREE:
> - {
> - struct compat_ion_handle_data __user *data32;
> - struct ion_handle_data __user *data;
> - int err;
> -
> - data32 = compat_ptr(arg);
> - data = compat_alloc_user_space(sizeof(*data));
> - if (!data)
> - return -EFAULT;
> -
> - err = compat_get_ion_handle_data(data32, data);
> - if (err)
> - return err;
> -
> - return filp->f_op->unlocked_ioctl(filp, ION_IOC_FREE,
> - (unsigned long)data);
> - }
> - case ION_IOC_SHARE:
> - return filp->f_op->unlocked_ioctl(filp, cmd,
> - (unsigned long)compat_ptr(arg));
> - default:
> - return -ENOIOCTLCMD;
> - }
> -}
> diff --git a/drivers/staging/android/ion/compat_ion.h b/drivers/staging/android/ion/compat_ion.h
> deleted file mode 100644
> index 9da8f91..0000000
> --- a/drivers/staging/android/ion/compat_ion.h
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -/*
> - * drivers/staging/android/ion/compat_ion.h
> - *
> - * Copyright (C) 2013 Google, Inc.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - */
> -
> -#ifndef _LINUX_COMPAT_ION_H
> -#define _LINUX_COMPAT_ION_H
> -
> -#if IS_ENABLED(CONFIG_COMPAT)
> -
> -long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
> -
> -#else
> -
> -#define compat_ion_ioctl NULL
> -
> -#endif /* CONFIG_COMPAT */
> -#endif /* _LINUX_COMPAT_ION_H */
> diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
> index a361724..91b5c2b 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -20,7 +20,6 @@
>
> #include "ion.h"
> #include "ion_priv.h"
> -#include "compat_ion.h"
>
> union ion_ioctl_arg {
> struct ion_fd_data fd;
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index 65638f5..fbab1e3 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -40,7 +40,6 @@
>
> #include "ion.h"
> #include "ion_priv.h"
> -#include "compat_ion.h"
>
> bool ion_buffer_cached(struct ion_buffer *buffer)
> {
> @@ -1065,7 +1064,9 @@ static const struct file_operations ion_fops = {
> .open = ion_open,
> .release = ion_release,
> .unlocked_ioctl = ion_ioctl,
> - .compat_ioctl = compat_ion_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = ion_ioctl,
> +#endif
> };
>
> static size_t ion_debug_heap_total(struct ion_client *client,
> diff --git a/drivers/staging/android/uapi/ion.h b/drivers/staging/android/uapi/ion.h
> index abd72fd..bba1c47 100644
> --- a/drivers/staging/android/uapi/ion.h
> +++ b/drivers/staging/android/uapi/ion.h
> @@ -20,8 +20,6 @@
> #include <linux/ioctl.h>
> #include <linux/types.h>
>
> -typedef int ion_user_handle_t;
> -
> /**
> * enum ion_heap_types - list of all possible types of heaps
> * @ION_HEAP_TYPE_SYSTEM: memory allocated via vmalloc
> @@ -76,7 +74,6 @@ enum ion_heap_type {
> /**
> * struct ion_allocation_data - metadata passed from userspace for allocations
> * @len: size of the allocation
> - * @align: required alignment of the allocation
> * @heap_id_mask: mask of heap ids to allocate from
> * @flags: flags passed to heap
> * @handle: pointer that will be populated with a cookie to use to
> @@ -85,11 +82,11 @@ enum ion_heap_type {
> * Provided by userspace as an argument to the ioctl
> */
> struct ion_allocation_data {
> - size_t len;
> - size_t align;
> - unsigned int heap_id_mask;
> - unsigned int flags;
> - ion_user_handle_t handle;
> + __u64 len;
> + __u32 heap_id_mask;
> + __u32 flags;
> + __u32 handle;
> + __u32 unused;
> };
>
> /**
> @@ -103,8 +100,8 @@ struct ion_allocation_data {
> * provides the file descriptor and the kernel returns the handle.
> */
> struct ion_fd_data {
> - ion_user_handle_t handle;
> - int fd;
> + __u32 handle;
> + __u32 fd;
> };
>
> /**
> @@ -112,7 +109,7 @@ struct ion_fd_data {
> * @handle: a handle
> */
> struct ion_handle_data {
> - ion_user_handle_t handle;
> + __u32 handle;
> };
>
> #define MAX_HEAP_NAME 32
> --
> 2.7.4
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [Linaro-mm-sig] [PATCHv4 10/12] staging: android: ion: Remove ion_handle and ion_client
From: Daniel Vetter @ 2017-04-19 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492540034-5466-11-git-send-email-labbott@redhat.com>
On Tue, Apr 18, 2017 at 11:27:12AM -0700, Laura Abbott wrote:
> ion_handle was introduced as an abstraction to represent a reference to
> a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
> emerged as the preferred standard for use in the kernel. This has made
> the ion_handle an unnecessary abstraction and prone to race
> conditions. ion_client is also now only used internally. We have enough
> mechanisms for race conditions and leaks already so just drop ion_handle
> and ion_client. This also includes ripping out most of the debugfs
> infrastructure since much of that was tied to clients and handles.
> The debugfs infrastructure was prone to give confusing data (orphaned
> allocations) so it can be replaced with something better if people
> actually want it.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
Yeah I think improving the dma-buf debugfs stuff (maybe with an allocator
callback to dump additional data) is the better option.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/staging/android/ion/ion-ioctl.c | 53 +--
> drivers/staging/android/ion/ion.c | 701 ++------------------------------
> drivers/staging/android/ion/ion.h | 77 +---
> drivers/staging/android/uapi/ion.h | 25 +-
> 4 files changed, 51 insertions(+), 805 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
> index 4e7bf16..76427e4 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -21,9 +21,7 @@
> #include "ion.h"
>
> union ion_ioctl_arg {
> - struct ion_fd_data fd;
> struct ion_allocation_data allocation;
> - struct ion_handle_data handle;
> struct ion_heap_query query;
> };
>
> @@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
> static unsigned int ion_ioctl_dir(unsigned int cmd)
> {
> switch (cmd) {
> - case ION_IOC_FREE:
> - return _IOC_WRITE;
> default:
> return _IOC_DIR(cmd);
> }
> @@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
>
> long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> {
> - struct ion_client *client = filp->private_data;
> - struct ion_handle *cleanup_handle = NULL;
> int ret = 0;
> unsigned int dir;
> union ion_ioctl_arg data;
> @@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> switch (cmd) {
> case ION_IOC_ALLOC:
> {
> - struct ion_handle *handle;
> + int fd;
>
> - handle = ion_alloc(client, data.allocation.len,
> + fd = ion_alloc(data.allocation.len,
> data.allocation.heap_id_mask,
> data.allocation.flags);
> - if (IS_ERR(handle))
> - return PTR_ERR(handle);
> + if (fd < 0)
> + return fd;
>
> - data.allocation.handle = handle->id;
> + data.allocation.fd = fd;
>
> - cleanup_handle = handle;
> - break;
> - }
> - case ION_IOC_FREE:
> - {
> - struct ion_handle *handle;
> -
> - mutex_lock(&client->lock);
> - handle = ion_handle_get_by_id_nolock(client,
> - data.handle.handle);
> - if (IS_ERR(handle)) {
> - mutex_unlock(&client->lock);
> - return PTR_ERR(handle);
> - }
> - ion_free_nolock(client, handle);
> - ion_handle_put_nolock(handle);
> - mutex_unlock(&client->lock);
> - break;
> - }
> - case ION_IOC_SHARE:
> - {
> - struct ion_handle *handle;
> -
> - handle = ion_handle_get_by_id(client, data.handle.handle);
> - if (IS_ERR(handle))
> - return PTR_ERR(handle);
> - data.fd.fd = ion_share_dma_buf_fd(client, handle);
> - ion_handle_put(handle);
> - if (data.fd.fd < 0)
> - ret = data.fd.fd;
> break;
> }
> case ION_IOC_HEAP_QUERY:
> - ret = ion_query_heaps(client, &data.query);
> + ret = ion_query_heaps(&data.query);
> break;
> default:
> return -ENOTTY;
> }
>
> if (dir & _IOC_READ) {
> - if (copy_to_user((void __user *)arg, &data, _IOC_SIZE(cmd))) {
> - if (cleanup_handle)
> - ion_free(client, cleanup_handle);
> + if (copy_to_user((void __user *)arg, &data, _IOC_SIZE(cmd)))
> return -EFAULT;
> - }
> }
> return ret;
> }
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index 5a82bea..9eeb06f 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -90,7 +90,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
>
> buffer->heap = heap;
> buffer->flags = flags;
> - kref_init(&buffer->ref);
>
> ret = heap->ops->allocate(heap, buffer, len, flags);
>
> @@ -140,9 +139,8 @@ void ion_buffer_destroy(struct ion_buffer *buffer)
> kfree(buffer);
> }
>
> -static void _ion_buffer_destroy(struct kref *kref)
> +static void _ion_buffer_destroy(struct ion_buffer *buffer)
> {
> - struct ion_buffer *buffer = container_of(kref, struct ion_buffer, ref);
> struct ion_heap *heap = buffer->heap;
> struct ion_device *dev = buffer->dev;
>
> @@ -156,255 +154,6 @@ static void _ion_buffer_destroy(struct kref *kref)
> ion_buffer_destroy(buffer);
> }
>
> -static void ion_buffer_get(struct ion_buffer *buffer)
> -{
> - kref_get(&buffer->ref);
> -}
> -
> -static int ion_buffer_put(struct ion_buffer *buffer)
> -{
> - return kref_put(&buffer->ref, _ion_buffer_destroy);
> -}
> -
> -static void ion_buffer_add_to_handle(struct ion_buffer *buffer)
> -{
> - mutex_lock(&buffer->lock);
> - buffer->handle_count++;
> - mutex_unlock(&buffer->lock);
> -}
> -
> -static void ion_buffer_remove_from_handle(struct ion_buffer *buffer)
> -{
> - /*
> - * when a buffer is removed from a handle, if it is not in
> - * any other handles, copy the taskcomm and the pid of the
> - * process it's being removed from into the buffer. At this
> - * point there will be no way to track what processes this buffer is
> - * being used by, it only exists as a dma_buf file descriptor.
> - * The taskcomm and pid can provide a debug hint as to where this fd
> - * is in the system
> - */
> - mutex_lock(&buffer->lock);
> - buffer->handle_count--;
> - BUG_ON(buffer->handle_count < 0);
> - if (!buffer->handle_count) {
> - struct task_struct *task;
> -
> - task = current->group_leader;
> - get_task_comm(buffer->task_comm, task);
> - buffer->pid = task_pid_nr(task);
> - }
> - mutex_unlock(&buffer->lock);
> -}
> -
> -static struct ion_handle *ion_handle_create(struct ion_client *client,
> - struct ion_buffer *buffer)
> -{
> - struct ion_handle *handle;
> -
> - handle = kzalloc(sizeof(*handle), GFP_KERNEL);
> - if (!handle)
> - return ERR_PTR(-ENOMEM);
> - kref_init(&handle->ref);
> - RB_CLEAR_NODE(&handle->node);
> - handle->client = client;
> - ion_buffer_get(buffer);
> - ion_buffer_add_to_handle(buffer);
> - handle->buffer = buffer;
> -
> - return handle;
> -}
> -
> -static void ion_handle_kmap_put(struct ion_handle *);
> -
> -static void ion_handle_destroy(struct kref *kref)
> -{
> - struct ion_handle *handle = container_of(kref, struct ion_handle, ref);
> - struct ion_client *client = handle->client;
> - struct ion_buffer *buffer = handle->buffer;
> -
> - mutex_lock(&buffer->lock);
> - while (handle->kmap_cnt)
> - ion_handle_kmap_put(handle);
> - mutex_unlock(&buffer->lock);
> -
> - idr_remove(&client->idr, handle->id);
> - if (!RB_EMPTY_NODE(&handle->node))
> - rb_erase(&handle->node, &client->handles);
> -
> - ion_buffer_remove_from_handle(buffer);
> - ion_buffer_put(buffer);
> -
> - kfree(handle);
> -}
> -
> -static void ion_handle_get(struct ion_handle *handle)
> -{
> - kref_get(&handle->ref);
> -}
> -
> -int ion_handle_put_nolock(struct ion_handle *handle)
> -{
> - return kref_put(&handle->ref, ion_handle_destroy);
> -}
> -
> -int ion_handle_put(struct ion_handle *handle)
> -{
> - struct ion_client *client = handle->client;
> - int ret;
> -
> - mutex_lock(&client->lock);
> - ret = ion_handle_put_nolock(handle);
> - mutex_unlock(&client->lock);
> -
> - return ret;
> -}
> -
> -struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client *client,
> - int id)
> -{
> - struct ion_handle *handle;
> -
> - handle = idr_find(&client->idr, id);
> - if (handle)
> - ion_handle_get(handle);
> -
> - return handle ? handle : ERR_PTR(-EINVAL);
> -}
> -
> -struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
> - int id)
> -{
> - struct ion_handle *handle;
> -
> - mutex_lock(&client->lock);
> - handle = ion_handle_get_by_id_nolock(client, id);
> - mutex_unlock(&client->lock);
> -
> - return handle;
> -}
> -
> -static bool ion_handle_validate(struct ion_client *client,
> - struct ion_handle *handle)
> -{
> - WARN_ON(!mutex_is_locked(&client->lock));
> - return idr_find(&client->idr, handle->id) == handle;
> -}
> -
> -static int ion_handle_add(struct ion_client *client, struct ion_handle *handle)
> -{
> - int id;
> - struct rb_node **p = &client->handles.rb_node;
> - struct rb_node *parent = NULL;
> - struct ion_handle *entry;
> -
> - id = idr_alloc(&client->idr, handle, 1, 0, GFP_KERNEL);
> - if (id < 0)
> - return id;
> -
> - handle->id = id;
> -
> - while (*p) {
> - parent = *p;
> - entry = rb_entry(parent, struct ion_handle, node);
> -
> - if (handle->buffer < entry->buffer)
> - p = &(*p)->rb_left;
> - else if (handle->buffer > entry->buffer)
> - p = &(*p)->rb_right;
> - else
> - WARN(1, "%s: buffer already found.", __func__);
> - }
> -
> - rb_link_node(&handle->node, parent, p);
> - rb_insert_color(&handle->node, &client->handles);
> -
> - return 0;
> -}
> -
> -struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
> - unsigned int heap_id_mask,
> - unsigned int flags)
> -{
> - struct ion_handle *handle;
> - struct ion_device *dev = client->dev;
> - struct ion_buffer *buffer = NULL;
> - struct ion_heap *heap;
> - int ret;
> -
> - pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
> - len, heap_id_mask, flags);
> - /*
> - * traverse the list of heaps available in this system in priority
> - * order. If the heap type is supported by the client, and matches the
> - * request of the caller allocate from it. Repeat until allocate has
> - * succeeded or all heaps have been tried
> - */
> - len = PAGE_ALIGN(len);
> -
> - if (!len)
> - return ERR_PTR(-EINVAL);
> -
> - down_read(&dev->lock);
> - plist_for_each_entry(heap, &dev->heaps, node) {
> - /* if the caller didn't specify this heap id */
> - if (!((1 << heap->id) & heap_id_mask))
> - continue;
> - buffer = ion_buffer_create(heap, dev, len, flags);
> - if (!IS_ERR(buffer))
> - break;
> - }
> - up_read(&dev->lock);
> -
> - if (buffer == NULL)
> - return ERR_PTR(-ENODEV);
> -
> - if (IS_ERR(buffer))
> - return ERR_CAST(buffer);
> -
> - handle = ion_handle_create(client, buffer);
> -
> - /*
> - * ion_buffer_create will create a buffer with a ref_cnt of 1,
> - * and ion_handle_create will take a second reference, drop one here
> - */
> - ion_buffer_put(buffer);
> -
> - if (IS_ERR(handle))
> - return handle;
> -
> - mutex_lock(&client->lock);
> - ret = ion_handle_add(client, handle);
> - mutex_unlock(&client->lock);
> - if (ret) {
> - ion_handle_put(handle);
> - handle = ERR_PTR(ret);
> - }
> -
> - return handle;
> -}
> -EXPORT_SYMBOL(ion_alloc);
> -
> -void ion_free_nolock(struct ion_client *client,
> - struct ion_handle *handle)
> -{
> - if (!ion_handle_validate(client, handle)) {
> - WARN(1, "%s: invalid handle passed to free.\n", __func__);
> - return;
> - }
> - ion_handle_put_nolock(handle);
> -}
> -
> -void ion_free(struct ion_client *client, struct ion_handle *handle)
> -{
> - BUG_ON(client != handle->client);
> -
> - mutex_lock(&client->lock);
> - ion_free_nolock(client, handle);
> - mutex_unlock(&client->lock);
> -}
> -EXPORT_SYMBOL(ion_free);
> -
> static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
> {
> void *vaddr;
> @@ -433,234 +182,6 @@ static void ion_buffer_kmap_put(struct ion_buffer *buffer)
> }
> }
>
> -static void ion_handle_kmap_put(struct ion_handle *handle)
> -{
> - struct ion_buffer *buffer = handle->buffer;
> -
> - if (!handle->kmap_cnt) {
> - WARN(1, "%s: Double unmap detected! bailing...\n", __func__);
> - return;
> - }
> - handle->kmap_cnt--;
> - if (!handle->kmap_cnt)
> - ion_buffer_kmap_put(buffer);
> -}
> -
> -static struct mutex debugfs_mutex;
> -static struct rb_root *ion_root_client;
> -static int is_client_alive(struct ion_client *client)
> -{
> - struct rb_node *node;
> - struct ion_client *tmp;
> - struct ion_device *dev;
> -
> - node = ion_root_client->rb_node;
> - dev = container_of(ion_root_client, struct ion_device, clients);
> -
> - down_read(&dev->lock);
> - while (node) {
> - tmp = rb_entry(node, struct ion_client, node);
> - if (client < tmp) {
> - node = node->rb_left;
> - } else if (client > tmp) {
> - node = node->rb_right;
> - } else {
> - up_read(&dev->lock);
> - return 1;
> - }
> - }
> -
> - up_read(&dev->lock);
> - return 0;
> -}
> -
> -static int ion_debug_client_show(struct seq_file *s, void *unused)
> -{
> - struct ion_client *client = s->private;
> - struct rb_node *n;
> - size_t sizes[ION_NUM_HEAP_IDS] = {0};
> - const char *names[ION_NUM_HEAP_IDS] = {NULL};
> - int i;
> -
> - mutex_lock(&debugfs_mutex);
> - if (!is_client_alive(client)) {
> - seq_printf(s, "ion_client 0x%p dead, can't dump its buffers\n",
> - client);
> - mutex_unlock(&debugfs_mutex);
> - return 0;
> - }
> -
> - mutex_lock(&client->lock);
> - for (n = rb_first(&client->handles); n; n = rb_next(n)) {
> - struct ion_handle *handle = rb_entry(n, struct ion_handle,
> - node);
> - unsigned int id = handle->buffer->heap->id;
> -
> - if (!names[id])
> - names[id] = handle->buffer->heap->name;
> - sizes[id] += handle->buffer->size;
> - }
> - mutex_unlock(&client->lock);
> - mutex_unlock(&debugfs_mutex);
> -
> - seq_printf(s, "%16.16s: %16.16s\n", "heap_name", "size_in_bytes");
> - for (i = 0; i < ION_NUM_HEAP_IDS; i++) {
> - if (!names[i])
> - continue;
> - seq_printf(s, "%16.16s: %16zu\n", names[i], sizes[i]);
> - }
> - return 0;
> -}
> -
> -static int ion_debug_client_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, ion_debug_client_show, inode->i_private);
> -}
> -
> -static const struct file_operations debug_client_fops = {
> - .open = ion_debug_client_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = single_release,
> -};
> -
> -static int ion_get_client_serial(const struct rb_root *root,
> - const unsigned char *name)
> -{
> - int serial = -1;
> - struct rb_node *node;
> -
> - for (node = rb_first(root); node; node = rb_next(node)) {
> - struct ion_client *client = rb_entry(node, struct ion_client,
> - node);
> -
> - if (strcmp(client->name, name))
> - continue;
> - serial = max(serial, client->display_serial);
> - }
> - return serial + 1;
> -}
> -
> -struct ion_client *ion_client_create(struct ion_device *dev,
> - const char *name)
> -{
> - struct ion_client *client;
> - struct task_struct *task;
> - struct rb_node **p;
> - struct rb_node *parent = NULL;
> - struct ion_client *entry;
> - pid_t pid;
> -
> - if (!name) {
> - pr_err("%s: Name cannot be null\n", __func__);
> - return ERR_PTR(-EINVAL);
> - }
> -
> - get_task_struct(current->group_leader);
> - task_lock(current->group_leader);
> - pid = task_pid_nr(current->group_leader);
> - /*
> - * don't bother to store task struct for kernel threads,
> - * they can't be killed anyway
> - */
> - if (current->group_leader->flags & PF_KTHREAD) {
> - put_task_struct(current->group_leader);
> - task = NULL;
> - } else {
> - task = current->group_leader;
> - }
> - task_unlock(current->group_leader);
> -
> - client = kzalloc(sizeof(*client), GFP_KERNEL);
> - if (!client)
> - goto err_put_task_struct;
> -
> - client->dev = dev;
> - client->handles = RB_ROOT;
> - idr_init(&client->idr);
> - mutex_init(&client->lock);
> - client->task = task;
> - client->pid = pid;
> - client->name = kstrdup(name, GFP_KERNEL);
> - if (!client->name)
> - goto err_free_client;
> -
> - down_write(&dev->lock);
> - client->display_serial = ion_get_client_serial(&dev->clients, name);
> - client->display_name = kasprintf(
> - GFP_KERNEL, "%s-%d", name, client->display_serial);
> - if (!client->display_name) {
> - up_write(&dev->lock);
> - goto err_free_client_name;
> - }
> - p = &dev->clients.rb_node;
> - while (*p) {
> - parent = *p;
> - entry = rb_entry(parent, struct ion_client, node);
> -
> - if (client < entry)
> - p = &(*p)->rb_left;
> - else if (client > entry)
> - p = &(*p)->rb_right;
> - }
> - rb_link_node(&client->node, parent, p);
> - rb_insert_color(&client->node, &dev->clients);
> -
> - client->debug_root = debugfs_create_file(client->display_name, 0664,
> - dev->clients_debug_root,
> - client, &debug_client_fops);
> - if (!client->debug_root) {
> - char buf[256], *path;
> -
> - path = dentry_path(dev->clients_debug_root, buf, 256);
> - pr_err("Failed to create client debugfs at %s/%s\n",
> - path, client->display_name);
> - }
> -
> - up_write(&dev->lock);
> -
> - return client;
> -
> -err_free_client_name:
> - kfree(client->name);
> -err_free_client:
> - kfree(client);
> -err_put_task_struct:
> - if (task)
> - put_task_struct(current->group_leader);
> - return ERR_PTR(-ENOMEM);
> -}
> -EXPORT_SYMBOL(ion_client_create);
> -
> -void ion_client_destroy(struct ion_client *client)
> -{
> - struct ion_device *dev = client->dev;
> - struct rb_node *n;
> -
> - pr_debug("%s: %d\n", __func__, __LINE__);
> - mutex_lock(&debugfs_mutex);
> - while ((n = rb_first(&client->handles))) {
> - struct ion_handle *handle = rb_entry(n, struct ion_handle,
> - node);
> - ion_handle_destroy(&handle->ref);
> - }
> -
> - idr_destroy(&client->idr);
> -
> - down_write(&dev->lock);
> - if (client->task)
> - put_task_struct(client->task);
> - rb_erase(&client->node, &dev->clients);
> - debugfs_remove_recursive(client->debug_root);
> - up_write(&dev->lock);
> -
> - kfree(client->display_name);
> - kfree(client->name);
> - kfree(client);
> - mutex_unlock(&debugfs_mutex);
> -}
> -EXPORT_SYMBOL(ion_client_destroy);
> -
> static struct sg_table *dup_sg_table(struct sg_table *table)
> {
> struct sg_table *new_table;
> @@ -802,7 +323,7 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
> {
> struct ion_buffer *buffer = dmabuf->priv;
>
> - ion_buffer_put(buffer);
> + _ion_buffer_destroy(buffer);
> }
>
> static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
> @@ -881,24 +402,44 @@ static const struct dma_buf_ops dma_buf_ops = {
> .kunmap = ion_dma_buf_kunmap,
> };
>
> -struct dma_buf *ion_share_dma_buf(struct ion_client *client,
> - struct ion_handle *handle)
> +int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
> {
> + struct ion_device *dev = internal_dev;
> + struct ion_buffer *buffer = NULL;
> + struct ion_heap *heap;
> DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> - struct ion_buffer *buffer;
> + int fd;
> struct dma_buf *dmabuf;
> - bool valid_handle;
>
> - mutex_lock(&client->lock);
> - valid_handle = ion_handle_validate(client, handle);
> - if (!valid_handle) {
> - WARN(1, "%s: invalid handle passed to share.\n", __func__);
> - mutex_unlock(&client->lock);
> - return ERR_PTR(-EINVAL);
> + pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
> + len, heap_id_mask, flags);
> + /*
> + * traverse the list of heaps available in this system in priority
> + * order. If the heap type is supported by the client, and matches the
> + * request of the caller allocate from it. Repeat until allocate has
> + * succeeded or all heaps have been tried
> + */
> + len = PAGE_ALIGN(len);
> +
> + if (!len)
> + return -EINVAL;
> +
> + down_read(&dev->lock);
> + plist_for_each_entry(heap, &dev->heaps, node) {
> + /* if the caller didn't specify this heap id */
> + if (!((1 << heap->id) & heap_id_mask))
> + continue;
> + buffer = ion_buffer_create(heap, dev, len, flags);
> + if (!IS_ERR(buffer))
> + break;
> }
> - buffer = handle->buffer;
> - ion_buffer_get(buffer);
> - mutex_unlock(&client->lock);
> + up_read(&dev->lock);
> +
> + if (buffer == NULL)
> + return -ENODEV;
> +
> + if (IS_ERR(buffer))
> + return PTR_ERR(buffer);
>
> exp_info.ops = &dma_buf_ops;
> exp_info.size = buffer->size;
> @@ -907,22 +448,9 @@ struct dma_buf *ion_share_dma_buf(struct ion_client *client,
>
> dmabuf = dma_buf_export(&exp_info);
> if (IS_ERR(dmabuf)) {
> - ion_buffer_put(buffer);
> - return dmabuf;
> - }
> -
> - return dmabuf;
> -}
> -EXPORT_SYMBOL(ion_share_dma_buf);
> -
> -int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle)
> -{
> - struct dma_buf *dmabuf;
> - int fd;
> -
> - dmabuf = ion_share_dma_buf(client, handle);
> - if (IS_ERR(dmabuf))
> + _ion_buffer_destroy(buffer);
> return PTR_ERR(dmabuf);
> + }
>
> fd = dma_buf_fd(dmabuf, O_CLOEXEC);
> if (fd < 0)
> @@ -930,11 +458,10 @@ int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle)
>
> return fd;
> }
> -EXPORT_SYMBOL(ion_share_dma_buf_fd);
>
> -int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
> +int ion_query_heaps(struct ion_heap_query *query)
> {
> - struct ion_device *dev = client->dev;
> + struct ion_device *dev = internal_dev;
> struct ion_heap_data __user *buffer = u64_to_user_ptr(query->heaps);
> int ret = -EINVAL, cnt = 0, max_cnt;
> struct ion_heap *heap;
> @@ -976,137 +503,14 @@ int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
> return ret;
> }
>
> -static int ion_release(struct inode *inode, struct file *file)
> -{
> - struct ion_client *client = file->private_data;
> -
> - pr_debug("%s: %d\n", __func__, __LINE__);
> - ion_client_destroy(client);
> - return 0;
> -}
> -
> -static int ion_open(struct inode *inode, struct file *file)
> -{
> - struct miscdevice *miscdev = file->private_data;
> - struct ion_device *dev = container_of(miscdev, struct ion_device, dev);
> - struct ion_client *client;
> - char debug_name[64];
> -
> - pr_debug("%s: %d\n", __func__, __LINE__);
> - snprintf(debug_name, 64, "%u", task_pid_nr(current->group_leader));
> - client = ion_client_create(dev, debug_name);
> - if (IS_ERR(client))
> - return PTR_ERR(client);
> - file->private_data = client;
> -
> - return 0;
> -}
> -
> static const struct file_operations ion_fops = {
> .owner = THIS_MODULE,
> - .open = ion_open,
> - .release = ion_release,
> .unlocked_ioctl = ion_ioctl,
> #ifdef CONFIG_COMPAT
> .compat_ioctl = ion_ioctl,
> #endif
> };
>
> -static size_t ion_debug_heap_total(struct ion_client *client,
> - unsigned int id)
> -{
> - size_t size = 0;
> - struct rb_node *n;
> -
> - mutex_lock(&client->lock);
> - for (n = rb_first(&client->handles); n; n = rb_next(n)) {
> - struct ion_handle *handle = rb_entry(n,
> - struct ion_handle,
> - node);
> - if (handle->buffer->heap->id == id)
> - size += handle->buffer->size;
> - }
> - mutex_unlock(&client->lock);
> - return size;
> -}
> -
> -static int ion_debug_heap_show(struct seq_file *s, void *unused)
> -{
> - struct ion_heap *heap = s->private;
> - struct ion_device *dev = heap->dev;
> - struct rb_node *n;
> - size_t total_size = 0;
> - size_t total_orphaned_size = 0;
> -
> - seq_printf(s, "%16s %16s %16s\n", "client", "pid", "size");
> - seq_puts(s, "----------------------------------------------------\n");
> -
> - mutex_lock(&debugfs_mutex);
> - for (n = rb_first(&dev->clients); n; n = rb_next(n)) {
> - struct ion_client *client = rb_entry(n, struct ion_client,
> - node);
> - size_t size = ion_debug_heap_total(client, heap->id);
> -
> - if (!size)
> - continue;
> - if (client->task) {
> - char task_comm[TASK_COMM_LEN];
> -
> - get_task_comm(task_comm, client->task);
> - seq_printf(s, "%16s %16u %16zu\n", task_comm,
> - client->pid, size);
> - } else {
> - seq_printf(s, "%16s %16u %16zu\n", client->name,
> - client->pid, size);
> - }
> - }
> - mutex_unlock(&debugfs_mutex);
> -
> - seq_puts(s, "----------------------------------------------------\n");
> - seq_puts(s, "orphaned allocations (info is from last known client):\n");
> - mutex_lock(&dev->buffer_lock);
> - for (n = rb_first(&dev->buffers); n; n = rb_next(n)) {
> - struct ion_buffer *buffer = rb_entry(n, struct ion_buffer,
> - node);
> - if (buffer->heap->id != heap->id)
> - continue;
> - total_size += buffer->size;
> - if (!buffer->handle_count) {
> - seq_printf(s, "%16s %16u %16zu %d %d\n",
> - buffer->task_comm, buffer->pid,
> - buffer->size, buffer->kmap_cnt,
> - kref_read(&buffer->ref));
> - total_orphaned_size += buffer->size;
> - }
> - }
> - mutex_unlock(&dev->buffer_lock);
> - seq_puts(s, "----------------------------------------------------\n");
> - seq_printf(s, "%16s %16zu\n", "total orphaned",
> - total_orphaned_size);
> - seq_printf(s, "%16s %16zu\n", "total ", total_size);
> - if (heap->flags & ION_HEAP_FLAG_DEFER_FREE)
> - seq_printf(s, "%16s %16zu\n", "deferred free",
> - heap->free_list_size);
> - seq_puts(s, "----------------------------------------------------\n");
> -
> - if (heap->debug_show)
> - heap->debug_show(heap, s, unused);
> -
> - return 0;
> -}
> -
> -static int ion_debug_heap_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, ion_debug_heap_show, inode->i_private);
> -}
> -
> -static const struct file_operations debug_heap_fops = {
> - .open = ion_debug_heap_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = single_release,
> -};
> -
> static int debug_shrink_set(void *data, u64 val)
> {
> struct ion_heap *heap = data;
> @@ -1169,29 +573,18 @@ void ion_device_add_heap(struct ion_heap *heap)
> */
> plist_node_init(&heap->node, -heap->id);
> plist_add(&heap->node, &dev->heaps);
> - debug_file = debugfs_create_file(heap->name, 0664,
> - dev->heaps_debug_root, heap,
> - &debug_heap_fops);
> -
> - if (!debug_file) {
> - char buf[256], *path;
> -
> - path = dentry_path(dev->heaps_debug_root, buf, 256);
> - pr_err("Failed to create heap debugfs at %s/%s\n",
> - path, heap->name);
> - }
>
> if (heap->shrinker.count_objects && heap->shrinker.scan_objects) {
> char debug_name[64];
>
> snprintf(debug_name, 64, "%s_shrink", heap->name);
> debug_file = debugfs_create_file(
> - debug_name, 0644, dev->heaps_debug_root, heap,
> + debug_name, 0644, dev->debug_root, heap,
> &debug_shrink_fops);
> if (!debug_file) {
> char buf[256], *path;
>
> - path = dentry_path(dev->heaps_debug_root, buf, 256);
> + path = dentry_path(dev->debug_root, buf, 256);
> pr_err("Failed to create heap shrinker debugfs at %s/%s\n",
> path, debug_name);
> }
> @@ -1227,24 +620,12 @@ int ion_device_create(void)
> pr_err("ion: failed to create debugfs root directory.\n");
> goto debugfs_done;
> }
> - idev->heaps_debug_root = debugfs_create_dir("heaps", idev->debug_root);
> - if (!idev->heaps_debug_root) {
> - pr_err("ion: failed to create debugfs heaps directory.\n");
> - goto debugfs_done;
> - }
> - idev->clients_debug_root = debugfs_create_dir("clients",
> - idev->debug_root);
> - if (!idev->clients_debug_root)
> - pr_err("ion: failed to create debugfs clients directory.\n");
>
> debugfs_done:
> idev->buffers = RB_ROOT;
> mutex_init(&idev->buffer_lock);
> init_rwsem(&idev->lock);
> plist_head_init(&idev->heaps);
> - idev->clients = RB_ROOT;
> - ion_root_client = &idev->clients;
> - mutex_init(&debugfs_mutex);
> internal_dev = idev;
> return 0;
> }
> diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h
> index 36a1587..ace8416 100644
> --- a/drivers/staging/android/ion/ion.h
> +++ b/drivers/staging/android/ion/ion.h
> @@ -78,7 +78,6 @@ struct ion_platform_heap {
> * handle, used for debugging
> */
> struct ion_buffer {
> - struct kref ref;
> union {
> struct rb_node node;
> struct list_head list;
> @@ -109,8 +108,6 @@ void ion_buffer_destroy(struct ion_buffer *buffer);
> * @buffers: an rb tree of all the existing buffers
> * @buffer_lock: lock protecting the tree of buffers
> * @lock: rwsem protecting the tree of heaps and clients
> - * @heaps: list of all the heaps in the system
> - * @user_clients: list of all the clients created from userspace
> */
> struct ion_device {
> struct miscdevice dev;
> @@ -118,65 +115,11 @@ struct ion_device {
> struct mutex buffer_lock;
> struct rw_semaphore lock;
> struct plist_head heaps;
> - struct rb_root clients;
> struct dentry *debug_root;
> - struct dentry *heaps_debug_root;
> - struct dentry *clients_debug_root;
> int heap_cnt;
> };
>
> /**
> - * struct ion_client - a process/hw block local address space
> - * @node: node in the tree of all clients
> - * @dev: backpointer to ion device
> - * @handles: an rb tree of all the handles in this client
> - * @idr: an idr space for allocating handle ids
> - * @lock: lock protecting the tree of handles
> - * @name: used for debugging
> - * @display_name: used for debugging (unique version of @name)
> - * @display_serial: used for debugging (to make display_name unique)
> - * @task: used for debugging
> - *
> - * A client represents a list of buffers this client may access.
> - * The mutex stored here is used to protect both handles tree
> - * as well as the handles themselves, and should be held while modifying either.
> - */
> -struct ion_client {
> - struct rb_node node;
> - struct ion_device *dev;
> - struct rb_root handles;
> - struct idr idr;
> - struct mutex lock;
> - const char *name;
> - char *display_name;
> - int display_serial;
> - struct task_struct *task;
> - pid_t pid;
> - struct dentry *debug_root;
> -};
> -
> -/**
> - * ion_handle - a client local reference to a buffer
> - * @ref: reference count
> - * @client: back pointer to the client the buffer resides in
> - * @buffer: pointer to the buffer
> - * @node: node in the client's handle rbtree
> - * @kmap_cnt: count of times this client has mapped to kernel
> - * @id: client-unique id allocated by client->idr
> - *
> - * Modifications to node, map_cnt or mapping should be protected by the
> - * lock in the client. Other fields are never changed after initialization.
> - */
> -struct ion_handle {
> - struct kref ref;
> - struct ion_client *client;
> - struct ion_buffer *buffer;
> - struct rb_node node;
> - unsigned int kmap_cnt;
> - int id;
> -};
> -
> -/**
> * struct ion_heap_ops - ops to operate on a given heap
> * @allocate: allocate memory
> * @free: free memory
> @@ -296,14 +239,10 @@ int ion_heap_map_user(struct ion_heap *heap, struct ion_buffer *buffer,
> int ion_heap_buffer_zero(struct ion_buffer *buffer);
> int ion_heap_pages_zero(struct page *page, size_t size, pgprot_t pgprot);
>
> -struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
> +int ion_alloc(size_t len,
> unsigned int heap_id_mask,
> unsigned int flags);
>
> -void ion_free(struct ion_client *client, struct ion_handle *handle);
> -
> -int ion_share_dma_buf_fd(struct ion_client *client, struct ion_handle *handle);
> -
> /**
> * ion_heap_init_shrinker
> * @heap: the heap
> @@ -431,18 +370,6 @@ int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t gfp_mask,
>
> long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
>
> -struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client *client,
> - int id);
> -
> -void ion_free_nolock(struct ion_client *client, struct ion_handle *handle);
> -
> -int ion_handle_put_nolock(struct ion_handle *handle);
> -
> -struct ion_handle *ion_handle_get_by_id(struct ion_client *client,
> - int id);
> -
> -int ion_handle_put(struct ion_handle *handle);
> -
> -int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query);
> +int ion_query_heaps(struct ion_heap_query *query);
>
> #endif /* _ION_H */
> diff --git a/drivers/staging/android/uapi/ion.h b/drivers/staging/android/uapi/ion.h
> index bba1c47..b76db1b 100644
> --- a/drivers/staging/android/uapi/ion.h
> +++ b/drivers/staging/android/uapi/ion.h
> @@ -85,31 +85,8 @@ struct ion_allocation_data {
> __u64 len;
> __u32 heap_id_mask;
> __u32 flags;
> - __u32 handle;
> - __u32 unused;
> -};
> -
> -/**
> - * struct ion_fd_data - metadata passed to/from userspace for a handle/fd pair
> - * @handle: a handle
> - * @fd: a file descriptor representing that handle
> - *
> - * For ION_IOC_SHARE or ION_IOC_MAP userspace populates the handle field with
> - * the handle returned from ion alloc, and the kernel returns the file
> - * descriptor to share or map in the fd field. For ION_IOC_IMPORT, userspace
> - * provides the file descriptor and the kernel returns the handle.
> - */
> -struct ion_fd_data {
> - __u32 handle;
> __u32 fd;
> -};
> -
> -/**
> - * struct ion_handle_data - a handle passed to/from the kernel
> - * @handle: a handle
> - */
> -struct ion_handle_data {
> - __u32 handle;
> + __u32 unused;
> };
>
> #define MAX_HEAP_NAME 32
> --
> 2.7.4
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] arm64: dts: r8a7795: salvator-x: Add current sense amplifiers
From: Geert Uytterhoeven @ 2017-04-19 8:35 UTC (permalink / raw)
To: linux-arm-kernel
Add device nodes for two Maxim max961x current sense amplifiers
sensing the VDD_0.8V and DVFS_0.8V lines.
Based on a patch for r8a7796-salvator-x.dts by Jacopo Mondi.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Bindings and driver are now in staging-next.
v2:
- Use shunt-resistor-micro-ohms to match updated bindings.
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index ff68bac4cd7ed2f5..bd6cccb0d4a75561 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -415,6 +415,24 @@
};
};
+&i2c4 {
+ status = "okay";
+
+ csa_vdd: adc at 7c {
+ compatible = "maxim,max9611";
+ reg = <0x7c>;
+
+ shunt-resistor-micro-ohms = <5000>;
+ };
+
+ csa_dvfs: adc at 7f {
+ compatible = "maxim,max9611";
+ reg = <0x7f>;
+
+ shunt-resistor-micro-ohms = <5000>;
+ };
+};
+
&rcar_sound {
pinctrl-0 = <&sound_pins &sound_clk_pins>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [Linaro-mm-sig] [PATCHv4 12/12] staging/android: Update Ion TODO list
From: Daniel Vetter @ 2017-04-19 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492540034-5466-13-git-send-email-labbott@redhat.com>
On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> Most of the items have been taken care of by a clean up series. Remove
> the completed items and add a few new ones.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> drivers/staging/android/TODO | 21 ++++-----------------
> 1 file changed, 4 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
> index 8f3ac37..5f14247 100644
> --- a/drivers/staging/android/TODO
> +++ b/drivers/staging/android/TODO
> @@ -7,23 +7,10 @@ TODO:
>
>
> ion/
> - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel internal
> - interface on top of dma-buf. flush_for_device needs to be added to dma-buf
> - first.
> - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some
> - vendor trees. Should be replaced with an ioctl on the dma-buf to expose the
> - begin/end_cpu_access hooks to userspace.
> - - Clarify the tricks ion plays with explicitly managing coherency behind the
> - dma api's back (this is absolutely needed for high-perf gpu drivers): Add an
> - explicit coherency management mode to flush_for_device to be used by drivers
> - which want to manage caches themselves and which indicates whether cpu caches
> - need flushing.
> - - With those removed there's probably no use for ION_IOC_IMPORT anymore either
> - since ion would just be the central allocator for shared buffers.
> - - Add dt-binding to expose cma regions as ion heaps, with the rule that any
> - such cma regions must already be used by some device for dma. I.e. ion only
> - exposes existing cma regions and doesn't reserve unecessarily memory when
> - booting a system which doesn't use ion.
> + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
> + involve putting appropriate bindings in a memory node for Ion to find.
> + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
> + - Better test framework (integration with VGEM was suggested)
Found another one: Integrate the ion kernel-doc into
Documenation/gpu/ion.rst and link it up within Documenation/gpu/index.rst.
There's a lot of api and overview stuff already around, would be great to
make this more accessible.
But I wouldn't put this as a de-staging blocker, just an idea.
On the series: Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No full review since a bunch of stuff I'm not too familiar with, but I
like where this is going.
-Daniel
>
> Please send patches to Greg Kroah-Hartman <greg@kroah.com> and Cc:
> Arve Hj?nnev?g <arve@android.com> and Riley Andrews <riandrews@android.com>
> --
> 2.7.4
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2] arm64: dts: r8a7795: salvator-x: Add current sense amplifiers
From: Geert Uytterhoeven @ 2017-04-19 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492590950-10534-1-git-send-email-geert+renesas@glider.be>
Add device nodes for two Maxim max961x current sense amplifiers
sensing the VDD_0.8V and DVFS_0.8V lines.
Based on a patch for r8a7796-salvator-x.dts by Jacopo Mondi.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Bindings and driver are now in staging-next.
v2:
- Use shunt-resistor-micro-ohms to match updated bindings.
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index ff68bac4cd7ed2f5..bd6cccb0d4a75561 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -415,6 +415,24 @@
};
};
+&i2c4 {
+ status = "okay";
+
+ csa_vdd: adc at 7c {
+ compatible = "maxim,max9611";
+ reg = <0x7c>;
+
+ shunt-resistor-micro-ohms = <5000>;
+ };
+
+ csa_dvfs: adc at 7f {
+ compatible = "maxim,max9611";
+ reg = <0x7f>;
+
+ shunt-resistor-micro-ohms = <5000>;
+ };
+};
+
&rcar_sound {
pinctrl-0 = <&sound_pins &sound_clk_pins>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH v2] ARM: dts: at91: sama5d2: add m_can nodes
From: Wenyou Yang @ 2017-04-19 8:46 UTC (permalink / raw)
To: linux-arm-kernel
Add nodes to support the Controller Area Network(M_CAN) on SAMA5D2.
The version of M_CAN IP core is 3.1.0 (CREL = 0x31040730).
As said in SAMA5D2 datasheet, the CAN clock is recommended to use
frequencies of 20, 40 or 80 MHz. To achieve these frequencies,
PMC GCLK3 must select the UPLLCK(480 MHz) as source clock and
divide by 24, 12, or 6. So, the "assigned-clock-rates" property
has three options: 20000000, 40000000, and 80000000.
The "assigned-clock-parents" property should be referred to utmi
fixedly.
The MSBs [bits 31:16] of the CAN Message RAM for CAN0 and CAN1 are
default configured in 0x00200000. To avoid conflict with SRAM map
for PM, change them to 0x00210000 in the AT91Bootstrap via setting
the CAN Memories Address-based Register(SFR_CAN) of SFR.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
The patch is tested on SAMA5D2 Xplained and based on the patch set,
1. [PATCH v4 1/7] can: m_can: Disabled Interrupt Line 1
http://marc.info/?l=linux-can&m=149165343604033&w=2
Changes in v2:
- Configures 10 TX Event FIFO elements and 10 TX Buffers/FIFO slots,
because the TXE FIFO is needed to be configured.
- Configure the offset of Message RAM for CAN1 followed from CAN0's.
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 24 +++++++++++++
arch/arm/boot/dts/sama5d2.dtsi | 56 +++++++++++++++++++++++++++++
2 files changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 9f7f8a7d8ff9..2f19b08dc226 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -257,6 +257,12 @@
status = "okay";
};
+ can0: can at f8054000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can0_default>;
+ status = "okay";
+ };
+
uart3: serial at fc008000 {
atmel,use-dma-rx;
atmel,use-dma-tx;
@@ -321,6 +327,18 @@
bias-disable;
};
+ pinctrl_can0_default: can0_default {
+ pinmux = <PIN_PC10__CANTX0>,
+ <PIN_PC11__CANRX0>;
+ bias-disable;
+ };
+
+ pinctrl_can1_default: can1_default {
+ pinmux = <PIN_PC26__CANTX1>,
+ <PIN_PC27__CANRX1>;
+ bias-disable;
+ };
+
pinctrl_charger_chglev: charger_chglev {
pinmux = <PIN_PA12__GPIO>;
bias-disable;
@@ -468,6 +486,12 @@
};
};
+
+ can1: can at fc050000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1_default>;
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 22332be72140..383ca9307edf 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -762,6 +762,18 @@
atmel,clk-output-range = <0 83000000>;
};
+ can0_clk: can0_clk {
+ #clock-cells = <0>;
+ reg = <56>;
+ atmel,clk-output-range = <0 83000000>;
+ };
+
+ can1_clk: can1_clk {
+ #clock-cells = <0>;
+ reg = <57>;
+ atmel,clk-output-range = <0 83000000>;
+ };
+
classd_clk: classd_clk {
#clock-cells = <0>;
reg = <59>;
@@ -890,6 +902,18 @@
#clock-cells = <0>;
reg = <55>;
};
+
+ can0_gclk: can0_gclk {
+ #clock-cells = <0>;
+ reg = <56>;
+ atmel,clk-output-range = <0 80000000>;
+ };
+
+ can1_gclk: can1_gclk {
+ #clock-cells = <0>;
+ reg = <57>;
+ atmel,clk-output-range = <0 80000000>;
+ };
};
};
@@ -1144,6 +1168,22 @@
clocks = <&clk32k>;
};
+ can0: can at f8054000 {
+ compatible = "bosch,m_can";
+ reg = <0xf8054000 0x4000>, <0x210000 0x4000>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <56 IRQ_TYPE_LEVEL_HIGH 7>,
+ <64 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupt-names = "int0", "int1";
+ clocks = <&can0_clk>, <&can0_gclk>;
+ clock-names = "hclk", "cclk";
+ assigned-clocks = <&can0_gclk>;
+ assigned-clock-parents = <&utmi>;
+ assigned-clock-rates = <40000000>;
+ bosch,mram-cfg = <0x0 0 0 32 0 0 10 10>;
+ status = "disabled";
+ };
+
spi1: spi at fc000000 {
compatible = "atmel,at91rm9200-spi";
reg = <0xfc000000 0x100>;
@@ -1305,6 +1345,22 @@
status = "okay";
};
+ can1: can at fc050000 {
+ compatible = "bosch,m_can";
+ reg = <0xfc050000 0x4000>, <0x210000 0x4000>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <57 IRQ_TYPE_LEVEL_HIGH 7>,
+ <65 IRQ_TYPE_LEVEL_HIGH 7>;
+ interrupt-names = "int0", "int1";
+ clocks = <&can1_clk>, <&can1_gclk>;
+ clock-names = "hclk", "cclk";
+ assigned-clocks = <&can1_gclk>;
+ assigned-clock-parents = <&utmi>;
+ assigned-clock-rates = <40000000>;
+ bosch,mram-cfg = <0x1100 0 0 32 0 0 10 10>;
+ status = "disabled";
+ };
+
chipid at fc069000 {
compatible = "atmel,sama5d2-chipid";
reg = <0xfc069000 0x8>;
--
2.11.0
^ permalink raw reply related
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Johan Hovold @ 2017-04-19 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <186569458.91967.1492547106553@email.1und1.de>
On Tue, Apr 18, 2017 at 10:25:06PM +0200, Stefan Wahren wrote:
> Hi,
>
> [add Johan]
>
> > Stefan Wahren <stefan.wahren@i2se.com> hat am 18. April 2017 um 10:07 geschrieben:
> >
> >
> > Am 18.04.2017 um 00:37 schrieb Doug Anderson:
> > > Hi,
> > >
> > > On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> > >> Hi,
> > >>
> > >>> Stefan Wahren <stefan.wahren@i2se.com> hat am 31. Oktober 2016 um 21:34 geschrieben:
> > >>>
> > >>>
> > >>> I inspired by this issue [1] i build up a slightly modified
> > >>> setup with a Raspberry Pi B (mainline kernel 4.9rc3), a powered
> > >>> 7 port USB hub and 5 Prolific PL2303 USB to serial convertors. I
> > >>> modified the usb_test for dwc2 [2], which only tries to open all
> > >>> ttyUSB devices one after the other.
> > >>>
> > >>> Unfortunately the complete system stuck after opening the first
> > >>> ttyUSB device ( heartbeat LED stop blinking, no reaction to
> > >>> debug UART). The only way to reanimate the system is to
> > >>> powerdown the USB hub with the USB to serial convertors.
> > >>>
> > >>> [1] - https://github.com/raspberrypi/linux/issues/1692
> i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure
> _dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).
>
> So i made my observations for 3 test cases:
>
> 1) no serial converter connected (idle)
> 2) 1 FTDI serial converter connected
> 3) 1 PL2303 serial converter connected
>
> case | ksoftirq cpu | mean duration | max duration | max duration | urb_enqueue |
> | | hcd_irq | hcd_irq | urb_enqueue | within 10 sec|
> -------+------------------+---------------+---------------+--------------+--------------+
> idle | 0.0% | 2 us | 16.5 us | 12 us | 5 |
> FTDI | 25.0% | 8.5 us | 18.0 us | 31000 us | ~ 400 |
> PL2303 | top doesn't work | 8.5 us | 22.5 us | 900000 us | 4 |
>
> So it seems the serial USB driver has also an impact. In the analyzer
> trace the FTDI triggers many smaller urb_enqueue calls in the opposite
> to the PL2303 which only has few but huge calls.
What do you mean by "huge calls" above?
Are you just keeping the ports open (i.e. with no data being received or
sent)?
FTDI devices are notorious for their status messages being sent
continuously while the port is open. You'll get a two-byte bulk-in
message every 16ms by default (these were sent every millisecond up
until recently due to a long-standing regression).
PL2303 devices have an interrupt-in endpoint which is used for status
notifications so you would not see any completion callbacks on an
otherwise idle port.
> Additional notes:
> After closing the serial connection to the FTDI the system is usable
> as before. In case of PL2303 i need to disconnect the converter in
> order to get a usable system.
Does your system lock up when you open the first pl2303 device?
> Why do they behave so differently?
So the ftdi bulk-in status messages and the pl2303 interrupt-in endpoint
could be two reasons, but I guess so could any change in timing etc.
Is your ftdi-device a Full Speed device like the pl2303?
Johan
^ permalink raw reply
* [PATCH v3 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Heiko Stuebner @ 2017-04-19 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f6f127efb44fb1012f18c483fa522918f8f82d7c.1492588180.git.guillaume.tucker@collabora.com>
Am Mittwoch, 19. April 2017, 09:06:18 CEST schrieb Guillaume Tucker:
> Add Mali GPU device tree node for the rk3288 SoC, with devfreq
> opp table.
>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> ---
> arch/arm/boot/dts/rk3288.dtsi | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index df8a0dbe9d91..187eed528f83 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -43,6 +43,7 @@
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/clock/rk3288-cru.h>
> +#include <dt-bindings/power/rk3288-power.h>
> #include <dt-bindings/thermal/thermal.h>
> #include <dt-bindings/power/rk3288-power.h>
> #include <dt-bindings/soc/rockchip,boot-mode.h>
> @@ -227,6 +228,27 @@
> ports = <&vopl_out>, <&vopb_out>;
> };
>
> + gpu: mali at ffa30000 {
please sort nodes by address. ffa30000 should be placed below hdmi at ff980000
and above qos at ffaa0000 .
> + compatible = "arm,mali-t760", "arm,mali-midgard";
As indicated before I don't trust that a generic binding will work for
everything, so I would feel safer if we had a "rockchip,rk3288-mali" in
front for future purposes, making it a
compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
> + reg = <0xffa30000 0x10000>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&cru ACLK_GPU>;
> + operating-points = <
> + /* KHz uV */
> + 100000 950000
> + 200000 950000
> + 300000 1000000
> + 400000 1100000
> + 500000 1200000
> + 600000 1250000
> + >;
Wasn't there a wish for opp-v2 in a previous version?
Thanks
Heiko
> + power-domains = <&power RK3288_PD_GPU>;
> + status = "disabled";
> + };
> +
> sdmmc: dwmmc at ff0c0000 {
> compatible = "rockchip,rk3288-dw-mshc";
> max-frequency = <150000000>;
>
^ permalink raw reply
* [PATCH v3 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Heiko Stuebner @ 2017-04-19 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <96021d989387d9aaff039efebd66aa3bfe667941.1492588180.git.guillaume.tucker@collabora.com>
Am Mittwoch, 19. April 2017, 09:06:17 CEST schrieb Guillaume Tucker:
> The ARM Mali Midgard GPU family is present in a number of SoCs
> from many different vendors such as Samsung Exynos and Rockchip.
>
> Import the device tree bindings documentation from the r16p0
> release of the Mali Midgard GPU kernel driver:
>
> https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
>
> The "compatible" property strings have been redesigned to explicitly
> list all the Mali Midgard GPU types and include optional vendor ones.
>
> The "clock-names" property has been dropped as only one clock is used
> by the Mali Midgard driver which now needs to call clk_get with NULL.
>
> The "interrupt-names" property values have been converted to
> lower-case: "job", "mmu" and "gpu".
>
> The following optional bindings have been omitted in this initial
> version as they are only used in very specific cases:
>
> * snoop_enable_smc
> * snoop_disable_smc
> * jm_config
> * power_model
> * system-coherency
> * ipa-model
>
> The example has been simplified accordingly.
>
> The copyright and GPL licence header has been removed as deemed not
> necessary.
>
> CC: John Reitan <john.reitan@arm.com>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
> ---
> .../devicetree/bindings/gpu/arm,mali-midgard.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> new file mode 100644
> index 000000000000..917c4f8d178f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -0,0 +1,57 @@
> +ARM Mali Midgard GPU
> +====================
> +
> +Required properties:
> +
> +- compatible :
> + * Must be one of the following:
> + + "arm,mali-t60x"
> + + "arm,mali-t62x"
> + + "arm,mali-t720"
> + + "arm,mali-t760"
> + + "arm,mali-t820"
> + + "arm,mali-t830"
> + + "arm,mali-t860"
> + + "arm,mali-t880"
> + * And, optionally, one of the vendor specific compatible:
> + + "amlogic,meson-gxm-mali"
Please add a "rockchip,rk3288-mali" as well :-) , as I don't trust that the
generic compatible will be enough for all time and having that already
defined makes fixing the per soc things later a lot easier.
Thanks
Heiko
> +
> +- reg : Physical base address of the device and length of the register area.
> +
> +- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
> +
> +- interrupt-names : Contains the names of IRQ resources in the order they were
> + provided in the interrupts property. Must contain: "job", "mmu", "gpu".
> +
> +
> +Optional properties:
> +
> +- clocks : Phandle to clock for the Mali Midgard device.
> +
> +- mali-supply : Phandle to regulator for the Mali device. Refer to
> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
> +
> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
> + for details.
> +
> +
> +Example for a Mali-T602:
> +
> +gpu at fc010000 {
> + compatible = "arm,mali-t60x", "arm,mali-midgard";
> + reg = <0xfc010000 0x4000>;
> + interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
> + interrupt-names = "job", "mmu", "gpu";
> + clocks = <&pclk_mali>;
> + mali-supply = <&vdd_mali>;
> + operating-points = <
> + /* KHz uV */
> + 533000 1250000,
> + 450000 1150000,
> + 400000 1125000,
> + 350000 1075000,
> + 266000 1025000,
> + 160000 925000,
> + 100000 912500,
> + >;
> +};
>
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Stefan Wahren @ 2017-04-19 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419085620.GE2823@localhost>
Am 19.04.2017 um 10:56 schrieb Johan Hovold:
> On Tue, Apr 18, 2017 at 10:25:06PM +0200, Stefan Wahren wrote:
>> Hi,
>>
>> [add Johan]
>>
>>> Stefan Wahren <stefan.wahren@i2se.com> hat am 18. April 2017 um 10:07 geschrieben:
>>>
>>>
>>> Am 18.04.2017 um 00:37 schrieb Doug Anderson:
>>>> Hi,
>>>>
>>>> On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>>>>> Hi,
>>>>>
>>>>>> Stefan Wahren <stefan.wahren@i2se.com> hat am 31. Oktober 2016 um 21:34 geschrieben:
>>>>>>
>>>>>>
>>>>>> I inspired by this issue [1] i build up a slightly modified
>>>>>> setup with a Raspberry Pi B (mainline kernel 4.9rc3), a powered
>>>>>> 7 port USB hub and 5 Prolific PL2303 USB to serial convertors. I
>>>>>> modified the usb_test for dwc2 [2], which only tries to open all
>>>>>> ttyUSB devices one after the other.
>>>>>>
>>>>>> Unfortunately the complete system stuck after opening the first
>>>>>> ttyUSB device ( heartbeat LED stop blinking, no reaction to
>>>>>> debug UART). The only way to reanimate the system is to
>>>>>> powerdown the USB hub with the USB to serial convertors.
>>>>>>
>>>>>> [1] - https://github.com/raspberrypi/linux/issues/1692
>> i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure
>> _dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).
>>
>> So i made my observations for 3 test cases:
>>
>> 1) no serial converter connected (idle)
>> 2) 1 FTDI serial converter connected
>> 3) 1 PL2303 serial converter connected
>>
>> case | ksoftirq cpu | mean duration | max duration | max duration | urb_enqueue |
>> | | hcd_irq | hcd_irq | urb_enqueue | within 10 sec|
>> -------+------------------+---------------+---------------+--------------+--------------+
>> idle | 0.0% | 2 us | 16.5 us | 12 us | 5 |
>> FTDI | 25.0% | 8.5 us | 18.0 us | 31000 us | ~ 400 |
>> PL2303 | top doesn't work | 8.5 us | 22.5 us | 900000 us | 4 |
>>
>> So it seems the serial USB driver has also an impact. In the analyzer
>> trace the FTDI triggers many smaller urb_enqueue calls in the opposite
>> to the PL2303 which only has few but huge calls.
> What do you mean by "huge calls" above?
The time it takes until _dwc2_hcd_urb_enqueue is finished.
>
> Are you just keeping the ports open (i.e. with no data being received or
> sent)?
Yes, only open and no data is received or sent (LEDs doesn't show any
activity).
>
> FTDI devices are notorious for their status messages being sent
> continuously while the port is open. You'll get a two-byte bulk-in
> message every 16ms by default (these were sent every millisecond up
> until recently due to a long-standing regression).
>
> PL2303 devices have an interrupt-in endpoint which is used for status
> notifications so you would not see any completion callbacks on an
> otherwise idle port.
>
>> Additional notes:
>> After closing the serial connection to the FTDI the system is usable
>> as before. In case of PL2303 i need to disconnect the converter in
>> order to get a usable system.
> Does your system lock up when you open the first pl2303 device?
Yes (directly to the onboard hub or an external hub make no difference).
>
>> Why do they behave so differently?
> So the ftdi bulk-in status messages and the pl2303 interrupt-in endpoint
> could be two reasons, but I guess so could any change in timing etc.
>
> Is your ftdi-device a Full Speed device like the pl2303?
Sorry, i will need to verify.
Thanks
Stefan
>
> Johan
^ permalink raw reply
* [PATCH v2 0/4] ARM: imx: Set LDO regulator supply
From: Leonard Crestez @ 2017-04-19 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1491324640.git.leonard.crestez@nxp.com>
On Tue, 2017-04-04 at 20:04 +0300, Leonard Crestez wrote:
> Setting the LDO regulator parent is optional but beneficial. It will cause
> the PMIC output voltage to be dynamically set to the minimum input for the
> LDOs, this should be more efficient.
>
> This propagation was introduced by:
> commit fc42112c0eaa ("regulator: core: Propagate voltage changes to supply
> regulators")
>
> Changes since v1:
> * Drop patch 1 since it only avoids logging a warning and the gpc driver
> is going through more changes.
> * Initialize cpufreq->suspend_freq based on policy->max instead.
> * Remove reference to ldo-bypass from suspend_freq patch message.
Hello,
This is a gentle reminder that this was sent ~2 weeks ago and patches 1
and 2 are still waiting (with no objections). Patches 3/4 were applied.
--
Regards,
Leonard
^ permalink raw reply
* [PATCH 1/2] arm64: Fix power-of-ten vs. power-of-two prefixes in user-visible messages
From: Geert Uytterhoeven @ 2017-04-19 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492085867.20068.4.camel@infradead.org>
Hi David,
On Thu, Apr 13, 2017 at 2:17 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> The IEC binary prefixes (Ki, Mi, Gi, etc.) were published over twenty
> years ago. We should use them consistently, especially in user-visible
> messages.
>
> Sure, it doesn't often matter, just as *most* typos and spelling or
> grammar mistakes don't often matter. But sometimes, such misuse really
> do actually introduce ambiguity, and we should avoid that.
>
> Conversely, there is absolutely no good reason *not* to be using the
> binary prefixes. Some people once claimed to find them "ugly", or that
> they would cause confusion. But those are purely down to unfamiliarity.
>
> The perceived ugliness, and the alleged confusion, will pass with use.
>
> The correctness, and the lack of ambiguity, will not.
>
> ARM64 in particular, as a new platform, has no excuse for not using the
> IEC prefixes which predate its existence by a decade and a half.
>
> What's worse is that some people are pointing at the existing errors and
> actually claiming that they want their *new* code to be deliberately
> wrong in order to be "consistent" with what's there.
>
> So let's fix the user-visible messages in all of arch/arm64 and nip
> *that* particular stupidity in the bud...
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
For correctness:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
For the policy:
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
You're gonna need a new sweep for soon to be added occurrences, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340)
From: Mark Rutland @ 2017-04-19 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492535481.28092.14.camel@v3.sk>
On Tue, Apr 18, 2017 at 07:11:21PM +0200, Lubomir Rintel wrote:
> On Tue, 2017-04-18 at 14:03 +0100, Mark Rutland wrote:
> > On Tue, Apr 18, 2017 at 12:44:28PM +0200, Lubomir Rintel wrote:
> > > I'm getting a crash that looks awfully lot like what ddc37832a1 [ARM:
> > > 8634/1: hw_breakpoint: blacklist Scorpion CPUs] aims to fix.
> >
> > Just to check, have you successfully booted a kernel on this board
> > before? i.e. is this a new crash?
>
> I've now checked, and it doesn't seem like it ever worked when
> PERF_EVENTS (and in turn HAVE_HW_BREAKPOINT) is enabled. The crash look
> the same up to 4.7; the previous versions also crash as soon as I
> enable the options but for some reason I don't get an oops on the
> console even with earlyprintk enabled (the machine reboots with panic=
> argument, so there's just possibly just something wrong with the
> console).
Ok. So this isn't a recent regression.
> > > My hardware doesn't use a Scorpion CPU though -- it uses a Cortex-A9
> > > (cpuid=0x412fc091).
> > >
> > > [????0.157000] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> > > [????0.157000] Modules linked in:
> > > [????0.157000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-0.rc3.git0.2.spear2.fc26.armv7hl #1
> > > [????0.157000] Hardware name: ST SPEAr1340 SoC with Flattened Device Tree
> > > [????0.157000] task: ef102b80 task.stack: ef0fa000
> > > [????0.157000] PC is at arch_hw_breakpoint_init+0x130/0x2a0
> > > [????0.157000] LR is at arch_hw_breakpoint_init+0x7c/0x2a0
> > > [????0.157000] pc : [<c0e0538c>]????lr : [<c0e052d8>]????psr: 60000013
> >
> > It would be helpful to know which specific access that is.
> >
> > Can you figure that out with addr2line, e.g.
> >
> > ?$ addr2line -ife vmlinux c0e0538c
>
> Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc7 #21
> Hardware name: ST SPEAr1340 SoC with Flattened Device Tree
> task: ef058000 task.stack: ef04c000
> PC is at arch_hw_breakpoint_init+0x9c/0x2a4
> LR is at arch_hw_breakpoint_init+0x84/0x2a4
> pc : [<c0905504>]????lr : [<c09054ec>]????psr: 60000013
>
> $ addr2line -ife vmlinux c0905504
> core_has_os_save_restore
> /home/lkundrak/spear/linux/arch/arm/kernel/hw_breakpoint.c:920
That's a read of DBGOSLSR, which shouldn't UNDEF.
I suspect this is a result of Cortex-A9 erratum 764319, which causes
DBGOSLSR to unexpectedly behave as UNDEF when the external DBGSWENABLE
pin is wired to 0.
The official workaround is to ensure that the DBGSWENABLE pin is wired
to 1.
It might be possible to handle the trap and bail out, but it's not clear
to me if we can safely assume that other functionality is available.
Thanks,
Mark.
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Johan Hovold @ 2017-04-19 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13d18e41-b430-37ea-afb8-d300326bfb12@i2se.com>
On Wed, Apr 19, 2017 at 11:12:17AM +0200, Stefan Wahren wrote:
> Am 19.04.2017 um 10:56 schrieb Johan Hovold:
> > On Tue, Apr 18, 2017 at 10:25:06PM +0200, Stefan Wahren wrote:
> >> Hi,
> >>
> >> [add Johan]
> >>
> >>> Stefan Wahren <stefan.wahren@i2se.com> hat am 18. April 2017 um 10:07 geschrieben:
> >>>
> >>>
> >>> Am 18.04.2017 um 00:37 schrieb Doug Anderson:
> >>>> Hi,
> >>>>
> >>>> On Mon, Apr 17, 2017 at 4:05 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> >>>>> Hi,
> >>>>>
> >>>>>> Stefan Wahren <stefan.wahren@i2se.com> hat am 31. Oktober 2016 um 21:34 geschrieben:
> >>>>>>
> >>>>>>
> >>>>>> I inspired by this issue [1] i build up a slightly modified
> >>>>>> setup with a Raspberry Pi B (mainline kernel 4.9rc3), a powered
> >>>>>> 7 port USB hub and 5 Prolific PL2303 USB to serial convertors. I
> >>>>>> modified the usb_test for dwc2 [2], which only tries to open all
> >>>>>> ttyUSB devices one after the other.
> >>>>>>
> >>>>>> Unfortunately the complete system stuck after opening the first
> >>>>>> ttyUSB device ( heartbeat LED stop blinking, no reaction to
> >>>>>> debug UART). The only way to reanimate the system is to
> >>>>>> powerdown the USB hub with the USB to serial convertors.
> >>>>>>
> >>>>>> [1] - https://github.com/raspberrypi/linux/issues/1692
> >> i took GPIO17 to measure _dwc2_hcd_irq and GPIO18 to measure
> >> _dwc2_hcd_urb_enqueue (patch against 4.11rc1 below).
> >>
> >> So i made my observations for 3 test cases:
> >>
> >> 1) no serial converter connected (idle)
> >> 2) 1 FTDI serial converter connected
> >> 3) 1 PL2303 serial converter connected
> >>
> >> case | ksoftirq cpu | mean duration | max duration | max duration | urb_enqueue |
> >> | | hcd_irq | hcd_irq | urb_enqueue | within 10 sec|
> >> -------+------------------+---------------+---------------+--------------+--------------+
> >> idle | 0.0% | 2 us | 16.5 us | 12 us | 5 |
> >> FTDI | 25.0% | 8.5 us | 18.0 us | 31000 us | ~ 400 |
> >> PL2303 | top doesn't work | 8.5 us | 22.5 us | 900000 us | 4 |
> >>
> >> So it seems the serial USB driver has also an impact. In the analyzer
> >> trace the FTDI triggers many smaller urb_enqueue calls in the opposite
> >> to the PL2303 which only has few but huge calls.
> > What do you mean by "huge calls" above?
>
> The time it takes until _dwc2_hcd_urb_enqueue is finished.
Yes, sorry, I realised that after I sent my reply.
> > Are you just keeping the ports open (i.e. with no data being received or
> > sent)?
>
> Yes, only open and no data is received or sent (LEDs doesn't show any
> activity).
>
> > FTDI devices are notorious for their status messages being sent
> > continuously while the port is open. You'll get a two-byte bulk-in
> > message every 16ms by default (these were sent every millisecond up
> > until recently due to a long-standing regression).
> >
> > PL2303 devices have an interrupt-in endpoint which is used for status
> > notifications so you would not see any completion callbacks on an
> > otherwise idle port.
> >
> >> Additional notes:
> >> After closing the serial connection to the FTDI the system is usable
> >> as before. In case of PL2303 i need to disconnect the converter in
> >> order to get a usable system.
> > Does your system lock up when you open the first pl2303 device?
>
> Yes (directly to the onboard hub or an external hub make no difference).
Ok, good. I suggest not using the external hub until you've tracked this
down.
> >> Why do they behave so differently?
> > So the ftdi bulk-in status messages and the pl2303 interrupt-in endpoint
> > could be two reasons, but I guess so could any change in timing etc.
> >
> > Is your ftdi-device a Full Speed device like the pl2303?
>
> Sorry, i will need to verify.
Can you reproduce this on 4.11-rc7 without the external hub and post the
corresponding soft lockup bug output?
On open, the pl2303 driver first enqueues the interrupt-in URB before
enqueueing two bulk-in URBs. From your original stack trace it looks
like the lockup happens when queueing either of those. Perhaps you can
enable debugging in the dwc2 driver or add some printks to determine how
far you get.
Another thing to try is to comment out the interrupt-in URB submission
in pl2303 and see whether that avoids triggering the lockup.
Johan
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: reuse firefly dtsi
From: Heiko Stuebner @ 2017-04-19 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJrj+DPjNnk9n5k4DoxJ0Focm0DOz6362PYtVRZTEkaUFKYX0g@mail.gmail.com>
Hi Eddie,
Am Mittwoch, 19. April 2017, 08:42:09 CEST schrieb Eddie Cai:
> 2017-04-19 6:20 GMT+08:00 Heiko Stuebner <heiko@sntech.de>:
> > Hi Eddie,
> >
> > Am Dienstag, 18. April 2017, 20:15:27 CEST schrieb Eddie Cai:
> >> firefly reload is very similar with firefly board, so reuse firefly dtsi
> >>
> >> Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
> >> ---
> >> arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 310 ------------------
> >> arch/arm/boot/dts/rk3288-firefly-reload.dts | 368 ++--------------------
> >
> > I would disagree and remember having a similar discussion when the reload-
> > support was initially submitted. Please keep in mind that the firefly-
> > reload is a som+baseboard combination, so somebody could (or maybe
> > already has) create a completely different baseboard for the som that
> > does not have any similarities with the original firefly.
> > The previous firefly being a real single board.
> >
> > We also don't combine rock2 and firefly and other boards following the
> > general rk3288 design guidelines :-) and the original firefly and reload are
> > very different boards if you look at them.
> OK, i think the real similar part is the core board and firefly. how
> about reuse the
> firefly code in the core board?
I'd really like to keep these separate.
- firefly-rk3288 is one board
- firefly-rk3288-reload is a completely different som+baseboard
That they both have the "firefly" in the name is really more based on the
company being named firefly :-) , but are not an indication that they
are similar boards.
Heiko
^ permalink raw reply
* [PATCH v3 7/7] ARM: dma-mapping: Remove traces of NOMMU code
From: Arnd Bergmann @ 2017-04-19 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1489137839-549-8-git-send-email-vladimir.murzin@arm.com>
On Fri, Mar 10, 2017 at 10:23 AM, Vladimir Murzin
<vladimir.murzin@arm.com> wrote:
> DMA operations for NOMMU case have been just factored out into
> separate compilation unit, so don't keep dead code.
>
> Tested-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Tested-by: Andras Szemzo <sza@esh.hu>
> Tested-by: Alexandre TORGUE <alexandre.torgue@st.com>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
The patch is "obviously correct" after the previous changes,
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* LDM/STM alignment fixups on arm64
From: Russell King - ARM Linux @ 2017-04-19 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58F704D6.6000301@codeaurora.org>
On Wed, Apr 19, 2017 at 12:03:58PM +0530, Srinivas Ramana wrote:
> Hi,
>
> While understanding how the alignment are handled on arm and arm64, we came
> across the fixups for LDM/LDRD/STM on arm where as these fixups are not
> present on arm64.
>
> There may be some specific reason why these fixups are not ported to arm64.
> Can you please help us understand this?
>
> With this difference in how kernel handles 32-bit apps on arm and arm64,
> there can be apps which are working without abort on arm, but fail on arm64
> (SIGBUS). We have tried to get some history on web, but not successful.
>
> If this is indeed missing on arm64, do you see any issue if its ported (does
> it fail any guidance)?
Do you have an application that fails because of this? Your email makes
it sound very theoretical.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox