* [PATCH v2 5/8] iio: stm32-adc: pass iio device as arg for the interrupt handler
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
This changes the argument for the interrupt handler to be the IIO device
instead of the state-struct.
Since there will be some changes to how iio_priv_to_dev() is implemented,
it could be that the helper becomes a bit slower, as it will be hidden away
in the IIO core.
The iio_priv() call will still be fast enough, as it will return a void
pointer from the public IIO device structure. So it's better to switch the
order.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/adc/stm32-adc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
index 80c3f963527b..34885387fbdb 100644
--- a/drivers/iio/adc/stm32-adc.c
+++ b/drivers/iio/adc/stm32-adc.c
@@ -1227,8 +1227,8 @@ static int stm32_adc_read_raw(struct iio_dev *indio_dev,
static irqreturn_t stm32_adc_threaded_isr(int irq, void *data)
{
- struct stm32_adc *adc = data;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = data;
+ struct stm32_adc *adc = iio_priv(indio_dev);
const struct stm32_adc_regspec *regs = adc->cfg->regs;
u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg);
@@ -1240,8 +1240,8 @@ static irqreturn_t stm32_adc_threaded_isr(int irq, void *data)
static irqreturn_t stm32_adc_isr(int irq, void *data)
{
- struct stm32_adc *adc = data;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = data;
+ struct stm32_adc *adc = iio_priv(indio_dev);
const struct stm32_adc_regspec *regs = adc->cfg->regs;
u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg);
@@ -1882,7 +1882,7 @@ static int stm32_adc_probe(struct platform_device *pdev)
ret = devm_request_threaded_irq(&pdev->dev, adc->irq, stm32_adc_isr,
stm32_adc_threaded_isr,
- 0, pdev->name, adc);
+ 0, pdev->name, indio_dev);
if (ret) {
dev_err(&pdev->dev, "failed to request IRQ\n");
return ret;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/8] iio: at91_adc: pass ref to IIO device via param for int function
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
Since there will be some changes to how iio_priv_to_dev() is implemented,
it could be that the helper becomes a bit slower, as it will be hidden away
in the IIO core.
For this driver, the IIO device can be passed directly as a parameter to
the at91_ts_sample() function, thus making it immune to the change of
iio_priv_to_dev().
The function gets called in an interrupt context.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/adc/at91_adc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 0368b6dc6d60..5999defe47cd 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -287,13 +287,12 @@ static void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
}
}
-static int at91_ts_sample(struct at91_adc_state *st)
+static int at91_ts_sample(struct iio_dev *idev, struct at91_adc_state *st)
{
unsigned int xscale, yscale, reg, z1, z2;
unsigned int x, y, pres, xpos, ypos;
unsigned int rxp = 1;
unsigned int factor = 1000;
- struct iio_dev *idev = iio_priv_to_dev(st);
unsigned int xyz_mask_bits = st->res;
unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
@@ -449,7 +448,7 @@ static irqreturn_t at91_adc_9x5_interrupt(int irq, void *private)
if (status & AT91_ADC_ISR_PENS) {
/* validate data by pen contact */
- at91_ts_sample(st);
+ at91_ts_sample(idev, st);
} else {
/* triggered by event that is no pen contact, just read
* them to clean the interrupt and discard all.
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/8] iio: at91-sama5d2_adc: pass ref to IIO device via param for int function
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
Since there will be some changes to how iio_priv_to_dev() is implemented,
it could be that the helper becomes a bit slower, as it will be hidden away
in the IIO core.
For this driver, the IIO device can be passed directly as a parameter to
the at91_adc_no_pen_detect_interrupt() function, thus making it immune to
the change of iio_priv_to_dev().
The function gets called in an interrupt context.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/adc/at91-sama5d2_adc.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
index 9abbbdcc7420..822b8782acba 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -1275,10 +1275,9 @@ static void at91_adc_pen_detect_interrupt(struct at91_adc_state *st)
st->touch_st.touching = true;
}
-static void at91_adc_no_pen_detect_interrupt(struct at91_adc_state *st)
+static void at91_adc_no_pen_detect_interrupt(struct iio_dev *indio_dev,
+ struct at91_adc_state *st)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(st);
-
at91_adc_writel(st, AT91_SAMA5D2_TRGR,
AT91_SAMA5D2_TRGR_TRGMOD_NO_TRIGGER);
at91_adc_writel(st, AT91_SAMA5D2_IDR, AT91_SAMA5D2_IER_NOPEN |
@@ -1318,7 +1317,7 @@ static irqreturn_t at91_adc_interrupt(int irq, void *private)
at91_adc_pen_detect_interrupt(st);
} else if ((status & AT91_SAMA5D2_IER_NOPEN)) {
/* nopen detected IRQ */
- at91_adc_no_pen_detect_interrupt(st);
+ at91_adc_no_pen_detect_interrupt(indio, st);
} else if ((status & AT91_SAMA5D2_ISR_PENS) &&
((status & rdy_mask) == rdy_mask)) {
/* periodic trigger IRQ - during pen sense */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/8] iio: core: wrap IIO device into an iio_dev_opaque object
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
This change starts to hide some internal fields of the IIO device into
the framework.
Because the iio_priv_to_dev() will be hidden some pre-work is done to
try to remove it from some interrupt handlers.
iio_priv_to_dev() will become a function call and won't be expandable
into place (as-is now as an inline function).
Changelog v1 -> v2:
- add pre-work patches that remove some calls to iio_priv_to_dev() from
interrupt handlers
- renamed iio_dev_priv -> iio_dev_opaque
- moved the iio_dev_opaque to 'include/linux/iio/iio-opaque.h' this way
it should be usable for debugging
- the iio_priv() call, is still an inline function that returns an
'indio_dev->priv' reference; this field is added to 'struct iio_dev';
the reference is computed in iio_device_alloc() and should be
cacheline aligned
- the to_iio_dev_opaque() container is in the
'include/linux/iio/iio-opaque.h' header; it's still implemented with
some pointer arithmetic; one idea was to do it via an
'indio_dev->opaque' field; that may still be an optionif there are
some opinions in that direction
Alexandru Ardelean (8):
iio: proximity: ping: pass reference to IIO device via call-stack
iio: at91-sama5d2_adc: pass ref to IIO device via param for int
function
iio: at91_adc: pass ref to IIO device via param for int function
iio: stm32-dfsdm-adc: pass iio device as arg for the interrupt handler
iio: stm32-adc: pass iio device as arg for the interrupt handler
iio: core: wrap IIO device into an iio_dev_opaque object
iio: core: simplify alloc alignment code
iio: core: move debugfs data on the private iio dev info
drivers/iio/adc/at91-sama5d2_adc.c | 7 ++-
drivers/iio/adc/at91_adc.c | 5 +-
drivers/iio/adc/stm32-adc.c | 10 ++--
drivers/iio/adc/stm32-dfsdm-adc.c | 6 +--
drivers/iio/industrialio-core.c | 75 ++++++++++++++++++++----------
drivers/iio/proximity/ping.c | 5 +-
include/linux/iio/iio-opaque.h | 27 +++++++++++
include/linux/iio/iio.h | 24 +++-------
8 files changed, 99 insertions(+), 60 deletions(-)
create mode 100644 include/linux/iio/iio-opaque.h
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/8] iio: proximity: ping: pass reference to IIO device via call-stack
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
Since there will be some changes to how iio_priv_to_dev() is implemented,
it could be that the helper becomes a bit slower, as it will be hidden away
in the IIO core.
For this driver, the IIO device can be passed directly as a parameter to
the ping_read() function, thus making it immune to the change of
iio_priv_to_dev().
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/proximity/ping.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/proximity/ping.c b/drivers/iio/proximity/ping.c
index 12b893c5b0ee..ddc43a5a2ef8 100644
--- a/drivers/iio/proximity/ping.c
+++ b/drivers/iio/proximity/ping.c
@@ -89,14 +89,13 @@ static irqreturn_t ping_handle_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int ping_read(struct ping_data *data)
+static int ping_read(struct iio_dev *indio_dev, struct ping_data *data)
{
int ret;
ktime_t ktime_dt;
s64 dt_ns;
u32 time_ns, distance_mm;
struct platform_device *pdev = to_platform_device(data->dev);
- struct iio_dev *indio_dev = iio_priv_to_dev(data);
/*
* just one read-echo-cycle can take place at a time
@@ -236,7 +235,7 @@ static int ping_read_raw(struct iio_dev *indio_dev,
switch (info) {
case IIO_CHAN_INFO_RAW:
- ret = ping_read(data);
+ ret = ping_read(indio_dev, data);
if (ret < 0)
return ret;
*val = ret;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 0/5] iommu: Add Allwinner H6 IOMMU driver
From: Joerg Roedel @ 2020-05-14 13:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, iommu, Chen-Yu Tsai, Rob Herring,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20200514130900.k4gvr3zcajg3rouc@gilmour.lan>
On Thu, May 14, 2020 at 03:09:00PM +0200, Maxime Ripard wrote:
> On Thu, May 14, 2020 at 02:38:55PM +0200, Joerg Roedel wrote:
> > On Wed, May 13, 2020 at 04:07:19PM +0200, Maxime Ripard wrote:
> > > Maxime Ripard (5):
> > > dt-bindings: iommu: Add Allwinner H6 IOMMU bindings
> > > dt-bindings: display: sun8i-mixer: Allow for an iommu property
> > > iommu: Add Allwinner H6 IOMMU driver
> > > arm64: dts: allwinner: h6: Add IOMMU
> > > drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
> >
> > Applied all to the IOMMU tree, thanks. The code lives in the
> > arm/allwinner branch.
>
> Did you also merge the DTS and DRM patches?
>
> Ideally, they should be merged through other trees to avoid the conflicts as
> much as possible (arm-soc and drm-misc respectively).
>
> If it's an option, could you drop all of them but "dt-bindings: iommu: Add
> Allwinner H6 IOMMU bindings" and "iommu: Add Allwinner H6 IOMMU driver"?
Okay, just to be on the safe side, I am going to drop:
dt-bindings: display: sun8i-mixer: Allow for an iommu property
arm64: dts: allwinner: h6: Add IOMMU
drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
from the iommu-tree?
I took them because you are also maintaining the DRM driver, which
counted as an implicit ACK for me :)
Joerg
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/2] i2c: mediatek: Add i2c ac-timing adjust support
From: Qii Wang @ 2020-05-14 13:09 UTC (permalink / raw)
To: wsa
Cc: devicetree, qii.wang, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, linux-i2c, linux-arm-kernel
In-Reply-To: <1589461844-15614-1-git-send-email-qii.wang@mediatek.com>
This patch adds a algorithm to calculate some ac-timing parameters
which can fully meet I2C Spec.
Signed-off-by: Qii Wang <qii.wang@mediatek.com>
---
drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
1 file changed, 277 insertions(+), 51 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 0ca6c38a..7020618 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -40,12 +40,11 @@
#define I2C_SOFT_RST 0x0001
#define I2C_FIFO_ADDR_CLR 0x0001
#define I2C_DELAY_LEN 0x0002
-#define I2C_ST_START_CON 0x8001
-#define I2C_FS_START_CON 0x1800
#define I2C_TIME_CLR_VALUE 0x0000
#define I2C_TIME_DEFAULT_VALUE 0x0003
#define I2C_WRRD_TRANAC_VALUE 0x0002
#define I2C_RD_TRANAC_VALUE 0x0001
+#define I2C_SCL_MIS_COMP_VALUE 0x0000
#define I2C_DMA_CON_TX 0x0000
#define I2C_DMA_CON_RX 0x0001
@@ -55,10 +54,13 @@
#define I2C_DMA_HARD_RST 0x0002
#define I2C_DMA_4G_MODE 0x0001
-#define I2C_DEFAULT_CLK_DIV 5
#define MAX_SAMPLE_CNT_DIV 8
#define MAX_STEP_CNT_DIV 64
+#define MAX_CLOCK_DIV 256
#define MAX_HS_STEP_CNT_DIV 8
+#define I2C_STANDARD_MODE_BUFFER (1000 / 2)
+#define I2C_FAST_MODE_BUFFER (300 / 2)
+#define I2C_FAST_MODE_PLUS_BUFFER (20 / 2)
#define I2C_CONTROL_RS (0x1 << 1)
#define I2C_CONTROL_DMA_EN (0x1 << 2)
@@ -123,6 +125,12 @@ enum I2C_REGS_OFFSET {
OFFSET_TRANSFER_LEN_AUX,
OFFSET_CLOCK_DIV,
OFFSET_LTIMING,
+ OFFSET_SCL_HIGH_LOW_RATIO,
+ OFFSET_HS_SCL_HIGH_LOW_RATIO,
+ OFFSET_SCL_MIS_COMP_POINT,
+ OFFSET_STA_STO_AC_TIMING,
+ OFFSET_HS_STA_STO_AC_TIMING,
+ OFFSET_SDA_TIMING,
};
static const u16 mt_i2c_regs_v1[] = {
@@ -150,6 +158,12 @@ enum I2C_REGS_OFFSET {
[OFFSET_DEBUGCTRL] = 0x68,
[OFFSET_TRANSFER_LEN_AUX] = 0x6c,
[OFFSET_CLOCK_DIV] = 0x70,
+ [OFFSET_SCL_HIGH_LOW_RATIO] = 0x74,
+ [OFFSET_HS_SCL_HIGH_LOW_RATIO] = 0x78,
+ [OFFSET_SCL_MIS_COMP_POINT] = 0x7C,
+ [OFFSET_STA_STO_AC_TIMING] = 0x80,
+ [OFFSET_HS_STA_STO_AC_TIMING] = 0x84,
+ [OFFSET_SDA_TIMING] = 0x88,
};
static const u16 mt_i2c_regs_v2[] = {
@@ -168,9 +182,11 @@ enum I2C_REGS_OFFSET {
[OFFSET_HS] = 0x30,
[OFFSET_IO_CONFIG] = 0x34,
[OFFSET_FIFO_ADDR_CLR] = 0x38,
+ [OFFSET_SDA_TIMING] = 0x3c,
[OFFSET_TRANSFER_LEN_AUX] = 0x44,
[OFFSET_CLOCK_DIV] = 0x48,
[OFFSET_SOFTRESET] = 0x50,
+ [OFFSET_SCL_MIS_COMP_POINT] = 0x90,
[OFFSET_DEBUGSTAT] = 0xe0,
[OFFSET_DEBUGCTRL] = 0xe8,
[OFFSET_FIFO_STAT] = 0xf4,
@@ -191,6 +207,19 @@ struct mtk_i2c_compatible {
unsigned char ltiming_adjust: 1;
};
+struct mtk_i2c_ac_timing {
+ u16 htiming;
+ u16 ltiming;
+ u16 hs;
+ u16 ext;
+ u16 inter_clk_div;
+ u16 scl_hl_ratio;
+ u16 hs_scl_hl_ratio;
+ u16 sta_stop;
+ u16 hs_sta_stop;
+ u16 sda_timing;
+};
+
struct mtk_i2c {
struct i2c_adapter adap; /* i2c host adapter */
struct device *dev;
@@ -215,9 +244,46 @@ struct mtk_i2c {
u16 ltiming_reg;
unsigned char auto_restart;
bool ignore_restart_irq;
+ struct mtk_i2c_ac_timing ac_timing;
const struct mtk_i2c_compatible *dev_comp;
};
+/**
+ * struct i2c_spec_values:
+ * min_low_ns: min LOW period of the SCL clock
+ * min_su_sta_ns: min set-up time for a repeated START condition
+ * max_hd_dat_ns: max data hold time
+ * min_su_dat_ns: min data set-up time
+ */
+struct i2c_spec_values {
+ unsigned int min_low_ns;
+ unsigned int min_high_ns;
+ unsigned int min_su_sta_ns;
+ unsigned int max_hd_dat_ns;
+ unsigned int min_su_dat_ns;
+};
+
+static const struct i2c_spec_values standard_mode_spec = {
+ .min_low_ns = 4700 + I2C_STANDARD_MODE_BUFFER,
+ .min_su_sta_ns = 4700 + I2C_STANDARD_MODE_BUFFER,
+ .max_hd_dat_ns = 3450 - I2C_STANDARD_MODE_BUFFER,
+ .min_su_dat_ns = 250 + I2C_STANDARD_MODE_BUFFER,
+};
+
+static const struct i2c_spec_values fast_mode_spec = {
+ .min_low_ns = 1300 + I2C_FAST_MODE_BUFFER,
+ .min_su_sta_ns = 600 + I2C_FAST_MODE_BUFFER,
+ .max_hd_dat_ns = 900 - I2C_FAST_MODE_BUFFER,
+ .min_su_dat_ns = 100 + I2C_FAST_MODE_BUFFER,
+};
+
+static const struct i2c_spec_values fast_mode_plus_spec = {
+ .min_low_ns = 500 + I2C_FAST_MODE_PLUS_BUFFER,
+ .min_su_sta_ns = 260 + I2C_FAST_MODE_PLUS_BUFFER,
+ .max_hd_dat_ns = 400 - I2C_FAST_MODE_PLUS_BUFFER,
+ .min_su_dat_ns = 50 + I2C_FAST_MODE_PLUS_BUFFER,
+};
+
static const struct i2c_adapter_quirks mt6577_i2c_quirks = {
.flags = I2C_AQ_COMB_WRITE_THEN_READ,
.max_num_msgs = 1,
@@ -397,14 +463,38 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
if (i2c->dev_comp->dcm)
mtk_i2c_writew(i2c, I2C_DCM_DISABLE, OFFSET_DCM_EN);
- if (i2c->dev_comp->timing_adjust)
- mtk_i2c_writew(i2c, I2C_DEFAULT_CLK_DIV - 1, OFFSET_CLOCK_DIV);
-
mtk_i2c_writew(i2c, i2c->timing_reg, OFFSET_TIMING);
mtk_i2c_writew(i2c, i2c->high_speed_reg, OFFSET_HS);
if (i2c->dev_comp->ltiming_adjust)
mtk_i2c_writew(i2c, i2c->ltiming_reg, OFFSET_LTIMING);
+ if (i2c->dev_comp->timing_adjust) {
+ mtk_i2c_writew(i2c, i2c->ac_timing.ext, OFFSET_EXT_CONF);
+ mtk_i2c_writew(i2c, i2c->ac_timing.inter_clk_div,
+ OFFSET_CLOCK_DIV);
+ mtk_i2c_writew(i2c, I2C_SCL_MIS_COMP_VALUE,
+ OFFSET_SCL_MIS_COMP_POINT);
+ mtk_i2c_writew(i2c, i2c->ac_timing.sda_timing,
+ OFFSET_SDA_TIMING);
+
+ if (i2c->dev_comp->ltiming_adjust) {
+ mtk_i2c_writew(i2c, i2c->ac_timing.htiming,
+ OFFSET_TIMING);
+ mtk_i2c_writew(i2c, i2c->ac_timing.hs, OFFSET_HS);
+ mtk_i2c_writew(i2c, i2c->ac_timing.ltiming,
+ OFFSET_LTIMING);
+ } else {
+ mtk_i2c_writew(i2c, i2c->ac_timing.scl_hl_ratio,
+ OFFSET_SCL_HIGH_LOW_RATIO);
+ mtk_i2c_writew(i2c, i2c->ac_timing.hs_scl_hl_ratio,
+ OFFSET_HS_SCL_HIGH_LOW_RATIO);
+ mtk_i2c_writew(i2c, i2c->ac_timing.sta_stop,
+ OFFSET_STA_STO_AC_TIMING);
+ mtk_i2c_writew(i2c, i2c->ac_timing.hs_sta_stop,
+ OFFSET_HS_STA_STO_AC_TIMING);
+ }
+ }
+
/* If use i2c pin from PMIC mt6397 side, need set PATH_DIR first */
if (i2c->have_pmic)
mtk_i2c_writew(i2c, I2C_CONTROL_WRAPPER, OFFSET_PATH_DIR);
@@ -422,6 +512,125 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_RST);
}
+static const struct i2c_spec_values *mtk_i2c_get_spec(unsigned int speed)
+{
+ if (speed <= I2C_MAX_STANDARD_MODE_FREQ)
+ return &standard_mode_spec;
+ else if (speed <= I2C_MAX_FAST_MODE_FREQ)
+ return &fast_mode_spec;
+ else
+ return &fast_mode_plus_spec;
+}
+
+static int mtk_i2c_max_step_cnt(unsigned int target_speed)
+{
+ if (target_speed > I2C_MAX_FAST_MODE_FREQ)
+ return MAX_HS_STEP_CNT_DIV;
+ else
+ return MAX_STEP_CNT_DIV;
+}
+
+/*
+ * Check and Calculate i2c ac-timing
+ *
+ * Hardware design:
+ * sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src
+ * xxx_cnt_div = spec->min_xxx_ns / sample_ns
+ *
+ * Sample_ns is rounded down for xxx_cnt_div would be greater
+ * than the smallest spec.
+ * The sda_timing is chosen as the middle value between
+ * the largest and smallest.
+ */
+static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
+ unsigned int clk_src,
+ unsigned int check_speed,
+ unsigned int step_cnt,
+ unsigned int sample_cnt)
+{
+ const struct i2c_spec_values *spec;
+ unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
+ unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
+ long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
+
+ if (!i2c->dev_comp->timing_adjust)
+ return 0;
+
+ if (i2c->dev_comp->ltiming_adjust)
+ max_sta_cnt = 0x100;
+
+ spec = mtk_i2c_get_spec(check_speed);
+
+ if (i2c->dev_comp->ltiming_adjust)
+ clk_ns = 1000000000 / clk_src;
+ else
+ clk_ns = sample_ns / 2;
+
+ su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
+ if (su_sta_cnt > max_sta_cnt)
+ return -1;
+
+ low_cnt = DIV_ROUND_UP(spec->min_low_ns, sample_ns);
+ max_step_cnt = mtk_i2c_max_step_cnt(check_speed);
+ if ((2 * step_cnt) > low_cnt && low_cnt < max_step_cnt) {
+ if (low_cnt > step_cnt) {
+ high_cnt = 2 * step_cnt - low_cnt;
+ } else {
+ high_cnt = step_cnt;
+ low_cnt = step_cnt;
+ }
+ } else {
+ return -2;
+ }
+
+ sda_max = spec->max_hd_dat_ns / sample_ns;
+ if (sda_max > low_cnt)
+ sda_max = 0;
+
+ sda_min = DIV_ROUND_UP(spec->min_su_dat_ns, sample_ns);
+ if (sda_min < low_cnt)
+ sda_min = 0;
+
+ if (sda_min > sda_max)
+ return -3;
+
+ if (check_speed > I2C_MAX_FAST_MODE_FREQ) {
+ if (i2c->dev_comp->ltiming_adjust) {
+ i2c->ac_timing.hs = I2C_TIME_DEFAULT_VALUE |
+ (sample_cnt << 12) | (high_cnt << 8);
+ i2c->ac_timing.ltiming &= ~GENMASK(15, 9);
+ i2c->ac_timing.ltiming |= (sample_cnt << 12) |
+ (low_cnt << 9);
+ i2c->ac_timing.ext &= ~GENMASK(7, 1);
+ i2c->ac_timing.ext |= (su_sta_cnt << 1) | (1 << 0);
+ } else {
+ i2c->ac_timing.hs_scl_hl_ratio = (1 << 12) |
+ (high_cnt << 6) | low_cnt;
+ i2c->ac_timing.hs_sta_stop = (su_sta_cnt << 8) |
+ su_sta_cnt;
+ }
+ i2c->ac_timing.sda_timing &= ~GENMASK(11, 6);
+ i2c->ac_timing.sda_timing |= (1 << 12) |
+ ((sda_max + sda_min) / 2) << 6;
+ } else {
+ if (i2c->dev_comp->ltiming_adjust) {
+ i2c->ac_timing.htiming = (sample_cnt << 8) | (high_cnt);
+ i2c->ac_timing.ltiming = (sample_cnt << 6) | (low_cnt);
+ i2c->ac_timing.ext = (su_sta_cnt << 8) | (1 << 0);
+ } else {
+ i2c->ac_timing.scl_hl_ratio = (1 << 12) |
+ (high_cnt << 6) | low_cnt;
+ i2c->ac_timing.sta_stop = (su_sta_cnt << 8) |
+ su_sta_cnt;
+ }
+
+ i2c->ac_timing.sda_timing = (1 << 12) |
+ (sda_max + sda_min) / 2;
+ }
+
+ return 0;
+}
+
/*
* Calculate i2c port speed
*
@@ -446,15 +655,12 @@ static int mtk_i2c_calculate_speed(struct mtk_i2c *i2c, unsigned int clk_src,
unsigned int opt_div;
unsigned int best_mul;
unsigned int cnt_mul;
+ int ret = -EINVAL;
if (target_speed > I2C_MAX_FAST_MODE_PLUS_FREQ)
target_speed = I2C_MAX_FAST_MODE_PLUS_FREQ;
- if (target_speed > I2C_MAX_FAST_MODE_FREQ)
- max_step_cnt = MAX_HS_STEP_CNT_DIV;
- else
- max_step_cnt = MAX_STEP_CNT_DIV;
-
+ max_step_cnt = mtk_i2c_max_step_cnt(target_speed);
base_step_cnt = max_step_cnt;
/* Find the best combination */
opt_div = DIV_ROUND_UP(clk_src >> 1, target_speed);
@@ -473,6 +679,11 @@ static int mtk_i2c_calculate_speed(struct mtk_i2c *i2c, unsigned int clk_src,
continue;
if (cnt_mul < best_mul) {
+ ret = mtk_i2c_check_ac_timing(i2c, clk_src,
+ target_speed, step_cnt - 1, sample_cnt - 1);
+ if (ret)
+ continue;
+
best_mul = cnt_mul;
base_sample_cnt = sample_cnt;
base_step_cnt = step_cnt;
@@ -481,6 +692,9 @@ static int mtk_i2c_calculate_speed(struct mtk_i2c *i2c, unsigned int clk_src,
}
}
+ if (ret)
+ return -EINVAL;
+
sample_cnt = base_sample_cnt;
step_cnt = base_step_cnt;
@@ -506,47 +720,68 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk)
unsigned int l_step_cnt;
unsigned int l_sample_cnt;
unsigned int target_speed;
+ unsigned int clk_div;
+ unsigned int max_clk_div;
int ret;
- clk_src = parent_clk / i2c->clk_src_div;
target_speed = i2c->speed_hz;
+ parent_clk /= i2c->clk_src_div;
- if (target_speed > I2C_MAX_FAST_MODE_FREQ) {
- /* Set master code speed register */
- ret = mtk_i2c_calculate_speed(i2c, clk_src, I2C_MAX_FAST_MODE_FREQ,
- &l_step_cnt, &l_sample_cnt);
- if (ret < 0)
- return ret;
-
- i2c->timing_reg = (l_sample_cnt << 8) | l_step_cnt;
-
- /* Set the high speed mode register */
- ret = mtk_i2c_calculate_speed(i2c, clk_src, target_speed,
- &step_cnt, &sample_cnt);
- if (ret < 0)
- return ret;
-
- i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE |
- (sample_cnt << 12) | (step_cnt << 8);
+ if (i2c->dev_comp->timing_adjust)
+ max_clk_div = MAX_CLOCK_DIV;
+ else
+ max_clk_div = 1;
+
+ for (clk_div = 1; clk_div <= max_clk_div; clk_div++) {
+ clk_src = parent_clk / clk_div;
+
+ if (target_speed > I2C_MAX_FAST_MODE_FREQ) {
+ /* Set master code speed register */
+ ret = mtk_i2c_calculate_speed(i2c, clk_src,
+ I2C_MAX_FAST_MODE_FREQ,
+ &l_step_cnt,
+ &l_sample_cnt);
+ if (ret < 0)
+ continue;
+
+ i2c->timing_reg = (l_sample_cnt << 8) | l_step_cnt;
+
+ /* Set the high speed mode register */
+ ret = mtk_i2c_calculate_speed(i2c, clk_src,
+ target_speed, &step_cnt,
+ &sample_cnt);
+ if (ret < 0)
+ continue;
+
+ i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE |
+ (sample_cnt << 12) | (step_cnt << 8);
+
+ if (i2c->dev_comp->ltiming_adjust)
+ i2c->ltiming_reg =
+ (l_sample_cnt << 6) | l_step_cnt |
+ (sample_cnt << 12) | (step_cnt << 9);
+ } else {
+ ret = mtk_i2c_calculate_speed(i2c, clk_src,
+ target_speed, &l_step_cnt,
+ &l_sample_cnt);
+ if (ret < 0)
+ continue;
- if (i2c->dev_comp->ltiming_adjust)
- i2c->ltiming_reg = (l_sample_cnt << 6) | l_step_cnt |
- (sample_cnt << 12) | (step_cnt << 9);
- } else {
- ret = mtk_i2c_calculate_speed(i2c, clk_src, target_speed,
- &step_cnt, &sample_cnt);
- if (ret < 0)
- return ret;
+ i2c->timing_reg = (l_sample_cnt << 8) | l_step_cnt;
- i2c->timing_reg = (sample_cnt << 8) | step_cnt;
+ /* Disable the high speed transaction */
+ i2c->high_speed_reg = I2C_TIME_CLR_VALUE;
- /* Disable the high speed transaction */
- i2c->high_speed_reg = I2C_TIME_CLR_VALUE;
+ if (i2c->dev_comp->ltiming_adjust)
+ i2c->ltiming_reg =
+ (l_sample_cnt << 6) | l_step_cnt;
+ }
- if (i2c->dev_comp->ltiming_adjust)
- i2c->ltiming_reg = (sample_cnt << 6) | step_cnt;
+ break;
}
+ i2c->ac_timing.inter_clk_div = clk_div - 1;
+
return 0;
}
@@ -586,12 +821,6 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
mtk_i2c_writew(i2c, control_reg, OFFSET_CONTROL);
- /* set start condition */
- if (i2c->speed_hz <= I2C_MAX_STANDARD_MODE_FREQ)
- mtk_i2c_writew(i2c, I2C_ST_START_CON, OFFSET_EXT_CONF);
- else
- mtk_i2c_writew(i2c, I2C_FS_START_CON, OFFSET_EXT_CONF);
-
addr_reg = i2c_8bit_addr_from_msg(msgs);
mtk_i2c_writew(i2c, addr_reg, OFFSET_SLAVE_ADDR);
@@ -948,9 +1177,6 @@ static int mtk_i2c_probe(struct platform_device *pdev)
if (ret)
return -EINVAL;
- if (i2c->dev_comp->timing_adjust)
- i2c->clk_src_div *= I2C_DEFAULT_CLK_DIV;
-
if (i2c->have_pmic && !i2c->dev_comp->pmic_i2c)
return -EINVAL;
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/2] MAINTAINERS: add maintainer for mediatek i2c controller driver
From: Qii Wang @ 2020-05-14 13:09 UTC (permalink / raw)
To: wsa
Cc: devicetree, qii.wang, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, linux-i2c, linux-arm-kernel
In-Reply-To: <1589461844-15614-1-git-send-email-qii.wang@mediatek.com>
Add Qii Wang as maintainer for mediatek i2c controller driver.
Signed-off-by: Qii Wang <qii.wang@mediatek.com>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db..c0fdf11 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10658,6 +10658,13 @@ L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/mediatek/
+MEDIATEK I2C CONTROLLER DRIVER
+M: Qii Wang <qii.wang@mediatek.com>
+L: linux-i2c@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
+F: drivers/i2c/busses/i2c-mt65xx.c
+
MEDIATEK JPEG DRIVER
M: Rick Chang <rick.chang@mediatek.com>
M: Bin Liu <bin.liu@mediatek.com>
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/2] Add i2c ac-timing adjust support
From: Qii Wang @ 2020-05-14 13:09 UTC (permalink / raw)
To: wsa
Cc: devicetree, qii.wang, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, linux-i2c, linux-arm-kernel
This series are based on 5.7-rc1, we provide two patches to support i2c ac-timing.
Main changes compared to v1:
--add maintainer for mediatek i2c controller driver
--fix warning of self-assignment
Qii Wang (2):
MAINTAINERS: add maintainer for mediatek i2c controller driver
i2c: mediatek: Add i2c ac-timing adjust support
MAINTAINERS | 7 +
drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
2 files changed, 284 insertions(+), 51 deletions(-)
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/5] iommu: Add Allwinner H6 IOMMU driver
From: Maxime Ripard @ 2020-05-14 13:09 UTC (permalink / raw)
To: Joerg Roedel
Cc: Mark Rutland, devicetree, iommu, Chen-Yu Tsai, Rob Herring,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20200514123855.GI18353@8bytes.org>
[-- Attachment #1.1: Type: text/plain, Size: 1235 bytes --]
On Thu, May 14, 2020 at 02:38:55PM +0200, Joerg Roedel wrote:
> On Wed, May 13, 2020 at 04:07:19PM +0200, Maxime Ripard wrote:
> > Maxime Ripard (5):
> > dt-bindings: iommu: Add Allwinner H6 IOMMU bindings
> > dt-bindings: display: sun8i-mixer: Allow for an iommu property
> > iommu: Add Allwinner H6 IOMMU driver
> > arm64: dts: allwinner: h6: Add IOMMU
> > drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
>
> Applied all to the IOMMU tree, thanks. The code lives in the
> arm/allwinner branch.
Did you also merge the DTS and DRM patches?
Ideally, they should be merged through other trees to avoid the conflicts as
much as possible (arm-soc and drm-misc respectively).
If it's an option, could you drop all of them but "dt-bindings: iommu: Add
Allwinner H6 IOMMU bindings" and "iommu: Add Allwinner H6 IOMMU driver"?
> Please use 'iommu/sun50i: <Capital Letter>...' as the pattern for your future
> subject lines when changing the driver.
I'll try to remember that, thanks! :)
> I also have two fixes on-top which I will send out shortly and add to
> that branch.
Ugh. I'm not sure how the first one slipped through.. Sorry for that, I'm fine
with both.
Thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
From: dillon min @ 2020-05-14 13:07 UTC (permalink / raw)
To: Alexandre Torgue
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Daniel Vetter, Dave Airlie, Linus Walleij, linux-clk,
linux-kernel@vger.kernel.org, open list:DRM PANEL DRIVERS,
linux-stm32, Stephen Boyd, Rob Herring, thierry.reding@gmail.com,
Maxime Coquelin, Sam Ravnborg, Michael Turquette, Linux ARM
In-Reply-To: <a4ebd7cd-5756-0683-135f-0f96be8a4a7b@st.com>
Hi Alexandre,
On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
<alexandre.torgue@st.com> wrote:
>
>
>
> On 5/14/20 10:24 AM, Linus Walleij wrote:
> > On Tue, May 12, 2020 at 9:04 AM <dillon.minfei@gmail.com> wrote:
> >
> >> From: dillon min <dillon.minfei@gmail.com>
> >>
> >> Enable the ltdc & ili9341 on stm32429-disco board.
> >>
> >> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> >
> > This mostly looks good but...
> >
> >> +&spi5 {
> >> + status = "okay";
> >> + pinctrl-0 = <&spi5_pins>;
> >> + pinctrl-names = "default";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + cs-gpios = <&gpioc 2 GPIO_ACTIVE_LOW>;
> >> + dmas = <&dma2 3 2 0x400 0x0>,
> >> + <&dma2 4 2 0x400 0x0>;
> >> + dma-names = "rx", "tx";
> >
> > These DMA assignments seem to be SoC things and should
> > rather be in the DTS(I) file where &spi5 is defined, right?
> > stm32f429.dtsi I suppose?
>
> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
> doesn't want to use it, we use the "delete-property".
Yes, will move to Soc dtsi in next submits.
i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
pixel conversion
alpha blending between foreground and background graphics.
as you know, some soc's engineer trying to add this function to drm system.
do you know st's planning about soc's hardware accelerator driver on stm32mp?
such as chrom-art, will add to drm subsystem via ioctl to access, or to v4l2,
thanks.
>
> >
> > It is likely the same no matter which device is using spi5.
> >
> > Yours,
> > Linus Walleij
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/10] spi: dw: Add support for polled operation via no IRQ specified in DT
From: Serge Semin @ 2020-05-14 13:04 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree, Alexandre Belloni, Andy Shevchenko, linux-kernel,
Serge Semin, linux-spi, SoC Team, linux-arm-kernel,
Microchip Linux Driver Support, Lars Povlsen
In-Reply-To: <20200513142050.GH4803@sirena.org.uk>
Hi Mark
On Wed, May 13, 2020 at 03:20:50PM +0100, Mark Brown wrote:
> On Wed, May 13, 2020 at 04:00:22PM +0200, Lars Povlsen wrote:
> > With this change a SPI controller can be added without having a IRQ
> > associated, and causing all transfers to be polled. For SPI controllers
> > without DMA, this can significantly improve performance by less
> > interrupt handling overhead.
>
> This overlaps substantially with some work that Serge Semin (CCed) has
> in progress, please coordinate with him.
Thanks for copying me these mails. I haven't been Cc'ed in the series and
hasn't been subscribed to the SPI mailing list, so I would have definitely
missed that.
I would like to coordinate my efforts with Lars. I'll have the patchset reviewed
soon in addition providing my comments/suggestions of how to make it useful for
both mine and Lars solution.
One thing I can tell about the mem_ops he implemented, is that they aren't
mem_ops, but dirmap (as you remember it's also implemented in my code, but with
alignment specific), and the exec_mem_op partly consists of a code, which belong
to the supports_op() callback. The rest of my comments will be inlined in the
patches.
-Sergey
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mmc: Add Sparx5 SDHCI controller bindings
From: Rob Herring @ 2020-05-14 13:03 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, Ulf Hansson, Adrian Hunter, linux-mmc,
Alexandre Belloni, linux-kernel, SoC Team, Rob Herring,
Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200513133122.25121-2-lars.povlsen@microchip.com>
On Wed, 13 May 2020 15:31:20 +0200, Lars Povlsen wrote:
> The Sparx5 SDHCI controller is based on the Designware controller IP.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> .../mmc/microchip,dw-sparx5-sdhci.yaml | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dts:20:18: fatal error: dt-bindings/clock/microchip,sparx5.h: No such file or directory
#include <dt-bindings/clock/microchip,sparx5.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
scripts/Makefile.lib:312: recipe for target 'Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dt.yaml' failed
make[1]: *** [Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1289290
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/13] usb: dwc3: meson: add OTG support for GXL/GXM
From: Felipe Balbi @ 2020-05-14 12:59 UTC (permalink / raw)
To: Neil Armstrong, kishon, khilman, martin.blumenstingl
Cc: linux-amlogic, linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <8404c7a0-fca7-9e28-b65a-312ed09ecdd3@baylibre.com>
[-- Attachment #1.1: Type: text/plain, Size: 2527 bytes --]
Neil Armstrong <narmstrong@baylibre.com> writes:
> Hi,
>
> On 14/05/2020 12:23, Felipe Balbi wrote:
>> Felipe Balbi <balbi@kernel.org> writes:
>>
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>
>>>> The USB support was initialy done with a set of PHYs and dwc3-of-simple
>>>> because the architecture of the USB complex was not understood correctly
>>>> at the time (and proper documentation was missing...).
>>>>
>>>> But with the G12A family, the USB complex was correctly understood and
>>>> implemented correctly.
>>>> But seems the G12A architecture was derived for the GXL USB architecture,
>>>> with minor differences and looks we can share most of the USB DWC3 glue
>>>> driver.
>>>>
>>>> This patchset refactors and adds callbacks to handle the architecture
>>>> difference while keeping the main code shared.
>>>>
>>>> The main difference is that on GXL/GXM the USB2 PHY control registers
>>>> are mixed with the PHY registers (we already handle correctly), and
>>>> the GLUE registers are allmost (99%) the same as G12A.
>>>>
>>>> But, the GXL/GXM HW is buggy, here are the quirks :
>>>> - for the DWC2 controller to reset correctly, the GLUE mux must be switched
>>>> to peripheral when the DWC2 controlle probes. For now it's handled by simply
>>>> switching to device when probing the subnodes, but it may be not enough
>>>> - when manually switching from Host to Device when the USB port is not
>>>> populated (should not happen with proper Micro-USB/USB-C OTG switch), it
>>>> makes the DWC3 to crash. The only way to avoid that is to use the Host
>>>> Disconnect bit to disconnect the DWC3 controller from the port, but we can't
>>>> recover the Host functionnality unless resetting the DWC3 controller.
>>>> This bit is set when only manual switch is done, and a warning is printed
>>>> on manual switching.
>>>>
>>>> The patches 1-8 should be applied first, then either waiting the next release
>>>> or if the usb maintainer can provide us a stable tag, we can use it to merge
>>>> the DT and bindings.
>>>
>>> it's unclear to me if this series is ready to be merged. Can someone
>>> confirm? If it is, can you resend with all reviewed by tags in place?
>>
>> Are we getting a v2 for this?
>>
>
> Yes, even a v3 with reviews on all patches:
> http://lkml.kernel.org/r/20200416121910.12723-1-narmstrong@baylibre.com
In that case, can you check that I have applied everything correctly in
testing/next?
cheers
--
balbi
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] Revert "clk: rockchip: fix wrong mmc sample phase shift for rk3328"
From: Robin Murphy @ 2020-05-14 12:58 UTC (permalink / raw)
To: mturquette, sboyd, heiko; +Cc: linux-rockchip, linux-clk, linux-arm-kernel
This reverts commit 82f4b67f018c88a7cc9337f0067ed3d6ec352648.
According to a subsequent revert in the vendor kernel, the original
change was based on unclear documentation and was in fact incorrect.
Emprically, my board's SD card at 50MHz and eMMC at 200MHZ seem to get
lucky with a phase where it had no impact, but limiting the eMMC clock
to 150MHz to match the nominal limit for the I/O pins made it virtually
unusable, constantly throwing errors and retuning. With this revert, it
starts behaving perfectly at 150MHz too.
Fixes: 82f4b67f018c ("clk: rockchip: fix wrong mmc sample phase shift for rk3328")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/clk/rockchip/clk-rk3328.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3328.c b/drivers/clk/rockchip/clk-rk3328.c
index c186a1985bf4..2429b7c2a8b3 100644
--- a/drivers/clk/rockchip/clk-rk3328.c
+++ b/drivers/clk/rockchip/clk-rk3328.c
@@ -808,22 +808,22 @@ static struct rockchip_clk_branch rk3328_clk_branches[] __initdata = {
MMC(SCLK_SDMMC_DRV, "sdmmc_drv", "clk_sdmmc",
RK3328_SDMMC_CON0, 1),
MMC(SCLK_SDMMC_SAMPLE, "sdmmc_sample", "clk_sdmmc",
- RK3328_SDMMC_CON1, 0),
+ RK3328_SDMMC_CON1, 1),
MMC(SCLK_SDIO_DRV, "sdio_drv", "clk_sdio",
RK3328_SDIO_CON0, 1),
MMC(SCLK_SDIO_SAMPLE, "sdio_sample", "clk_sdio",
- RK3328_SDIO_CON1, 0),
+ RK3328_SDIO_CON1, 1),
MMC(SCLK_EMMC_DRV, "emmc_drv", "clk_emmc",
RK3328_EMMC_CON0, 1),
MMC(SCLK_EMMC_SAMPLE, "emmc_sample", "clk_emmc",
- RK3328_EMMC_CON1, 0),
+ RK3328_EMMC_CON1, 1),
MMC(SCLK_SDMMC_EXT_DRV, "sdmmc_ext_drv", "clk_sdmmc_ext",
RK3328_SDMMC_EXT_CON0, 1),
MMC(SCLK_SDMMC_EXT_SAMPLE, "sdmmc_ext_sample", "clk_sdmmc_ext",
- RK3328_SDMMC_EXT_CON1, 0),
+ RK3328_SDMMC_EXT_CON1, 1),
};
static const char *const rk3328_critical_clocks[] __initconst = {
--
2.23.0.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
From: Alexandre Torgue @ 2020-05-14 12:52 UTC (permalink / raw)
To: Linus Walleij, dillon.minfei
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Maxime Coquelin, Dave Airlie, Michael Turquette,
linux-kernel@vger.kernel.org, open list:DRM PANEL DRIVERS,
linux-clk, Stephen Boyd, Rob Herring, thierry.reding@gmail.com,
Daniel Vetter, Sam Ravnborg, linux-stm32, Linux ARM
In-Reply-To: <CACRpkda5VjjBdbruXTi33QBNb=VU6vK2zDE8yyQXoWw7=NQFeg@mail.gmail.com>
On 5/14/20 10:24 AM, Linus Walleij wrote:
> On Tue, May 12, 2020 at 9:04 AM <dillon.minfei@gmail.com> wrote:
>
>> From: dillon min <dillon.minfei@gmail.com>
>>
>> Enable the ltdc & ili9341 on stm32429-disco board.
>>
>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
>
> This mostly looks good but...
>
>> +&spi5 {
>> + status = "okay";
>> + pinctrl-0 = <&spi5_pins>;
>> + pinctrl-names = "default";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + cs-gpios = <&gpioc 2 GPIO_ACTIVE_LOW>;
>> + dmas = <&dma2 3 2 0x400 0x0>,
>> + <&dma2 4 2 0x400 0x0>;
>> + dma-names = "rx", "tx";
>
> These DMA assignments seem to be SoC things and should
> rather be in the DTS(I) file where &spi5 is defined, right?
> stm32f429.dtsi I suppose?
I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
doesn't want to use it, we use the "delete-property".
>
> It is likely the same no matter which device is using spi5.
>
> Yours,
> Linus Walleij
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] firmware: arm-smccc: define identifier for Arm SMCCC v1.2
From: Etienne Carriere @ 2020-05-14 12:52 UTC (permalink / raw)
To: Steven Price
Cc: Mark Rutland, lorenzo.pieralisi, maz, linux-kernel,
alexios.zavras, Sudeep Holla, Thomas Gleixner, will,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <b8661499-6ecc-2adc-9ed6-b7c428a8aa35@arm.com>
On Thu, 14 May 2020 at 14:38, Steven Price <steven.price@arm.com> wrote:
>
> On 14/05/2020 09:21, Etienne Carriere wrote:
> > Define identifier value reported by secure firmware when its
> > supports Arm SMCCC specification v1.2.
> >
> > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
>
> FYI Sudeep has already posted a patch to do this[1].
>
> Steve
Thanks. I'll follow the thread.
Regards
Etienne
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20200430114814.14116-3-sudeep.holla@arm.com/
>
> > ---
> > include/linux/arm-smccc.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index 59494df0f55b..1cf221f3f07a 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -56,6 +56,7 @@
> >
> > #define ARM_SMCCC_VERSION_1_0 0x10000
> > #define ARM_SMCCC_VERSION_1_1 0x10001
> > +#define ARM_SMCCC_VERSION_1_2 0x10002
> >
> > #define ARM_SMCCC_VERSION_FUNC_ID \
> > ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] iommu/sun50i: Use __GFP_ZERO instead of memset()
From: Joerg Roedel @ 2020-05-14 12:46 UTC (permalink / raw)
To: Maxime Ripard
Cc: jroedel, joro, iommu, linux-kernel, Chen-Yu Tsai, Maxime Ripard,
linux-arm-kernel
In-Reply-To: <20200514124621.25999-1-joro@8bytes.org>
From: Joerg Roedel <jroedel@suse.de>
Allocate zeroed memory so there is no need to memset it to 0 in the
driver.
Cc: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
drivers/iommu/sun50i-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index a52f52eff7c8..9c763d4a8e2a 100644
--- a/drivers/iommu/sun50i-iommu.c
+++ b/drivers/iommu/sun50i-iommu.c
@@ -616,11 +616,10 @@ static struct iommu_domain *sun50i_iommu_domain_alloc(unsigned type)
iommu_get_dma_cookie(&sun50i_domain->domain))
goto err_free_domain;
- sun50i_domain->dt = (u32 *)__get_free_pages(GFP_KERNEL,
+ sun50i_domain->dt = (u32 *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
get_order(DT_SIZE));
if (!sun50i_domain->dt)
goto err_put_cookie;
- memset(sun50i_domain->dt, 0, DT_SIZE);
refcount_set(&sun50i_domain->refcnt, 1);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] iommu/sun50i: Fix compile warnings
From: Joerg Roedel @ 2020-05-14 12:46 UTC (permalink / raw)
To: Maxime Ripard
Cc: jroedel, joro, iommu, linux-kernel, Chen-Yu Tsai, Maxime Ripard,
linux-arm-kernel
From: Joerg Roedel <jroedel@suse.de>
A few compile warnings show up when building this driver:
CC drivers/iommu/sun50i-iommu.o
drivers/iommu/sun50i-iommu.c: In function ‘sun50i_dte_get_page_table’:
drivers/iommu/sun50i-iommu.c:486:16: warning: unused variable ‘flags’ [-Wunused-variable]
486 | unsigned long flags;
| ^~~~~
drivers/iommu/sun50i-iommu.c: In function ‘sun50i_iommu_unmap’:
drivers/iommu/sun50i-iommu.c:559:23: warning: unused variable ‘iommu’ [-Wunused-variable]
559 | struct sun50i_iommu *iommu = sun50i_domain->iommu;
| ^~~~~
drivers/iommu/sun50i-iommu.c: In function ‘sun50i_iommu_probe_device’:
drivers/iommu/sun50i-iommu.c:749:22: warning: unused variable ‘group’ [-Wunused-variable]
749 | struct iommu_group *group;
| ^~~~~
Remove the unused variables.
Cc: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
drivers/iommu/sun50i-iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index 989d87aa4426..a52f52eff7c8 100644
--- a/drivers/iommu/sun50i-iommu.c
+++ b/drivers/iommu/sun50i-iommu.c
@@ -483,7 +483,6 @@ static u32 *sun50i_dte_get_page_table(struct sun50i_iommu_domain *sun50i_domain,
dma_addr_t iova, gfp_t gfp)
{
struct sun50i_iommu *iommu = sun50i_domain->iommu;
- unsigned long flags;
u32 *page_table;
u32 *dte_addr;
u32 old_dte;
@@ -556,7 +555,6 @@ static size_t sun50i_iommu_unmap(struct iommu_domain *domain, unsigned long iova
size_t size, struct iommu_iotlb_gather *gather)
{
struct sun50i_iommu_domain *sun50i_domain = to_sun50i_domain(domain);
- struct sun50i_iommu *iommu = sun50i_domain->iommu;
phys_addr_t pt_phys;
dma_addr_t pte_dma;
u32 *pte_addr;
@@ -746,7 +744,6 @@ static int sun50i_iommu_attach_device(struct iommu_domain *domain,
static struct iommu_device *sun50i_iommu_probe_device(struct device *dev)
{
struct sun50i_iommu *iommu;
- struct iommu_group *group;
iommu = sun50i_iommu_from_dev(dev);
if (!iommu)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 00/13] usb: dwc3: meson: add OTG support for GXL/GXM
From: Neil Armstrong @ 2020-05-14 12:42 UTC (permalink / raw)
To: Felipe Balbi, kishon, khilman, martin.blumenstingl
Cc: linux-amlogic, linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <87r1vm4xyq.fsf@kernel.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 2319 bytes --]
Hi,
On 14/05/2020 12:23, Felipe Balbi wrote:
> Felipe Balbi <balbi@kernel.org> writes:
>
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>
>>> The USB support was initialy done with a set of PHYs and dwc3-of-simple
>>> because the architecture of the USB complex was not understood correctly
>>> at the time (and proper documentation was missing...).
>>>
>>> But with the G12A family, the USB complex was correctly understood and
>>> implemented correctly.
>>> But seems the G12A architecture was derived for the GXL USB architecture,
>>> with minor differences and looks we can share most of the USB DWC3 glue
>>> driver.
>>>
>>> This patchset refactors and adds callbacks to handle the architecture
>>> difference while keeping the main code shared.
>>>
>>> The main difference is that on GXL/GXM the USB2 PHY control registers
>>> are mixed with the PHY registers (we already handle correctly), and
>>> the GLUE registers are allmost (99%) the same as G12A.
>>>
>>> But, the GXL/GXM HW is buggy, here are the quirks :
>>> - for the DWC2 controller to reset correctly, the GLUE mux must be switched
>>> to peripheral when the DWC2 controlle probes. For now it's handled by simply
>>> switching to device when probing the subnodes, but it may be not enough
>>> - when manually switching from Host to Device when the USB port is not
>>> populated (should not happen with proper Micro-USB/USB-C OTG switch), it
>>> makes the DWC3 to crash. The only way to avoid that is to use the Host
>>> Disconnect bit to disconnect the DWC3 controller from the port, but we can't
>>> recover the Host functionnality unless resetting the DWC3 controller.
>>> This bit is set when only manual switch is done, and a warning is printed
>>> on manual switching.
>>>
>>> The patches 1-8 should be applied first, then either waiting the next release
>>> or if the usb maintainer can provide us a stable tag, we can use it to merge
>>> the DT and bindings.
>>
>> it's unclear to me if this series is ready to be merged. Can someone
>> confirm? If it is, can you resend with all reviewed by tags in place?
>
> Are we getting a v2 for this?
>
Yes, even a v3 with reviews on all patches:
http://lkml.kernel.org/r/20200416121910.12723-1-narmstrong@baylibre.com
Neil
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: ARM: static kernel in vmalloc space
From: Arnd Bergmann @ 2020-05-14 12:41 UTC (permalink / raw)
To: afzal mohammed; +Cc: Russell King, Linux ARM, linux-kernel@vger.kernel.org
In-Reply-To: <20200514111755.GA4997@afzalpc>
On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> On Tue, May 12, 2020 at 09:49:59PM +0200, Arnd Bergmann wrote:
>
> > Any idea which bit you want to try next?
>
> My plan has been to next post patches for the static kernel migration
> to vmalloc space (currently the code is rigid, taking easy route
> wherever possible & not of high quality) as that feature has an
> independent existence & adds value by itself. And then start working
> on other steps towards VMSPLIT_4G_4G.
>
> Now that you mentioned about other things, i will slowly start those
> as well.
Sounds good.
> > Creating a raw_copy_{from,to}_user()
> > based on get_user_pages()/kmap_atomic()/memcpy() is probably a good
> > next thing to do. I think it can be done one page at a time with only
> > checking for
> > get_fs(), access_ok(), and page permissions, while get_user()/put_user()
> > need to handle a few more corner cases.
>
> Before starting w/ other things, i would like to align on the high
> level design,
>
> My understanding (mostly based on your comments) as follows,
> (i currently do not have a firm grip over these things, hope to have
> it once started w/ the implementation)
>
> 1. SoC w/ LPAE
> 2. TTBR1 (top 256MB) for static kernel, modules, io mappings, vmalloc,
> kmap, fixmap & vectors
Right, these kind of go together because pre-LPAE cannot do the
same TTBR1 split, and they more frequently have conflicting
static mappings.
It's clearly possible to do something very similar for older chips
(v6 or v7 without LPAE, possibly even v5), it just gets harder
while providing less benefit.
> 3. TTBR0 (low 3768MB) for user space & lowmem (kernel lowmem to have
> separate ASID)
Right. This could in theory become a boot-time decision, using
a larger TTBR1 on machines that want more vmalloc space, but a
hardcoded 3840/256 split is likely the best compromise of all the
constraints.
> 4. for user space to/from copy
> a. pin user pages
> b. kmap user page (can't corresponding lowmem be used instead ?)
> c. copy
Right, this is probably the simplest and most generic implementation,
it can even be in an architecture-independent lib/uaccess-generic
file.
These are the trade-offs I see:
- we can have optimizations for get_user/put_user or small copy_from_user
based on ttbr0 switching, but large copies should probably use the pinned
page approach anyway, and it's easier to only have one method to
start with, and then measure the overhead before starting to optimize.
- In the long run, there is no need for kmap()/kmap_atomic() after
highmem gets removed from the kernel, but for the next few years
we should still assume that highmem can be used, in order to support
systems like the 8GB highbank, armadaxp, keystone2 or virtual
machines. For lowmem pages (i.e. all pages when highmem is
disabled), kmap_atomic() falls back to page_address() anyway,
so there is no much overhead.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/5] iommu: Add Allwinner H6 IOMMU driver
From: Joerg Roedel @ 2020-05-14 12:38 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, iommu, Maxime Ripard, Chen-Yu Tsai,
Rob Herring, Frank Rowand, linux-arm-kernel
In-Reply-To: <cover.b27dedd61e008ffcf55a028ccddda3bb4d21dfc8.1589378833.git-series.maxime@cerno.tech>
On Wed, May 13, 2020 at 04:07:19PM +0200, Maxime Ripard wrote:
> Maxime Ripard (5):
> dt-bindings: iommu: Add Allwinner H6 IOMMU bindings
> dt-bindings: display: sun8i-mixer: Allow for an iommu property
> iommu: Add Allwinner H6 IOMMU driver
> arm64: dts: allwinner: h6: Add IOMMU
> drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
Applied all to the IOMMU tree, thanks. The code lives in the
arm/allwinner branch. Please use 'iommu/sun50i: <Capital Letter>...' as
the pattern for your future subject lines when changing the driver.
I also have two fixes on-top which I will send out shortly and add to
that branch.
Regards,
Joerg
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/6] Add Stinger96 and IoT Box board support
From: Alexandre Torgue @ 2020-05-14 12:38 UTC (permalink / raw)
To: mani, robh+dt, mcoquelin.stm32
Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20200503154215.23654-1-mani@kernel.org>
Hi Mani
On 5/3/20 5:42 PM, mani@kernel.org wrote:
> From: Manivannan Sadhasivam <mani@kernel.org>
>
> Hello,
>
> This series adds Stinger96 and IoT Box board support. These boards are
> based on STM32MP157A SoC, designed and manufactured by Shiratech solutions.
>
> The Stinger96 is a base board (96Boards IoT Extended edition) while IoT Box
> adds one mezzanine on top of it and sold as a gateway device.
>
> This series depends on below patchsets already submitted and gone through
> reviews:
>
> [PATCH v3 0/3] Add Reset and Wakeup support for CCS811
> [PATCH v3 0/2] Add CTS/RTS gpio support to STM32 UART
>
> More information about these boards can be found in below links:
>
> https://www.shiratech-solutions.com/products/stinger96/
> https://www.shiratech-solutions.com/products/iot-box/
>
> Thanks,
> Mani
>
Series applied on stm32-next.
Regards
Alex
> Changes in v2:
>
> * Used "stm32" prefix for all DT commits
> * Dropped custom sdmmc2 pinctrl node since existing node itself has pullup
> enabled and works fine.
>
> Manivannan Sadhasivam (6):
> dt-bindings: Add vendor prefix for Shiratech Solutions
> ARM: dts: stm32: Add missing pinctrl entries for STM32MP15
> dt-bindings: arm: stm32: Document Stinger96 compatible
> ARM: dts: stm32: Add Stinger96 board support
> dt-bindings: arm: stm32: Document IoT Box compatible
> ARM: dts: stm32: Add IoT Box board support
>
> .../devicetree/bindings/arm/stm32/stm32.yaml | 2 +
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 64 ++++
> arch/arm/boot/dts/stm32mp157a-iot-box.dts | 68 ++++
> arch/arm/boot/dts/stm32mp157a-stinger96.dts | 12 +
> arch/arm/boot/dts/stm32mp157a-stinger96.dtsi | 342 ++++++++++++++++++
> 7 files changed, 492 insertions(+)
> create mode 100644 arch/arm/boot/dts/stm32mp157a-iot-box.dts
> create mode 100644 arch/arm/boot/dts/stm32mp157a-stinger96.dts
> create mode 100644 arch/arm/boot/dts/stm32mp157a-stinger96.dtsi
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] firmware: arm-smccc: define identifier for Arm SMCCC v1.2
From: Steven Price @ 2020-05-14 12:38 UTC (permalink / raw)
To: Etienne Carriere, linux-kernel
Cc: mark.rutland, lorenzo.pieralisi, maz, alexios.zavras,
Sudeep Holla, tglx, will, linux-arm-kernel
In-Reply-To: <20200514082109.27573-1-etienne.carriere@linaro.org>
On 14/05/2020 09:21, Etienne Carriere wrote:
> Define identifier value reported by secure firmware when its
> supports Arm SMCCC specification v1.2.
>
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
FYI Sudeep has already posted a patch to do this[1].
Steve
[1]
https://lore.kernel.org/linux-arm-kernel/20200430114814.14116-3-sudeep.holla@arm.com/
> ---
> include/linux/arm-smccc.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 59494df0f55b..1cf221f3f07a 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -56,6 +56,7 @@
>
> #define ARM_SMCCC_VERSION_1_0 0x10000
> #define ARM_SMCCC_VERSION_1_1 0x10001
> +#define ARM_SMCCC_VERSION_1_2 0x10002
>
> #define ARM_SMCCC_VERSION_FUNC_ID \
> ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] [RFC] genirq: Check irq_data_get_irq_chip() return value before use
From: Alexandre Torgue @ 2020-05-14 12:16 UTC (permalink / raw)
To: Marek Vasut, Thomas Gleixner, linux-arm-kernel
Cc: Marc Zyngier, Linus Walleij, Stephen Boyd, Fabien Dessenne
In-Reply-To: <d3b76d43-675b-c699-06fa-aab448504f25@denx.de>
Hi Marek
On 5/10/20 4:49 PM, Marek Vasut wrote:
> On 5/7/20 11:51 PM, Thomas Gleixner wrote:
>> Marek,
>>
>> Marek Vasut <marex@denx.de> writes:
>>> On 5/7/20 7:30 PM, Thomas Gleixner wrote:
>>>> Marek Vasut <marex@denx.de> writes:
>>>>> NOTE: I don't know whether this is a correct fix. Maybe the
>>>>> irq_data_get_irq_chip() should never return NULL, and
>>>>> I have some other issue?
>>>>
>>>> What's the callchain?
>>>
>>> Hmm, I'm currently unable to replicate it on linux-next, but on 5.4.39 I
>>> get what's at the end of the email.
>>>
>>> On next I just noticed I get i2c: Transfer while suspended, which is
>>> what I suspect would be the real root cause of my problem, and why
>>> irq_data_get_irq_chip() returns NULL?
>>
>> Looks like.
>>
>>> Unable to handle kernel NULL pointer dereference at virtual address 00000070
>>> PC is at __irq_get_irqchip_state+0x4/0x30
>>> LR is at __synchronize_hardirq+0x7c/0xe8
>>> [<c0166758>] (__irq_get_irqchip_state) from [<c0166800>] (__synchronize_hardirq+0x7c/0xe8)
>>> [<c0166800>] (__synchronize_hardirq) from [<c01668f0>] (synchronize_irq+0x2c/0x9c)
>>> [<c01668f0>] (synchronize_irq) from [<c016cba0>] (suspend_device_irqs+0xd8/0xf4)
>>> [<c016cba0>] (suspend_device_irqs) from [<c04e3388>] (dpm_suspend_noirq+0x18/0x194)
>>> [<c04e3388>] (dpm_suspend_noirq) from [<c015f174>] (suspend_devices_and_enter+0x170/0x514)
>>> [<c015f174>] (suspend_devices_and_enter) from [<c015f6f4>] (pm_suspend+0x1dc/0x278)
>>> [<c015f6f4>] (pm_suspend) from [<c015e100>] (state_store+0x9c/0xcc)
>>> [<c015e100>] (state_store) from [<c029a424>] (kernfs_fop_write+0x124/0x1e0)
>>> [<c029a424>] (kernfs_fop_write) from [<c02301c8>] (__vfs_write+0x2c/0xe8)
>>> [<c02301c8>] (__vfs_write) from [<c0231658>] (vfs_write+0x98/0xbc)
>>> [<c0231658>] (vfs_write) from [<c02317fc>] (ksys_write+0x74/0xc4)
>>> [<c02317fc>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
>>
>> I assume that the i2c controller in question tears down the interrupt on
>> suspend. The changelog of that i2c driver should give you a few hints.
>
> All right, so I found out the root cause is already fixed in next, and
> just needs to be backported to stable. I'll ping the patch author about
> that.
>
> It's this patch:
> 69269446ccbf ("mailbox: stm32-ipcc: Update wakeup management")
Just to inform you that I got same issue some times ago. As far I
understood, issue was related to the fact that we used
"dedicated_wakeup" API for Exti interrupt. Those Exti interrupts had no
parent which seems to generate this issue (sorry for the lake of details).
Adding a check is a good thing, but note that I have patches in my
backlog which change a bit hw abstraction done in Exti irqchip driver.
To better fit with HW, each Exti wakeup interrupt will have a GIC irq
parent (and issue is no more observed).
regards
Alex
> I also need to revisit the regulator suspend topic next, that seems to
> be a separate issue after all.
>
> Sorry for the noise.
>
> That said, do you want to take this patch to add the missing check
> anyway or is there a reason the check is missing ?
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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