* [PATCH 05/11] drm/bridge/synopsys: dw-hdmi: Add deinit callback
From: Jernej Skrabec @ 2017-12-30 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-1-jernej.skrabec@siol.net>
Some SoCs, like Allwinner A83T, have to do additional cleanup when
HDMI driver unloads. When using DW HDMI through DRM bridge API, there is
no place to store driver's private data so it can be accessed in unbind
function. Because of that, add deinit function which is called at the
very end, so drivers can do a proper cleanup.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +++
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 67467d0b683a..a6fe7a323c83 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2592,6 +2592,9 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
i2c_del_adapter(&hdmi->i2c->adap);
else
i2c_put_adapter(hdmi->ddc);
+
+ if (hdmi->plat_data->deinit)
+ hdmi->plat_data->deinit(hdmi->plat_data);
}
/* -----------------------------------------------------------------------------
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index f5cca4362154..a3218d3da61b 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -124,6 +124,7 @@ struct dw_hdmi_phy_ops {
struct dw_hdmi_plat_data {
struct regmap *regm;
+ void (*deinit)(const struct dw_hdmi_plat_data *pdata);
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
const struct drm_display_mode *mode);
unsigned long input_bus_format;
--
2.15.1
^ permalink raw reply related
* [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
From: Jernej Skrabec @ 2017-12-30 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-1-jernej.skrabec@siol.net>
Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.
It turns out that even completely custom HDMI PHYs, such as the one
found in Allwinner H3, can reuse some of those functions. This would
suggest that (some?) functions exported in this commit are actually part
of generic PHY interface and not really specific to Synopsys PHYs.
Export useful PHY functions.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 ++++++++++++++++++++++---------
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
include/drm/bridge/dw_hdmi.h | 10 +++++++
3 files changed, 44 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..67467d0b683a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SVSRET_MASK);
}
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
{
@@ -1065,6 +1067,23 @@ static void dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SELDIPIF_MASK);
}
+void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
+{
+ hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
+ HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
+ HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
+
+void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
+{
+ hdmi_phy_test_clear(hdmi, 1);
+ hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
+ HDMI_PHY_I2CM_SLAVE_ADDR);
+ hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
+
static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
{
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_svsret(hdmi, 1);
/* PHY reset. The reset signal is active high on Gen2 PHYs. */
- hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
- hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+ dw_hdmi_phy_gen2_reset(hdmi, 1);
+ dw_hdmi_phy_gen2_reset(hdmi, 0);
hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
- hdmi_phy_test_clear(hdmi, 1);
- hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
- HDMI_PHY_I2CM_SLAVE_ADDR);
- hdmi_phy_test_clear(hdmi, 0);
+ dw_hdmi_phy_set_slave_addr(hdmi);
/* Write to the PHY as configured by the platform */
if (pdata->configure_phy)
@@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, void *data)
dw_hdmi_phy_power_off(hdmi);
}
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+ void *data)
{
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
- bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+ bool force, bool disabled, bool rxsense)
{
u8 old_mask = hdmi->phy_mask;
@@ -1271,8 +1288,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
{
/*
* Configure the PHY RX SENSE and HPD interrupts polarities and clear
@@ -1291,6 +1309,7 @@ static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
HDMI_IH_MUTE_PHY_STAT0);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_setup_hpd);
static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
.init = dw_hdmi_phy_init,
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
index 9d90eb9c46e5..fd150430d0b3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
@@ -950,6 +950,8 @@ enum {
/* MC_PHYRSTZ field values */
HDMI_MC_PHYRSTZ_PHYRSTZ = 0x01,
+ HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET = 0x00,
+ HDMI_MC_PHYRSTZ_PHYRSTZ_MASK = 0x01,
/* MC_HEACPHY_RST field values */
HDMI_MC_HEACPHY_RST_ASSERT = 0x1,
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 182f83283e24..f5cca4362154 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -159,5 +159,15 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
/* PHY configuration */
void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
unsigned char addr);
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+ void *data);
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+ bool force, bool disabled, bool rxsense);
+void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+
+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable);
+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable);
+void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable);
+void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi);
#endif /* __IMX_HDMI_H__ */
--
2.15.1
^ permalink raw reply related
* [PATCH 03/11] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a
From: Jernej Skrabec @ 2017-12-30 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-1-jernej.skrabec@siol.net>
Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.
Tests show that one iteration is enough.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7ca14d7325b5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
* then write one of the FC registers several times.
*
* The number of iterations matters and depends on the HDMI TX revision
- * (and possibly on the platform). So far only i.MX6Q (v1.30a) and
- * i.MX6DL (v1.31a) have been identified as needing the workaround, with
- * 4 and 1 iterations respectively.
+ * (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+ * (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+ * as needing the workaround, with 4 iterations for v1.30a and 1
+ * iteration for others.
*/
switch (hdmi->version) {
@@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+ case 0x132a:
count = 1;
break;
default:
--
2.15.1
^ permalink raw reply related
* [PATCH 02/11] clk: sunxi-ng: a83t: Add M divider to TCON1 clock
From: Jernej Skrabec @ 2017-12-30 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-1-jernej.skrabec@siol.net>
TCON1 also has M divider, contrary to TCON0.
Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
index 04a9c33f53f0..7d08015b980d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -504,8 +504,8 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon0_clk, "tcon0", tcon0_parents,
0x118, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
static const char * const tcon1_parents[] = { "pll-video1" };
-static SUNXI_CCU_MUX_WITH_GATE(tcon1_clk, "tcon1", tcon1_parents,
- 0x11c, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
+static SUNXI_CCU_M_WITH_MUX_GATE(tcon1_clk, "tcon1", tcon1_parents,
+ 0x11c, 0, 4, 24, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(csi_misc_clk, "csi-misc", "osc24M", 0x130, BIT(16), 0);
--
2.15.1
^ permalink raw reply related
* [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
From: Jernej Skrabec @ 2017-12-30 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230210203.24115-1-jernej.skrabec@siol.net>
For example, A83T have nmp plls which are modelled as nkmp plls. Since k
is not specified, it has offset 0, shift 0 and lowest value 1. This
means that LSB bit is always set to 1, which may change clock rate.
Fix that by applying k factor only if k width is greater than 0.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
index e58c95787f94..709f528af2b3 100644
--- a/drivers/clk/sunxi-ng/ccu_nkmp.c
+++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
@@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
- unsigned long n, m, k, p;
+ unsigned long n, m, k = 1, p;
u32 reg;
reg = readl(nkmp->common.base + nkmp->common.reg);
@@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
if (!n)
n++;
- k = reg >> nkmp->k.shift;
- k &= (1 << nkmp->k.width) - 1;
- k += nkmp->k.offset;
- if (!k)
- k++;
+ if (nkmp->k.width) {
+ k = reg >> nkmp->k.shift;
+ k &= (1 << nkmp->k.width) - 1;
+ k += nkmp->k.offset;
+ if (!k)
+ k++;
+ }
m = reg >> nkmp->m.shift;
m &= (1 << nkmp->m.width) - 1;
@@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned long rate,
reg = readl(nkmp->common.base + nkmp->common.reg);
reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
- reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
+ if (nkmp->k.width)
+ reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
+ nkmp->k.shift);
reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
- reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
+ if (nkmp->k.width)
+ reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
reg |= ilog2(_nkmp.p) << nkmp->p.shift;
--
2.15.1
^ permalink raw reply related
* [PATCH 00/11] drm/sun4i: Add A83T HDMI support
From: Jernej Skrabec @ 2017-12-30 21:01 UTC (permalink / raw)
To: linux-arm-kernel
This patch series implements support for A83T DW HDMI and PHY. It is based
upon Maxime Ripard's "drm/sun4i: Add A83t LVDS support" patch series which
can be found here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/550035.html
While exactly this combination of HDMI controller and PHY is not common in
Allwinner SoCs, this patch series nevertheless makes groundwork for other
SoCs, which have same DW HDMI IP block, but different PHYs, like H3 and H5.
All patches can also be found on github:
https://github.com/jernejsk/linux-1/commits/a83t_hdmi
Please take a look.
Best regards,
Jernej
Jernej Skrabec (11):
clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
clk: sunxi-ng: a83t: Add M divider to TCON1 clock
drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a
drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
drm/bridge/synopsys: dw-hdmi: Add deinit callback
dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
drm/sun4i: Add support for A83T second TCON
drm/sun4i: Add support for A83T second DE2 mixer
drm/sun4i: Implement A83T HDMI driver
ARM: dts: sun8i: a83t: Add HDMI display pipeline
ARM: dts: sun8i: a83t: Enable HDMI on BananaPi M3
.../bindings/display/sunxi/sun4i-drm.txt | 188 ++++++++++-
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 29 ++
arch/arm/boot/dts/sun8i-a83t.dtsi | 108 +++++-
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 4 +-
drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 56 +++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 +
drivers/gpu/drm/sun4i/Kconfig | 9 +
drivers/gpu/drm/sun4i/Makefile | 1 +
drivers/gpu/drm/sun4i/sun4i_tcon.c | 46 ++-
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 367 +++++++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_mixer.c | 11 +
include/drm/bridge/dw_hdmi.h | 11 +
14 files changed, 808 insertions(+), 46 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
--
2.15.1
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Russell King - ARM Linux @ 2017-12-30 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKcFT5YgvwEk9QNB5=O0j23ds1jCxaBYnMVhxDHeBZzbDA@mail.gmail.com>
Hi Marcin,
On Sat, Dec 30, 2017 at 05:34:23PM +0100, Marcin Wojtas wrote:
> Yes, I already split the series and will send first one right away. I
> will be followed by MDIO bus / PHY handling proposal, including the
> bits related to phylink. I'm looking forward to your opinion on that
> once sent.
I'm looking forward to the patches. :)
> This my understanding of how the PP2 HW works in terms of signalling
> the link interrupt:
>
> The full in-band management, similar to mvneta is supported only in
> the SGMII mode (1G, not sure how it looks like in 2.5G mode). Such
> handling is not yet implemented in the mvpp2.c
>
> 10G:
> The XGMII MAC (XLG) is capable of generating link status change
> interrupt upon information provided from the reconciliation layer (RS)
> of the interface.
>
> 2.5G/1G SGMII:
> Apart from the in-band management, the MAC is also capable of
> generating IRQ during link-status change.
>
> 1G RGMII:
> I was a bit surprised, but checked on my own - the link change IRQ can
> be generated here as well.
>
> In addition to above the clause 22 PHYs can be automatically polled
> via SMI bus and provide complete information about link status, speed,
> etc., reflecting it directly in GMAC status registers. However, this
> feature had to be disabled, in order not to conflict with SW PHY
> management of the phylib.
>
> Stefan, is above correct?
This sounds very much like mvneta's 'managed = "in-band"' mode.
Having done some research earlier this month on the "2.5G SGMII" I have
a number of comments about this:
1. Beware of "SGMII" being used as a generic term for single lane serdes
based ethernet. Marvell seem to use this for 802.3z BASE-X in their
code, but it is not. SGMII is a modification of 802.3z BASE-X by
Cisco. This leads to some confusion!
2. For Cisco SGMII running at 2.5G, PHYs such as those from Xilinx do not
support the speed bits, because the speed is defined to be 2.5G. IOW,
they do not support 250Mbps or 25Mbps speeds by data replication as is
done with 100Mbps and 10Mbps over 1G SGMII.
3. There is also 1000BASE-X upclocked to 2.5G speeds, which mvneta and
mvpp2 both support by appropriate configuration of the comphy. I've
already tested this with 4.3Mbps Fiberchannel SFPs between clearfog
and mcbin - but needing devmem2 to reconfigure the clearfog comphy.
> > If my guessing is correct, I have to wonder why mvpp2 invented a
> > different way to represent this from mvneta? This makes it much more
> > difficult to convert mvpp2 to phylink, and it also makes it difficult
> > to add SFP support ignoring the phylink issue (since there is no phy
> > handle there either.)
>
> Doesn't SFP require the fwnode handle to the sfp node? This is what I
> understand at least from the phylink_register_sfp.
Yes, internally within phylink. What I'm concerned about is the
following disparity between mvneta and mvpp2 - I'll try to explain it
more clearly with DT examples:
1.1. mvneta phy
ð {
phy = <&phy>;
phy-mode = "whatever";
};
1.2. mvneta fixed-link
ð {
fixed-link {
speed = <1000>;
full-duplex;
};
};
1.3. mvneta in-band
ð {
phy-mode = "sgmii";
managed = "in-band-status";
};
2.1. mvpp2 phy
ð {
phy = <&phy>;
phy-mode = "whatever";
};
2.2. mvpp2 fixed-link
ð {
fixed-link {
speed = <1000>;
full-duplex;
};
};
2.3. mvpp2 in-band (guess)
ð {
phy-mode = "sgmii";
};
In both cases, the representation for phy and fixed-link mode are the
same, but the in-band are different. In mvneta in-band, the generic
"managed" property must be specified as specified by
Documentation/devicetree/bindings/net/ethernet.txt. However, for mvpp2,
this mode is currently selected by omission of both a "phy" property and
a "fixed-link" sub-node/property - and that goes against the description
of the "managed" property in the ethernet.txt binding doc.
Phylink won't recognise the mvpp2's style of "in-band" because phylink,
being a piece of generic code, is written to follow the generic binding
documentation, rather than accomodating driver's individual quirks.
So, if what I think is correct (basically what I've said above) there is
a problem converting mvpp2 to use phylink - any existing DT files that
use the "2.3 mvpp2 in-band" method instantly break, and I think that's
what Antoine referred to when I picked out that the previous patches
avoided using phylink when there was no "phy" node present.
However, I haven't spotted anything using the 2.3 method, but it's not
that easy to find the lack of a property amongst the maze of .dts*
files - trying to track down which use mvpp2 and which do not specify
a phy or fixed-link node can't be done by grep alone due to the
includes etc. I think the only possible way would be to build all DT
files, then reverse them back to dts and search those for the mvpp2
compatible strings, and then manually check each one.
> Anyway, once the phylink is introduced in mvpp2.c, its presence will
> simply be detected by port->phylink pointer. In such case the link IRQ
> will no be used. In longer perspective, link IRQ should be used only
> by ACPI and once MDIO bus is supported in generic way in this world,
> it could remain as the 'last resort' option.
It's not though - there are SFP modules that are SGMII and we have no
access to the PHY onboard, so the only way we know what they're doing
is from the inband status sent as part of the SGMII in-band
configuration. So, even when using phylink, we need the in-band
stuff to work, and so we need those link IRQs.
There's also additional complexities around Cisco SGMII and "extended"
SGMII concerning the flow control settings - in Cisco SGMII, there
are no bits in the 16-bit control word for communicating the flow
control to the MAC. In extended SGMII (which appears in some Marvell
devices) you can configure flow control to appear in the 16-bit
control word, and in some cases, also EEE. When implemented correctly
by the MAC, phylink supports the "Cisco" method when it knows that
in-band AN is being used along with a PHY - it knows to read the
settings from the MAC but combine the flow control with what has been
read from the PHY. If this is not done, we're likely to end up with
the link partner believing that FC is supported (eg, because the PHY
has defaulted to advertising FC) but the local MAC having FC disabled.
Note that there's another quirk as far as SGMII goes - some PHYs will
not pass data until their "negotiation" (iow, passing and acknowledgement
of the SGMII control word by the MAC) has completed. Disabling SGMII
"AN" on the MAC causes some SGMII PHYs to apparently be in "link up"
state but with no traffic flow possible in either direction. This is
a particularly important point if using phylib - the temptation is to
use phylib to pass the results of AN to the MAC for SGMII and disable
AN on the MAC, but this is, in fact, wrong for the reason set out in
this paragraph.
There are bits present that allow AN bypass if it doesn't complete in
a certain time, but that's an entirely separate issue - especially
when there's SGMII PHYs that we have no access to!
Sorting out these nuances over the life of phylink so far has been
"interesting".
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface
From: Marcin Wojtas @ 2017-12-30 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229113850.GX10595@n2100.armlinux.org.uk>
Hi Russell and Stefan,
2017-12-29 12:38 GMT+01:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Fri, Dec 29, 2017 at 12:12:15PM +0100, Marcin Wojtas wrote:
>> Hi Russell,
>>
>> I see that I misspelled your email address, hence the series remained unnoticed:
>> https://lkml.org/lkml/2017/12/18/216
>>
>> In terms of the phylink support, I think the most important are:
>> * 3/8
>> https://lkml.org/lkml/2017/12/18/211
>> * 7/8
>> https://lkml.org/lkml/2017/12/18/207
>>
>> I think the way of obtaining PHY fwnode and connecting it from the
>> latter patch could be incorporated to the phylink code. Although I
>> didn't get much feedback, the whole ACPI-handling of MDIO bus and the
>> PHYs touch ACPI specification and I expect it a slower to get merged.
>> Hence my idea is following:
>> * Send v2 with ACPI supporting link-irq only in mvpp2.c
>> * Extract MDIO bus handling for ACPI and propose PHY handling
>> modifications in phylink.
>>
>> This way we may push the two things forwards in more efficient way.
>> I'm looking forward to your opinion.
>
> Agreed - as we have very few users of phylink at the moment (they're
> mostly all in external trees) we can easily change the phylink
> interfaces. The first step is solving the ACPI representation of the
> MDIO bus and attached devices, and until that is settled, not much can
> be done.
>
> However, it seems to me that the issues of adding ACPI to mvpp2 vs
> adding phylink to mvpp2 are two entirely separate problems that don't
> really conflict with each other - since the "phy" problem afflicts
> both.
>
Yes, I already split the series and will send first one right away. I
will be followed by MDIO bus / PHY handling proposal, including the
bits related to phylink. I'm looking forward to your opinion on that
once sent.
> However, I'm not sure what this "link-irq" thing is that you talk
> about (and I suspect it's one of the things that I've been trying for
> months to find out about from Antoine when he says that there's stuff
> that mvpp2 supports that phylink doesn't.) So, I'm left to guess, and
> I guess it's the mvpp2-variant of mvneta's in-band autonegotiation.
> Continuing to guess from the mvpp2 phylink conversion patch, this mvpp2
> variant is selected by not providing a phy handle in DT, whereas
> mvneta's variant is selected using the ethernet-standard property
> 'managed = "in-band-status"'.
This my understanding of how the PP2 HW works in terms of signalling
the link interrupt:
The full in-band management, similar to mvneta is supported only in
the SGMII mode (1G, not sure how it looks like in 2.5G mode). Such
handling is not yet implemented in the mvpp2.c
10G:
The XGMII MAC (XLG) is capable of generating link status change
interrupt upon information provided from the reconciliation layer (RS)
of the interface.
2.5G/1G SGMII:
Apart from the in-band management, the MAC is also capable of
generating IRQ during link-status change.
1G RGMII:
I was a bit surprised, but checked on my own - the link change IRQ can
be generated here as well.
In addition to above the clause 22 PHYs can be automatically polled
via SMI bus and provide complete information about link status, speed,
etc., reflecting it directly in GMAC status registers. However, this
feature had to be disabled, in order not to conflict with SW PHY
management of the phylib.
Stefan, is above correct?
>
> If my guessing is correct, I have to wonder why mvpp2 invented a
> different way to represent this from mvneta? This makes it much more
> difficult to convert mvpp2 to phylink, and it also makes it difficult
> to add SFP support ignoring the phylink issue (since there is no phy
> handle there either.)
Doesn't SFP require the fwnode handle to the sfp node? This is what I
understand at least from the phylink_register_sfp.
Anyway, once the phylink is introduced in mvpp2.c, its presence will
simply be detected by port->phylink pointer. In such case the link IRQ
will no be used. In longer perspective, link IRQ should be used only
by ACPI and once MDIO bus is supported in generic way in this world,
it could remain as the 'last resort' option.
Best regards,
Marcin
^ permalink raw reply
* [PATCH] ethernet/broadcom: Use zeroing memory allocator than allocator/memset
From: Himanshu Jha @ 2017-12-30 15:44 UTC (permalink / raw)
To: linux-arm-kernel
Use dma_zalloc_coherent for allocating zeroed
memory and remove unnecessary memset function.
Done using Coccinelle.
Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
0-day tested with no failures.
Suggested-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 6 ++----
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 5 ++---
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
index 1fbbbab..14a59e5 100644
--- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
+++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
@@ -2128,27 +2128,25 @@ static int bcm_enetsw_open(struct net_device *dev)
/* allocate rx dma ring */
size = priv->rx_ring_size * sizeof(struct bcm_enet_desc);
- p = dma_alloc_coherent(kdev, size, &priv->rx_desc_dma, GFP_KERNEL);
+ p = dma_zalloc_coherent(kdev, size, &priv->rx_desc_dma, GFP_KERNEL);
if (!p) {
dev_err(kdev, "cannot allocate rx ring %u\n", size);
ret = -ENOMEM;
goto out_freeirq_tx;
}
- memset(p, 0, size);
priv->rx_desc_alloc_size = size;
priv->rx_desc_cpu = p;
/* allocate tx dma ring */
size = priv->tx_ring_size * sizeof(struct bcm_enet_desc);
- p = dma_alloc_coherent(kdev, size, &priv->tx_desc_dma, GFP_KERNEL);
+ p = dma_zalloc_coherent(kdev, size, &priv->tx_desc_dma, GFP_KERNEL);
if (!p) {
dev_err(kdev, "cannot allocate tx ring\n");
ret = -ENOMEM;
goto out_free_rx_ring;
}
- memset(p, 0, size);
priv->tx_desc_alloc_size = size;
priv->tx_desc_cpu = p;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
index fed37cd..3c746f2 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
@@ -278,12 +278,11 @@ static int bnxt_hwrm_set_dcbx_app(struct bnxt *bp, struct dcb_app *app,
n = IEEE_8021QAZ_MAX_TCS;
data_len = sizeof(*data) + sizeof(*fw_app) * n;
- data = dma_alloc_coherent(&bp->pdev->dev, data_len, &mapping,
- GFP_KERNEL);
+ data = dma_zalloc_coherent(&bp->pdev->dev, data_len, &mapping,
+ GFP_KERNEL);
if (!data)
return -ENOMEM;
- memset(data, 0, data_len);
bnxt_hwrm_cmd_hdr_init(bp, &get, HWRM_FW_GET_STRUCTURED_DATA, -1, -1);
get.dest_data_addr = cpu_to_le64(mapping);
get.structure_id = cpu_to_le16(STRUCT_HDR_STRUCT_ID_DCBX_APP);
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: sun7i: lamobo-r1: Add backup battery charging property
From: Paul Kocialkowski @ 2017-12-30 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230152330.28946-1-contact@paulk.fr>
This adds the axp20x backup property to the lamobo-r1 device-tree,
that allows charging the backup battery attached to its AXP209.
It is especially useful since the battery is used for the RTC module.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
diff --git a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
index 442f3c755f36..e218fd8ea94f 100644
--- a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
+++ b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
@@ -207,6 +207,8 @@
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+ backup = <3000 200>;
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH 2/3] mfd: axp20x: Add support for backup battery charging
From: Paul Kocialkowski @ 2017-12-30 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230152330.28946-1-contact@paulk.fr>
This adds support for backup battery charging for axp20x PMICs, that is
configured through a dedicated device-tree property.
It supports 4 different charging voltages and as many charging currents.
This is especially useful to allow the on-chip RTC (on the SoC side) to
be powered when the rest of the system is off.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 2468b431bb22..7847f5d0b979 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -34,6 +34,16 @@
#define AXP806_REG_ADDR_EXT_ADDR_MASTER_MODE 0
#define AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE BIT(4)
+#define AXP20X_CHRG_BAK_CTRL_ENABLE BIT(7)
+#define AXP20X_CHRG_BAK_VOLTAGE_3100_MV (0 << 5)
+#define AXP20X_CHRG_BAK_VOLTAGE_3000_MV (1 << 5)
+#define AXP20X_CHRG_BAK_VOLTAGE_3600_MV (2 << 5)
+#define AXP20X_CHRG_BAK_VOLTAGE_2500_MV (3 << 5)
+#define AXP20X_CHRG_BAK_CURRENT_50_UA (0 << 0)
+#define AXP20X_CHRG_BAK_CURRENT_100_UA (1 << 0)
+#define AXP20X_CHRG_BAK_CURRENT_200_UA (2 << 0)
+#define AXP20X_CHRG_BAK_CURRENT_400_UA (3 << 0)
+
static const char * const axp20x_model_names[] = {
"AXP152",
"AXP202",
@@ -894,6 +904,63 @@ static void axp20x_power_off(void)
msleep(500);
}
+static void axp20x_backup_setup(struct axp20x_dev *axp20x)
+{
+ u32 backup[2];
+ int reg;
+ int ret;
+
+ ret = of_property_read_u32_array(axp20x->dev->of_node, "backup", backup,
+ 2);
+ if (ret != 0)
+ return;
+
+ switch (axp20x->variant) {
+ case AXP202_ID:
+ case AXP209_ID:
+ reg = AXP20X_CHRG_BAK_CTRL_ENABLE;
+
+ /* Charging voltage. */
+ switch (backup[0]) {
+ case 2500:
+ reg |= AXP20X_CHRG_BAK_VOLTAGE_2500_MV;
+ break;
+ case 3000:
+ reg |= AXP20X_CHRG_BAK_VOLTAGE_3000_MV;
+ break;
+ case 3100:
+ reg |= AXP20X_CHRG_BAK_VOLTAGE_3100_MV;
+ break;
+ case 3600:
+ reg |= AXP20X_CHRG_BAK_VOLTAGE_3600_MV;
+ break;
+ default:
+ return;
+ }
+
+ /* Charging current. */
+ switch (backup[1]) {
+ case 50:
+ reg |= AXP20X_CHRG_BAK_CURRENT_50_UA;
+ break;
+ case 100:
+ reg |= AXP20X_CHRG_BAK_CURRENT_100_UA;
+ break;
+ case 200:
+ reg |= AXP20X_CHRG_BAK_CURRENT_200_UA;
+ break;
+ case 400:
+ reg |= AXP20X_CHRG_BAK_CURRENT_400_UA;
+ break;
+ default:
+ return;
+ }
+
+ regmap_write(axp20x->regmap, AXP20X_CHRG_BAK_CTRL, reg);
+ break;
+ }
+}
+
int axp20x_match_device(struct axp20x_dev *axp20x)
{
struct device *dev = axp20x->dev;
@@ -1023,6 +1090,9 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE);
}
+ /* Backup RTC battery. */
+ axp20x_backup_setup(axp20x);
+
ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
-1, axp20x->regmap_irq_chip, &axp20x->regmap_irqc);
--
2.15.1
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: mfd: axp20x: Document backup battery charging property
From: Paul Kocialkowski @ 2017-12-30 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230152330.28946-1-contact@paulk.fr>
This adds documentation for the "backup" property of the axp20x driver,
that controls the charging mechanism for the backup battery on axp20x.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 9455503b0299..382776b29932 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -58,6 +58,11 @@ Optional properties:
See Documentation/devicetree/bindings/regulator/regulator.txt
for more information on standard regulator bindings.
+- backup: An array of two integers for backup battery charging (axp20x-only),
+ describing the charging voltage in mV first and the charging current
+ in uA second. Backup battery charging is only enabled when these two
+ fields are filled.
+
Optional properties for DCDC regulators:
- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO (PWM/PFM) mode
Default: Current hardware setting
@@ -256,4 +261,6 @@ axp209: pmic at 34 {
/* unused but preferred to be managed by OS */
};
};
+
+ backup = <3000 200>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH 0/3] axp20x backup battery charging
From: Paul Kocialkowski @ 2017-12-30 15:23 UTC (permalink / raw)
To: linux-arm-kernel
This series introduces support for axp20x backup battery charging, with
a dedicated device-tree property.
I wondered whether to include this in a power-supply driver or not.
Since it does not, in fact, supply power to the whole system and
because no status changes over time, I thought it would be inappropriate
to craft a power supply driver only for this.
I also wondered whether to stick this into an existing power-supply
driver, as is done by e.g. twl4030, but we have two distinct supply
drivers for the axp20x (ac and usb), that may be used together or not.
Also, the backup battery isn't tied to the power supply anyway.
This is why I thought it would make more sense to put this in the mfd
driver directly. What do you think?
^ permalink raw reply
* [PATCH] arm64: Target aarch64elf emulation to allow bare-metal toolchains
From: Paul Kocialkowski @ 2017-12-30 15:08 UTC (permalink / raw)
To: linux-arm-kernel
This sets the LDFLAGS variable to target the aarch64elf emulation
instead of aarch64linux, which is incompatible with bare-metal
toolchains.
This change allows the kernel to build with bare-metal toolchains again.
Fixes: 3d6a7b99e3fa ("arm64: ensure the kernel is compiled for LP64")
Cc: stable at vger.kernel.org
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
arch/arm64/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index b481b4a7c011..a249233edcd8 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -64,14 +64,14 @@ KBUILD_CPPFLAGS += -mbig-endian
CHECKFLAGS += -D__AARCH64EB__
AS += -EB
LD += -EB
-LDFLAGS += -maarch64linuxb
+LDFLAGS += -maarch64elfb
UTS_MACHINE := aarch64_be
else
KBUILD_CPPFLAGS += -mlittle-endian
CHECKFLAGS += -D__AARCH64EL__
AS += -EL
LD += -EL
-LDFLAGS += -maarch64linux
+LDFLAGS += -maarch64elf
UTS_MACHINE := aarch64
endif
--
2.15.1
^ permalink raw reply related
* [PATCH V2] ARM: imx: introduce imx_l2c310_write_sec
From: Peng Fan @ 2017-12-30 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uGL=zyxj5VzKAKsAcU6bcL2bJQCcvP9eg4qYAKN00iwJg@mail.gmail.com>
> -----Original Message-----
> From: Philippe Ombredanne [mailto:pombredanne at nexb.com]
> Sent: Saturday, December 30, 2017 10:17 PM
> To: Peng Fan <peng.fan@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>; moderated list:ARM/FREESCALE IMX
> / MXC ARM ARCHITECTURE <linux-arm-kernel@lists.infradead.org>; LKML
> <linux-kernel@vger.kernel.org>; Peng Fan <van.freenix@gmail.com>; Sascha
> Hauer <kernel@pengutronix.de>; Fabio Estevam <fabio.estevam@nxp.com>;
> A.s. Dong <aisheng.dong@nxp.com>
> Subject: Re: [PATCH V2] ARM: imx: introduce imx_l2c310_write_sec
>
> On Sat, Dec 30, 2017 at 1:34 PM, Peng Fan <peng.fan@nxp.com> wrote:
> > Some PL310 registers could only be wrote in secure world, so introduce
> > imx_l2c310_write_sec to support Linux running in non-secure world
> > configure PL310.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> > Cc: Dong Aisheng <aisheng.dong@nxp.com>
> > ---
> >
> > V2:
> > Use SPDX Tag
> > Use CONFIG_HAVE_ARM_SMCCC to fix build error for armv5.
> > Add IS_ENABLED(CONFIG_OPTEE) check when assigning write_sec
> >
> > arch/arm/mach-imx/system.c | 27 ++++++++++++++++++++++++++-
> > include/soc/imx/imx_sip_smc.h | 21 +++++++++++++++++++++
> > 2 files changed, 47 insertions(+), 1 deletion(-) create mode 100644
> > include/soc/imx/imx_sip_smc.h
> >
> > diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
> > index c06af650e6b1..2c27e52d8c7d 100644
> > --- a/arch/arm/mach-imx/system.c
> > +++ b/arch/arm/mach-imx/system.c
> > @@ -23,11 +23,13 @@
> > #include <linux/delay.h>
> > #include <linux/of.h>
> > #include <linux/of_address.h>
> > +#include <soc/imx/imx_sip_smc.h>
> >
> > #include <asm/system_misc.h>
> > #include <asm/proc-fns.h>
> > #include <asm/mach-types.h>
> > #include <asm/hardware/cache-l2x0.h>
> > +#include <asm/outercache.h>
> >
> > #include "common.h"
> > #include "hardware.h"
> > @@ -92,6 +94,22 @@ void __init imx1_reset_init(void __iomem *base)
> > #endif
> >
> > #ifdef CONFIG_CACHE_L2X0
> > +#ifdef CONFIG_HAVE_ARM_SMCCC
> > +void imx_l2c310_write_sec(unsigned long val, unsigned int reg) {
> > + struct arm_smccc_res res;
> > +
> > + arm_smccc_smc(IMX_SIP_SMC_L2C310, val, reg, 0, 0, 0, 0, 0,
> > + &res);
> > +
> > + if (res.a0 != 0)
> > + pr_err("Failed to write l2c310 0x%x: 0x%lx\n", reg,
> > +res.a0); } #else void imx_l2c310_write_sec(unsigned long val,
> > +unsigned int reg) { } #endif
> > +
> > void __init imx_init_l2cache(void)
> > {
> > void __iomem *l2x0_base;
> > @@ -102,6 +120,10 @@ void __init imx_init_l2cache(void)
> > if (!np)
> > return;
> >
> > + if (IS_ENABLED(CONFIG_OPTEE) &&
> > + of_find_compatible_node(NULL, NULL, "linaro,optee-tz"))
> > + outer_cache.write_sec = imx_l2c310_write_sec;
> > +
> > l2x0_base = of_iomap(np, 0);
> > if (!l2x0_base)
> > goto put_node;
> > @@ -117,7 +139,10 @@ void __init imx_init_l2cache(void)
> > val &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
> > val |= 15;
> >
> > - writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
> > + if (outer_cache.write_sec)
> > + outer_cache.write_sec(val, L310_PREFETCH_CTRL);
> > + else
> > + writel_relaxed(val, l2x0_base +
> > + L310_PREFETCH_CTRL);
> > }
> >
> > iounmap(l2x0_base);
> > diff --git a/include/soc/imx/imx_sip_smc.h
> > b/include/soc/imx/imx_sip_smc.h new file mode 100644 index
> > 000000000000..c35ae69e0d2f
> > --- /dev/null
> > +++ b/include/soc/imx/imx_sip_smc.h
> > @@ -0,0 +1,21 @@
> > +/*
> > + * Copyright 2017 NXP
> > + *
> > + * SPDX-License-Identifier: GPL-2.0
> > + */
> > +
>
> Thanks! but the SPDX tag should be on the first line as its own comment. So this
> would come out something like this
>
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright 2017 NXP */
>
> or
>
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2017 NXP
> > + */
>
Thanks. I'll correct in V3. Before that, I would like to see if more comments
about the code. Then I'll address them all in V3.
Thanks,
Peng.
>
>
> > +#ifndef __IMX_SIP_SMC_H_
> > +#define __IMX_SIP_SMC_H_
> > +
> > +#include <linux/arm-smccc.h>
> > +
> > +#define IMX_SIP_SMC_VAL(func)
> ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> > + ARM_SMCCC_SMC_32, \
> > + ARM_SMCCC_OWNER_SIP, \
> > + (func))
> > +
> > +#define IMX_L2C310 0x1
> > +
> > +#define IMX_SIP_SMC_L2C310 IMX_SIP_SMC_VAL(IMX_L2C310)
> > +
> > +#endif
> > --
> > 2.14.1
> >
>
>
>
> --
> Cordially
> Philippe Ombredanne
^ permalink raw reply
* [PATCH V2] ARM: imx: introduce imx_l2c310_write_sec
From: Philippe Ombredanne @ 2017-12-30 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514637243-20111-1-git-send-email-peng.fan@nxp.com>
On Sat, Dec 30, 2017 at 1:34 PM, Peng Fan <peng.fan@nxp.com> wrote:
> Some PL310 registers could only be wrote in secure world, so
> introduce imx_l2c310_write_sec to support Linux running in
> non-secure world configure PL310.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> ---
>
> V2:
> Use SPDX Tag
> Use CONFIG_HAVE_ARM_SMCCC to fix build error for armv5.
> Add IS_ENABLED(CONFIG_OPTEE) check when assigning write_sec
>
> arch/arm/mach-imx/system.c | 27 ++++++++++++++++++++++++++-
> include/soc/imx/imx_sip_smc.h | 21 +++++++++++++++++++++
> 2 files changed, 47 insertions(+), 1 deletion(-)
> create mode 100644 include/soc/imx/imx_sip_smc.h
>
> diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
> index c06af650e6b1..2c27e52d8c7d 100644
> --- a/arch/arm/mach-imx/system.c
> +++ b/arch/arm/mach-imx/system.c
> @@ -23,11 +23,13 @@
> #include <linux/delay.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <soc/imx/imx_sip_smc.h>
>
> #include <asm/system_misc.h>
> #include <asm/proc-fns.h>
> #include <asm/mach-types.h>
> #include <asm/hardware/cache-l2x0.h>
> +#include <asm/outercache.h>
>
> #include "common.h"
> #include "hardware.h"
> @@ -92,6 +94,22 @@ void __init imx1_reset_init(void __iomem *base)
> #endif
>
> #ifdef CONFIG_CACHE_L2X0
> +#ifdef CONFIG_HAVE_ARM_SMCCC
> +void imx_l2c310_write_sec(unsigned long val, unsigned int reg)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_smc(IMX_SIP_SMC_L2C310, val, reg, 0, 0, 0, 0, 0, &res);
> +
> + if (res.a0 != 0)
> + pr_err("Failed to write l2c310 0x%x: 0x%lx\n", reg, res.a0);
> +}
> +#else
> +void imx_l2c310_write_sec(unsigned long val, unsigned int reg)
> +{
> +}
> +#endif
> +
> void __init imx_init_l2cache(void)
> {
> void __iomem *l2x0_base;
> @@ -102,6 +120,10 @@ void __init imx_init_l2cache(void)
> if (!np)
> return;
>
> + if (IS_ENABLED(CONFIG_OPTEE) &&
> + of_find_compatible_node(NULL, NULL, "linaro,optee-tz"))
> + outer_cache.write_sec = imx_l2c310_write_sec;
> +
> l2x0_base = of_iomap(np, 0);
> if (!l2x0_base)
> goto put_node;
> @@ -117,7 +139,10 @@ void __init imx_init_l2cache(void)
> val &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
> val |= 15;
>
> - writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
> + if (outer_cache.write_sec)
> + outer_cache.write_sec(val, L310_PREFETCH_CTRL);
> + else
> + writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
> }
>
> iounmap(l2x0_base);
> diff --git a/include/soc/imx/imx_sip_smc.h b/include/soc/imx/imx_sip_smc.h
> new file mode 100644
> index 000000000000..c35ae69e0d2f
> --- /dev/null
> +++ b/include/soc/imx/imx_sip_smc.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright 2017 NXP
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
Thanks! but the SPDX tag should be on the first line as its own
comment. So this would come out something like this
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright 2017 NXP */
or
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2017 NXP
> + */
> +#ifndef __IMX_SIP_SMC_H_
> +#define __IMX_SIP_SMC_H_
> +
> +#include <linux/arm-smccc.h>
> +
> +#define IMX_SIP_SMC_VAL(func) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_32, \
> + ARM_SMCCC_OWNER_SIP, \
> + (func))
> +
> +#define IMX_L2C310 0x1
> +
> +#define IMX_SIP_SMC_L2C310 IMX_SIP_SMC_VAL(IMX_L2C310)
> +
> +#endif
> --
> 2.14.1
>
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH 2/2] ARM: imx: cpuidle-imx6q: configure CCM to RUN mode when CPU is active
From: Peng Fan @ 2017-12-30 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514641999-20521-1-git-send-email-peng.fan@nxp.com>
There are two states in i.MX6Q cpuidle driver.
state[1]: ARM WFI mode
state[2]: i.MX6Q WAIT mode
Take i.MX6DL as example, think out such a case:
1. CPU0/1 both run at normal mode
2. On CPU0, `sleep 1` is executed. And there are no workload on CPU1.
3. CPU0 first runs into state[2] and 'wfi' instruction. Switched to use
GPT broadcast.
4. CPU1 runs into state[2] and configure CCM to WAIT MODE,
then 'wfi' instruction. Now arm_clk and local timer clock are
shutdown. Switched to use GPT broadcast
5. GPT broadcast timer interrupt comes to GPC/GIC, then CPU0 wakes up.
CPU0 switched to use arm local timer. CPU1 is still sleeping.
6. No workload on CPU0, CPU0 runs into state[1]. But CCM register
is still not restored to Normal RUN mode. 'wfi' + CCM WAIT will
cause arm_clk and arm core clk.
Now CPU0 stops, which is not correct.
So, need to make sure CCM configured to RUN mode when any cpu exit
state[2].
In this patch,
When CPU exits state[2], it configures CCM to RUN mode.
When all CPUs enters state[2], the last CPU needs to check
whether it's ok to configure CCM to WAIT mode or not.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
V1:
This is to upstream patch:
http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/commit/?h=imx_4.9.11_1.0.0_ga&id=0d980646ee068b92db71fd5e4e4efcbc33749cbd
arch/arm/mach-imx/cpuidle-imx6q.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c b/arch/arm/mach-imx/cpuidle-imx6q.c
index bfeb25aaf9a2..4d342e2fdfe6 100644
--- a/arch/arm/mach-imx/cpuidle-imx6q.c
+++ b/arch/arm/mach-imx/cpuidle-imx6q.c
@@ -30,6 +30,8 @@ static int imx6q_enter_wait(struct cpuidle_device *dev,
if (!spin_trylock(&master_lock))
goto idle;
imx6_set_lpm(WAIT_UNCLOCKED);
+ if (atomic_read(&master) != num_online_cpus())
+ imx6_set_lpm(WAIT_CLOCKED);
cpu_do_idle();
imx6_set_lpm(WAIT_CLOCKED);
spin_unlock(&master_lock);
@@ -41,6 +43,7 @@ static int imx6q_enter_wait(struct cpuidle_device *dev,
done:
atomic_dec(&master);
+ imx6_set_lpm(WAIT_CLOCKED);
return index;
}
--
2.14.1
^ permalink raw reply related
* [PATCH 1/2] ARM: imx: no unmask/mask GINT for WAIT_CLOCKED
From: Peng Fan @ 2017-12-30 13:53 UTC (permalink / raw)
To: linux-arm-kernel
WAIT_CLOCKED is for RUN mode, there is no need to unmask/mask
IRQ32 in GPC.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
V1:
This is to upstream patch:
http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/commit/?h=imx_4.9.11_1.0.0_ga&id=0d980646ee068b92db71fd5e4e4efcbc33749cbd
arch/arm/mach-imx/pm-imx6.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 153a0afc7645..56bfd9b5229e 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -337,9 +337,11 @@ int imx6_set_lpm(enum mxc_cpu_pwr_mode mode)
*
* Note that IRQ #32 is GIC SPI #0.
*/
- imx_gpc_hwirq_unmask(0);
+ if (mode != WAIT_CLOCKED)
+ imx_gpc_hwirq_unmask(0);
writel_relaxed(val, ccm_base + CLPCR);
- imx_gpc_hwirq_mask(0);
+ if (mode != WAIT_CLOCKED)
+ imx_gpc_hwirq_mask(0);
return 0;
}
--
2.14.1
^ permalink raw reply related
* [PATCH V2] ARM: imx: introduce imx_l2c310_write_sec
From: Peng Fan @ 2017-12-30 12:34 UTC (permalink / raw)
To: linux-arm-kernel
Some PL310 registers could only be wrote in secure world, so
introduce imx_l2c310_write_sec to support Linux running in
non-secure world configure PL310.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Dong Aisheng <aisheng.dong@nxp.com>
---
V2:
Use SPDX Tag
Use CONFIG_HAVE_ARM_SMCCC to fix build error for armv5.
Add IS_ENABLED(CONFIG_OPTEE) check when assigning write_sec
arch/arm/mach-imx/system.c | 27 ++++++++++++++++++++++++++-
include/soc/imx/imx_sip_smc.h | 21 +++++++++++++++++++++
2 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 include/soc/imx/imx_sip_smc.h
diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
index c06af650e6b1..2c27e52d8c7d 100644
--- a/arch/arm/mach-imx/system.c
+++ b/arch/arm/mach-imx/system.c
@@ -23,11 +23,13 @@
#include <linux/delay.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <soc/imx/imx_sip_smc.h>
#include <asm/system_misc.h>
#include <asm/proc-fns.h>
#include <asm/mach-types.h>
#include <asm/hardware/cache-l2x0.h>
+#include <asm/outercache.h>
#include "common.h"
#include "hardware.h"
@@ -92,6 +94,22 @@ void __init imx1_reset_init(void __iomem *base)
#endif
#ifdef CONFIG_CACHE_L2X0
+#ifdef CONFIG_HAVE_ARM_SMCCC
+void imx_l2c310_write_sec(unsigned long val, unsigned int reg)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_SMC_L2C310, val, reg, 0, 0, 0, 0, 0, &res);
+
+ if (res.a0 != 0)
+ pr_err("Failed to write l2c310 0x%x: 0x%lx\n", reg, res.a0);
+}
+#else
+void imx_l2c310_write_sec(unsigned long val, unsigned int reg)
+{
+}
+#endif
+
void __init imx_init_l2cache(void)
{
void __iomem *l2x0_base;
@@ -102,6 +120,10 @@ void __init imx_init_l2cache(void)
if (!np)
return;
+ if (IS_ENABLED(CONFIG_OPTEE) &&
+ of_find_compatible_node(NULL, NULL, "linaro,optee-tz"))
+ outer_cache.write_sec = imx_l2c310_write_sec;
+
l2x0_base = of_iomap(np, 0);
if (!l2x0_base)
goto put_node;
@@ -117,7 +139,10 @@ void __init imx_init_l2cache(void)
val &= ~L310_PREFETCH_CTRL_OFFSET_MASK;
val |= 15;
- writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
+ if (outer_cache.write_sec)
+ outer_cache.write_sec(val, L310_PREFETCH_CTRL);
+ else
+ writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
}
iounmap(l2x0_base);
diff --git a/include/soc/imx/imx_sip_smc.h b/include/soc/imx/imx_sip_smc.h
new file mode 100644
index 000000000000..c35ae69e0d2f
--- /dev/null
+++ b/include/soc/imx/imx_sip_smc.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#ifndef __IMX_SIP_SMC_H_
+#define __IMX_SIP_SMC_H_
+
+#include <linux/arm-smccc.h>
+
+#define IMX_SIP_SMC_VAL(func) ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+ ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_SIP, \
+ (func))
+
+#define IMX_L2C310 0x1
+
+#define IMX_SIP_SMC_L2C310 IMX_SIP_SMC_VAL(IMX_L2C310)
+
+#endif
--
2.14.1
^ permalink raw reply related
* [PATCH v5 03/12] dt-bindings: display: sun4i-drm: Add LVDS properties
From: Jernej Škrabec @ 2017-12-30 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ddbde28fe2e4f21412974e4c69fbfe1c5ff9383f.1513854122.git-series.maxime.ripard@free-electrons.com>
Hi Maxime,
Dne ?etrtek, 21. december 2017 ob 12:02:29 CET je Maxime Ripard napisal(a):
> Some clocks and resets supposed to drive the LVDS logic in the display
> engine have been overlooked when the driver was first introduced.
>
> Add those additional resources to the binding, and we'll deal with the ABI
> stability in the code.
>
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 9 +++++++-
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> 50cc72ee1168..1e21cfaac9e2 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -121,6 +121,15 @@ Required properties:
> On SoCs other than the A33 and V3s, there is one more clock required:
> - 'tcon-ch1': The clock driving the TCON channel 1
>
> +On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you
> +need one more reset line:
> + - 'lvds': The reset line driving the LVDS logic
> +
> +And on the SoCs newer than the A31 (sun6i and sun8i families), you
> +need one more clock line:
> + - 'lvds-alt': An alternative clock source, separate from the TCON
> channel 0 + clock, that can be used to drive the LVDS clock
I think this wording is imprecise, since A83T is part of the sun8i family, but
from the code (patch 7) and DT changes (patch 9) you do, it doesn't need this
property.
Maybe it would be just easier to enumerate all compatibles which needs this
property?
Best regards,
Jernej
^ permalink raw reply
* [PATCH 1/6] phy: sun4i-usb: add support for R40 USB PHY
From: Icenowy Zheng @ 2017-12-30 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <020a2b04-dbcc-032a-89d1-75479dd436e7@ti.com>
? 2017?10?18???? CST ??7:46:08?Kishon Vijay Abraham I ???
> On Wednesday 18 October 2017 05:12 PM, Maxime Ripard wrote:
> > On Wed, Oct 18, 2017 at 05:09:00PM +0530, Kishon Vijay Abraham I wrote:
> >> Hi,
> >>
> >> On Tuesday 10 October 2017 02:28 AM, Maxime Ripard wrote:
> >>> On Sun, Oct 08, 2017 at 04:29:01AM +0000, Icenowy Zheng wrote:
> >>>> Allwinner R40 features a USB PHY like the one in A64, but with 3 PHYs.
> >>>>
> >>>> Add support for it.
> >>>>
> >>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >>>
> >>> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>
> >> Is this patch good to be merged? I see you have pending comments on the
> >> other patch in the series.
> >
> > Yeah, but I guess you can merge this one, it's pretty harmless, and it
> > will reduce the amount of patches to review / merge later on.
>
> Thank you for the quick reply.
>
> merged with Maxime's and Rob's Ack.
Sorry, but I didn't see the patch appears in linux-next for such long time.
Is it lost?
>
> Thanks
> Kishon
^ permalink raw reply
* [PATCH v4 6/6] arm64: allwinner: a64: add HDMI regulator to all DTs' simplefb_hdmi
From: Icenowy Zheng @ 2017-12-30 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230113043.30237-1-icenowy@aosc.io>
On usual A64 board design the power of HDMI controller is connected to
DLDO1 of the AXP803 PMIC. If this regulator is shut down, the HDMI
output will be blank. Therefore the simplefb driver should keep this
regulator on.
Add the regulator to all currently available A64 boards' simplefb_hdmi
device node.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
New patch introduced in v4.
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts | 4 ++++
6 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index a6975670cd1c..f98c496e1f30 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -283,6 +283,10 @@
regulator-name = "vcc-rtc";
};
+&simplefb_hdmi {
+ vcc-hdmi-supply = <®_dldo1>;
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index 2beef9e6cb88..7cbbbf238f4f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -196,6 +196,10 @@
regulator-name = "vcc-rtc";
};
+&simplefb_hdmi {
+ vcc-hdmi-supply = <®_dldo1>;
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index 8807664f363a..568de83427d0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -215,6 +215,10 @@
regulator-name = "vcc-rtc";
};
+&simplefb_hdmi {
+ vcc-hdmi-supply = <®_dldo1>;
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
index 240d35731d10..ce38080db324 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
@@ -192,6 +192,10 @@
regulator-name = "vcc-rtc";
};
+&simplefb_hdmi {
+ vcc-hdmi-supply = <®_dldo1>;
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 604cdaedac38..40d9802959c4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -230,6 +230,10 @@
regulator-name = "vcc-rtc";
};
+&simplefb_hdmi {
+ vcc-hdmi-supply = <®_dldo1>;
+};
+
/* On Exp and Euler connectors */
&uart0 {
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
index abe179de35d7..c21f2331add6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts
@@ -134,6 +134,10 @@
regulator-name = "vcc-wifi";
};
+&simplefb_hdmi {
+ vcc-hdmi-supply = <®_dldo1>;
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.14.2
^ permalink raw reply related
* [PATCH v4 5/6] arm64: allwinner: a64: add simplefb for A64 SoC
From: Icenowy Zheng @ 2017-12-30 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230113043.30237-1-icenowy@aosc.io>
The A64 SoC features two display pipelines, one has a LCD output, the
other has a HDMI output.
Add support for simplefb for these pipelines on A64 SoC.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v4:
- Dropped extra clocks.
- Added labels to the SimpleFB device tree nodes as boards may have
extra regulator for display pipeline.
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index fb8ea7c414e1..d803c115d362 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -42,9 +42,11 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include <dt-bindings/clock/sun8i-de2.h>
#include <dt-bindings/clock/sun50i-a64-ccu.h>
#include <dt-bindings/clock/sun8i-r-ccu.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset/sun8i-de2.h>
#include <dt-bindings/reset/sun50i-a64-ccu.h>
/ {
@@ -52,6 +54,30 @@
#address-cells = <1>;
#size-cells = <1>;
+ chosen {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ simplefb_lcd: framebuffer-lcd {
+ compatible = "allwinner,simple-framebuffer",
+ "simple-framebuffer";
+ allwinner,pipeline = "mixer0-lcd0";
+ clocks = <&display_clocks CLK_MIXER0>,
+ <&ccu CLK_TCON0>;
+ status = "disabled";
+ };
+
+ simplefb_hdmi: framebuffer-hdmi {
+ compatible = "allwinner,simple-framebuffer",
+ "simple-framebuffer";
+ allwinner,pipeline = "mixer1-lcd1-hdmi";
+ clocks = <&display_clocks CLK_MIXER1>,
+ <&ccu CLK_TCON1>, <&ccu CLK_HDMI>;
+ status = "disabled";
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
--
2.14.2
^ permalink raw reply related
* [PATCH v4 4/6] arm64: allwinner: a64: add DE2 CCU for A64 SoC
From: Icenowy Zheng @ 2017-12-30 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230113043.30237-1-icenowy@aosc.io>
The A64 SoC features a DE2 CCU like the one in H5, but needs to claim a
section of SRAM (SRAM C) to be accessed.
Adds the device tree nodes for the SRAM controller and the DE2 CCU.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v3:
- Fixed the alliwnner,sram property (the 1 after SRAM phadle is missing
in v2).
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 34 +++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index d783d164b9c3..fb8ea7c414e1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -130,6 +130,40 @@
#size-cells = <1>;
ranges;
+ display_clocks: clock at 1000000 {
+ compatible = "allwinner,sun50i-a64-de2-clk";
+ reg = <0x01000000 0x100000>;
+ clocks = <&ccu CLK_DE>,
+ <&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ allwinner,sram = <&de2_sram 1>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ sram-controller at 1c00000 {
+ compatible = "allwinner,sun50i-a64-sram-controller";
+ reg = <0x01c00000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ sram_c: sram at 18000 {
+ compatible = "mmio-sram";
+ reg = <0x00018000 0x28000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x00018000 0x28000>;
+
+ de2_sram: sram-section at 0 {
+ compatible = "allwinner,sun50i-a64-sram-c";
+ reg = <0x0000 0x28000>;
+ };
+ };
+ };
+
syscon: syscon at 1c00000 {
compatible = "allwinner,sun50i-a64-system-controller",
"syscon";
--
2.14.2
^ permalink raw reply related
* [PATCH v4 3/6] clk: sunxi-ng: add support for Allwinner A64 DE2 CCU
From: Icenowy Zheng @ 2017-12-30 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230113043.30237-1-icenowy@aosc.io>
Allwinner A64's DE2 needs to claim a section of SRAM (SRAM C) to work.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v4:
- Use a struct to maintain both ccu desc and quirks as Chen-Yu Tsai
suggested.
drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 117 +++++++++++++++++++++++------------
1 file changed, 77 insertions(+), 40 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
index 468d1abaf0ee..b65953b32bd0 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-de2.c
@@ -17,6 +17,7 @@
#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/reset.h>
+#include <linux/soc/sunxi/sunxi_sram.h>
#include "ccu_common.h"
#include "ccu_div.h"
@@ -156,44 +157,70 @@ static struct ccu_reset_map sun50i_a64_de2_resets[] = {
[RST_WB] = { 0x08, BIT(2) },
};
-static const struct sunxi_ccu_desc sun8i_a83t_de2_clk_desc = {
- .ccu_clks = sun8i_a83t_de2_clks,
- .num_ccu_clks = ARRAY_SIZE(sun8i_a83t_de2_clks),
+struct de2_ccu {
+ struct sunxi_ccu_desc desc;
+ bool sram_needed;
+};
+
+static const struct de2_ccu sun8i_a83t_de2_clk = {
+ .desc = {
+ .ccu_clks = sun8i_a83t_de2_clks,
+ .num_ccu_clks = ARRAY_SIZE(sun8i_a83t_de2_clks),
+
+ .hw_clks = &sun8i_a83t_de2_hw_clks,
+
+ .resets = sun8i_a83t_de2_resets,
+ .num_resets = ARRAY_SIZE(sun8i_a83t_de2_resets),
+ },
+};
+
+static const struct de2_ccu sun8i_h3_de2_clk = {
+ .desc = {
+ .ccu_clks = sun8i_h3_de2_clks,
+ .num_ccu_clks = ARRAY_SIZE(sun8i_h3_de2_clks),
- .hw_clks = &sun8i_a83t_de2_hw_clks,
+ .hw_clks = &sun8i_h3_de2_hw_clks,
- .resets = sun8i_a83t_de2_resets,
- .num_resets = ARRAY_SIZE(sun8i_a83t_de2_resets),
+ .resets = sun8i_a83t_de2_resets,
+ .num_resets = ARRAY_SIZE(sun8i_a83t_de2_resets),
+ },
};
-static const struct sunxi_ccu_desc sun8i_h3_de2_clk_desc = {
- .ccu_clks = sun8i_h3_de2_clks,
- .num_ccu_clks = ARRAY_SIZE(sun8i_h3_de2_clks),
+static const struct de2_ccu sun50i_a64_de2_clk = {
+ .desc = {
+ .ccu_clks = sun8i_h3_de2_clks,
+ .num_ccu_clks = ARRAY_SIZE(sun8i_h3_de2_clks),
- .hw_clks = &sun8i_h3_de2_hw_clks,
+ .hw_clks = &sun8i_h3_de2_hw_clks,
- .resets = sun8i_a83t_de2_resets,
- .num_resets = ARRAY_SIZE(sun8i_a83t_de2_resets),
+ .resets = sun50i_a64_de2_resets,
+ .num_resets = ARRAY_SIZE(sun50i_a64_de2_resets),
+ },
+ .sram_needed = true,
};
-static const struct sunxi_ccu_desc sun50i_a64_de2_clk_desc = {
- .ccu_clks = sun8i_h3_de2_clks,
- .num_ccu_clks = ARRAY_SIZE(sun8i_h3_de2_clks),
+static const struct de2_ccu sun50i_h5_de2_clk = {
+ .desc = {
+ .ccu_clks = sun8i_h3_de2_clks,
+ .num_ccu_clks = ARRAY_SIZE(sun8i_h3_de2_clks),
- .hw_clks = &sun8i_h3_de2_hw_clks,
+ .hw_clks = &sun8i_h3_de2_hw_clks,
- .resets = sun50i_a64_de2_resets,
- .num_resets = ARRAY_SIZE(sun50i_a64_de2_resets),
+ .resets = sun50i_a64_de2_resets,
+ .num_resets = ARRAY_SIZE(sun50i_a64_de2_resets),
+ },
};
-static const struct sunxi_ccu_desc sun8i_v3s_de2_clk_desc = {
- .ccu_clks = sun8i_v3s_de2_clks,
- .num_ccu_clks = ARRAY_SIZE(sun8i_v3s_de2_clks),
+static const struct de2_ccu sun8i_v3s_de2_clk = {
+ .desc = {
+ .ccu_clks = sun8i_v3s_de2_clks,
+ .num_ccu_clks = ARRAY_SIZE(sun8i_v3s_de2_clks),
- .hw_clks = &sun8i_v3s_de2_hw_clks,
+ .hw_clks = &sun8i_v3s_de2_hw_clks,
- .resets = sun8i_a83t_de2_resets,
- .num_resets = ARRAY_SIZE(sun8i_a83t_de2_resets),
+ .resets = sun8i_a83t_de2_resets,
+ .num_resets = ARRAY_SIZE(sun8i_a83t_de2_resets),
+ },
};
static int sunxi_de2_clk_probe(struct platform_device *pdev)
@@ -202,11 +229,11 @@ static int sunxi_de2_clk_probe(struct platform_device *pdev)
struct clk *bus_clk, *mod_clk;
struct reset_control *rstc;
void __iomem *reg;
- const struct sunxi_ccu_desc *ccu_desc;
+ const struct de2_ccu *ccu;
int ret;
- ccu_desc = of_device_get_match_data(&pdev->dev);
- if (!ccu_desc)
+ ccu = of_device_get_match_data(&pdev->dev);
+ if (!ccu)
return -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -239,11 +266,20 @@ static int sunxi_de2_clk_probe(struct platform_device *pdev)
return ret;
}
+ if (ccu->sram_needed) {
+ ret = sunxi_sram_claim(&pdev->dev);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Error couldn't map SRAM to device\n");
+ return ret;
+ }
+ }
+
/* The clocks need to be enabled for us to access the registers */
ret = clk_prepare_enable(bus_clk);
if (ret) {
dev_err(&pdev->dev, "Couldn't enable bus clk: %d\n", ret);
- return ret;
+ goto err_release_sram;
}
ret = clk_prepare_enable(mod_clk);
@@ -260,7 +296,7 @@ static int sunxi_de2_clk_probe(struct platform_device *pdev)
goto err_disable_mod_clk;
}
- ret = sunxi_ccu_probe(pdev->dev.of_node, reg, ccu_desc);
+ ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &ccu->desc);
if (ret)
goto err_assert_reset;
@@ -272,33 +308,34 @@ static int sunxi_de2_clk_probe(struct platform_device *pdev)
clk_disable_unprepare(mod_clk);
err_disable_bus_clk:
clk_disable_unprepare(bus_clk);
+err_release_sram:
+ if (ccu->sram_needed)
+ sunxi_sram_release(&pdev->dev);
+
return ret;
}
static const struct of_device_id sunxi_de2_clk_ids[] = {
{
.compatible = "allwinner,sun8i-a83t-de2-clk",
- .data = &sun8i_a83t_de2_clk_desc,
+ .data = &sun8i_a83t_de2_clk,
},
{
.compatible = "allwinner,sun8i-h3-de2-clk",
- .data = &sun8i_h3_de2_clk_desc,
+ .data = &sun8i_h3_de2_clk,
},
{
.compatible = "allwinner,sun8i-v3s-de2-clk",
- .data = &sun8i_v3s_de2_clk_desc,
+ .data = &sun8i_v3s_de2_clk,
+ },
+ {
+ .compatible = "allwinner,sun50i-a64-de2-clk",
+ .data = &sun50i_a64_de2_clk,
},
{
.compatible = "allwinner,sun50i-h5-de2-clk",
- .data = &sun50i_a64_de2_clk_desc,
+ .data = &sun50i_h5_de2_clk,
},
- /*
- * The Allwinner A64 SoC needs some bit to be poke in syscon to make
- * DE2 really working.
- * So there's currently no A64 compatible here.
- * H5 shares the same reset line with A64, so here H5 is using the
- * clock description of A64.
- */
{ }
};
--
2.14.2
^ 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