* [PATCH v2 07/11] drm/rockchip/dsi: fix mipi display can't found at init time
From: Chris Zhong @ 2017-01-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484561311-494-1-git-send-email-zyw@rock-chips.com>
From: Mark Yao <mark.yao@rock-chips.com>
The problem is that:
mipi panel probe request mipi_dsi_host_register.
mipi host attach is call from panel device, so the defer function
always can't works.
So at the first bind time, always can't found mipi panel.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 57 +++++++++++++++++++++++-----------
1 file changed, 39 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 5e3f031..4ec82f6 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -551,11 +551,9 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
dsi->panel = of_drm_find_panel(device->dev.of_node);
if (!dsi->panel) {
DRM_ERROR("failed to find panel\n");
- return -EPROBE_DEFER;
+ return -ENODEV;
}
- drm_panel_attach(dsi->panel, &dsi->connector);
-
return 0;
}
@@ -567,6 +565,7 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host *host,
if (dsi->panel)
drm_panel_detach(dsi->panel);
+ dsi->panel = NULL;
return 0;
}
@@ -1048,6 +1047,8 @@ static int dw_mipi_dsi_register(struct drm_device *drm,
&dw_mipi_dsi_atomic_connector_funcs,
DRM_MODE_CONNECTOR_DSI);
+ drm_panel_attach(dsi->panel, &dsi->connector);
+
drm_mode_connector_attach_encoder(connector, encoder);
return 0;
@@ -1097,23 +1098,17 @@ MODULE_DEVICE_TABLE(of, dw_mipi_dsi_dt_ids);
static int dw_mipi_dsi_bind(struct device *dev, struct device *master,
void *data)
{
- const struct of_device_id *of_id =
- of_match_device(dw_mipi_dsi_dt_ids, dev);
- const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = data;
- struct dw_mipi_dsi *dsi;
+ struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
struct resource *res;
int ret;
- dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
- if (!dsi)
- return -ENOMEM;
-
- dsi->dev = dev;
- dsi->pdata = pdata;
dsi->dpms_mode = DRM_MODE_DPMS_OFF;
+ if (!dsi->panel)
+ return -EPROBE_DEFER;
+
ret = rockchip_mipi_parse_dt(dsi);
if (ret)
return ret;
@@ -1160,9 +1155,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct device *master,
pm_runtime_enable(dev);
- dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
- dsi->dsi_host.dev = dev;
- return mipi_dsi_host_register(&dsi->dsi_host);
+ return 0;
err_pllref:
clk_disable_unprepare(dsi->pllref_clk);
@@ -1174,7 +1167,6 @@ static void dw_mipi_dsi_unbind(struct device *dev, struct device *master,
{
struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
- mipi_dsi_host_unregister(&dsi->dsi_host);
pm_runtime_disable(dev);
clk_disable_unprepare(dsi->pllref_clk);
}
@@ -1186,11 +1178,40 @@ static const struct component_ops dw_mipi_dsi_ops = {
static int dw_mipi_dsi_probe(struct platform_device *pdev)
{
- return component_add(&pdev->dev, &dw_mipi_dsi_ops);
+ struct device *dev = &pdev->dev;
+ const struct of_device_id *of_id =
+ of_match_device(dw_mipi_dsi_dt_ids, dev);
+ const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
+ struct dw_mipi_dsi *dsi;
+ int ret;
+
+ dsi = devm_kzalloc(&pdev->dev, sizeof(*dsi), GFP_KERNEL);
+ if (!dsi)
+ return -ENOMEM;
+
+ dsi->dev = dev;
+ dsi->pdata = pdata;
+ dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
+ dsi->dsi_host.dev = &pdev->dev;
+
+ ret = mipi_dsi_host_register(&dsi->dsi_host);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, dsi);
+ ret = component_add(&pdev->dev, &dw_mipi_dsi_ops);
+ if (ret)
+ mipi_dsi_host_unregister(&dsi->dsi_host);
+
+ return ret;
}
static int dw_mipi_dsi_remove(struct platform_device *pdev)
{
+ struct dw_mipi_dsi *dsi = dev_get_drvdata(&pdev->dev);
+
+ if (dsi)
+ mipi_dsi_host_unregister(&dsi->dsi_host);
component_del(&pdev->dev, &dw_mipi_dsi_ops);
return 0;
}
--
2.6.3
^ permalink raw reply related
* [PATCH v2 08/11] drm/rockchip/dsi: fix the issue can not send commands
From: Chris Zhong @ 2017-01-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484561311-494-1-git-send-email-zyw@rock-chips.com>
From: xubilv <xbl@rock-chips.com>
There is a bug in hdr_write function, the value from the caller will be
overwritten, it cause the mipi can not send the correct command. And the
MIPI_DSI_GENERIC_SHORT_WRITE_n_PARAM message type should be supported.
Signed-off-by: xubilv <xbl@rock-chips.com>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 4ec82f6..4a2691c 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -572,10 +572,12 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host *host,
static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 val)
{
int ret;
+ u32 sts;
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
- val, !(val & GEN_CMD_FULL), 1000,
+ sts, !(sts & GEN_CMD_FULL), 1000,
CMD_PKT_STATUS_TIMEOUT_US);
+
if (ret < 0) {
dev_err(dsi->dev, "failed to get available command FIFO\n");
return ret;
@@ -584,8 +586,9 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 val)
dsi_write(dsi, DSI_GEN_HDR, val);
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
- val, val & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
+ sts, sts & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
1000, CMD_PKT_STATUS_TIMEOUT_US);
+
if (ret < 0) {
dev_err(dsi->dev, "failed to write command FIFO\n");
return ret;
@@ -594,8 +597,8 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 val)
return 0;
}
-static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
- const struct mipi_dsi_msg *msg)
+static int dw_mipi_dsi_short_write(struct dw_mipi_dsi *dsi,
+ const struct mipi_dsi_msg *msg)
{
const u16 *tx_buf = msg->tx_buf;
u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
@@ -609,13 +612,14 @@ static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
}
-static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
- const struct mipi_dsi_msg *msg)
+static int dw_mipi_dsi_long_write(struct dw_mipi_dsi *dsi,
+ const struct mipi_dsi_msg *msg)
{
const u32 *tx_buf = msg->tx_buf;
int len = msg->tx_len, pld_data_bytes = sizeof(*tx_buf), ret;
u32 val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
u32 remainder = 0;
+ u32 sts = 0;
if (msg->tx_len < 3) {
dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
@@ -635,7 +639,7 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
}
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
- val, !(val & GEN_PLD_W_FULL), 1000,
+ sts, !(sts & GEN_PLD_W_FULL), 1000,
CMD_PKT_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev,
@@ -656,11 +660,15 @@ static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM:
case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
- ret = dw_mipi_dsi_dcs_short_write(dsi, msg);
+ ret = dw_mipi_dsi_short_write(dsi, msg);
break;
case MIPI_DSI_DCS_LONG_WRITE:
- ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
+ case MIPI_DSI_GENERIC_LONG_WRITE:
+ ret = dw_mipi_dsi_long_write(dsi, msg);
break;
default:
dev_err(dsi->dev, "unsupported message type\n");
--
2.6.3
^ permalink raw reply related
* [PATCH v2 09/11] drm/rockchip/dsi: decrease the value of Ths-prepare
From: Chris Zhong @ 2017-01-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484561311-494-1-git-send-email-zyw@rock-chips.com>
From: xubilv <xbl@rock-chips.com>
Signed-off-by: xubilv <xbl@rock-chips.com>
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 4a2691c..f50909e 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -455,7 +455,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
BANDGAP_SEL(BANDGAP_96_10));
dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | 0xf);
- dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | 0x55);
+ dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | 0x2d);
dw_mipi_dsi_phy_write(dsi, 0x72, THS_ZERO_PROGRAM_EN | 0xa);
dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
--
2.6.3
^ permalink raw reply related
* [PATCH v2 10/11] drm/rockchip/dsi: fix phy clk lane stop state timeout
From: Chris Zhong @ 2017-01-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484561311-494-1-git-send-email-zyw@rock-chips.com>
Before phy init, the detection of phy state should be controlled
manually. After that, we can switch the detection to hardward,
it is automatic. Hence move PHY_TXREQUESTCLKHS setting to the end
of phy init.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f50909e..9dfa73d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -475,6 +475,8 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dev_err(dsi->dev,
"failed to wait for phy clk lane stop state\n");
+ dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
+
phy_init_end:
if (!IS_ERR(dsi->phy_cfg_clk))
clk_disable_unprepare(dsi->phy_cfg_clk);
@@ -721,7 +723,6 @@ static void dw_mipi_dsi_init(struct dw_mipi_dsi *dsi)
| PHY_RSTZ | PHY_SHUTDOWNZ);
dsi_write(dsi, DSI_CLKMGR_CFG, TO_CLK_DIVIDSION(10) |
TX_ESC_CLK_DIVIDSION(7));
- dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
}
static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi,
--
2.6.3
^ permalink raw reply related
* [PATCH v2 11/11] drm/rockchip/dsi: fix insufficient bandwidth of some panel
From: Chris Zhong @ 2017-01-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484561311-494-1-git-send-email-zyw@rock-chips.com>
Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
for some panel, it will cause the screen display is not normal, so
increases the badnwidth to 1 / 0.8.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9dfa73d..5a973fe 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -501,8 +501,8 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);
if (mpclk) {
- /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
- tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
+ /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
+ tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;
if (tmp < max_mbps)
target_mbps = tmp;
else
--
2.6.3
^ permalink raw reply related
* [Question] A question about arm64 pte
From: Yisheng Xie @ 2017-01-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
hi,
I have question about arm64 pte.
For arm64, PTE_WRITE?== PTE_DBM? is to mark whether the page is writable,
and PTE_DIRTY is to mark whether the page is dirty.
However, PTE_RDONLY is only cleared when both PTE_WRITE and PTE_DIRTY are set.
Is that means that the page is still writable when PTE_RDONLY is set with PTE_WRITE?
But in ARM Architecture Reference Manual for ARMv8,
when PTE_RDONLY is set(AP[2:1] = 0b1x), Acess from EL1 is Ready only?
so what is the really means of the PTE_RDONLY? could some one help to explain it?
Thanks
Yisheng Xie
^ permalink raw reply
* [PATCH] rtc: stm32: fix comparison warnings
From: Amelie Delaunay @ 2017-01-16 10:08 UTC (permalink / raw)
To: linux-arm-kernel
This patches fixes comparison between signed and unsigned values as it
could produce an incorrect result when the signed value is converted to
unsigned:
drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_valid_alrm':
drivers/rtc/rtc-stm32.c:404:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if ((((tm->tm_year > cur_year) &&
...
It also fixes comparison always true or false due to the fact that unsigned
value is compared against zero with >= or <:
drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_init':
drivers/rtc/rtc-stm32.c:514:35: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
for (pred_a = pred_a_max; pred_a >= 0; pred_a-- ) {
drivers/rtc/rtc-stm32.c:530:44: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
(rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
drivers/rtc/rtc-stm32.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
index 03c97c1..bd57eb1 100644
--- a/drivers/rtc/rtc-stm32.c
+++ b/drivers/rtc/rtc-stm32.c
@@ -383,7 +383,7 @@ static int stm32_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
static int stm32_rtc_valid_alrm(struct stm32_rtc *rtc, struct rtc_time *tm)
{
- unsigned int cur_day, cur_mon, cur_year, cur_hour, cur_min, cur_sec;
+ int cur_day, cur_mon, cur_year, cur_hour, cur_min, cur_sec;
unsigned int dr = readl_relaxed(rtc->base + STM32_RTC_DR);
unsigned int tr = readl_relaxed(rtc->base + STM32_RTC_TR);
@@ -509,7 +509,7 @@ static int stm32_rtc_init(struct platform_device *pdev,
pred_a_max = STM32_RTC_PRER_PRED_A >> STM32_RTC_PRER_PRED_A_SHIFT;
pred_s_max = STM32_RTC_PRER_PRED_S >> STM32_RTC_PRER_PRED_S_SHIFT;
- for (pred_a = pred_a_max; pred_a >= 0; pred_a--) {
+ for (pred_a = pred_a_max; pred_a + 1 > 0; pred_a--) {
pred_s = (rate / (pred_a + 1)) - 1;
if (((pred_s + 1) * (pred_a + 1)) == rate)
@@ -525,7 +525,7 @@ static int stm32_rtc_init(struct platform_device *pdev,
pred_s = (rate / (pred_a + 1)) - 1;
dev_warn(&pdev->dev, "ck_rtc is %s\n",
- (rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
+ (rate < ((pred_a + 1) * (pred_s + 1))) ?
"fast" : "slow");
}
--
1.9.1
^ permalink raw reply related
* [PATCH 03/10] devicetree: bindings: add bindings for ahci-da850
From: Bartosz Golaszewski @ 2017-01-16 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <35ff358d-9b17-b2be-38d8-6a51cdddc1a1@lechnology.com>
2017-01-13 20:25 GMT+01:00 David Lechner <david@lechnology.com>:
> On 01/13/2017 06:37 AM, Bartosz Golaszewski wrote:
>>
>> Add DT bindings for the TI DA850 AHCI SATA controller.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> .../devicetree/bindings/ata/ahci-da850.txt | 21
>> +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> b/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> new file mode 100644
>> index 0000000..d07c241
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> @@ -0,0 +1,21 @@
>> +Device tree binding for the TI DA850 AHCI SATA Controller
>> +---------------------------------------------------------
>> +
>> +Required properties:
>> + - compatible: must be "ti,da850-ahci"
>> + - reg: physical base addresses and sizes of the controller's register
>> areas
>> + - interrupts: interrupt specifier (refer to the interrupt binding)
>> +
>> +Optional properties:
>> + - clocks: clock specifier (refer to the common clock binding)
>> + - da850,clk_multiplier: the multiplier for the reference clock needed
>> + for 1.5GHz PLL output
>
>
> A clock multiplier property seems redundant if you are specifying a clock.
> It should be possible to get the rate from the clock to determine which
> multiplier is needed.
>
I probably should have named it differently. This is not a multiplier
of a clock derived from PLL0 or PLL1. Instead it's a value set by
writing to the Port PHY Control Register (MPY bits) of the SATA
controller that configures the multiplier for the external low-jitter
clock. On the lcdk the signals (REFCLKP, REFCLKN) are provided by
CDCM61001 (SATA OSCILLATOR component on the schematics).
I'll find a better name and comment the property accordingly.
FYI: the da850 platform does not use the common clock framework, so I
don't specify the clock property on the sata node in the device tree.
Instead I add the clock lookup entry in patch [01/10]. This is
transparent for AHCI which can get the clock as usual by calling
clk_get() in ahci_platform_get_resources().
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH 06/10] sata: ahci_da850: implement a softreset quirk
From: Bartosz Golaszewski @ 2017-01-16 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115231208.GD14446@mtj.duckdns.org>
2017-01-16 0:12 GMT+01:00 Tejun Heo <tj@kernel.org>:
> On Fri, Jan 13, 2017 at 01:38:00PM +0100, Bartosz Golaszewski wrote:
>> +static int ahci_da850_softreset(struct ata_link *link,
>> + unsigned int *class, unsigned long deadline)
>> +{
>> + int pmp, ret;
>> +
>> + pmp = sata_srst_pmp(link);
>> +
>> + ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
>> + if (pmp && ret == -EBUSY)
>> + return ahci_do_softreset(link, class, 0,
>> + deadline, ahci_check_ready);
>> +
>> + return ret;
>> +}
>
> Please add some comments explaining what's going on.
Sure, I'll add some explanation in v2.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH v2 0/4] Amlogic Meson SAR ADC support
From: Neil Armstrong @ 2017-01-16 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115224221.15510-1-martin.blumenstingl@googlemail.com>
On 01/15/2017 11:42 PM, Martin Blumenstingl wrote:
> This series add support for the SAR ADC on Amlogic Meson GXBB, GXL and
> GXM SoCs.
> The hardware on GXBB provides 10-bit ADC results, while GXL and GXM are
> providing 12-bit results. Support for older SoCs (Meson8b and Meson8)
> can be added with little effort, most of which is testing I guess (I
> don't have any pre-GXBB hardware so I can't say).
>
> A new set of clocks had to be added to the GXBB clock controller (used
> by the GXBB/GXL/GXM SoCs) which are required to get the ADC working.
>
> The ADC itself can sample multiple channels at the same time and allows
> capturing multiple samples (which can be used for filtering/averaging).
> The ADC results are stored inside a FIFO register. More details on what
> the driver supports (or doesn't) can be found in the description of
> patch #3.
>
> The code is based on the public S805 (Meson8b) and S905 (GXBB)
> datasheets, as well as by reading (various versions of) the vendor
> driver and by inspecting the registers on the vendor kernels of my
> testing-hardware.
>
> Typical use-cases for the ADC on the Meson GX SoCs are:
> - adc-keys ("ADC attached resistor ladder buttons")
> - SoC temperature measurement (not supported by this driver yet as
> the system firmware does this already and provides the values via the
> SCPI protocol)
> - "version-strapping" (different resistor values are used to indicate
> the board-revision)
> - and of course typical ADC measurements
>
> Thanks to Heiner Kallweit, Jonathan Cameron and Lars-Peter Clausen for
> reviewing this series and providing valuable input!
>
> Changes since v1 (all changes are for patch #3, except where noted):
> - fix IRQ number in meson-gx.dtsi (thanks to Heiner Kallweit for
> providing the correct value), affects patch #4
> - move the most used members of meson_saradc_priv to the beginning
> - remove unused struct member "completion" from meson_saradc_priv
> - use devm_kasprintf() instead of snprintf() + devm_kstrdup()
> - initialize indio_dev->dev.parent earlier in meson_saradc_probe()
> - moved meson_saradc_clear_fifo() logic to a separate function
> - add comment why a do ... while loop is required in
> meson_saradc_wait_busy_clear()
> - remove SAR_ADC_NUM_CHANNELS and SAR_ADC_VALUE_MASK macros (each of them
> was only used once and it's an unneeded level of abstraction)
> - fixed multiline comment syntax violations
> - dropped unneeded log messages during initialization
> - set iio_dev name to "meson-gxbb-saradc" or "meson-gxl-saradc"
> - use "indio_dev->dev.parent" in all kernel log calls (dev_warn/err/etc)
> to make it show the OF node name (instead of the iio device name)
> - introduce struct meson_saradc_data to hold platform-specific
> information (such as resolution in bits and the iio_dev name)
>
>
> Martin Blumenstingl (4):
> Documentation: dt-bindings: add the Amlogic Meson SAR ADC
> documentation
> clk: gxbb: add the SAR ADC clocks and expose them
> iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs
> ARM64: dts: meson: meson-gx: add the SAR ADC
>
> .../bindings/iio/adc/amlogic,meson-saradc.txt | 31 +
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 +
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 10 +
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 10 +
> drivers/clk/meson/gxbb.c | 48 ++
> drivers/clk/meson/gxbb.h | 9 +-
> drivers/iio/adc/Kconfig | 12 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/meson_saradc.c | 893 +++++++++++++++++++++
> include/dt-bindings/clock/gxbb-clkc.h | 4 +
> 10 files changed, 1023 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> create mode 100644 drivers/iio/adc/meson_saradc.c
>
Good work martin !
Tested on the P200 board with the resistor ladderred key matrix, patch will be posted shortly.
For all the serie :
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH] ARM64: meson-gxbb-p200: add ADC laddered keys
From: Neil Armstrong @ 2017-01-16 10:22 UTC (permalink / raw)
To: linux-arm-kernel
Add the 5 buttons connected to a resistor laddered matrix and sampled
by the SAR ADC channel 0.
Only the p200 board has these buttons, the P201 doesn't.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 50 +++++++++++++++++++++++++
1 file changed, 50 insertions(+)
This patch depends on Martin Blumenstingl's sar adc patchset at [1].
[1] http://lkml.kernel.org/r/20170115224221.15510-1-martin.blumenstingl at googlemail.com
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
index af7b151..3051cc8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
@@ -45,6 +45,7 @@
/dts-v1/;
#include "meson-gxbb-p20x.dtsi"
+#include <dt-bindings/input/input.h>
/ {
compatible = "amlogic,p200", "amlogic,meson-gxbb";
@@ -58,6 +59,50 @@
*/
linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
};
+
+ avdd18_usb_adc: regulator-avdd18_usb_adc {
+ compatible = "regulator-fixed";
+ regulator-name = "AVDD18_USB_ADC";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ adc_keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ press-threshold-microvolt = <900000>; /* 50% */
+ };
+
+ button-esc {
+ label = "Esc";
+ linux,code = <KEY_ESC>;
+ press-threshold-microvolt = <684000>; /* 38% */
+ };
+
+ button-up {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ press-threshold-microvolt = <468000>; /* 26% */
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = <KEY_VOLUMEDOWN>;
+ press-threshold-microvolt = <252000>; /* 14% */
+ };
+
+ button-menu {
+ label = "Menu";
+ linux,code = <KEY_MENU>;
+ press-threshold-microvolt = <0>; /* 0% */
+ };
+ };
};
&i2c_B {
@@ -65,3 +110,8 @@
pinctrl-0 = <&i2c_b_pins>;
pinctrl-names = "default";
};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&avdd18_usb_adc>;
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 09/37] PCI: dwc: designware: Parse *num-lanes* property in dw_pcie_setup_rc
From: Joao Pinto @ 2017-01-16 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587C57FD.7050601@ti.com>
Hi,
?s 5:19 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
> Hi,
>
> On Friday 13 January 2017 10:43 PM, Joao Pinto wrote:
>> Hi,
>>
>> ?s 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
>>> *num-lanes* dt property is parsed in dw_pcie_host_init. However
>>> *num-lanes* property is applicable to both root complex mode and
>>> endpoint mode. As a first step, move the parsing of this property
>>> outside dw_pcie_host_init. This is in preparation for splitting
>>> pcie-designware.c to pcie-designware.c and pcie-designware-host.c
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> drivers/pci/dwc/pcie-designware.c | 18 +++++++++++-------
>>> drivers/pci/dwc/pcie-designware.h | 1 -
>>> 2 files changed, 11 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/pci/dwc/pcie-designware.c b/drivers/pci/dwc/pcie-designware.c
>>> index 00a0fdc..89cdb6b 100644
>>> --- a/drivers/pci/dwc/pcie-designware.c
>>> +++ b/drivers/pci/dwc/pcie-designware.c
>>> @@ -551,10 +551,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>>> }
>>> }
>>>
>>> - ret = of_property_read_u32(np, "num-lanes", &pci->lanes);
>>> - if (ret)
>>> - pci->lanes = 0;
>>> -
>>> ret = of_property_read_u32(np, "num-viewport", &pci->num_viewport);
>>> if (ret)
>>> pci->num_viewport = 2;
>>> @@ -751,18 +747,26 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
>>>
>>> void dw_pcie_setup_rc(struct pcie_port *pp)
>>> {
>>> + int ret;
>>> + u32 lanes;
>>> u32 val;
>>> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>>> + struct device *dev = pci->dev;
>>> + struct device_node *np = dev->of_node;
>>>
>>> /* get iATU unroll support */
>>> pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
>>> dev_dbg(pci->dev, "iATU unroll: %s\n",
>>> pci->iatu_unroll_enabled ? "enabled" : "disabled");
>>>
>>> + ret = of_property_read_u32(np, "num-lanes", &lanes);
>>> + if (ret)
>>> + lanes = 0;
>>
>> You moved from host_init to root complex setup function, which in my opinion did
>> not improve (in this scope).
>>
>> I suggest that instead of making so much intermediary patches, which is nice to
>> understand your development sequence, but hard to review. Wouldn't be better to
>> condense some of the patches? We would have a cloear vision of the final product :)
>
> I thought the other way. If squashing patches is easier to review, I'll do it.
I understand. To break it in small pieces is good to understand clearly what is
done and how was done, but I would break too much. That's a personal opinion of
course, lets see what others say :).
Thanks,
Joao
>
> Btw, thanks for reviewing.
>
> Cheers
> Kishon
>
^ permalink raw reply
* [v2 2/3] ARM: dts: STM32 Add USB FS host mode support
From: Bruno Herrera @ 2017-01-16 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f1fac058-6c03-595a-0d67-a89fcf70d7cc@st.com>
Hi Alex,
On Mon, Jan 16, 2017 at 6:57 AM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> Hi Bruno,
>
> On 01/16/2017 03:09 AM, Bruno Herrera wrote:
>>
>> This patch adds the USB pins and nodes for USB HS/FS cores working at FS
>> speed,
>> using embedded PHY.
>>
>> Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
>
>
> Sorry, but what is patch 1 & pacth 3 status ?
My bad, I'll add the status of the patch series version 3.
>
> For this one, can split it in 3 patches (one patch for SOC and one for each
> board) please.
>
No problem.
>
>
>> ---
>> arch/arm/boot/dts/stm32f429-disco.dts | 30 ++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/stm32f429.dtsi | 35
>> ++++++++++++++++++++++++++++++++++-
>> arch/arm/boot/dts/stm32f469-disco.dts | 30 ++++++++++++++++++++++++++++++
>> 3 files changed, 94 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
>> b/arch/arm/boot/dts/stm32f429-disco.dts
>> index 7d0415e..374c5ed 100644
>> --- a/arch/arm/boot/dts/stm32f429-disco.dts
>> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
>> @@ -88,6 +88,16 @@
>> gpios = <&gpioa 0 0>;
>> };
>> };
>> +
>> + /* This turns on vbus for otg for host mode (dwc2) */
>> + vcc5v_otg: vcc5v-otg-regulator {
>> + compatible = "regulator-fixed";
>> + gpio = <&gpioc 4 0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&usbotg_pwren_h>;
>> + regulator-name = "vcc5_host1";
>> + regulator-always-on;
>> + };
>> };
>>
>> &clk_hse {
>> @@ -99,3 +109,23 @@
>> pinctrl-names = "default";
>> status = "okay";
>> };
>> +
>> +&usbotg_hs {
>> + compatible = "st,stm32-fsotg", "snps,dwc2";
>> + dr_mode = "host";
>> + pinctrl-0 = <&usbotg_fs_pins_b>;
>> + pinctrl-names = "default";
>> + status = "okay";
>> +};
>> +
>> +&pinctrl {
>> + usb-host {
>> + usbotg_pwren_h: usbotg-pwren-h {
>> + pins {
>> + pinmux = <STM32F429_PC4_FUNC_GPIO>;
>> + bias-disable;
>> + drive-push-pull;
>> + };
>> + };
>> + };
>> +};
>
>
> Pinctrl muxing has to be defined/declared in stm32f429.dtsi
>
This is board specific logic and it vary from board to board, should
it be defined here?
>
>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> b/arch/arm/boot/dts/stm32f429.dtsi
>> index e4dae0e..bc07aa8 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -206,7 +206,7 @@
>> reg = <0x40007000 0x400>;
>> };
>>
>> - pin-controller {
>> + pinctrl: pin-controller {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "st,stm32f429-pinctrl";
>> @@ -316,6 +316,30 @@
>> };
>> };
>>
>> + usbotg_fs_pins_a: usbotg_fs at 0 {
>> + pins {
>> + pinmux =
>> <STM32F429_PA10_FUNC_OTG_FS_ID>,
>> +
>> <STM32F429_PA11_FUNC_OTG_FS_DM>,
>> +
>> <STM32F429_PA12_FUNC_OTG_FS_DP>;
>> + bias-disable;
>> + drive-push-pull;
>> + slew-rate = <2>;
>> + };
>> + };
>> +
>> + usbotg_fs_pins_b: usbotg_fs at 1 {
>> + pins {
>> + pinmux =
>> <STM32F429_PB12_FUNC_OTG_HS_ID>,
>> +
>> <STM32F429_PB14_FUNC_OTG_HS_DM>,
>> +
>> <STM32F429_PB15_FUNC_OTG_HS_DP>;
>> + bias-disable;
>> + drive-push-pull;
>> + slew-rate = <2>;
>> + };
>> + };
>> +
>> +
>> +
>> usbotg_hs_pins_a: usbotg_hs at 0 {
>> pins {
>> pinmux =
>> <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
>> @@ -420,6 +444,15 @@
>> status = "disabled";
>> };
>>
>> + usbotg_fs: usb at 50000000 {
>> + compatible = "st,stm32f4xx-fsotg", "snps,dwc2";
>> + reg = <0x50000000 0x40000>;
>> + interrupts = <67>;
>> + clocks = <&rcc 0 39>;
>> + clock-names = "otg";
>> + status = "disabled";
>> + };
>> +
>> rng: rng at 50060800 {
>> compatible = "st,stm32-rng";
>> reg = <0x50060800 0x400>;
>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>> b/arch/arm/boot/dts/stm32f469-disco.dts
>> index 8877c00..8ae6763 100644
>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> @@ -68,6 +68,17 @@
>> soc {
>> dma-ranges = <0xc0000000 0x0 0x10000000>;
>> };
>> +
>> + /* This turns on vbus for otg for host mode (dwc2) */
>> + vcc5v_otg: vcc5v-otg-regulator {
>> + compatible = "regulator-fixed";
>> + enable-active-high;
>> + gpio = <&gpiob 2 0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&usbotg_pwren_h>;
>> + regulator-name = "vcc5_host1";
>> + regulator-always-on;
>> + };
>> };
>>
>> &rcc {
>> @@ -81,3 +92,22 @@
>> &usart3 {
>> status = "okay";
>> };
>> +
>> +&usbotg_fs {
>> + dr_mode = "host";
>> + pinctrl-0 = <&usbotg_fs_pins_a>;
>> + pinctrl-names = "default";
>> + status = "okay";
>> +};
>> +
>> +&pinctrl {
>> + usb-host {
>> + usbotg_pwren_h: usbotg-pwren-h {
>> + pins {
>> + pinmux = <STM32F429_PB2_FUNC_GPIO>;
>> + bias-disable;
>> + drive-push-pull;
>> + };
>> + };
>> + };
>> +};
>
> Same. Note that if you have 2 configuration for one feature (like it is here
> for "usbotg_pwren_h"), you could index it. Not that I'm adding a dedidacted
> pinctroller for stm32f469.
>
Sorry, but I dont know what you mean by index here.
The usbotg_pwren_h (VBUS ENABLE) is attached in different port/pins
for each board.
Br.,
> Br
> Alex
>>
>>
>
>
^ permalink raw reply
* [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-16 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <612bc7bc-4ee4-51c0-d7ac-06151854ac03@suse.de>
On 01/15/2017 04:44 PM, Andreas F?rber wrote:
> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>> it really makes a difference if we write
>>
>> memory at 0 {
>> device_type = "memory";
>> linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> or
>>
>> memory at 0 {
>> device_type = "memory";
>> reg = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> The second version leads to failure of the Odroid C2.
>>
>> When I looked at /sys/firmware/fdt I saw this difference:
>>
>> --- fails
>> +++ works
>>
>> memory at 0 {
>> - device_type = "memory";
>> reg = <0x0 0x0 0x0 0x78000000>;
>> + device_type = "memory";
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> I found the following sentence in the NXP forum:
>> In case you want to overwrite the memory usage passed from u-boot, you
>> can use "linux,usable-memory".
>> https://community.nxp.com/thread/382284
>
> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
> instead of forcing the creation of unnecessary new .dts files onto
> everyone due to hardcoded linux,usable-memory properties. In fact, it
> already reserves 0x1000000, so it seems you are merely using an older
> U-Boot.
>
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
>
> I would bet that the upper limit is unrelated here.
>
> Regards,
> Andreas
>
Hi Andreas,
I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
a lot of u-boot version in the field, and the Odroid-C2 is part of this.
Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
Neil
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: used managed kasprintf
From: Felipe Balbi @ 2017-01-16 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB023508B@AcuExch.aculab.com>
Hi,
David Laight <David.Laight@ACULAB.COM> writes:
> From: Alexandre Belloni
>> Sent: 02 December 2016 16:19
>> On 02/12/2016 at 15:59:57 +0000, David Laight wrote :
>> > From: Alexandre Belloni
>> > > Sent: 01 December 2016 10:27
>> > > Use devm_kasprintf instead of simple kasprintf to free the allocated memory
>> > > when needed.
>> >
>> > s/when needed/when the device is freed/
>> >
>> > > Suggested-by: Peter Rosin <peda@axentia.se>
>> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> > > ---
>> > > drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
>> > > 1 file changed, 2 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> > > index 45bc997d0711..aec72fe8273c 100644
>> > > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
>> > > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> > > @@ -1978,7 +1978,8 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
>> > > dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
>> > > goto err;
>> > > }
>> > > - ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
>> > > + ep->ep.name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "ep%d",
>> > > + ep->index);
>> >
>> > Acually why bother mallocing such a small string at all.
>> > The maximum length is 12 bytes even if 'index' are unrestricted.
>> >
>>
>> IIRC, using statically allocated string is failing somewhere is the USB
>> core but I don't remember all the details.
>
> I can't imagine that changing ep->ep.name from 'char *' to 'char [12]' would
> make any difference.
the actual name is managed by the UDC. Meaning, ep->ep.name should be a
pointer, but it could very well just point to ep->name which would be
char [12].
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170116/9893a195/attachment.sig>
^ permalink raw reply
* [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files
From: Joao Pinto @ 2017-01-16 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587C586C.6070003@ti.com>
Hi,
?s 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
> Hi Joao,
>
> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote:
>> ?s 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
>>> Split pcie-designware.c into pcie-designware-host.c that contains
>>> the host specific parts of the driver and pcie-designware.c that
>>> contains the parts used by both host driver and endpoint driver.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> drivers/pci/dwc/Makefile | 2 +-
>>> drivers/pci/dwc/pcie-designware-host.c | 619 ++++++++++++++++++++++++++++++++
>>> drivers/pci/dwc/pcie-designware.c | 613 +------------------------------
>>> drivers/pci/dwc/pcie-designware.h | 8 +
>>> 4 files changed, 634 insertions(+), 608 deletions(-)
>>> create mode 100644 drivers/pci/dwc/pcie-designware-host.c
>>>
>>> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
>>> index 7d27c14..3b57e55 100644
>>> --- a/drivers/pci/dwc/Makefile
>>> +++ b/drivers/pci/dwc/Makefile
>>> @@ -1,4 +1,4 @@
>>
>> (snip...)
>>
>>> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>> - int type, u64 cpu_addr, u64 pci_addr,
>>> - u32 size)
>>> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
>>> + u64 cpu_addr, u64 pci_addr, u32 size)
>>> {
>>> u32 retries, val;
>>>
>>> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>> dev_err(pci->dev, "iATU is not being enabled\n");
>>> }
>>
>> Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
>> the pcie-designware-host.
>
> That is not true. Outbound ATU should be programmed to access host side buffers
> and inbound ATU should be programmed for the host to access EP mem space.
Sorry, I was not clear enough. What I was trying to suggest is, since the ATU
programming is done by the host, wouldn't be better to include it in the
pcie-designware-host? It is just an architectural detail.
>
> Thanks
> Kishon
>
^ permalink raw reply
* USB: OHCI: high softirq load
From: Antoine Aubert @ 2017-01-16 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116100220.0b00658e@bbrezillon>
Thx for your answer Boris
Le 16/01/2017 ? 10:02, Boris Brezillon a ?crit :
> Hi Antoine,
>
> On Mon, 16 Jan 2017 08:45:58 +0100
> Antoine Aubert <a.aubert@overkiz.com> wrote:
>
>> Hi,
>>
>> Im working on a AT91SAM9G25cu board
>> (arch/arm/boot/dts/at91-kizboxmini.dts). We use linux-4.1.31, and when
>> OHCI is enabled, I got some wired effects.
> Can you test on a more recent kernel (4.9 or 4.10-rc4)?
I'll give a try, just need little time ;)
>
>> eg with 3 FTDI pluged, interrupts: more than 3.5k/s, cpu softirq > 24%,
>> loadavg > 0.5
> Can you check which interrupt is triggered (cat /proc/interrupts),
cat /proc/interrupts
CPU0
16: 2286 atmel-aic 1 Level pmc, at91_tick, at91_rtc, ttyS0
17: 0 PMC 17 Level main_rc_osc
18: 0 PMC 0 Level main_osc
19: 0 PMC 16 Level mainck
20: 0 PMC 1 Level clk-plla
21: 0 PMC 6 Level clk-utmi
22: 0 PMC 3 Level clk-master
23: 945527 atmel-aic 17 Level tc_clkevt
24: 21815 atmel-aic 20 Level at_hdmac
25: 0 atmel-aic 21 Level at_hdmac
30: 120299 atmel-aic 24 Level eth0
31: 22783651 atmel-aic 22 Level ehci_hcd:usb1, ohci_hcd:usb2
99: 0 GPIO 16 Edge PB_RST
100: 0 GPIO 17 Edge PB_PROG
Err: 0
> and
> enable debug messages in drivers/usb/host/ohci-at91.c?
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.1.31 (antoine at ltp.antoine) (gcc version
4.9.2 (GCC) ) #1 Mon Jan 16 11:04:03 CET 2017
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine model: Overkiz Kizbox Mini RailDIN
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 32512
[ 0.000000] Kernel command line: panic=5 oops=panic root=ubi0:root
rootfstype=ubifs ubi.mtd=ubi rw console=ttyS0,115200 earlyprintk
loglevel=7 dyndbg='file ohci-at91.c +p'
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536
bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 125076K/131072K available (3204K kernel code,
136K rwdata, 1116K rodata, 132K init, 84K bss, 5996K reserved, 0K
cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc04404b4 (4322 kB)
[ 0.000000] .init : 0xc0441000 - 0xc0462000 ( 132 kB)
[ 0.000000] .data : 0xc0462000 - 0xc0484310 ( 137 kB)
[ 0.000000] .bss : 0xc0484310 - 0xc0499550 ( 85 kB)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] clocksource pit: mask: 0x7ffffff max_cycles: 0x7ffffff,
max_idle_ns: 7167226906 ns
[ 0.000000] sched_clock: 32 bits at 128 Hz, resolution 7812500ns,
wraps every 16777215996093750ns
[ 0.007812] Calibrating delay loop... 198.76 BogoMIPS (lpj=775168)
[ 0.078125] pid_max: default: 32768 minimum: 301
[ 0.085937] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.093750] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
bytes)
[ 0.101562] CPU: Testing write buffer coherency: ok
[ 0.101562] Setting up static identity map for 0x20008400 - 0x2000847c
[ 0.117187] dynamic_debug:ddebug_tokenize: unclosed quote: file
[ 0.125000] dynamic_debug:ddebug_exec_query: tokenize failed
[ 0.132812] devtmpfs: initialized
[ 0.164062] clocksource jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 14931722236523437 ns
[ 0.171875] pinctrl core: initialized pinctrl subsystem
[ 0.179687] NET: Registered protocol family 16
[ 0.187500] DMA: preallocated 256 KiB pool for atomic coherent
allocations
[ 0.195312] AT91: Detected SoC family: at91sam9x5
[ 0.203125] AT91: Detected SoC: at91sam9g25, revision 1
[ 0.226562] gpio-at91 fffff400.gpio: at address fefff400
[ 0.234375] gpio-at91 fffff600.gpio: at address fefff600
[ 0.242187] gpio-at91 fffff800.gpio: at address fefff800
[ 0.250000] gpio-at91 fffffa00.gpio: at address fefffa00
[ 0.257812] pinctrl-at91 ahb:apb:pinctrl at fffff400: initialized AT91
pinctrl driver
[ 0.265625] clocksource tcb_clksrc: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 114675631333 ns
[ 4.718750] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 4.726562] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 4.734375] NET: Registered protocol family 1
[ 4.742187] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 4.789062] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 4.804687] io scheduler noop registered (default)
[ 4.812500] fffff200.serial: ttyS0 at MMIO 0xfffff200 (irq = 16,
base_baud = 8333333) is a ATMEL_SERIAL
[ 4.820312] console [ttyS0] enabled
[ 4.828125] bootconsole [earlycon0] disabled
[ 4.851562] brd: module loaded
[ 4.882812] loop: module loaded
[ 4.898437] atmel_nand 40000000.nand: Use On Flash BBT
[ 4.898437] atmel_nand 40000000.nand: Using dma0chan0 for DMA transfers.
[ 4.906250] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xf1
[ 4.914062] nand: Micron MT29F1G08ABAEAWP
[ 4.921875] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
[ 4.929687] atmel_nand 40000000.nand: minimum ECC: 4 bits in 512 bytes
[ 4.929687] atmel_nand 40000000.nand: Initialize PMECC params, cap:
4, sector: 512
[ 4.945312] Bad block table found at page 65472, version 0x01
[ 4.945312] Bad block table found at page 65408, version 0x01
[ 4.953125] 2 ofpart partitions found on MTD device atmel_nand
[ 4.960937] Creating 2 MTD partitions on "atmel_nand":
[ 4.968750] 0x000000000000-0x000000020000 : "bootstrap"
[ 4.976562] 0x000000020000-0x000008000000 : "ubi"
[ 4.992187] macb f802c000.ethernet (unnamed net_device)
(uninitialized): invalid hw address, using random
[ 5.000000] libphy: MACB_mii_bus: probed
[ 5.093750] macb f802c000.ethernet eth0: Cadence MACB rev 0x0001010c
at 0xf802c000 irq 30 (8e:06:02:88:ed:97)
[ 5.101562] macb f802c000.ethernet eth0: attached PHY driver [Micrel
KSZ8081 or KSZ8091] (mii_bus:phy_addr=f802c000.etherne:01, irq=-1)
[ 5.109375] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 5.117187] ehci-atmel: EHCI Atmel driver
[ 5.125000] atmel-ehci 700000.ehci: EHCI Host Controller
[ 5.125000] atmel-ehci 700000.ehci: new USB bus registered, assigned
bus number 1
[ 5.140625] atmel-ehci 700000.ehci: irq 31, io mem 0x00700000
[ 5.156250] atmel-ehci 700000.ehci: USB 2.0 started, EHCI 1.00
[ 5.156250] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 5.164062] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 5.171875] usb usb1: Product: EHCI Host Controller
[ 5.179687] usb usb1: Manufacturer: Linux 4.1.31 ehci_hcd
[ 5.179687] usb usb1: SerialNumber: 700000.ehci
[ 5.187500] hub 1-0:1.0: USB hub found
[ 5.195312] hub 1-0:1.0: 3 ports detected
[ 5.203125] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 5.203125] ohci-atmel: OHCI Atmel driver
[ 5.210937] at91_ohci 600000.ohci: start
[ 5.210937] at91_ohci 600000.ohci: USB Host Controller
[ 5.218750] at91_ohci 600000.ohci: new USB bus registered, assigned
bus number 2
[ 5.226562] at91_ohci 600000.ohci: irq 31, io mem 0x00600000
[ 5.289062] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
[ 5.296875] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 5.304687] usb usb2: Product: USB Host Controller
[ 5.304687] usb usb2: Manufacturer: Linux 4.1.31 ohci_hcd
[ 5.312500] usb usb2: SerialNumber: at91
[ 5.320312] hub 2-0:1.0: USB hub found
[ 5.320312] at91_ohci 600000.ohci:
ohci_at91_hub_control(c7a86800,0xa006,0x2900,0x0000,c78b8b60,000f)
[ 5.320312] at91_ohci 600000.ohci: wHubCharacteristics 0x0002
[ 5.328125] at91_ohci 600000.ohci: wHubCharacteristics after 0x0001
[ 5.328125] hub 2-0:1.0: 1 port detected
[ 5.328125] at91_ohci 600000.ohci:
ohci_at91_hub_control(c7a86800,0xa000,0x0000,0x0000,c78b8b80,0004)
[ 5.328125] at91_ohci 600000.ohci:
ohci_at91_hub_control(c7a86800,0x2303,0x0008,0x0001,c78b8c00,0000)
[ 5.328125] at91_ohci 600000.ohci: SetPortFeat: POWER
[ 5.328125] rtc rtc0: alarm rollover not handled
[ 5.335937] rtc rtc0: invalid alarm value: 1900-1-1 0:0:0
[ 5.343750] at91_rtc fffffeb0.rtc: rtc core: registered fffffeb0.rtc
as rtc0
[ 5.351562] at91_rtc fffffeb0.rtc: AT91 Real Time Clock driver.
[ 5.359375] AT91: Starting after software reset
[ 5.367187] at91sam9_wdt: enabled (heartbeat=15 sec, nowayout=1)
[ 5.375000] hidraw: raw HID events driver (C) Jiri Kosina
[ 5.382812] usbcore: registered new interface driver usbhid
[ 5.382812] usbhid: USB HID core driver
[ 5.390625] NET: Registered protocol family 17
[ 5.398437] bridge: automatic filtering via arp/ip/ip6tables has been
deprecated. Update your scripts to load br_netfilter if you need this.
[ 5.421875] ubi0: attaching mtd1
[ 5.429687] at91_ohci 600000.ohci:
ohci_at91_hub_control(c7a86800,0xa300,0x0000,0x0001,c7980a00,0004)
[ 5.429687] at91_ohci 600000.ohci: GetPortStatus(0)
[ 5.546875] usb 1-1: new high-speed USB device number 2 using atmel-ehci
[ 5.703125] usb 1-1: New USB device found, idVendor=0424, idProduct=2512
[ 5.703125] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 5.718750] hub 1-1:1.0: USB hub found
[ 5.718750] hub 1-1:1.0: 2 ports detected
[ 5.906250] ubi0: scanning is finished
[ 5.929687] ubi0: attached mtd1 (name "ubi", size 127 MiB)
[ 5.937500] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976
bytes
[ 5.945312] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 5.945312] ubi0: VID header offset: 2048 (aligned 2048), data
offset: 4096
[ 5.953125] ubi0: good PEBs: 1019, bad PEBs: 4, corrupted PEBs: 0
[ 5.960937] ubi0: user volume: 9, internal volumes: 1, max. volumes
count: 128
[ 5.968750] ubi0: max/mean erase counter: 22/16, WL threshold: 4096,
image sequence number: 1226704751
[ 5.976562] ubi0: available PEBs: 94, total reserved PEBs: 925, PEBs
reserved for bad PEB handling: 16
[ 5.984375] ubi0: background thread "ubi_bgt0d" started, PID 375
[ 6.039062] input: gpio_keys as /devices/soc0/gpio_keys/input/input0
[ 6.046875] at91_rtc fffffeb0.rtc: setting system clock to 2017-01-16
10:22:55 UTC (1484562175)
[ 6.062500] usb 1-1.1: new full-speed USB device number 3 using
atmel-ehci
[ 6.085937] UBIFS (ubi0:7): background thread "ubifs_bgt0_7" started,
PID 434
[ 6.109375] UBIFS (ubi0:7): recovery needed
[ 6.187500] usb 1-1.1: New USB device found, idVendor=2d71,
idProduct=0703
[ 6.195312] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 6.203125] usb 1-1.1: Product: C
[ 6.210937] usb 1-1.1: Manufacturer: OVERKIZ SAS
[ 6.210937] usb 1-1.1: SerialNumber: 12-16
[ 6.234375] UBIFS (ubi0:7): recovery completed
[ 6.234375] UBIFS (ubi0:7): UBIFS: mounted UBI device 0, volume 7,
name "root"
[ 6.242187] UBIFS (ubi0:7): LEB size: 126976 bytes (124 KiB),
min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 6.250000] UBIFS (ubi0:7): FS size: 49393664 bytes (47 MiB, 389
LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
[ 6.257812] UBIFS (ubi0:7): reserved for root: 0 bytes (0 KiB)
[ 6.265625] UBIFS (ubi0:7): media format: w4/r0 (latest is w4/r0),
UUID 8FB0025A-D045-4284-B10B-16D0A55EFC51, small LPT model
[ 6.281250] VFS: Mounted root (ubifs filesystem) on device 0:13.
[ 6.289062] devtmpfs: mounted
[ 6.289062] Freeing unused kernel memory: 132K (c0441000 - c0462000)
[ 6.359375] usb 1-1.2: new high-speed USB device number 4 using
atmel-ehci
[ 6.476562] usb 1-1.2: New USB device found, idVendor=0424,
idProduct=2512
[ 6.484375] usb 1-1.2: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 6.492187] hub 1-1.2:1.0: USB hub found
[ 6.500000] hub 1-1.2:1.0: 2 ports detected
[ 6.789062] usb 1-1.2.1: new full-speed USB device number 5 using
atmel-ehci
[ 6.921875] usb 1-1.2.1: New USB device found, idVendor=2d71,
idProduct=0702
[ 6.921875] usb 1-1.2.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 6.929687] usb 1-1.2.1: Product: B
[ 6.937500] usb 1-1.2.1: Manufacturer: OVERKIZ SAS
[ 6.945312] usb 1-1.2.1: SerialNumber: 12-16
[ 7.132812] usb 1-1.2.2: new high-speed USB device number 6 using
atmel-ehci
[ 7.250000] usb 1-1.2.2: New USB device found, idVendor=0424,
idProduct=2512
[ 7.257812] usb 1-1.2.2: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[ 7.335937] hub 1-1.2.2:1.0: USB hub found
[ 7.382812] hub 1-1.2.2:1.0: 2 ports detected
[ 7.476562] usbcore: registered new interface driver usbserial
[ 7.476562] usbcore: registered new interface driver usbserial_generic
[ 7.484375] usbserial: USB Serial support registered for generic
[ 7.632812] usbcore: registered new interface driver ftdi_sio
[ 7.640625] usbserial: USB Serial support registered for FTDI USB
Serial Device
[ 7.648437] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
[ 7.656250] usb 1-1.1: Detected FT232RL
[ 7.679687] usb 1-1.2.2.1: new full-speed USB device number 7 using
atmel-ehci
[ 7.796875] usb 1-1.1: FTDI USB Serial Device converter now attached
to ttyUSB0
[ 7.804687] ftdi_sio 1-1.2.1:1.0: FTDI USB Serial Device converter
detected
[ 7.812500] usb 1-1.2.1: Detected FT232RL
[ 7.820312] cfg80211: Calling CRDA to update world regulatory domain
[ 7.828125] usb 1-1.2.2.1: New USB device found, idVendor=2d71,
idProduct=0700
[ 7.835937] usb 1-1.2.2.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 7.843750] usb 1-1.2.2.1: Product: A
[ 7.851562] usb 1-1.2.2.1: Manufacturer: OVERKIZ SAS
[ 7.851562] usb 1-1.2.2.1: SerialNumber: 12-16
[ 7.914062] usb 1-1.2.1: FTDI USB Serial Device converter now
attached to ttyUSB1
[ 8.000000] ftdi_sio 1-1.2.2.1:1.0: FTDI USB Serial Device converter
detected
[ 8.007812] usb 1-1.2.2.1: Detected FT232RL
[ 8.054687] usb 1-1.2.2.1: FTDI USB Serial Device converter now
attached to ttyUSB2
[ 8.187500] usb 1-1.2.2.2: new high-speed USB device number 8 using
atmel-ehci
[ 8.312500] usb 1-1.2.2.2: New USB device found, idVendor=7392,
idProduct=7811
[ 8.320312] usb 1-1.2.2.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 8.328125] usb 1-1.2.2.2: Product: 802.11n WLAN Adapter
[ 8.328125] usb 1-1.2.2.2: Manufacturer: Realtek
[ 8.335937] usb 1-1.2.2.2: SerialNumber: 00e04c000001
>
> Thanks,
>
> Boris
>
>> This issue disappear when disabling OHCI and use EHCI only.
>>
>> What are the usual causes, and where to begin with ?
>>
>> Thanks in advance,
>>
Thanks,
^ permalink raw reply
* [PATCH v2 1/2] of: base: add support to find the level of the last cache
From: Sudeep Holla @ 2017-01-16 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLi3fxpSPH1q+edNeDXEVfcypQK085FrZytBQrfJPh_3g@mail.gmail.com>
On 14/01/17 02:45, Rob Herring wrote:
> On Thu, Jan 12, 2017 at 12:29 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> It is useful to have helper function just to get the number of cache
>> levels for a given logical cpu. We can obtain the same by just checking
>> the level at which the last cache is present. This patch adds support
>> to find the level of the last cache for a given cpu.
>>
>> It will be used on ARM64 platform where the device tree provides the
>> information for the additional non-architected/transparent/external
>> last level caches that are not integrated with the processors.
>>
>> Suggested-by: Rob Herring <robh+dt@kernel.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/of/base.c | 27 +++++++++++++++++++++++++++
>> include/linux/of.h | 1 +
>> 2 files changed, 28 insertions(+)
>>
>> v1->v2:
>> - Moved to using "cache-level" in the last level cache instead
>> of counting through all the nodes as suggested by Rob
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index d4bea3c797d6..c1128a077aea 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -25,6 +25,7 @@
>> #include <linux/cpu.h>
>> #include <linux/module.h>
>> #include <linux/of.h>
>> +#include <linux/of_device.h>
>> #include <linux/of_graph.h>
>> #include <linux/spinlock.h>
>> #include <linux/slab.h>
>> @@ -2268,6 +2269,32 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
>> }
>>
>> /**
>> + * of_find_last_cache_level - Find the level at which the last cache is
>> + * present for the given logical cpu
>> + *
>> + * @cpu: cpu number(logical index) for which the last cache level is needed
>> + *
>> + * Returns the the level at which the last cache is present. It is exactly
>> + * same as the total number of cache levels for the given logical cpu.
>> + */
>> +int of_find_last_cache_level(unsigned int cpu)
>> +{
>> + int cache_level = 0;
>> + struct device_node *prev = NULL, *np = of_cpu_device_node_get(cpu);
>> +
>> + while (np) {
>> + prev = np;
>> + of_node_put(np);
>> + np = of_find_next_cache_node(np);
>> + }
>> +
>> + if (prev)
>
> Probably don't need this check. Otherwise,
>
Sure I will drop the check.
> Acked-by: Rob Herring <robh@kernel.org>
>
I assume you are fine taking this via arm64 tree. If not, let us know.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)
From: Sylwester Nawrocki @ 2017-01-16 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170114123642.15581-3-krzk@kernel.org>
On 01/14/2017 01:36 PM, Krzysztof Kozlowski wrote:
> Support for Exynos4415 is going away because there are no internal nor
> external users.
>
> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
> the platform cannot be instantiated so remove also the drivers.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names
From: Felipe Balbi @ 2017-01-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111164537.2981-1-shuahkh@osg.samsung.com>
Hi,
Shuah Khan <shuahkh@osg.samsung.com> writes:
> Change goto labels to meaningful names from a series of errNs.
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
doesn't apply to testing/next, please rebase.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170116/ba4f2748/attachment.sig>
^ permalink raw reply
* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-16 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06fd3327-f451-bc0d-b80c-4200bc9fadaa@huawei.com>
On 2017/1/12 21:24, Ding Tianhong wrote:
>
> On 2017/1/12 17:11, Marc Zyngier wrote:
>> On 12/01/17 04:23, Ding Tianhong wrote:
>>> Hi Marc:
>>>
>>> How about this v7, if any suggestions very grateful.
>>
>> It's been less than 5 days since you posted this. I'll get to it once I
>> finish reviewing all the other patches that are sitting in the queue
>> right before yours.
>>
>
> Ok and sorry for the noisy.
>
Hi Marc?
After discussion with the chip developer, we decide to update the erratum id for this bug, so I will resend a new version
about this, if you has start to review this v7 patch set, I think I could wait until you have finished yet. :)
Thanks
Ding
> Thanks
> Ding
>
>> Thanks,
>>
>> M.
>>
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-16 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d3a00788-c3c1-4b10-90bf-2a8bc6a138f8@suse.de>
On 01/15/2017 03:43 PM, Andreas F?rber wrote:
> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>
>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>> this patch adds this reserved zone and redefines the usable memory range.
>>>
>>> The memory node is also moved from the dtsi files into the proper dts files
>>> to handle variants memory sizes.
>>>
>>> This patch also fixes the memory sizes for the following platforms :
>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>
>> Queued for v4.10-rc.
>
> What is the motivation for this change? I have a local U-Boot patch to
> detect the amount of memory available as done downstream, but U-Boot
> only updates the reg property that you seem to be abandoning here...
>
> So for devices that come in multiple RAM configurations - like R-Box Pro
> - this would require separate .dts files now! This looks very wrong to
> me, especially since I am not aware of other platforms doing the same.
> Instead, there's memory reservations for top and bottom done in U-Boot
> for reg, plus reserved-memory nodes for anything in the middle.
>
> Another thing to consider is that uEFI boot (bootefi) handles memory
> reservation differently yet again, on the bootloader level. I have had
> that working fine on Odroid-C2 and Vega S95.
>
> So if there's no bug this is fixing (none mentioned in commit message) I
> strongly object to this patch.
>
> Regards,
> Andreas
>
Hi Andreas,
Like I replied of my RFT patch :
I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
a lot of u-boot versions in the field, and the Odroid-C2 is part of this.
Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
their advices.
Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
running stock u-boot version on various shipped products and Amlogic's own development boards.
The bug is easily triggered by running :
# stress --vm 4 --vm-bytes 128M --timeout 10s &
[ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
...
[ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
...
Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...
Neil
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-16 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113201933-mutt-send-email-mst@kernel.org>
On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > > I'd rather people didn't use SMMU with legacy devices.
> > > >
> > > > I'm afraid we've been doing that for two years and the model already
> > > > exists in a mature state, being actively used for development and
> > > > validation by ARM and our partners. One of the big things its used for
> > > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > > dropping the SMMU from the picture isn't an option.
> > >
> > > Oh so this fixes a regression? This is something I didn't realize.
> >
> > Yes, thanks. The regression came about because we implemented SMMU-backed
> > DMA ops and only then was it apparent that the virtio stuff was bypassing
> > even with translation enabled (because it wasn't using the DMA API).
>
> Could you point out a commit ID?
There has been a fair amount of work in this area recently, but you're
probably after something like 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
as the culprit, which is the point at which we started to swizzle DMA
ops for devices upstream of an SMMU automatically.
> > > A "Fixes:" tag can't hurt here. I then wonder
> > > might DMA ops ever use a DMA address which isn't a physical address
> > > from QEMU point of view? If that happens, this hack breaks
> > > because in legacy mode QEMU still uses the GPA.
> >
> > If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> > because we won't swizzle the DMA ops for the master device. If QEMU does
> > advertise an SMMU, then we'll allocate DMA addresses to fit within the
> > the intersection of the SMMU aperture and device's DMA mask.
>
>
> Right but doesn't just poking from qemu into phys addresses work
> anymore? It used to ...
Provided that there's no SMMU, then it will continue to work. and my
understanding (from talking to Peter Maydell) is that qemu doesn't model
an SMMU for ARM-based machines.
Will
^ permalink raw reply
* [PATCH v3 1/2] of: base: add support to find the level of the last cache
From: Sudeep Holla @ 2017-01-16 10:40 UTC (permalink / raw)
To: linux-arm-kernel
It is useful to have helper function just to get the number of cache
levels for a given logical cpu. We can obtain the same by just checking
the level at which the last cache is present. This patch adds support
to find the level of the last cache for a given cpu.
It will be used on ARM64 platform where the device tree provides the
information for the additional non-architected/transparent/external
last level caches that are not integrated with the processors.
Cc: Mark Rutland <mark.rutland@arm.com>
Suggested-by: Rob Herring <robh+dt@kernel.org>
Acked-by: Rob Herring <robh+dt@kernel.org>
Tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/of/base.c | 26 ++++++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 27 insertions(+)
v2->v3:
- Dropped unnecessary pointer check
- Added Rob's Ack and Tan's Tested-by tags
v1->v2:
- Moved to using "cache-level" in the last level cache instead
of counting through all the nodes as suggested by Rob
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..a30f541f0825 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -25,6 +25,7 @@
#include <linux/cpu.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
@@ -2268,6 +2269,31 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
}
/**
+ * of_find_last_cache_level - Find the level at which the last cache is
+ * present for the given logical cpu
+ *
+ * @cpu: cpu number(logical index) for which the last cache level is needed
+ *
+ * Returns the the level at which the last cache is present. It is exactly
+ * same as the total number of cache levels for the given logical cpu.
+ */
+int of_find_last_cache_level(unsigned int cpu)
+{
+ int cache_level = 0;
+ struct device_node *prev = NULL, *np = of_cpu_device_node_get(cpu);
+
+ while (np) {
+ prev = np;
+ of_node_put(np);
+ np = of_find_next_cache_node(np);
+ }
+
+ of_property_read_u32(prev, "cache-level", &cache_level);
+
+ return cache_level;
+}
+
+/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
* @endpoint: pointer to the OF endpoint data structure
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..21e6323de0f3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
+extern int of_find_last_cache_level(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/2] arm64: cacheinfo: add support to override cache levels via device tree
From: Sudeep Holla @ 2017-01-16 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484563244-14743-1-git-send-email-sudeep.holla@arm.com>
The cache hierarchy can be identified through Cache Level ID(CLIDR)
architected system register. However in some cases it will provide
only the number of cache levels that are integrated into the processor
itself. In other words, it can't provide any information about the
caches that are external and/or transparent.
Some platforms require to export the information about all such external
caches to the userspace applications via the sysfs interface.
This patch adds support to override the cache levels using device tree
to take such external non-architected caches into account.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/cacheinfo.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 9617301f76b5..3f2250fc391b 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -84,7 +84,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves;
+ unsigned int ctype, level, leaves, of_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -97,6 +97,17 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
+ of_level = of_find_last_cache_level(cpu);
+ if (level < of_level) {
+ /*
+ * some external caches not specified in CLIDR_EL1
+ * the information may be available in the device tree
+ * only unified external caches are considered here
+ */
+ leaves += (of_level - level);
+ level = of_level;
+ }
+
this_cpu_ci->num_levels = level;
this_cpu_ci->num_leaves = leaves;
return 0;
--
2.7.4
^ permalink raw reply related
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