* [PATCH next v10 07/11] usb: roles: Add fwnode_usb_role_switch_get() function
From: Chunfeng Yun @ 2019-08-23 7:57 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, devicetree, Hans de Goede, Heikki Krogerus,
Badhri Jagan Sridharan, Linus Walleij, linux-usb, linux-kernel,
Matthias Brugger, Andy Shevchenko, linux-mediatek, Min Guo,
Chunfeng Yun, Nagarjuna Kristam, Adam Thomson, linux-arm-kernel,
Li Jun
In-Reply-To: <1566547041-20804-1-git-send-email-chunfeng.yun@mediatek.com>
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
The fwnode_usb_role_switch_get() function is exactly the
same as usb_role_switch_get(), except that it takes struct
fwnode_handle as parameter instead of struct device.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Tested-by: Biju Das <biju.das@bp.renesas.com>
---
v10:
revert changes of v9
v9:
replace signed-off-by by suggested-by Heikki
v8: no changes
v7:
add signed-off-by Chunfeng and tested-by Biju
v6:
new patch
---
drivers/usb/roles/class.c | 20 ++++++++++++++++++++
include/linux/usb/role.h | 7 +++++++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
index 0526efbc4922..2abb6fe384ca 100644
--- a/drivers/usb/roles/class.c
+++ b/drivers/usb/roles/class.c
@@ -123,6 +123,26 @@ struct usb_role_switch *usb_role_switch_get(struct device *dev)
}
EXPORT_SYMBOL_GPL(usb_role_switch_get);
+/**
+ * fwnode_usb_role_switch_get - Find USB role switch linked with the caller
+ * @fwnode: The caller device node
+ *
+ * This is similar to the usb_role_switch_get() function above, but it searches
+ * the switch using fwnode instead of device entry.
+ */
+struct usb_role_switch *fwnode_usb_role_switch_get(struct fwnode_handle *fwnode)
+{
+ struct usb_role_switch *sw;
+
+ sw = fwnode_connection_find_match(fwnode, "usb-role-switch", NULL,
+ usb_role_switch_match);
+ if (!IS_ERR_OR_NULL(sw))
+ WARN_ON(!try_module_get(sw->dev.parent->driver->owner));
+
+ return sw;
+}
+EXPORT_SYMBOL_GPL(fwnode_usb_role_switch_get);
+
/**
* usb_role_switch_put - Release handle to a switch
* @sw: USB Role Switch
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index da2b9641b877..2d77f97df72d 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -47,6 +47,7 @@ struct usb_role_switch_desc {
int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
struct usb_role_switch *usb_role_switch_get(struct device *dev);
+struct usb_role_switch *fwnode_usb_role_switch_get(struct fwnode_handle *node);
void usb_role_switch_put(struct usb_role_switch *sw);
struct usb_role_switch *
@@ -70,6 +71,12 @@ static inline struct usb_role_switch *usb_role_switch_get(struct device *dev)
return ERR_PTR(-ENODEV);
}
+static inline struct usb_role_switch *
+fwnode_usb_role_switch_get(struct fwnode_handle *node)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void usb_role_switch_put(struct usb_role_switch *sw) { }
static inline struct usb_role_switch *
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH next v10 11/11] usb: mtu3: register a USB Role Switch for dual role mode
From: Chunfeng Yun @ 2019-08-23 7:57 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, devicetree, Hans de Goede, Heikki Krogerus,
Badhri Jagan Sridharan, Linus Walleij, linux-usb, linux-kernel,
Matthias Brugger, Andy Shevchenko, linux-mediatek, Min Guo,
Chunfeng Yun, Nagarjuna Kristam, Adam Thomson, linux-arm-kernel,
Li Jun
In-Reply-To: <1566547041-20804-1-git-send-email-chunfeng.yun@mediatek.com>
Because extcon is not allowed for new bindings, and the
dual role switch is supported by USB Role Switch,
especially for Type-C drivers, so register a USB Role
Switch to support the new way
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v5~v10 no changes
v4 changes:
1. assign fwnode member of usb_role_switch struct suggested by Heikki
v3 changes:
1. select USB_ROLE_SWITCH in Kconfig suggested by Heikki
2. rename ssusb_mode_manual_switch() to ssusb_mode_switch()
v2 no changes
---
drivers/usb/mtu3/Kconfig | 1 +
drivers/usb/mtu3/mtu3.h | 5 ++++
drivers/usb/mtu3/mtu3_debugfs.c | 4 +--
drivers/usb/mtu3/mtu3_dr.c | 48 ++++++++++++++++++++++++++++++++-
drivers/usb/mtu3/mtu3_dr.h | 6 ++---
drivers/usb/mtu3/mtu3_plat.c | 3 ++-
6 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 928c2cd6fc00..bf98fd36341d 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -44,6 +44,7 @@ config USB_MTU3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || USB_GADGET=USB_MTU3))
depends on (EXTCON=y || EXTCON=USB_MTU3)
+ select USB_ROLE_SWITCH
help
This is the default mode of working of MTU3 controller where
both host and gadget features are enabled.
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 76ecf12fdf62..6087be236a35 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -199,6 +199,9 @@ struct mtu3_gpd_ring {
* @id_nb : notifier for iddig(idpin) detection
* @id_work : work of iddig detection notifier
* @id_event : event of iddig detecion notifier
+* @role_sw : use USB Role Switch to support dual-role switch, can't use
+* extcon at the same time, and extcon is deprecated.
+* @role_sw_used : true when the USB Role Switch is used.
* @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
* @manual_drd_enabled: it's true when supports dual-role device by debugfs
* to switch host/device modes depending on user input.
@@ -212,6 +215,8 @@ struct otg_switch_mtk {
struct notifier_block id_nb;
struct work_struct id_work;
unsigned long id_event;
+ struct usb_role_switch *role_sw;
+ bool role_sw_used;
bool is_u3_drd;
bool manual_drd_enabled;
};
diff --git a/drivers/usb/mtu3/mtu3_debugfs.c b/drivers/usb/mtu3/mtu3_debugfs.c
index 62c57ddc554e..c96e5dab0a48 100644
--- a/drivers/usb/mtu3/mtu3_debugfs.c
+++ b/drivers/usb/mtu3/mtu3_debugfs.c
@@ -453,9 +453,9 @@ static ssize_t ssusb_mode_write(struct file *file, const char __user *ubuf,
return -EFAULT;
if (!strncmp(buf, "host", 4) && !ssusb->is_host) {
- ssusb_mode_manual_switch(ssusb, 1);
+ ssusb_mode_switch(ssusb, 1);
} else if (!strncmp(buf, "device", 6) && ssusb->is_host) {
- ssusb_mode_manual_switch(ssusb, 0);
+ ssusb_mode_switch(ssusb, 0);
} else {
dev_err(ssusb->dev, "wrong or duplicated setting\n");
return -EINVAL;
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index 5fcb71af875a..08e18448e8b8 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -7,6 +7,8 @@
* Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
*/
+#include <linux/usb/role.h>
+
#include "mtu3.h"
#include "mtu3_dr.h"
#include "mtu3_debug.h"
@@ -280,7 +282,7 @@ static int ssusb_extcon_register(struct otg_switch_mtk *otg_sx)
* This is useful in special cases, such as uses TYPE-A receptacle but also
* wants to support dual-role mode.
*/
-void ssusb_mode_manual_switch(struct ssusb_mtk *ssusb, int to_host)
+void ssusb_mode_switch(struct ssusb_mtk *ssusb, int to_host)
{
struct otg_switch_mtk *otg_sx = &ssusb->otg_switch;
@@ -318,6 +320,47 @@ void ssusb_set_force_mode(struct ssusb_mtk *ssusb,
mtu3_writel(ssusb->ippc_base, SSUSB_U2_CTRL(0), value);
}
+static int ssusb_role_sw_set(struct device *dev, enum usb_role role)
+{
+ struct ssusb_mtk *ssusb = dev_get_drvdata(dev);
+ bool to_host = false;
+
+ if (role == USB_ROLE_HOST)
+ to_host = true;
+
+ if (to_host ^ ssusb->is_host)
+ ssusb_mode_switch(ssusb, to_host);
+
+ return 0;
+}
+
+static enum usb_role ssusb_role_sw_get(struct device *dev)
+{
+ struct ssusb_mtk *ssusb = dev_get_drvdata(dev);
+ enum usb_role role;
+
+ role = ssusb->is_host ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+
+ return role;
+}
+
+static int ssusb_role_sw_register(struct otg_switch_mtk *otg_sx)
+{
+ struct usb_role_switch_desc role_sx_desc = { 0 };
+ struct ssusb_mtk *ssusb =
+ container_of(otg_sx, struct ssusb_mtk, otg_switch);
+
+ if (!otg_sx->role_sw_used)
+ return 0;
+
+ role_sx_desc.set = ssusb_role_sw_set;
+ role_sx_desc.get = ssusb_role_sw_get;
+ role_sx_desc.fwnode = dev_fwnode(ssusb->dev);
+ otg_sx->role_sw = usb_role_switch_register(ssusb->dev, &role_sx_desc);
+
+ return PTR_ERR_OR_ZERO(otg_sx->role_sw);
+}
+
int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
{
struct otg_switch_mtk *otg_sx = &ssusb->otg_switch;
@@ -328,6 +371,8 @@ int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
if (otg_sx->manual_drd_enabled)
ssusb_dr_debugfs_init(ssusb);
+ else if (otg_sx->role_sw_used)
+ ret = ssusb_role_sw_register(otg_sx);
else
ret = ssusb_extcon_register(otg_sx);
@@ -340,4 +385,5 @@ void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
cancel_work_sync(&otg_sx->id_work);
cancel_work_sync(&otg_sx->vbus_work);
+ usb_role_switch_unregister(otg_sx->role_sw);
}
diff --git a/drivers/usb/mtu3/mtu3_dr.h b/drivers/usb/mtu3/mtu3_dr.h
index ba6fe357ce29..5e58c4dbd54a 100644
--- a/drivers/usb/mtu3/mtu3_dr.h
+++ b/drivers/usb/mtu3/mtu3_dr.h
@@ -71,7 +71,7 @@ static inline void ssusb_gadget_exit(struct ssusb_mtk *ssusb)
#if IS_ENABLED(CONFIG_USB_MTU3_DUAL_ROLE)
int ssusb_otg_switch_init(struct ssusb_mtk *ssusb);
void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb);
-void ssusb_mode_manual_switch(struct ssusb_mtk *ssusb, int to_host);
+void ssusb_mode_switch(struct ssusb_mtk *ssusb, int to_host);
int ssusb_set_vbus(struct otg_switch_mtk *otg_sx, int is_on);
void ssusb_set_force_mode(struct ssusb_mtk *ssusb,
enum mtu3_dr_force_mode mode);
@@ -86,8 +86,8 @@ static inline int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
static inline void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
{}
-static inline void
-ssusb_mode_manual_switch(struct ssusb_mtk *ssusb, int to_host) {}
+static inline void ssusb_mode_switch(struct ssusb_mtk *ssusb, int to_host)
+{}
static inline int ssusb_set_vbus(struct otg_switch_mtk *otg_sx, int is_on)
{
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index fd0f6c5dfbc1..9c256ea3cdf5 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -299,8 +299,9 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
otg_sx->is_u3_drd = of_property_read_bool(node, "mediatek,usb3-drd");
otg_sx->manual_drd_enabled =
of_property_read_bool(node, "enable-manual-drd");
+ otg_sx->role_sw_used = of_property_read_bool(node, "usb-role-switch");
- if (of_property_read_bool(node, "extcon")) {
+ if (!otg_sx->role_sw_used && of_property_read_bool(node, "extcon")) {
otg_sx->edev = extcon_get_edev_by_phandle(ssusb->dev, 0);
if (IS_ERR(otg_sx->edev)) {
dev_err(ssusb->dev, "couldn't get extcon device\n");
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 0/2] improve the concurrency of arm_smmu_atc_inv_domain()
From: Leizhen (ThunderTown) @ 2019-08-23 8:06 UTC (permalink / raw)
To: Will Deacon
Cc: Jean-Philippe Brucker, Joerg Roedel, John Garry, iommu,
Robin Murphy, linux-arm-kernel
In-Reply-To: <20190823075026.pwlx33e4crh3m6tn@willie-the-truck>
On 2019/8/23 15:50, Will Deacon wrote:
> On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote:
>> v2 --> v3:
>> As Will Deacon's suggestion, I changed the lock type of
>> arm_smmu_domain.devices_lock from spinlock_t to rwlock_t, and I saw that the
>> performance is all right. And further use nr_ats_masters to quickly check have
>> no obvious effect, so I drop it.
>
> :/
>
> I already sent two versions of a series fixing this without any locking at
> all on the ->unmap() path, and you were on cc. I've also queued that stuff
> up.
>
> Did you not receive my patches?
Sorry, my message filter setting is a bit wrong, must contains
"linux-kernel@vger.kernel.org", I have corrected it.
>
> v1: https://lists.linuxfoundation.org/pipermail/iommu/2019-August/038306.html
> v2: https://lists.linuxfoundation.org/pipermail/iommu/2019-August/038374.html
OK, I will test it when it's my turn to use the board.
>
> Queued: https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/smmu-v3
>
> Will
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] i2c: mediatek: disable zero-length transfers for mt8183
From: Qii Wang @ 2019-08-23 8:09 UTC (permalink / raw)
To: Hsin-Yi Wang
Cc: Nicolas Boichat, Alexandru M Stan, Wolfram Sang, Jun Gao,
linux-kernel, linux-mediatek, linux-i2c, Matthias Brugger,
Yingjoe Chen, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190822094516.55130-1-hsinyi@chromium.org>
On Thu, 2019-08-22 at 17:45 +0800, Hsin-Yi Wang wrote:
> When doing i2cdetect quick write mode, we would get transfer
> error ENOMEM, and i2cdetect shows there's no device at the address.
> Quoting from mt8183 datasheet, the number of transfers to be
> transferred in one transaction should be set to bigger than 1,
> so we should forbid zero-length transfer and update functionality.
>
> Incorrect return:
> localhost ~ # i2cdetect -q -y 0
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: -- -- -- -- -- -- -- -- -- -- -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --
>
> After this patch:
> localhost ~ # i2cdetect -q -y 0
> Error: Can't use SMBus Quick Write command on this bus
>
> localhost ~ # i2cdetect -y 0
> Warning: Can't use SMBus Quick Write command, will skip some addresses
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00:
> 10:
> 20:
> 30: -- -- -- -- -- -- -- --
> 40:
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60:
> 70:
>
> Reported-by: Alexandru M Stan <amstan@chromium.org>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> ---
> Change from v1:
> * restore the order of algo and quirks
> ---
> drivers/i2c/busses/i2c-mt65xx.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 252edb433fdf..29eae1bf4f86 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -234,6 +234,10 @@ static const struct i2c_adapter_quirks mt7622_i2c_quirks = {
> .max_num_msgs = 255,
> };
>
> +static const struct i2c_adapter_quirks mt8183_i2c_quirks = {
> + .flags = I2C_AQ_NO_ZERO_LEN,
> +};
> +
> static const struct mtk_i2c_compatible mt2712_compat = {
> .regs = mt_i2c_regs_v1,
> .pmic_i2c = 0,
> @@ -298,6 +302,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
> };
>
> static const struct mtk_i2c_compatible mt8183_compat = {
> + .quirks = &mt8183_i2c_quirks,
> .regs = mt_i2c_regs_v2,
> .pmic_i2c = 0,
> .dcm = 0,
> @@ -870,7 +875,11 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id)
>
> static u32 mtk_i2c_functionality(struct i2c_adapter *adap)
> {
> - return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> + if (adap->quirks->flags & I2C_AQ_NO_ZERO_LEN)
> + return I2C_FUNC_I2C |
> + (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
> + else
> + return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
It can be removed?
> }
>
> static const struct i2c_algorithm mtk_i2c_algorithm = {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] i2c: mediatek: disable zero-length transfers for mt8183
From: Hsin-Yi Wang @ 2019-08-23 8:13 UTC (permalink / raw)
To: Qii Wang
Cc: Nicolas Boichat, Alexandru M Stan, Wolfram Sang, Jun Gao, lkml,
linux-mediatek, linux-i2c, Matthias Brugger, Yingjoe Chen,
Thomas Gleixner,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1566547772.19935.2.camel@mhfsdcap03>
On Fri, Aug 23, 2019 at 4:09 PM Qii Wang <qii.wang@mediatek.com> wrote:
> >
> > static u32 mtk_i2c_functionality(struct i2c_adapter *adap)
> > {
> > - return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
> > + if (adap->quirks->flags & I2C_AQ_NO_ZERO_LEN)
> > + return I2C_FUNC_I2C |
> > + (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
> > + else
> > + return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
>
> It can be removed?
See previous discussion: https://patchwork.kernel.org/patch/10814391/#22484435
but not all SoC's quirks has I2C_AQ_NO_ZERO_LEN.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/3] arm64: meson-sm1: add support for the SM1 based VIM3
From: Neil Armstrong @ 2019-08-23 8:14 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
This patchset adds support for the Amlogic SM1 based Khadas VIM3 variant.
The S903D3 package variant of SM1 is pin-to-pin compatible with the
S922X and A311d, so only internal DT changes are needed :
- DVFS support is different
- Audio support not yet available for SM1
This patchset moved all the non-g12b nodes to meson-khadas-vim3.dtsi
and add the sm1 specific nodes into meson-sm1-khadas-vim3.dts.
Display has a color conversion bug on SM1 by using a more recent vendor
bootloader on the SM1 based VIM3, this is out of scope of this patchset
and will be fixed in the drm/meson driver.
Dependencies:
- patch 1,2: None
- patch 3: Depends on the "arm64: meson-sm1: add support for DVFS" patchset at [1]
[1] https://patchwork.kernel.org/cover/11109411/
Neil Armstrong (3):
arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi
amlogic: arm: add Amlogic SM1 based Khadas VIM3 variant bindings
arm64: dts: khadas-vim3: add support for the SM1 based VIM3
.../devicetree/bindings/arm/amlogic.yaml | 3 +-
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../amlogic/meson-g12b-a311d-khadas-vim3.dts | 1 +
.../dts/amlogic/meson-g12b-khadas-vim3.dtsi | 355 -----------------
.../amlogic/meson-g12b-s922x-khadas-vim3.dts | 1 +
.../boot/dts/amlogic/meson-khadas-vim3.dtsi | 360 ++++++++++++++++++
.../dts/amlogic/meson-sm1-khadas-vim3.dts | 69 ++++
7 files changed, 434 insertions(+), 356 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3.dts
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] amlogic: arm: add Amlogic SM1 based Khadas VIM3 variant bindings
From: Neil Armstrong @ 2019-08-23 8:14 UTC (permalink / raw)
To: khilman, devicetree
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190823081427.17228-1-narmstrong@baylibre.com>
The Khadas VIM3 is also available with the Pin-to-pin compatible
Amlogic SM1 SoC in the S905D3 variant package.
Change the description to match the S905X3/D3/Y3 variants like the G12A
description, and add the vim3 compatible.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index b48ea1e4913a..2751dd778ce0 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -150,9 +150,10 @@ properties:
- const: amlogic,s922x
- const: amlogic,g12b
- - description: Boards with the Amlogic Meson SM1 S905X3 SoC
+ - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
items:
- enum:
- seirobotics,sei610
+ - khadas,vim3
- const: amlogic,sm1
...
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi
From: Neil Armstrong @ 2019-08-23 8:14 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190823081427.17228-1-narmstrong@baylibre.com>
To prepare support of the Amlogic SM1 based Khadas VIM3, move the non-G12B
specific nodes (all except DVFS and Audio) to a new meson-khadas-vim3.dtsi
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../amlogic/meson-g12b-a311d-khadas-vim3.dts | 1 +
.../dts/amlogic/meson-g12b-khadas-vim3.dtsi | 355 -----------------
.../amlogic/meson-g12b-s922x-khadas-vim3.dts | 1 +
.../boot/dts/amlogic/meson-khadas-vim3.dtsi | 360 ++++++++++++++++++
4 files changed, 362 insertions(+), 355 deletions(-)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
index 73128ed24361..3a6a1e0c1e32 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "meson-g12b-a311d.dtsi"
+#include "meson-khadas-vim3.dtsi"
#include "meson-g12b-khadas-vim3.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
index 9c3ca2edc725..554863429aa6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-khadas-vim3.dtsi
@@ -5,116 +5,9 @@
* Copyright (c) 2019 Christian Hewitt <christianshewitt@gmail.com>
*/
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/gpio/meson-g12a-gpio.h>
#include <dt-bindings/sound/meson-g12a-tohdmitx.h>
/ {
- model = "Khadas VIM3";
-
- aliases {
- serial0 = &uart_AO;
- ethernet0 = ðmac;
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x0 0x0 0x80000000>;
- };
-
- adc-keys {
- compatible = "adc-keys";
- io-channels = <&saradc 2>;
- io-channel-names = "buttons";
- keyup-threshold-microvolt = <1710000>;
-
- button-function {
- label = "Function";
- linux,code = <KEY_FN>;
- press-threshold-microvolt = <10000>;
- };
- };
-
- leds {
- compatible = "gpio-leds";
-
- white {
- label = "vim3:white:sys";
- gpios = <&gpio_ao GPIOAO_4 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "heartbeat";
- };
-
- red {
- label = "vim3:red";
- gpios = <&gpio_expander 5 GPIO_ACTIVE_LOW>;
- };
- };
-
- emmc_pwrseq: emmc-pwrseq {
- compatible = "mmc-pwrseq-emmc";
- reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
- };
-
- gpio-keys-polled {
- compatible = "gpio-keys-polled";
- poll-interval = <100>;
-
- power-button {
- label = "power";
- linux,code = <KEY_POWER>;
- gpios = <&gpio_ao GPIOAO_7 GPIO_ACTIVE_LOW>;
- };
- };
-
- sdio_pwrseq: sdio-pwrseq {
- compatible = "mmc-pwrseq-simple";
- reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
- clocks = <&wifi32k>;
- clock-names = "ext_clock";
- };
-
- dc_in: regulator-dc_in {
- compatible = "regulator-fixed";
- regulator-name = "DC_IN";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-always-on;
- };
-
- vcc_5v: regulator-vcc_5v {
- compatible = "regulator-fixed";
- regulator-name = "VCC_5V";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&dc_in>;
-
- gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
- enable-active-high;
- };
-
- vcc_1v8: regulator-vcc_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_3v3>;
- regulator-always-on;
- };
-
- vcc_3v3: regulator-vcc_3v3 {
- compatible = "regulator-fixed";
- regulator-name = "VCC_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vsys_3v3>;
- regulator-always-on;
- /* FIXME: actually controlled by VDDCPU_B_EN */
- };
-
vddcpu_a: regulator-vddcpu-a {
/*
* MP8756GD Regulator.
@@ -153,62 +46,6 @@
regulator-always-on;
};
- vddao_1v8: regulator-vddao_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "VDDIO_AO1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vsys_3v3>;
- regulator-always-on;
- };
-
- emmc_1v8: regulator-emmc_1v8 {
- compatible = "regulator-fixed";
- regulator-name = "EMMC_AO1V8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_3v3>;
- regulator-always-on;
- };
-
- vsys_3v3: regulator-vsys_3v3 {
- compatible = "regulator-fixed";
- regulator-name = "VSYS_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&dc_in>;
- regulator-always-on;
- };
-
- usb_pwr: regulator-usb_pwr {
- compatible = "regulator-fixed";
- regulator-name = "USB_PWR";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&vcc_5v>;
-
- gpio = <&gpio GPIOA_6 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
- hdmi-connector {
- compatible = "hdmi-connector";
- type = "a";
-
- port {
- hdmi_connector_in: endpoint {
- remote-endpoint = <&hdmi_tx_tmds_out>;
- };
- };
- };
-
- wifi32k: wifi32k {
- compatible = "pwm-clock";
- #clock-cells = <0>;
- clock-frequency = <32768>;
- pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
- };
-
sound {
compatible = "amlogic,axg-sound-card";
model = "G12A-KHADAS-VIM3";
@@ -269,20 +106,6 @@
status = "okay";
};
-&cec_AO {
- pinctrl-0 = <&cec_ao_a_h_pins>;
- pinctrl-names = "default";
- status = "disabled";
- hdmi-phandle = <&hdmi_tx>;
-};
-
-&cecb_AO {
- pinctrl-0 = <&cec_ao_b_h_pins>;
- pinctrl-names = "default";
- status = "okay";
- hdmi-phandle = <&hdmi_tx>;
-};
-
&clkc_audio {
status = "okay";
};
@@ -329,31 +152,6 @@
clock-latency = <50000>;
};
-&ext_mdio {
- external_phy: ethernet-phy@0 {
- /* Realtek RTL8211F (0x001cc916) */
- reg = <0>;
- max-speed = <1000>;
-
- interrupt-parent = <&gpio_intc>;
- /* MAC_INTR on GPIOZ_14 */
- interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
- };
-};
-
-ðmac {
- pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
- pinctrl-names = "default";
- status = "okay";
- phy-mode = "rgmii";
- phy-handle = <&external_phy>;
- amlogic,tx-delay-ns = <2>;
-};
-
-&frddr_a {
- status = "okay";
-};
-
&frddr_b {
status = "okay";
};
@@ -362,46 +160,6 @@
status = "okay";
};
-&hdmi_tx {
- status = "okay";
- pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
- pinctrl-names = "default";
- hdmi-supply = <&vcc_5v>;
-};
-
-&hdmi_tx_tmds_port {
- hdmi_tx_tmds_out: endpoint {
- remote-endpoint = <&hdmi_connector_in>;
- };
-};
-
-&i2c_AO {
- status = "okay";
- pinctrl-0 = <&i2c_ao_sck_pins>, <&i2c_ao_sda_pins>;
- pinctrl-names = "default";
-
- gpio_expander: gpio-controller@20 {
- compatible = "ti,tca6408";
- reg = <0x20>;
- vcc-supply = <&vcc_3v3>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- rtc@51 {
- compatible = "haoyu,hym8563";
- reg = <0x51>;
- #clock-cells = <0>;
- };
-};
-
-&ir {
- status = "okay";
- pinctrl-0 = <&remote_input_ao_pins>;
- pinctrl-names = "default";
- linux,rc-map-name = "rc-khadas";
-};
-
&pwm_ab {
pinctrl-0 = <&pwm_a_e_pins>;
pinctrl-names = "default";
@@ -418,81 +176,6 @@
status = "okay";
};
-&pwm_ef {
- status = "okay";
- pinctrl-0 = <&pwm_e_pins>;
- pinctrl-names = "default";
-};
-
-&saradc {
- status = "okay";
- vref-supply = <&vddao_1v8>;
-};
-
-/* SDIO */
-&sd_emmc_a {
- status = "okay";
- pinctrl-0 = <&sdio_pins>;
- pinctrl-1 = <&sdio_clk_gate_pins>;
- pinctrl-names = "default", "clk-gate";
- #address-cells = <1>;
- #size-cells = <0>;
-
- bus-width = <4>;
- cap-sd-highspeed;
- sd-uhs-sdr50;
- max-frequency = <100000000>;
-
- non-removable;
- disable-wp;
-
- mmc-pwrseq = <&sdio_pwrseq>;
-
- vmmc-supply = <&vsys_3v3>;
- vqmmc-supply = <&vddao_1v8>;
-
- brcmf: wifi@1 {
- reg = <1>;
- compatible = "brcm,bcm4329-fmac";
- };
-};
-
-/* SD card */
-&sd_emmc_b {
- status = "okay";
- pinctrl-0 = <&sdcard_c_pins>;
- pinctrl-1 = <&sdcard_clk_gate_c_pins>;
- pinctrl-names = "default", "clk-gate";
-
- bus-width = <4>;
- cap-sd-highspeed;
- max-frequency = <50000000>;
- disable-wp;
-
- cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
- vmmc-supply = <&vsys_3v3>;
- vqmmc-supply = <&vsys_3v3>;
-};
-
-/* eMMC */
-&sd_emmc_c {
- status = "okay";
- pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
- pinctrl-1 = <&emmc_clk_gate_pins>;
- pinctrl-names = "default", "clk-gate";
-
- bus-width = <8>;
- cap-mmc-highspeed;
- mmc-ddr-1_8v;
- mmc-hs200-1_8v;
- max-frequency = <200000000>;
- disable-wp;
-
- mmc-pwrseq = <&emmc_pwrseq>;
- vmmc-supply = <&vcc_3v3>;
- vqmmc-supply = <&emmc_1v8>;
-};
-
&tdmif_b {
status = "okay";
};
@@ -504,41 +187,3 @@
&tohdmitx {
status = "okay";
};
-
-&uart_A {
- status = "okay";
- pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
- pinctrl-names = "default";
- uart-has-rtscts;
-
- bluetooth {
- compatible = "brcm,bcm43438-bt";
- shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
- max-speed = <2000000>;
- clocks = <&wifi32k>;
- clock-names = "lpo";
- };
-};
-
-&uart_AO {
- status = "okay";
- pinctrl-0 = <&uart_ao_a_pins>;
- pinctrl-names = "default";
-};
-
-&usb2_phy0 {
- phy-supply = <&dc_in>;
-};
-
-&usb2_phy1 {
- phy-supply = <&usb_pwr>;
-};
-
-&usb3_pcie_phy {
- phy-supply = <&usb_pwr>;
-};
-
-&usb {
- status = "okay";
- dr_mode = "peripheral";
-};
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
index 6bcf972b8bfa..b73deb282120 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "meson-g12b-s922x.dtsi"
+#include "meson-khadas-vim3.dtsi"
#include "meson-g12b-khadas-vim3.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
new file mode 100644
index 000000000000..8647da7d6609
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -0,0 +1,360 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (c) 2019 Christian Hewitt <christianshewitt@gmail.com>
+ */
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/meson-g12a-gpio.h>
+
+/ {
+ model = "Khadas VIM3";
+
+ aliases {
+ serial0 = &uart_AO;
+ ethernet0 = ðmac;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x80000000>;
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 2>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1710000>;
+
+ button-function {
+ label = "Function";
+ linux,code = <KEY_FN>;
+ press-threshold-microvolt = <10000>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ white {
+ label = "vim3:white:sys";
+ gpios = <&gpio_ao GPIOAO_4 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ red {
+ label = "vim3:red";
+ gpios = <&gpio_expander 5 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
+ };
+
+ gpio-keys-polled {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ power-button {
+ label = "power";
+ linux,code = <KEY_POWER>;
+ gpios = <&gpio_ao GPIOAO_7 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+
+ dc_in: regulator-dc_in {
+ compatible = "regulator-fixed";
+ regulator-name = "DC_IN";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ vcc_5v: regulator-vcc_5v {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_in>;
+
+ gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
+ enable-active-high;
+ };
+
+ vcc_1v8: regulator-vcc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_3v3>;
+ regulator-always-on;
+ };
+
+ vcc_3v3: regulator-vcc_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_3v3>;
+ regulator-always-on;
+ /* FIXME: actually controlled by VDDCPU_B_EN */
+ };
+
+ vddao_1v8: regulator-vddao_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vsys_3v3>;
+ regulator-always-on;
+ };
+
+ emmc_1v8: regulator-emmc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "EMMC_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_3v3>;
+ regulator-always-on;
+ };
+
+ vsys_3v3: regulator-vsys_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VSYS_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ usb_pwr: regulator-usb_pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "USB_PWR";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v>;
+
+ gpio = <&gpio GPIOA_6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_tmds_out>;
+ };
+ };
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+};
+
+&cec_AO {
+ pinctrl-0 = <&cec_ao_a_h_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&cecb_AO {
+ pinctrl-0 = <&cec_ao_b_h_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&ext_mdio {
+ external_phy: ethernet-phy@0 {
+ /* Realtek RTL8211F (0x001cc916) */
+ reg = <0>;
+ max-speed = <1000>;
+
+ interrupt-parent = <&gpio_intc>;
+ /* MAC_INTR on GPIOZ_14 */
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+ðmac {
+ pinctrl-0 = <ð_pins>, <ð_rgmii_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ phy-mode = "rgmii";
+ phy-handle = <&external_phy>;
+ amlogic,tx-delay-ns = <2>;
+};
+
+&hdmi_tx {
+ status = "okay";
+ pinctrl-0 = <&hdmitx_hpd_pins>, <&hdmitx_ddc_pins>;
+ pinctrl-names = "default";
+ hdmi-supply = <&vcc_5v>;
+};
+
+&hdmi_tx_tmds_port {
+ hdmi_tx_tmds_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+};
+
+&i2c_AO {
+ status = "okay";
+ pinctrl-0 = <&i2c_ao_sck_pins>, <&i2c_ao_sda_pins>;
+ pinctrl-names = "default";
+
+ gpio_expander: gpio-controller@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ vcc-supply = <&vcc_3v3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ };
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+ linux,rc-map-name = "rc-khadas";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&vddao_1v8>;
+};
+
+/* SDIO */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vsys_3v3>;
+ vqmmc-supply = <&vddao_1v8>;
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_c_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_c_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <&vsys_3v3>;
+ vqmmc-supply = <&vsys_3v3>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&emmc_1v8>;
+};
+
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ };
+};
+
+&uart_AO {
+ status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
+};
+
+&usb2_phy0 {
+ phy-supply = <&dc_in>;
+};
+
+&usb2_phy1 {
+ phy-supply = <&usb_pwr>;
+};
+
+&usb3_pcie_phy {
+ phy-supply = <&usb_pwr>;
+};
+
+&usb {
+ status = "okay";
+ dr_mode = "peripheral";
+};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: khadas-vim3: add support for the SM1 based VIM3
From: Neil Armstrong @ 2019-08-23 8:14 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190823081427.17228-1-narmstrong@baylibre.com>
Add the Amlogic SM1 based Khadas VIM3, sharing all the same features
as the G12B based one, but:
- a different DVFS support since only a single cluster is available
- audio is still not available on SM1
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../dts/amlogic/meson-sm1-khadas-vim3.dts | 69 +++++++++++++++++++
2 files changed, 70 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index edbf128e7707..33690b2ae2e1 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -35,3 +35,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3.dts
new file mode 100644
index 000000000000..3eb9cc5915d9
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3.dts
@@ -0,0 +1,69 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+/dts-v1/;
+
+#include "meson-sm1.dtsi"
+#include "meson-khadas-vim3.dtsi"
+
+/ {
+ compatible = "khadas,vim3", "amlogic,sm1";
+
+ vddcpu: regulator-vddcpu {
+ /*
+ * Silergy SY8030DEC Regulator.
+ */
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU";
+ regulator-min-microvolt = <690000>;
+ regulator-max-microvolt = <1050000>;
+
+ vin-supply = <&vsys_3v3>;
+
+ pwms = <&pwm_AO_cd 1 1250 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vddcpu>;
+ operating-points-v2 = <&cpu_opp_table>;
+ clocks = <&clkc CLKID_CPU_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu1 {
+ cpu-supply = <&vddcpu>;
+ operating-points-v2 = <&cpu_opp_table>;
+ clocks = <&clkc CLKID_CPU1_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu2 {
+ cpu-supply = <&vddcpu>;
+ operating-points-v2 = <&cpu_opp_table>;
+ clocks = <&clkc CLKID_CPU2_CLK>;
+ clock-latency = <50000>;
+};
+
+&cpu3 {
+ cpu-supply = <&vddcpu>;
+ operating-points-v2 = <&cpu_opp_table>;
+ clocks = <&clkc CLKID_CPU3_CLK>;
+ clock-latency = <50000>;
+};
+
+&pwm_AO_cd {
+ pinctrl-0 = <&pwm_ao_d_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin1";
+ status = "okay";
+};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 0/2] iommu/iova: enhance the rcache optimization
From: Leizhen (ThunderTown) @ 2019-08-23 8:15 UTC (permalink / raw)
To: Jean-Philippe Brucker, Jean-Philippe Brucker, John Garry,
Robin Murphy, Will Deacon, Joerg Roedel, iommu, Omer Peleg,
Adam Morrison, Shaohua Li, Ben Serebrin, David Woodhouse,
linux-arm-kernel, linux-kernel
In-Reply-To: <20190815121104.29140-1-thunder.leizhen@huawei.com>
Hi all,
Can anyone help review it?
On 2019/8/15 20:11, Zhen Lei wrote:
> v1 --> v2
> 1. I did not chagne the patches but added this cover-letter.
> 2. Add a batch of reviewers base on
> 9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova allocation")
> 3. I described the problem I met in patch 2, but I hope below brief description
> can help people to quickly understand.
> Suppose there are six rcache sizes, each size can maximum hold 10000 IOVAs.
> --------------------------------------------
> | 4K | 8K | 16K | 32K | 64K | 128K |
> --------------------------------------------
> | 10000 | 9000 | 8500 | 8600 | 9200 | 7000 |
> --------------------------------------------
> As the above map displayed, the whole rcache buffered too many IOVAs. Now, the
> worst case can be coming, suppose we need 20000 4K IOVAs at one time. That means
> 10000 IOVAs can be allocated from rcache, but another 10000 IOVAs should be
> allocated from RB tree base on alloc_iova() function. But the RB tree currently
> have at least (9000 + 8500 + 8600 + 9200 + 7000) = 42300 nodes. The average speed
> of RB tree traverse will be very slow. For my test scenario, the 4K size IOVAs are
> frequently used, but others are not. So similarly, when the 20000 4K IOVAs are
> continuous freed, the first 10000 IOVAs can be quickly buffered, but the other
> 10000 IOVAs can not.
>
> Zhen Lei (2):
> iommu/iova: introduce iova_magazine_compact_pfns()
> iommu/iova: enhance the rcache optimization
>
> drivers/iommu/iova.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++----
> include/linux/iova.h | 1 +
> 2 files changed, 95 insertions(+), 6 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Tomasz Figa @ 2019-08-23 8:17 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, devicetree, srv_heupstream, shengnan.wang,
louis.kuo, sj.huang, robh+dt, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190708100641.2702-3-dongchun.zhu@mediatek.com>
Hi Dongchun,
On Mon, Jul 08, 2019 at 06:06:41PM +0800, dongchun.zhu@mediatek.com wrote:
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> This patch adds a V4L2 sub-device driver for DW9768 lens voice coil,
> and provides control to set the desired focus.
>
> The DW9807 is a 10 bit DAC from Dongwoon, designed for linear
> control of voice coil motor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> MAINTAINERS | 1 +
> drivers/media/i2c/Kconfig | 10 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/dw9768.c | 458 +++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 470 insertions(+)
> create mode 100644 drivers/media/i2c/dw9768.c
>
Thanks for the patch! Please see my comments inline.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8f6ac93..17152d7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4877,6 +4877,7 @@ M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> L: linux-media@vger.kernel.org
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> +F: drivers/media/i2c/dw9768.c
> F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
>
> DONGWOON DW9807 LENS VOICE COIL DRIVER
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 7793358..8ff6c95 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -1014,6 +1014,16 @@ config VIDEO_DW9714
> capability. This is designed for linear control of
> voice coil motors, controlled via I2C serial interface.
>
> +config VIDEO_DW9768
> + tristate "DW9768 lens voice coil support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + help
> + This is a driver for the DW9768 camera lens voice coil.
> + DW9768 is a 10 bit DAC with 100mA output current sink
> + capability. This is designed for linear control of
> + voice coil motors, controlled via I2C serial interface.
> +
> config VIDEO_DW9807_VCM
> tristate "DW9807 lens voice coil support"
> depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index d8ad9da..944fbf6 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
> obj-$(CONFIG_VIDEO_AD5820) += ad5820.o
> obj-$(CONFIG_VIDEO_AK7375) += ak7375.o
> obj-$(CONFIG_VIDEO_DW9714) += dw9714.o
> +obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
> obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
> obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
> obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
> diff --git a/drivers/media/i2c/dw9768.c b/drivers/media/i2c/dw9768.c
> new file mode 100644
> index 0000000..f5b5591
> --- /dev/null
> +++ b/drivers/media/i2c/dw9768.c
> @@ -0,0 +1,458 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/pm_runtime.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-subdev.h>
> +
> +#define DW9768_VOLTAGE_ANALOG 2800000
This is a platform detail and should be defined in the platform data, for
example DTS on platforms using DT.
> +#define DW9768_NAME "dw9768"
The chip we seem to be using this driver for is called gt9769. Shouldn't we
call the driver the same?
> +#define DW9768_MAX_FOCUS_POS 1023
> +/*
> + * This sets the minimum granularity for the focus positions.
> + * A value of 1 gives maximum accuracy for a desired focus position
> + */
> +#define DW9768_FOCUS_STEPS 1
> +
> +#define DW9768_CTRL_DELAY_US 5000
> +
> +#define DW9768_REG_DAC_MSB 0x03
> +#define DW9768_REG_DAC_LSB 0x04
> +#define DW9768_REG_NULL 0xff
> +
> +#define DW9768_DAC_SHIFT 8
> +
> +#define DW9768_REG_VALUE_16BIT 2
This driver seems to always write 16-bit values. Can we simplify it to just
always assume so?
> +
> +/* dw9768 device structure */
> +struct dw9768_device {
> + struct v4l2_ctrl_handler ctrls;
> + struct v4l2_subdev sd;
> + struct regulator *analog_regulator;
> + /*
> + * Serialize control access, get/set format, get selection
> + * and start streaming.
> + */
> + struct mutex power_lock;
> +
> + int power_count;
> + bool standby;
> +};
> +
> +static inline struct dw9768_device *to_dw9768_vcm(struct v4l2_ctrl *ctrl)
> +{
> + return container_of(ctrl->handler, struct dw9768_device, ctrls);
> +}
> +
> +static inline struct dw9768_device *sd_to_dw9768_vcm(struct v4l2_subdev *subdev)
> +{
> + return container_of(subdev, struct dw9768_device, sd);
> +}
> +
> +static int dw9768_i2c_write(struct dw9768_device *dw9768_dev, u8 *data,
> + int size)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&dw9768_dev->sd);
> + struct i2c_msg msg;
> + u8 *w_buf = NULL;
> + u8 retry_cnt = 3;
> + int ret;
> +
> + if (!client->adapter)
> + return -ENODEV;
This isn't possible.
> +
> + if (size != 1 && size != 2)
> + return -EINVAL;
All the calls always pass 2.
> +
> + memset(&msg, 0, sizeof(struct i2c_msg));
> +
> + w_buf = kzalloc(size, GFP_KERNEL);
> + if (!w_buf)
> + return -1;
The size is fixed to 2. Is it necessary to allocate the buffer dynamically?
> +
> + memcpy(w_buf, data, size);
> +
> + msg.addr = client->addr;
> + msg.flags = 0;
> + msg.len = size;
> + msg.buf = w_buf;
Actually, why don't we just use data directly?
> +
> + do {
> + ret = i2c_transfer(client->adapter, &msg, 1);
> + if (ret != 1)
> + dev_err(&client->dev, "write fail, ret:%d, retry:%d\n",
> + ret, retry_cnt);
> + else
> + break;
> + retry_cnt--;
> + } while (retry_cnt != 0);
> +
> + if (retry_cnt == 0) {
> + dev_err(&client->dev, "i2c write fail(%d)\n", ret);
> + return -EIO;
> + }
Why do we need to handle retries here? I don't see the hardware datasheet
refer to any need to do those. Are you seeing some issues with transfers?
> +
> + kfree(w_buf);
> +
> + return 0;
> +}
> +
> +static int dw9768_release(struct dw9768_device *dw9768_dev)
> +{
> + unsigned char i;
> + int ret;
> +
> + char puSendCmdArray[4][2] = {
Please use the correct kernel coding style.
> + {0x02, 0x00}, {DW9768_REG_NULL, DW9768_REG_NULL},
> + {0x01, 0x00}, {DW9768_REG_NULL, DW9768_REG_NULL},
We only check the first element for this specific value, so we don't need
to initialize the second one.
Also, could we call it DW9768_CMD_DELAY instead?
Also, please define macros for the magic values used in the array.
> + };
> +
> + for (i = 0; i < (sizeof(puSendCmdArray) / sizeof(char)) /
> + (sizeof(puSendCmdArray[0]) / sizeof(char)); i++) {
Wouldn't ARRAY_SIZE() work here?
> + if (puSendCmdArray[i][0] != DW9768_REG_NULL) {
> + ret = dw9768_i2c_write(dw9768_dev, puSendCmdArray[i],
> + DW9768_REG_VALUE_16BIT);
> + if (ret < 0)
> + return ret;
Hmm, isn't this command array actually a pair of addreses and values?
Please define a struct for the entries.
Could we just use i2c_smbus_write_byte_data() instead of the custom
dw9768_i2c_write()?
> + } else {
> + usleep_range(DW9768_CTRL_DELAY_US,
> + DW9768_CTRL_DELAY_US + 100);
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int dw9768_init(struct dw9768_device *dw9768_dev)
> +{
> + unsigned char i;
> + int ret;
> +
> + char puSendCmdArray[5][2] = {
> + {0x02, 0x02}, {DW9768_REG_NULL, DW9768_REG_NULL},
> + {0x06, 0x41}, {0x07, 0x39}, {DW9768_REG_NULL, DW9768_REG_NULL},
> + };
> +
> + for (i = 0; i < (sizeof(puSendCmdArray) / sizeof(char)) /
> + (sizeof(puSendCmdArray[0]) / sizeof(char)); i++) {
> + if (puSendCmdArray[i][0] != DW9768_REG_NULL) {
> + ret = dw9768_i2c_write(dw9768_dev, puSendCmdArray[i],
> + DW9768_REG_VALUE_16BIT);
> + if (ret < 0)
> + return ret;
> + } else {
> + usleep_range(DW9768_CTRL_DELAY_US,
> + DW9768_CTRL_DELAY_US + 100);
> + }
> + }
The code here is duplicated, just different command array is used. Could we
move the command array handling to a helper function? (+ all the comments
I mentioned above)
> +
> + return 0;
> +}
> +
> +/*
> + * Power handling
> + */
> +static int dw9768_power_off(struct dw9768_device *dw9768_dev, bool standby)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&dw9768_dev->sd);
> + int ret;
> +
> + /*
> + * Go to standby first as real power off my be denied by the hardware
> + * (single power line control for both dw9768_dev and sensor).
What do you mean here? The regulator subsystem already properly handles
reference counting.
> + */
> + if (standby) {
> + dw9768_dev->standby = true;
> + ret = dw9768_release(dw9768_dev);
> + if (ret)
> + dev_err(&client->dev, "dw9768_release failed!\n");
Shouldn't we always call this when we power off?
> + }
> + ret = regulator_disable(dw9768_dev->analog_regulator);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int dw9768_power_on(struct dw9768_device *dw9768_dev, bool restore)
> +{
> + int ret;
> +
> + ret = regulator_enable(dw9768_dev->analog_regulator);
> + if (ret < 0)
> + return ret;
> +
> + if (restore) {
> + /* Restore the hardware settings. */
> + dw9768_dev->standby = false;
> + ret = dw9768_init(dw9768_dev);
> + if (ret < 0)
> + goto fail;
Shouldn't we always call this when we power on, without any condition?
> + }
> +
> + return 0;
> +
> +fail:
> + dw9768_dev->standby = true;
> + regulator_disable(dw9768_dev->analog_regulator);
> +
> + return ret;
> +}
The two functions above should be called from the runtime PM suspend/resume
callbacks.
> +
> +/*
> + * Calculate status word and write it to the device based on current
> + * values of V4L2 controls. It is assumed that the stored V4L2 control
> + * values are properly limited and rounded.
> + */
> +static int dw9768_update_hw(struct dw9768_device *dw9768_dev, u16 val)
> +{
> + unsigned char i;
> + int ret;
> +
> + char puSendCmdArray[2][2] = {
> + {DW9768_REG_DAC_MSB, (char)(val >> DW9768_DAC_SHIFT)},
> + {DW9768_REG_DAC_LSB, (char)(val & 0xFF)},
> + };
> +
> + for (i = 0; i < (sizeof(puSendCmdArray) / sizeof(char)) /
> + (sizeof(puSendCmdArray[0]) / sizeof(char)); i++) {
> + ret = dw9768_i2c_write(dw9768_dev, puSendCmdArray[i],
> + DW9768_REG_VALUE_16BIT);
> + if (ret)
> + return ret;
> + }
Since the two registers are actually one after another, perhaps you could
use i2c_smbus_write_block_data() to batch them into one transfer?
> +
> + return 0;
> +}
> +
> +static int dw9768_set_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct dw9768_device *dw9768_dev = to_dw9768_vcm(ctrl);
> +
> + if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE)
> + return dw9768_update_hw(dw9768_dev, ctrl->val);
I think we could just inline the contents of that function here, because
this function doesn't do anything else.
> +
> + return 0;
> +}
> +
> +static const struct v4l2_ctrl_ops dw9768_vcm_ctrl_ops = {
> + .s_ctrl = dw9768_set_ctrl,
> +};
> +
> +static int
> +dw9768_set_power(struct v4l2_subdev *subdev, int on)
> +{
> + struct dw9768_device *dw9768_dev = sd_to_dw9768_vcm(subdev);
> + int ret = 0;
> +
> + mutex_lock(&dw9768_dev->power_lock);
> +
> + /*
> + * If the power count is modified from 0 to != 0 or from != 0 to 0,
> + * update the power state.
> + */
> + if (dw9768_dev->power_count == !on) {
> + ret = on ? dw9768_power_on(dw9768_dev, true) :
> + dw9768_power_off(dw9768_dev, true);
> + if (ret < 0)
> + goto done;
> + }
If we use runtime PM, we get the reference count handling done for us by
the subsystem.
> +
> + /* Update the power count. */
> + dw9768_dev->power_count += on ? 1 : -1;
> + WARN_ON(dw9768_dev->power_count < 0);
> +
> +done:
> + mutex_unlock(&dw9768_dev->power_lock);
> + return ret;
> +}
> +
> +static int dw9768_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> + return dw9768_set_power(sd, 1);
We could just call pm_runtime_get_sync() here.
> +}
> +
> +static int dw9768_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> + return dw9768_set_power(sd, 0);
And pm_runtime_put() here.
> +}
> +
> +static const struct v4l2_subdev_internal_ops dw9768_int_ops = {
> + .open = dw9768_open,
> + .close = dw9768_close,
> +};
> +
> +static const struct v4l2_subdev_ops dw9768_ops = { };
> +
> +static void dw9768_subdev_cleanup(struct dw9768_device *dw9768_dev)
> +{
> + v4l2_async_unregister_subdev(&dw9768_dev->sd);
> + v4l2_ctrl_handler_free(&dw9768_dev->ctrls);
> + media_entity_cleanup(&dw9768_dev->sd.entity);
> +}
> +
> +static int dw9768_init_controls(struct dw9768_device *dw9768_dev)
> +{
> + struct v4l2_ctrl_handler *hdl = &dw9768_dev->ctrls;
> + const struct v4l2_ctrl_ops *ops = &dw9768_vcm_ctrl_ops;
> +
> + v4l2_ctrl_handler_init(hdl, 1);
> +
> + v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE,
> + 0, DW9768_MAX_FOCUS_POS, DW9768_FOCUS_STEPS, 0);
> +
> + if (hdl->error) {
> + dev_err(dw9768_dev->sd.dev, "%s fail error: 0x%x\n",
> + __func__, hdl->error);
> + return hdl->error;
> + }
> +
> + dw9768_dev->sd.ctrl_handler = hdl;
> +
> + return 0;
> +}
> +
> +static int dw9768_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct dw9768_device *dw9768_dev;
nit: Could we drop the _device and _dev suffixes to shorten the names?
> + int rval;
> +
> + dw9768_dev = devm_kzalloc(&client->dev, sizeof(*dw9768_dev),
> + GFP_KERNEL);
> + if (!dw9768_dev)
> + return -ENOMEM;
> +
> + dw9768_dev->analog_regulator = devm_regulator_get(dev, "afvdd");
"avfdd" is the name on our camera module, not the chip. It should be "vdd".
> + if (IS_ERR(dw9768_dev->analog_regulator)) {
> + dev_err(dev, "cannot get analog regulator\n");
> + return PTR_ERR(dw9768_dev->analog_regulator);
> + }
We also need 1 more regulator here for the I2C interface. The datasheet
calls it "vin".
> +
> + rval = regulator_set_voltage(dw9768_dev->analog_regulator,
> + DW9768_VOLTAGE_ANALOG,
> + DW9768_VOLTAGE_ANALOG);
> + if (rval < 0) {
> + dev_err(dev, "cannot set analog voltage\n");
> + return rval;
> + }
This should be set in the platform code. For example, on systems using DT
it can be done by setting the regulator min and max constraints in the DTS.
> +
> + mutex_init(&dw9768_dev->power_lock);
> +
> + v4l2_i2c_subdev_init(&dw9768_dev->sd, client, &dw9768_ops);
> + dw9768_dev->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> + dw9768_dev->sd.internal_ops = &dw9768_int_ops;
> +
> + rval = dw9768_init_controls(dw9768_dev);
> + if (rval)
> + goto err_cleanup;
> +
> + rval = media_entity_pads_init(&dw9768_dev->sd.entity, 0, NULL);
> + if (rval < 0)
> + goto err_cleanup;
> +
> + dw9768_dev->sd.entity.function = MEDIA_ENT_F_LENS;
> +
> + rval = v4l2_async_register_subdev(&dw9768_dev->sd);
> + if (rval < 0)
> + goto err_cleanup;
> +
> + pm_runtime_set_active(dev);
We shouldn't call this if we didn't fully power up the device ourselves and
I don't see the code above enabling the regulator. Given the privacy LED
concerns, we actually shouldn't attempt to power on in probe.
> + pm_runtime_enable(dev);
> + pm_runtime_idle(dev);
Ditto for idle, which is not needed if the device was not set active.
> +
> + return 0;
> +
> +err_cleanup:
> + mutex_destroy(&dw9768_dev->power_lock);
> + dw9768_subdev_cleanup(dw9768_dev);
> + dev_err(dev, "Probe failed: %d\n", rval);
> + return rval;
> +}
> +
> +static int dw9768_remove(struct i2c_client *client)
> +{
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> + struct dw9768_device *dw9768_dev = sd_to_dw9768_vcm(sd);
> +
> + pm_runtime_disable(&client->dev);
Technically we need to check if (!pm_runtime_state_suspended()) and power
down manually and set_suspended if that was the case.
> + dw9768_subdev_cleanup(dw9768_dev);
> +
> + return 0;
> +}
> +
> +/*
> + * This function sets the vcm position, so it consumes least current
> + * The lens position is gradually moved in units of DW9768_CTRL_STEPS,
> + * to make the movements smoothly.
> + */
> +static int __maybe_unused dw9768_vcm_suspend(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> + struct dw9768_device *dw9768_dev = sd_to_dw9768_vcm(sd);
> +
> + if (!dw9768_dev->power_count)
> + return 0;
> +
> + return dw9768_power_off(dw9768_dev, false);
> +}
> +
> +/*
> + * This function sets the vcm position to the value set by the user
> + * through v4l2_ctrl_ops s_ctrl handler
> + * The lens position is gradually moved in units of DW9768_CTRL_STEPS,
> + * to make the movements smoothly.
> + */
> +static int __maybe_unused dw9768_vcm_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> + struct dw9768_device *dw9768_dev = sd_to_dw9768_vcm(sd);
> +
> + if (!dw9768_dev->power_count)
> + return 0;
> +
> + return dw9768_power_on(dw9768_dev, true);
> +}
> +
> +static const struct i2c_device_id dw9768_id_table[] = {
> + { DW9768_NAME, 0 },
> + { { 0 } }
> +};
> +MODULE_DEVICE_TABLE(i2c, dw9768_id_table);
> +
> +static const struct of_device_id dw9768_of_table[] = {
> + { .compatible = "dongwoon,dw9768" },
> + { { 0 } }
> +};
> +MODULE_DEVICE_TABLE(of, dw9768_of_table);
> +
> +static const struct dev_pm_ops dw9768_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(dw9768_vcm_suspend, dw9768_vcm_resume)
> + SET_RUNTIME_PM_OPS(dw9768_vcm_suspend, dw9768_vcm_resume, NULL)
Okay, so we already provided the callbacks, but we never called
pm_runtime_get/put().
Also, I'm not sure if we can provide the same callbacks for runtime and
system PM ops, but I think we could use pm_runtime_force_suspend() and
pm_runtime_force_resume() as system ones to achieve the same.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: sun50i-h6: Add support for RTC and fix the clock tree
From: Maxime Ripard @ 2019-08-23 8:19 UTC (permalink / raw)
To: megous
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
linux-sunxi, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190820151934.3860-4-megous@megous.com>
[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]
On Tue, Aug 20, 2019 at 05:19:34PM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> This patch adds RTC node and fixes the clock properties and nodes
> to reflect the real clock tree.
>
> The device nodes for the internal oscillator and osc32k are removed,
> as these clocks are now provided by the RTC device. Clock references
> are fixed accordingly, too.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
The prefix should be "arm64: dts: allwinner: h6:"
I've fixed it up and applied it.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update path to tcb_clksrc.c
From: Nicolas.Ferre @ 2019-08-23 8:20 UTC (permalink / raw)
To: alexandre.belloni
Cc: joe, Ludovic.Desroches, linux-kernel, efremov, linux-arm-kernel
In-Reply-To: <20190814090858.GF3600@piout.net>
On 14/08/2019 at 11:08, Alexandre Belloni wrote:
> External E-Mail
>
>
> On 13/08/2019 08:11:23+0000, Nicolas Ferre wrote:
>> On 13/08/2019 at 08:10, Denis Efremov wrote:
>>> Update MAINTAINERS record to reflect the filename change
>>> from tcb_clksrc.c to timer-atmel-tcb.c
>>>
>>> Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
>>
>> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>> But, while you're at it, I would add another line: see below...
>>
>>> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Fixes: a7aae768166e ("clocksource/drivers/tcb_clksrc: Rename the file for consistency")
>>> Signed-off-by: Denis Efremov <efremov@linux.com>
>>> ---
>>> MAINTAINERS | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index c9ad38a9414f..3ec8154e4630 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -10637,7 +10637,7 @@ M: Nicolas Ferre <nicolas.ferre@microchip.com>
>>
>> +M: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>
>> But Alexandre have to agree, of course.
>>
>>> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>>> S: Supported
>>> F: drivers/misc/atmel_tclib.c
>>> -F: drivers/clocksource/tcb_clksrc.c
>>> +F: drivers/clocksource/timer-atmel-tcb.c
>>>
>>> MICROCHIP USBA UDC DRIVER
>>> M: Cristian Birsan <cristian.birsan@microchip.com>
>>
>> We could also remove this entry and mix it with:
>> "ARM/Microchip (AT91) SoC support"
>>
>> But I prefer to keep it separated like this for various reasons.
>>
>
> I would simply remove this entry because all the files are already
> matching the SoC entry (it has N: atmel) and atmel_tclib will go away (I
> have a series to do that).
All right: let's remove it.
Thanks Denis for the heads-up!
Best regards,
Nicolas
> If you want to keep a separate entry, maybe we should then add the
> system timer and pit drivers.
>
>
--
Nicolas Ferre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/5] soc: amlogic: Add support for Everything-Else power domains controller
From: Neil Armstrong @ 2019-08-23 8:22 UTC (permalink / raw)
To: Kevin Hilman, ulf.hansson
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <7hzhk12b6m.fsf@baylibre.com>
On 22/08/2019 22:32, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> On 22/08/2019 01:16, Kevin Hilman wrote:
>>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>>
>>>> Add support for the General Purpose Amlogic Everything-Else Power controller,
>>>> with the first support for G12A and SM1 SoCs dedicated to the VPU, PCIe,
>>>> USB, NNA, GE2D and Ethernet Power Domains.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>
>>> Nice! Thanks for generalizing this.
>>>
>>> A few comments/concerns below, but this is mostly ready.
>
> [...]
>
>>>> +#define VPU_PD(__name, __resets, __clks, __top_pd, __mem, __get_power) \
>>>> + { \
>>>> + .name = __name, \
>>>> + .reset_names_count = ARRAY_SIZE(__resets), \
>>>> + .reset_names = __resets, \
>>>> + .clk_names_count = ARRAY_SIZE(__clks), \
>>>> + .clk_names = __clks, \
>>>> + .top_pd = __top_pd, \
>>>> + .mem_pd_count = ARRAY_SIZE(__mem), \
>>>> + .mem_pd = __mem, \
>>>> + .get_power = __get_power, \
>>>> + }
>>>> +
>>>> +#define TOP_PD(__name, __top_pd, __mem) \
>>>> + { \
>>>> + .name = __name, \
>>>> + .top_pd = __top_pd, \
>>>> + .mem_pd_count = ARRAY_SIZE(__mem), \
>>>> + .mem_pd = __mem, \
>>>> + }
>>>
>>> Why can't the TOP_PD domains also have a __get_power(). Shouldn't we
>>> just be able to check the sleep_reg/sleep_mask like in the VPU case?
>>
>> It can, I can add it later, do we need it for this version ?
>
> Yes please. Seems a pretty simple addition, let's have it from the
> beginning.
>
>>> Also, for readability, I think the arguments to VPU_PD and TOP_PD to
>>> have the same order, at least for the common ones. IOW, __name,
>>> __top_pd, __mem should be first.
>>
>> Sure, will fix
>
> and you can add __get_power to the common list too.
>
> [...]
>
>>>> +static int meson_ee_clk_disable(struct meson_ee_pwrc_domain *pwrc_domain)
>>>> +{
>>>> + int i;
>>>> +
>>>> + for (i = 0 ; i < pwrc_domain->num_clks ; ++i)
>>>> + clk_disable(pwrc_domain->clks[i]);
>>>> +
>>>> + for (i = 0 ; i < pwrc_domain->num_clks ; ++i)
>>>> + clk_unprepare(pwrc_domain->clks[i]);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int meson_ee_clk_enable(struct meson_ee_pwrc_domain *pwrc_domain)
>>>> +{
>>>> + int i, ret;
>>>> +
>>>> + for (i = 0 ; i < pwrc_domain->num_clks ; ++i) {
>>>> + ret = clk_prepare(pwrc_domain->clks[i]);
>>>> + if (ret)
>>>> + goto fail_prepare;
>>>> + }
>>>> +
>>>> + for (i = 0 ; i < pwrc_domain->num_clks ; ++i) {
>>>> + ret = clk_enable(pwrc_domain->clks[i]);
>>>> + if (ret)
>>>> + goto fail_enable;
>>>> + }
>>>> +
>>>> + return 0;
>>>> +fail_enable:
>>>> + while (--i)
>>>> + clk_disable(pwrc_domain->clks[i]);
>>>> +
>>>> + /* Unprepare all clocks */
>>>> + i = pwrc_domain->num_clks;
>>>> +
>>>> +fail_prepare:
>>>> + while (--i)
>>>> + clk_unprepare(pwrc_domain->clks[i]);
>>>> +
>>>> + return ret;
>>>> +}
>>>
>>> Both the clk enable and disable functions above are just open-coding of
>>> the clk_bulk equivalents. Please use clk_bulk_*, then you don't need
>>> these helpers. (c.f. the RFT patch I did to convert the old driver to
>>> clk_bulk[1])
>>
>> Yes, but clk_bulk takes _all_ the clocks from the node, you canot specify
>> a list of names, maybe it's overengineered but I wanted to specify the
>> exact resets and clocks for each power domain, clk_bulk doesn't provide this.
>
> I've been going on the assumption that there's no reason to list clocks
> in the pwrc DT node that you don't want managed by the driver. This
> also seems to match the exisiting driver, and this new one.
>
> What is the case where you would list clocks in the DT node for the
> power-domain, but not want to manage them in the driver?
>
> If there's no good reason to do that, then clk_bulk greatly simplifies
> this code.
I guess I could put back the code if we need to split clocks and resets across
power domains in the future.
>
>>>> +static int meson_ee_pwrc_off(struct generic_pm_domain *domain)
>>>> +{
>>>> + struct meson_ee_pwrc_domain *pwrc_domain =
>>>> + container_of(domain, struct meson_ee_pwrc_domain, base);
>>>> + int i;
>>>> +
>>>> + if (pwrc_domain->desc.top_pd)
>>>> + regmap_update_bits(pwrc_domain->pwrc->regmap_ao,
>>>> + pwrc_domain->desc.top_pd->sleep_reg,
>>>> + pwrc_domain->desc.top_pd->sleep_mask,
>>>> + pwrc_domain->desc.top_pd->sleep_mask);
>>>> + udelay(20);
>>>> +
>>>> + for (i = 0 ; i < pwrc_domain->desc.mem_pd_count ; ++i)
>>>> + regmap_update_bits(pwrc_domain->pwrc->regmap_hhi,
>>>> + pwrc_domain->desc.mem_pd[i].reg,
>>>> + pwrc_domain->desc.mem_pd[i].mask,
>>>> + pwrc_domain->desc.mem_pd[i].mask);
>>>> +
>>>> + udelay(20);
>>>> +
>>>> + if (pwrc_domain->desc.top_pd)
>>>> + regmap_update_bits(pwrc_domain->pwrc->regmap_ao,
>>>> + pwrc_domain->desc.top_pd->iso_reg,
>>>> + pwrc_domain->desc.top_pd->iso_mask,
>>>> + pwrc_domain->desc.top_pd->iso_mask);
>>>> +
>>>> + if (pwrc_domain->num_clks) {
>>>> + msleep(20);
>>>> + meson_ee_clk_disable(pwrc_domain);
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int meson_ee_pwrc_on(struct generic_pm_domain *domain)
>>>> +{
>>>> + struct meson_ee_pwrc_domain *pwrc_domain =
>>>> + container_of(domain, struct meson_ee_pwrc_domain, base);
>>>> + int i, ret;
>>>> +
>>>> + if (pwrc_domain->desc.top_pd)
>>>> + regmap_update_bits(pwrc_domain->pwrc->regmap_ao,
>>>> + pwrc_domain->desc.top_pd->sleep_reg,
>>>> + pwrc_domain->desc.top_pd->sleep_mask, 0);
>>>> + udelay(20);
>>>> +
>>>> + for (i = 0 ; i < pwrc_domain->desc.mem_pd_count ; ++i)
>>>> + regmap_update_bits(pwrc_domain->pwrc->regmap_hhi,
>>>> + pwrc_domain->desc.mem_pd[i].reg,
>>>> + pwrc_domain->desc.mem_pd[i].mask, 0);
>>>> +
>>>> + udelay(20);
>>>> +
>>>> + ret = meson_ee_reset_assert(pwrc_domain);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + if (pwrc_domain->desc.top_pd)
>>>> + regmap_update_bits(pwrc_domain->pwrc->regmap_ao,
>>>> + pwrc_domain->desc.top_pd->iso_reg,
>>>> + pwrc_domain->desc.top_pd->iso_mask, 0);
>>>> +
>>>> + ret = meson_ee_reset_deassert(pwrc_domain);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + return meson_ee_clk_enable(pwrc_domain);
>>>> +}
>>>> +
>>>> +static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
>>>> + struct meson_ee_pwrc *sm1_pwrc,
>>>> + struct meson_ee_pwrc_domain *dom)
>>>> +{
>>>> + dom->pwrc = sm1_pwrc;
>>>> + dom->num_rstc = dom->desc.reset_names_count;
>>>> + dom->num_clks = dom->desc.clk_names_count;
>>>> +
>>>> + if (dom->num_rstc) {
>>>> + int rst;
>>>> +
>>>> + dom->rstc = devm_kcalloc(&pdev->dev, dom->num_rstc,
>>>> + sizeof(struct reset_control *), GFP_KERNEL);
>>>> + if (!dom->rstc)
>>>> + return -ENOMEM;
>>>> +
>>>> + for (rst = 0 ; rst < dom->num_rstc ; ++rst) {
>>>> + dom->rstc[rst] = devm_reset_control_get_exclusive(
>>>> + &pdev->dev,
>>>> + dom->desc.reset_names[rst]);
>>>> + if (IS_ERR(dom->rstc[rst]))
>>>> + return PTR_ERR(dom->rstc[rst]);
>>>> + }
>>>
>>> Why not simplify and use the helpers that get multiple reset lines (like
>>> devm_reset_control_array_get() used in meson-gx-pwrc-vpu.c)?
>>
>> Same comment as clk_bulk, we cannot be sure we select the right reset lines.
>
> Again, what is the case for listing resets in the power-domain node that
> you don't want to be managed by the driver?
>
>>> You could also use reset_control_get_count() and compare to the expected
>>> number (dom->num_rstc).
>>
>> This seems oversimplified
>
> Similar to above, if you're always going to manage all the reset lines
> in the DT node, then simple is good.
>
> If there are reasons to list reset lines in the DT node that will not be
> managed by the driver, I'm defintiely curious why.
>
> If not, using the reset API helpers is much more readable and
> maintainble IMO.
Will simply add the resets and clocks numbers and check the number at probe.
>
>>>
>>>> + }
>>>> +
>>>> + if (dom->num_clks) {
>>>> + int clk;
>>>> +
>>>> + dom->clks = devm_kcalloc(&pdev->dev, dom->num_clks,
>>>> + sizeof(struct clk *), GFP_KERNEL);
>>>> + if (!dom->clks)
>>>> + return -ENOMEM;
>>>> +
>>>> + for (clk = 0 ; clk < dom->num_clks ; ++clk) {
>>>> + dom->clks[clk] = devm_clk_get(&pdev->dev,
>>>> + dom->desc.clk_names[clk]);
>>>> + if (IS_ERR(dom->clks[clk]))
>>>> + return PTR_ERR(dom->clks[clk]);
>>>> + }
>>>> + }
>>>
>>> Please use clk_bulk API, and then just double-check that the number of
>>> clocks found matches the expected number.
>>
>> Same, I'll either take all the clks and resets for the vpu power domain,
>> or keep this code to make sure we get the right clocks and resets.
>
> Similar to above. IMO, we should be sure to put the "right clocks and
> resets" into the DT, and then simplify the code.
>
>>>
>>>> + dom->base.name = dom->desc.name;
>>>> + dom->base.power_on = meson_ee_pwrc_on;
>>>> + dom->base.power_off = meson_ee_pwrc_off;
>>>> +
>>>> + if (dom->desc.get_power) {
>>>> + bool powered_off = dom->desc.get_power(dom);
>>>
>>> nit: insert blank line here
>>>
>>> More importantly, we defintely will have problem here in the
>>> !powered_off case. TL;DR; the driver's state does not match the actual
>>> hardware state.
>>>
>>> When powered_off = false, you're telling the genpd core that this domain
>>> is already turned on. However, you haven't called _pwrc_on() yet for
>>> the domain, which means internal state of the driver for this domain
>>> (e.g. clock enables, resets, etc.) is not in sync with the HW. On
>>> SEI610 this case is happending for the VPU, which seems to be enabled by
>>> u-boot, so this driver detects it as already on, which is fine. But...
>>>
>>> Remember that the ->power_off() function will be called during suspend,
>>> and will lead to the clk unprepare/disable calls. However, for domains
>>> that are detected as on (!powered_off), clk prepare/enable will never
>>> have been called, so that when suspend happens, you'll get "already
>>> unprepared" errors from the clock core
>>>
>>> IOW, I think you need something like this here:
>>>
>>> if (!powered_off)
>>> meson_ee_pwrc_on(&dom->base);
>>>
>>> so that the internal state of clock fwk etc. matches the detected state
>>> of the HW. The problem with that simple fix, at least for the VPU is
>>> that it might cause us to lose any existing display or framebuffer
>>> console that's on-going. Probably needs some testing.
>>
>> Yes, I forgot to take the _shutdown() function from gx_pwrc_vpu driver :
>>
>> 349 static void meson_gx_pwrc_vpu_shutdown(struct platform_device *pdev)
>> 350 {
>> 351 struct meson_gx_pwrc_vpu *vpu_pd = platform_get_drvdata(pdev);
>> 352 bool powered_off;
>> 353
>> 354 powered_off = meson_gx_pwrc_vpu_get_power(vpu_pd);
>> 355 if (!powered_off)
>> 356 vpu_pd->genpd.power_off(&vpu_pd->genpd);
>> 357 }
>
> OK, yeah, I hadn't noticed that in the original driver. I tested
> something simliar with suspend/resume on SEI610 and it gets rid of the
> "already unprepared" splats from the clock core.
>
>>>
>>> Anyways, to see what I mean, try suspend/resume (you can test this
>>> series on my integ branch with "rtcwake -d rtc0 -m mem -s4") and you'll
>>> see error splats from the clock core during suspend.
>>>
>>>
>>>
>>>> + pm_genpd_init(&dom->base, &pm_domain_always_on_gov,
>>>> + powered_off);
>>>
>>>> + } else
>>>> + pm_genpd_init(&dom->base, NULL, true);
>>>
>>> nit: the else clause should also have {} to match the if
>>> (c.f. CodingStyle)
>>
>> OK
>>
>>>
>>> Why do you force the always-on governor in the case where ->get_power()
>>> exists, but not the other?
>>>
>>> If you force that, then for any devices connected to these domains that
>>> use runtime PM, they will never turn off the domain when it's idle.
>>> IOW, these domains will only ever be turned off on system-wide
>>> suspend/resume.
>>>
>>> IMO, unless there's a good reason not to, you should pass NULL for the
>>> governor.
>>
>> It's for legacy when VPU is initialized from vendor U-Boot, look at commit :
>> 339cd0ea082287ea8e2b7e7159a5a33665a2cbe3 "soc: amlogic: meson-gx-pwrc-vpu: fix power-off when powered by bootloader"
>>
>> In the case the VPU power domain has been powered on by the bootloader
>> and no driver are attached to this power domain, the genpd will power it
>> off after a certain amount of time, but the clocks hasn't been enabled
>> by the kernel itself and the power-off will trigger some faults.
>> This patch enable the clocks to have a coherent state for an eventual
>> poweroff and switches to the pm_domain_always_on_gov governor.
>
> The key phrase there being "and no driver is attached". Now that we
> have a driver, it claims this domain so I don't think it will be
> powered off:
>
> # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
> domain status slaves
> /device runtime status
> ----------------------------------------------------------------------
> ETH on
> /devices/platform/soc/ff3f0000.ethernet unsupported
> AUDIO off-0
> GE2D off-0
> PCI off-0
> USB on
> /devices/platform/soc/ffe09000.usb active
> NNA off-0
> VPU on
> /devices/platform/soc/ff900000.vpu unsupported
>
> In my tests with a framebuffer console (over HDMI), I don't see the
> display being powered off.
It's in the case where the driver is a module loaded by the post-initramfs
system after the genpd timeout, or if the display driver is disabled.
In the later I had some system failures when vendor u-boot enabled the
display and genpd disabled the power domain later on.
>
>> I could set always-on governor only if the domain was already enabled,
>> what do you think ?
>
> I don't think that's necessary now that we have a driver. We really
> want to be able to power-down this domain when the display is not in
> use, and if you use always_on, that will never happen.
>
>> And seems I'm also missing the "This patch enable the clocks".
>
> I'm not sure what patch you're referring to.
It's also added in 339cd0ea082287ea8e2b7e7159a5a33665a2cbe3 "soc: amlogic: meson-gx-pwrc-vpu: fix power-off when powered by bootloader"
I would like to keep the same behavior as meson-gx-pwrc-vpu, since it works fine
and we debugged all the issues we got.
Neil
>
> Kevin
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] coresight: tmc-etr: Add barrier packet when moving offset forward
From: Leo Yan @ 2019-08-23 8:22 UTC (permalink / raw)
To: Mathieu Poirier
Cc: suzuki.poulose, alexander.shishkin, yabinc, linux-kernel,
mike.leach, linux-arm-kernel
In-Reply-To: <20190822220915.8876-3-mathieu.poirier@linaro.org>
Hi Mathieu,
On Thu, Aug 22, 2019 at 04:09:15PM -0600, Mathieu Poirier wrote:
> This patch adds barrier packets in the trace stream when the offset in the
> data buffer needs to be moved forward. Otherwise the decoder isn't aware
> of the break in the stream and can't synchronise itself with the trace
> data.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> .../hwtracing/coresight/coresight-tmc-etr.c | 43 ++++++++++++++-----
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 4f000a03152e..0e4cd6ec5f28 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -946,10 +946,6 @@ static void tmc_sync_etr_buf(struct tmc_drvdata *drvdata)
> WARN_ON(!etr_buf->ops || !etr_buf->ops->sync);
>
> etr_buf->ops->sync(etr_buf, rrp, rwp);
> -
> - /* Insert barrier packets at the beginning, if there was an overflow */
> - if (etr_buf->full)
> - tmc_etr_buf_insert_barrier_packet(etr_buf, etr_buf->offset);
> }
>
> static void __tmc_etr_enable_hw(struct tmc_drvdata *drvdata)
> @@ -1415,10 +1411,11 @@ static void tmc_free_etr_buffer(void *config)
> * buffer to the perf ring buffer.
> */
> static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
> + unsigned long src_offset,
> unsigned long to_copy)
> {
> long bytes;
> - long pg_idx, pg_offset, src_offset;
> + long pg_idx, pg_offset;
> unsigned long head = etr_perf->head;
> char **dst_pages, *src_buf;
> struct etr_buf *etr_buf = etr_perf->etr_buf;
> @@ -1427,7 +1424,6 @@ static void tmc_etr_sync_perf_buffer(struct etr_perf_buffer *etr_perf,
> pg_idx = head >> PAGE_SHIFT;
> pg_offset = head & (PAGE_SIZE - 1);
> dst_pages = (char **)etr_perf->pages;
> - src_offset = etr_buf->offset + etr_buf->len - to_copy;
>
> while (to_copy > 0) {
> /*
> @@ -1475,7 +1471,7 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> void *config)
> {
> bool lost = false;
> - unsigned long flags, size = 0;
> + unsigned long flags, offset, size = 0;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> struct etr_perf_buffer *etr_perf = config;
> struct etr_buf *etr_buf = etr_perf->etr_buf;
> @@ -1503,11 +1499,39 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> size = etr_buf->len;
> + offset = etr_buf->offset;
> + lost |= etr_buf->full;
> +
> + /*
> + * The ETR buffer may be bigger than the space available in the
> + * perf ring buffer (handle->size). If so advance the offset so that we
> + * get the latest trace data. In snapshot mode none of that matters
> + * since we are expected to clobber stale data in favour of the latest
> + * traces.
> + */
> if (!etr_perf->snapshot && size > handle->size) {
> - size = handle->size;
> + u32 mask = tmc_get_memwidth_mask(drvdata);
> +
> + /*
> + * Make sure the new size is aligned in accordance with the
> + * requirement explained in function tmc_get_memwidth_mask().
> + */
> + size = handle->size & mask;
> + offset = etr_buf->offset + etr_buf->len - size;
> +
> + if (offset >= etr_buf->size)
> + offset -= etr_buf->size;
> lost = true;
> }
> - tmc_etr_sync_perf_buffer(etr_perf, size);
> +
> + /*
> + * Insert barrier packets at the beginning, if there was an overflow
> + * or if the offset had to be brought forward.
> + */
> + if (lost)
> + tmc_etr_buf_insert_barrier_packet(etr_buf, offset);
> +
> + tmc_etr_sync_perf_buffer(etr_perf, offset, size);
With this new code, the inserting barrier packet has been moved out
from function tmc_sync_etr_buf(); but this patch doesn't handle the
path when user uses SysFS node to access trace data and the trace
buffer is also likely full, thus the SysFS mode might miss to insert
barrier packets?
Thanks,
Leo Yan
> /*
> * In snapshot mode we simply increment the head by the number of byte
> @@ -1518,7 +1542,6 @@ tmc_update_etr_buffer(struct coresight_device *csdev,
> if (etr_perf->snapshot)
> handle->head += size;
>
> - lost |= etr_buf->full;
> out:
> /*
> * Don't set the TRUNCATED flag in snapshot mode because 1) the
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 3/4] misc: xilinx_sdfec: Prevent a divide by zero in xsdfec_reg0_write()
From: Dragan Cvetic @ 2019-08-23 8:23 UTC (permalink / raw)
To: Dan Carpenter, Derek Kiernan
Cc: Arnd Bergmann, Greg Kroah-Hartman,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
Michal Simek, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190821070953.GC26957@mwanda>
Hi Dan,
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Wednesday 21 August 2019 08:10
> To: Derek Kiernan <dkiernan@xilinx.com>; Dragan Cvetic <draganc@xilinx.com>
> Cc: Arnd Bergmann <arnd@arndb.de>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Michal Simek <michals@xilinx.com>;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; kernel-janitors@vger.kernel.org
> Subject: [PATCH 3/4] misc: xilinx_sdfec: Prevent a divide by zero in xsdfec_reg0_write()
>
> The "psize" value comes from the user so we need to verify that it's
> non-zero before we check if "n % psize" or it will crash.
>
> Fixes: 20ec628e8007 ("misc: xilinx_sdfec: Add ability to configure LDPC")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> The parentheses in this condition are a no-op. They're just confusing.
> Perhaps something else was intended?
>
> drivers/misc/xilinx_sdfec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
> index 813b82c59360..3fc53d20abf3 100644
> --- a/drivers/misc/xilinx_sdfec.c
> +++ b/drivers/misc/xilinx_sdfec.c
> @@ -460,7 +460,7 @@ static int xsdfec_reg0_write(struct xsdfec_dev *xsdfec, u32 n, u32 k, u32 psize,
> {
> u32 wdata;
>
> - if (n < XSDFEC_REG0_N_MIN || n > XSDFEC_REG0_N_MAX ||
> + if (n < XSDFEC_REG0_N_MIN || n > XSDFEC_REG0_N_MAX || psize == 0 ||
> (n > XSDFEC_REG0_N_MUL_P * psize) || n <= k || ((n % psize) != 0)) {
> dev_dbg(xsdfec->dev, "N value is not in range");
> return -EINVAL;
> --
> 2.20.1
Reviewed-by: Dragan Cvetic <dragan.cvetic@xilinx.com>
Thanks,
Dragan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: ixp4xx: Protect IXP4xx SoC drivers by ARCH_IXP4XX || COMPILE_TEST
From: Linus Walleij @ 2019-08-23 8:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Linus Walleij, linux-kernel@vger.kernel.org,
Krzysztof Halasa, Imre Kaloz, Linux ARM
In-Reply-To: <20190819080028.13091-1-geert@linux-m68k.org>
On Mon, Aug 19, 2019 at 10:46 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> The move of the IXP4xx SoC drivers exposed their config options on all
> platforms.
>
> Fix this by wrapping them inside an ARCH_IXP4XX or COMPILE_TEST block.
>
> Fixes: fcf2d8978cd538a5 ("ARM: ixp4xx: Move NPE and QMGR to drivers/soc")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> v2:
> - Rebased on top of commit ec8f24b7faaf3d47 ("treewide: Add SPDX
> license identifier - Makefile/Kconfig").
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Do you want me to also take care of sending this into the ARM SoC tree?
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH v2 2/2] usb: xhci-mtk: add an optional xhci_ck clock
From: Mathias Nyman @ 2019-08-23 8:28 UTC (permalink / raw)
To: Chunfeng Yun, Mathias Nyman, Greg Kroah-Hartman, Rob Herring
Cc: Mark Rutland, devicetree, Ian Campbell, linux-usb, linux-kernel,
linux-mediatek, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1566542425-20082-2-git-send-email-chunfeng.yun@mediatek.com>
On 23.8.2019 9.40, Chunfeng Yun wrote:
> Some SoCs may have an optional clock xhci_ck (125M or 200M), it
> usually uses the same PLL as sys_ck, so support it.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] soc: ixp4xx: Protect IXP4xx SoC drivers by ARCH_IXP4XX || COMPILE_TEST
From: Geert Uytterhoeven @ 2019-08-23 8:28 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, Linus Walleij, linux-kernel@vger.kernel.org,
Krzysztof Halasa, Imre Kaloz, Linux ARM
In-Reply-To: <CACRpkdb66GWnW6j=G==vAP_79ePyVCL=dHwcM2ui-GRC58eCjg@mail.gmail.com>
Hi Linus,
On Fri, Aug 23, 2019 at 10:26 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Aug 19, 2019 at 10:46 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > The move of the IXP4xx SoC drivers exposed their config options on all
> > platforms.
> >
> > Fix this by wrapping them inside an ARCH_IXP4XX or COMPILE_TEST block.
> >
> > Fixes: fcf2d8978cd538a5 ("ARM: ixp4xx: Move NPE and QMGR to drivers/soc")
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > ---
> > v2:
> > - Rebased on top of commit ec8f24b7faaf3d47 ("treewide: Add SPDX
> > license identifier - Makefile/Kconfig").
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>
> Do you want me to also take care of sending this into the ARM SoC tree?
Given you're listed as (one of) the maintainer(s), I think that would make
perfect sense.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] MAINTAINERS: at91: remove the TC entry
From: Nicolas Ferre @ 2019-08-23 8:31 UTC (permalink / raw)
To: Alexandre Belloni, Ludovic Desroches; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190823083158.2649-1-nicolas.ferre@microchip.com>
"MICROCHIP TIMER COUNTER (TC) AND CLOCKSOURCE DRIVERS" is better
removed because one file entry is outdated and basically, the
maintainer's pool of Alexandre, Ludovic and myself is better suited.
drivers/misc/atmel_tclib.c file is going away in a patch to come and
drivers/clocksource/tcb_clksrc.c file is actually named timer-atmel-tcb.c.
This new name is catches by AT91 entry regular expression.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
MAINTAINERS | 7 -------
1 file changed, 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index da7630c727be..c28a28d4cac9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10691,13 +10691,6 @@ S: Supported
F: drivers/misc/atmel-ssc.c
F: include/linux/atmel-ssc.h
-MICROCHIP TIMER COUNTER (TC) AND CLOCKSOURCE DRIVERS
-M: Nicolas Ferre <nicolas.ferre@microchip.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-S: Supported
-F: drivers/misc/atmel_tclib.c
-F: drivers/clocksource/tcb_clksrc.c
-
MICROCHIP USBA UDC DRIVER
M: Cristian Birsan <cristian.birsan@microchip.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] MAINTAINERS: at91: Collect all pinctrl/gpio drivers in same entry
From: Nicolas Ferre @ 2019-08-23 8:31 UTC (permalink / raw)
To: Alexandre Belloni, Ludovic Desroches; +Cc: linux-kernel, linux-arm-kernel
Andrei's address is not valid anymore, collect all pinctrl/gpio
entries in the common "PIN CONTROLLER - MICROCHIP AT91" one
and remove the PIOBU specific one.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
MAINTAINERS | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d214d3ebfb54..da7630c727be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10679,12 +10679,6 @@ M: Nicolas Ferre <nicolas.ferre@microchip.com>
S: Supported
F: drivers/power/reset/at91-sama5d2_shdwc.c
-MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO
-M: Andrei Stefanescu <andrei.stefanescu@microchip.com>
-L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
-L: linux-gpio@vger.kernel.org
-F: drivers/gpio/gpio-sama5d2-piobu.c
-
MICROCHIP SPI DRIVER
M: Nicolas Ferre <nicolas.ferre@microchip.com>
S: Supported
@@ -12768,6 +12762,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-gpio@vger.kernel.org
S: Supported
F: drivers/pinctrl/pinctrl-at91*
+F: drivers/gpio/gpio-sama5d2-piobu.c
PIN CONTROLLER - FREESCALE
M: Dong Aisheng <aisheng.dong@nxp.com>
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] mailmap: map old company name to new one @microchip.com
From: Nicolas Ferre @ 2019-08-23 8:31 UTC (permalink / raw)
To: Alexandre Belloni, Ludovic Desroches; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20190823083158.2649-1-nicolas.ferre@microchip.com>
Map my old email address @atmel.com to my new company name. It happened 3
years ago but I realized the existence of this file recently.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 3e01b1e5d584..54fb6af3fa38 100644
--- a/.mailmap
+++ b/.mailmap
@@ -182,6 +182,7 @@ Morten Welinder <welinder@darter.rentec.com>
Morten Welinder <welinder@troll.com>
Mythri P K <mythripk@ti.com>
Nguyen Anh Quynh <aquynh@gmail.com>
+Nicolas Ferre <nicolas.ferre@microchip.com> <nicolas.ferre@atmel.com>
Nicolas Pitre <nico@fluxnic.net> <nicolas.pitre@linaro.org>
Nicolas Pitre <nico@fluxnic.net> <nico@linaro.org>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 0/3] soc: renesas: ARM errata updates
From: Geert Uytterhoeven @ 2019-08-23 8:35 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux-Renesas, Simon Horman, Magnus Damm, Linux ARM
In-Reply-To: <CAMuHMdWj7eCa9URtztqth=fYMn2uTHWDS3WAKnRvxDfMjjBH_A@mail.gmail.com>
On Fri, Aug 23, 2019 at 9:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, Aug 21, 2019 at 2:46 PM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > This patch series updates the handling of ARM errata for affected
> > Renesas SoCs.
> >
> > The first patch enables the new ARM_ERRATA_814220 for Cortex-A7, using
> > Kconfig logic.
>
> Queuing the first one in renesas-devel for v5.4.
>
> > The second patch moves enablement of ARM_ERRATA_754322 for Cortex-A9
> > from shmobile_defconfig to Kconfig logic, to make sure it's always
> > enabled when needed.
> > The third patch disables PL310_ERRATA_588369, as it doesn't affect any
> > Renesas SoCs.
> >
> > The last patch is marked RFC, as I don't know the revision of PL310 on
> > EMMA Mobile EV2, and cannot test it on EMEV2.
>
> The other 2 are postponed.
Given it untangles dependencies, I'm also queuing the Kconfig part of patch 2.
The defconfig update will happen automatically during the refresh
after v5.4-rc1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/2] PM / devfreq: Use dev_pm_qos for sysfs min/max_freq
From: Chanwoo Choi @ 2019-08-23 8:40 UTC (permalink / raw)
To: Leonard Crestez, Viresh Kumar
Cc: Artur Świgoń, Jacky Bai, Saravana Kannan,
linux-pm@vger.kernel.org, Krzysztof Kozlowski, Kyungmin Park,
MyungJoo Ham, Alexandre Bailon, cpgs (cpgs@samsung.com),
Georgi Djakov, linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB70231FF65C1A50FD6830D88FEEA50@VI1PR04MB7023.eurprd04.prod.outlook.com>
On 19. 8. 22. 오후 9:24, Leonard Crestez wrote:
> On 22.08.2019 14:06, Chanwoo Choi wrote:
>> On 19. 8. 22. 오후 7:58, Leonard Crestez wrote:
>>> On 8/22/2019 1:03 PM, Chanwoo Choi wrote:
>>>> This patch doesn't check the range of input value
>>>> with the supported frequencies of devfreq device.
>>>>
>>>> For example,
>>>> The devfreq0 device has the following available frequencies
>>>> 100000000 200000000 300000000
>>>>
>>>> and then user enters the 500000000 as following:
>>>> echo 500000000 > /sys/class/devfreq/devfreq0/min_freq
>>>>
>>>> In result, get_effective_min_freq() will return the 500000000.
>>>> It is wrong value. it show the unsupported frequency through
>>>> min_freq sysfs path.
>>>
>>> Through dev_pm_qos devices can also ask for a freq higher than the
>>> maximum OPP and unlike sysfs there is no way to reject such requests,
>>> instead PM qos claims it's based on "best effort".
>>>
>>> There are many requests in the kernel for "PM_QOS_CPU_DMA_LATENCY 0" and
>>> I think that DEV_PM_QOS_MIN_FREQUENCY, MAX_S32 is a reasonable way for a
>>> device to request "max performance" from devfreq.
>>>
>>> Rejecting min > max is complicated (what happens to rejected requests
>>> when max goes back up?) and I think it's better to just stick with a
>>> "max overrides min" policy since it can already deal with conflicts.
>>>
>>> Do you have a usecase for rejecting out-of-range min_freq from
>>> userspace? cpufreq also accepts arbitrary min/max values and handles them.
>>
>> I don't mean the rejecting when user enter the out-of-range frequency.
>> As I commented, user can enter the value they want. But, we should
>> check the range of input because devfreq have to show the correct supported
>> frequency through sysfs.
>
> We can avoid showing an out-of-range value in min_freq by printing
> min(min_freq, max_freq).
You can check the range of frequency in the get_min_freq()/get_max_freq().
I want to return the meaningful frequency from get_min_freq()/get_max_freq().
Everyone expects get_min_freq()/get_max_freq() functions will retunrn
the supported min/max frequency. If get_min_freq()/get_max_freq()
return the our-of-range frequency, it is not nice and cause the confusion
why these functions return the out-of-range frequency..
Also, if we don't check the return value of dev_pm_qos_read_value(),
the out-of-range frequency of dev_pm_qos_read_value() would be used
on multiple point of devfreq.c. I think that it is not good.
>
> The max_freq value from pm_qos can still be between OPPs so maybe print
> devfreq_recommended_opp(max_freq, DEVFREQ_FLAG_LEAST_UPPER_BOUND).
>
>>> In theory pm_qos could be extended to differentiate between "soft"
>>> requests (current behavior) and "hard" requests which return errors if
>>> they can't be guaranteed but this is far out of scope.
>>
>> I think that you agreed the limitation of dev_pm_qos when entering
>> or requesting the unsupported frequency.
>
> Yes, "best effort qos" is acceptable for now.
>
And please don't remove the my previous comment.
Just reply your opinion without any removal.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl, ls1028a-pcie"
From: Xiaowei Bao @ 2019-08-23 8:26 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, leoyang.li, minghuan.Lian,
mingkai.hu, roy.zang, lorenzo.pieralisi, linux-pci, devicetree,
linux-kernel, linux-arm-kernel, linuxppc-dev, zhiqiang.hou
Cc: bhelgaas, Hou Zhiqiang, Xiaowei Bao
Add the PCIe compatible string for LS1028A
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v2:
- No change.
v3:
- No change.
v4:
- No change.
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index e20ceaa..99a386e 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -21,6 +21,7 @@ Required properties:
"fsl,ls1046a-pcie"
"fsl,ls1043a-pcie"
"fsl,ls1012a-pcie"
+ "fsl,ls1028a-pcie"
EP mode:
"fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
- reg: base addresses and lengths of the PCIe controller register blocks.
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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