* Re: [PATCH v14 0/5] ZII RAVE platform driver
From: Johan Hovold @ 2017-12-19 9:06 UTC (permalink / raw)
To: Lee Jones
Cc: Guenter Roeck, Andrey Smirnov, Pavel Machek, Greg Kroah-Hartman,
cphealy-Re5JQEeQqe8AvxtiuMwx3w, Andy Shevchenko, Lucas Stach,
Nikita Yushchenko, Rob Herring, Mark Rutland, Johan Hovold,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
Andrew Morton
In-Reply-To: <20171219085603.nk6x25b7kkc2rukz@dell>
On Tue, Dec 19, 2017 at 08:56:03AM +0000, Lee Jones wrote:
> On Sat, 16 Dec 2017, Guenter Roeck wrote:
> > On 12/07/2017 08:27 AM, Andrey Smirnov wrote:
> > > Lee:
> > >
> > > This patch set has been marinating out there for a while now and
> > > yours, I belive, is that last signature I need to start pushing it for
> > > inclusion. I'd really appreciate if you could spare some of your time
> > > to give it a look. Thanks!
> > >
> > > Everyone:
> > >
> > > This patch series is v14 of the driver for supervisory processor found
> > > on RAVE series of devices from ZII. Supervisory processor is a PIC
> > > microcontroller connected to various electrical subsystems on RAVE
> > > devices whose firmware implements protocol to command/qery them.
> > >
> > > NOTE:
> > >
> > > * This driver dependends on crc_ccitt_false(), added by
> > > 2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
> > > was pulled in by Andrew Morton and is currently avaiting users, so
> > > this series might have to go in through Andrew's tree
> > >
> >
> > Strictly speaking, the solution would be for Andrew to provide an immutable
> > branch with the above, for Rob to provide an immutable branch based on Andrew's
> > branch, adding the serdev drivers, for Lee to provide yet another immutable
> > branch with all those plus the mfd driver, and for Wim to pick it all up
> > into the watchdog tree.
>
> I think that's the craziest thing I've ever heard. ;) Only 1
> immutable branch is required, which can be pulled in by everyone.
>
> Bear with me. Pull-request to follow.
Did the compatible-strings issue get sorted out? That is, that the cell
drivers were matching on the parent compatible string to determine
their type instead of encoding that in their own compatible strings. Is
that desired (and recommended)?
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 05/15] drm/sun4i: Fix error path handling
From: Maxime Ripard @ 2017-12-19 8:59 UTC (permalink / raw)
To: Daniel Vetter, David Airlie, Chen-Yu Tsai
Cc: Mark Rutland, Thomas Petazzoni, jernej.skrabec, plaes, devicetree,
linux-kernel, dri-devel, Rob Herring, thierry.reding, stable,
linux-arm-kernel, icenowy
In-Reply-To: <f83c1cebc731f0b4251f5ddd7b38c718cd79bb0b.1512662253.git-series.maxime.ripard@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 951 bytes --]
On Thu, Dec 07, 2017 at 04:58:50PM +0100, Maxime Ripard wrote:
> The commit 4c7f16d14a33 ("drm/sun4i: Fix TCON clock and regmap
> initialization sequence") moved a bunch of logic around, but forgot to
> update the gotos after the introduction of the err_free_dotclock label.
>
> It means that if we fail later that the one introduced in that commit,
> we'll just to the old label which isn't free the clock we created. This
> will result in a breakage as soon as someone tries to do something with
> that clock, since its resources will have been long reclaimed.
>
> Cc: <stable@vger.kernel.org>
> Fixes: 4c7f16d14a33 ("drm/sun4i: Fix TCON clock and regmap initialization sequence")
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied this one as a fix.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v2 3/3] PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x
From: Kishon Vijay Abraham I @ 2017-12-19 8:58 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring
Cc: Mark Rutland, linux-omap, devicetree, linux-pci, linux-kernel,
nsekhar, kishon
In-Reply-To: <20171219085823.8695-1-kishon@ti.com>
dra74x/dra76x and dra72x has separate compatible strings. Add support
for these compatible strings in pci-dra7xx driver to perform syscon
configurations required to get x2 mode working.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
drivers/pci/dwc/pci-dra7xx.c | 90 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
index e77a4ceed74c..3b4427c10228 100644
--- a/drivers/pci/dwc/pci-dra7xx.c
+++ b/drivers/pci/dwc/pci-dra7xx.c
@@ -83,11 +83,15 @@
#define MSI_REQ_GRANT BIT(0)
#define MSI_VECTOR_SHIFT 7
+#define PCIE_1LANE_2LANE_SELECTION BIT(13)
+#define PCIE_B1C0_MODE_SEL BIT(2)
+
struct dra7xx_pcie {
struct dw_pcie *pci;
void __iomem *base; /* DT ti_conf */
int phy_count; /* DT phy-names count */
struct phy **phy;
+ u32 *b1c0_mask;
int link_gen;
struct irq_domain *irq_domain;
enum dw_pcie_device_mode mode;
@@ -95,6 +99,7 @@ struct dra7xx_pcie {
struct dra7xx_pcie_of_data {
enum dw_pcie_device_mode mode;
+ u32 b1co_mode_sel_mask;
};
#define to_dra7xx_pcie(x) dev_get_drvdata((x)->dev)
@@ -533,6 +538,26 @@ static const struct dra7xx_pcie_of_data dra7xx_pcie_ep_of_data = {
.mode = DW_PCIE_EP_TYPE,
};
+static const struct dra7xx_pcie_of_data dra746_pcie_rc_of_data = {
+ .b1co_mode_sel_mask = BIT(2),
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static const struct dra7xx_pcie_of_data dra726_pcie_rc_of_data = {
+ .b1co_mode_sel_mask = GENMASK(3, 2),
+ .mode = DW_PCIE_RC_TYPE,
+};
+
+static const struct dra7xx_pcie_of_data dra746_pcie_ep_of_data = {
+ .b1co_mode_sel_mask = BIT(2),
+ .mode = DW_PCIE_EP_TYPE,
+};
+
+static const struct dra7xx_pcie_of_data dra726_pcie_ep_of_data = {
+ .b1co_mode_sel_mask = GENMASK(3, 2),
+ .mode = DW_PCIE_EP_TYPE,
+};
+
static const struct of_device_id of_dra7xx_pcie_match[] = {
{
.compatible = "ti,dra7-pcie",
@@ -542,6 +567,22 @@ static const struct of_device_id of_dra7xx_pcie_match[] = {
.compatible = "ti,dra7-pcie-ep",
.data = &dra7xx_pcie_ep_of_data,
},
+ {
+ .compatible = "ti,dra746-pcie-rc",
+ .data = &dra746_pcie_rc_of_data,
+ },
+ {
+ .compatible = "ti,dra726-pcie-rc",
+ .data = &dra726_pcie_rc_of_data,
+ },
+ {
+ .compatible = "ti,dra746-pcie-ep",
+ .data = &dra746_pcie_ep_of_data,
+ },
+ {
+ .compatible = "ti,dra726-pcie-ep",
+ .data = &dra726_pcie_ep_of_data,
+ },
{},
};
@@ -587,6 +628,47 @@ static int dra7xx_pcie_ep_unaligned_memaccess(struct device *dev)
return ret;
}
+static int dra7xx_pcie_configure_two_lane(struct device *dev,
+ u32 b1co_mode_sel_mask)
+{
+ struct device_node *np = dev->of_node;
+ struct regmap *pcie_syscon;
+ unsigned int pcie_reg;
+
+ pcie_syscon = syscon_regmap_lookup_by_phandle(np,
+ "ti,syscon-lane-conf");
+ if (IS_ERR(pcie_syscon)) {
+ dev_err(dev, "unable to get ti,syscon-lane-conf\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32_index(np, "ti,syscon-lane-conf", 1,
+ &pcie_reg)) {
+ dev_err(dev, "couldn't get lane configuration reg offset\n");
+ return -EINVAL;
+ }
+
+ regmap_update_bits(pcie_syscon, pcie_reg, PCIE_1LANE_2LANE_SELECTION,
+ PCIE_1LANE_2LANE_SELECTION);
+
+ pcie_syscon = syscon_regmap_lookup_by_phandle(np, "ti,syscon-lane-sel");
+ if (IS_ERR(pcie_syscon)) {
+ dev_err(dev, "unable to get ti,syscon-lane-sel\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32_index(np, "ti,syscon-lane-sel", 1,
+ &pcie_reg)) {
+ dev_err(dev, "couldn't get lane selection reg offset\n");
+ return -EINVAL;
+ }
+
+ regmap_update_bits(pcie_syscon, pcie_reg, b1co_mode_sel_mask,
+ PCIE_B1C0_MODE_SEL);
+
+ return 0;
+}
+
static int __init dra7xx_pcie_probe(struct platform_device *pdev)
{
u32 reg;
@@ -608,6 +690,7 @@ static int __init dra7xx_pcie_probe(struct platform_device *pdev)
const struct of_device_id *match;
const struct dra7xx_pcie_of_data *data;
enum dw_pcie_device_mode mode;
+ u32 b1co_mode_sel_mask;
match = of_match_device(of_match_ptr(of_dra7xx_pcie_match), dev);
if (!match)
@@ -615,6 +698,7 @@ static int __init dra7xx_pcie_probe(struct platform_device *pdev)
data = (struct dra7xx_pcie_of_data *)match->data;
mode = (enum dw_pcie_device_mode)data->mode;
+ b1co_mode_sel_mask = data->b1co_mode_sel_mask;
dra7xx = devm_kzalloc(dev, sizeof(*dra7xx), GFP_KERNEL);
if (!dra7xx)
@@ -673,6 +757,12 @@ static int __init dra7xx_pcie_probe(struct platform_device *pdev)
dra7xx->pci = pci;
dra7xx->phy_count = phy_count;
+ if (phy_count == 2) {
+ ret = dra7xx_pcie_configure_two_lane(dev, b1co_mode_sel_mask);
+ if (ret < 0)
+ goto err_link;
+ }
+
ret = dra7xx_pcie_enable_phy(dra7xx);
if (ret) {
dev_err(dev, "failed to enable phy\n");
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7
From: Kishon Vijay Abraham I @ 2017-12-19 8:58 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring
Cc: Mark Rutland, linux-omap, devicetree, linux-pci, linux-kernel,
nsekhar, kishon
In-Reply-To: <20171219085823.8695-1-kishon@ti.com>
Add syscon properties required for configuring PCIe in x2 lane mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
Documentation/devicetree/bindings/pci/ti-pci.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 82cb875e4cec..bfbc77ac7355 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -13,6 +13,12 @@ PCIe DesignWare Controller
- ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>",
where <X> is the instance number of the pcie from the HW spec.
- num-lanes as specified in ../designware-pcie.txt
+ - ti,syscon-lane-conf : phandle/offset pair. Phandle to the system control
+ module and the register offset to specify 1 lane or
+ 2 lane.
+ - ti,syscon-lane-sel : phandle/offset pair. Phandle to the system control
+ module and the register offset to specify lane
+ selection.
HOST MODE
=========
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: PCI: dra7xx: Add SoC specific compatible strings
From: Kishon Vijay Abraham I @ 2017-12-19 8:58 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring
Cc: Mark Rutland, linux-omap, devicetree, linux-pci, linux-kernel,
nsekhar, kishon
In-Reply-To: <20171219085823.8695-1-kishon@ti.com>
Add new compatible strings for dra74x SoC (also used by dra76x) and
dra72x. This can be used to perform SoC specific configuration
(like configuring PCIe in x2 lane mode).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/pci/ti-pci.txt | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 7f7af3044016..82cb875e4cec 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,8 +1,12 @@
TI PCI Controllers
PCIe DesignWare Controller
- - compatible: Should be "ti,dra7-pcie" for RC
- Should be "ti,dra7-pcie-ep" for EP
+ - compatible: Should be "ti,dra7-pcie" for RC (deprecated)
+ Should be "ti,dra7-pcie-ep" for EP (deprecated)
+ Should be "ti,dra746-pcie-rc" for dra74x/dra76 in RC mode
+ Should be "ti,dra746-pcie-ep" for dra74x/dra76 in EP mode
+ Should be "ti,dra726-pcie-rc" for dra72x in RC mode
+ Should be "ti,dra726-pcie-ep" for dra72x in EP mode
- phys : list of PHY specifiers (used by generic PHY framework)
- phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
number of PHYs as specified in *phys* property.
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/3] PCI: dra7xx: Support PCIe x2 lane mode
From: Kishon Vijay Abraham I @ 2017-12-19 8:58 UTC (permalink / raw)
To: Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring
Cc: Mark Rutland, linux-omap, devicetree, linux-pci, linux-kernel,
nsekhar, kishon
Previous version of this series can be found here @ [1]
Patch series adds support to enable x2 lane mode in dra74/dra76 and
dra72 based boards in pci-dra7xx driver. It introduces new compatible
strings in order to enable x2 lane mode support.
Changes from v1:
*) Added ti prefix to syscon-lane-conf and syscon-lane-sel as
suggested to Rob
*) Merged "PCI: dwc: dra7xx: Add support for SoC specific compatible
strings" and "PCI: dwc: pci-dra7xx: Enable x2 mode support" into
a single patch.
*) Fixed $subject as suggested by Bjorn
*) Added x2 lane mode support for DRA72x
The dts changes and phy changes will be sent as a separate series.
[1] -> https://lkml.org/lkml/2017/10/10/276
Kishon Vijay Abraham I (3):
dt-bindings: PCI: dra7xx: Add SoC specific compatible strings
dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7
PCI: dra7xx: Enable x2 mode support for dra74x, dra76x and dra72x
Documentation/devicetree/bindings/pci/ti-pci.txt | 14 +++-
drivers/pci/dwc/pci-dra7xx.c | 90 ++++++++++++++++++++++++
2 files changed, 102 insertions(+), 2 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH v4 14/15] ARM: dts: sun8i: a711: Reinstate the PMIC compatible
From: Maxime Ripard @ 2017-12-19 8:57 UTC (permalink / raw)
To: Daniel Vetter, David Airlie, Chen-Yu Tsai
Cc: Mark Rutland, Thomas Petazzoni, jernej.skrabec, plaes, devicetree,
linux-kernel, dri-devel, Rob Herring, thierry.reding,
linux-arm-kernel, icenowy
In-Reply-To: <80711a93a5e49166a26ade747687d8ba4ef7a6f3.1512662253.git-series.maxime.ripard@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 704 bytes --]
On Thu, Dec 07, 2017 at 04:58:59PM +0100, Maxime Ripard wrote:
> When we added the regulator support in commit 90c5d7cdae64 ("ARM: dts:
> sun8i: a711: Add regulator support"), we also dropped the PMIC's
> compatible. Since it's not in the PMIC DTSI, unlike most other PMIC
> DTSI, it obviously wasn't probing anymore.
>
> Re-add it so that everything works again.
>
> Fixes: 90c5d7cdae64 ("ARM: dts: sun8i: a711: Add regulator support")
> Reviewed-by: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied this one as a fix.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v14 0/5] ZII RAVE platform driver
From: Lee Jones @ 2017-12-19 8:56 UTC (permalink / raw)
To: Guenter Roeck
Cc: Andrey Smirnov, Pavel Machek, Greg Kroah-Hartman,
cphealy-Re5JQEeQqe8AvxtiuMwx3w, Andy Shevchenko, Lucas Stach,
Nikita Yushchenko, Rob Herring, Mark Rutland, Johan Hovold,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
Andrew Morton
In-Reply-To: <b64f8d3e-fb7d-328b-dfd5-ddd0e9dfe932-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
On Sat, 16 Dec 2017, Guenter Roeck wrote:
> On 12/07/2017 08:27 AM, Andrey Smirnov wrote:
> > Lee:
> >
> > This patch set has been marinating out there for a while now and
> > yours, I belive, is that last signature I need to start pushing it for
> > inclusion. I'd really appreciate if you could spare some of your time
> > to give it a look. Thanks!
> >
> > Everyone:
> >
> > This patch series is v14 of the driver for supervisory processor found
> > on RAVE series of devices from ZII. Supervisory processor is a PIC
> > microcontroller connected to various electrical subsystems on RAVE
> > devices whose firmware implements protocol to command/qery them.
> >
> > NOTE:
> >
> > * This driver dependends on crc_ccitt_false(), added by
> > 2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
> > was pulled in by Andrew Morton and is currently avaiting users, so
> > this series might have to go in through Andrew's tree
> >
>
> Strictly speaking, the solution would be for Andrew to provide an immutable
> branch with the above, for Rob to provide an immutable branch based on Andrew's
> branch, adding the serdev drivers, for Lee to provide yet another immutable
> branch with all those plus the mfd driver, and for Wim to pick it all up
> into the watchdog tree.
I think that's the craziest thing I've ever heard. ;) Only 1
immutable branch is required, which can be pulled in by everyone.
Bear with me. Pull-request to follow.
> That seems to be a bit complicated. I would suggest for Lee to pick it all up.
> If Lee is busy and ok with it, I'll be happy to pick it all up and submit to
> Linus as a separate pull request during the next commit window.
>
> Lee, Andrew, any thoughts/comments ?
>
> Thanks,
> Guenter
>
> > Changes since [v13]:
> >
> > - Fixed incorrect MFD driver menuconfig entry placement
> >
> > Changes since [v12]:
> >
> > - Minor comment inconsistencies fixes in rave-sp.c
> >
> > Changes since [v11]:
> >
> > - Fix incorrect include in rave-sp-wdt.c as uncovered by kernel
> > test robot
> >
> > Changes since [v10]:
> >
> > - Collected Acked-by from Rob and Reviewed-by from Guenter
> >
> > - Incorporated watchdog driver feedback from Gunter and Johan
> >
> > - Incorporated Johan's feedback for the rest of the code
> >
> > Changes since [v9]:
> >
> > - Converted watchdog driver to use watchdog_active() instead of
> > watchdog_hw_running() and replaced WARN_ON with a regular error
> > message as per feedback from Guenter
> >
> > - Changed rave_sp_wdt_start() to set WDOG_HW_RUNNING only if
> > communicating with hardware was sucessful
> >
> > - Collected Reviewd-by from Sebastian (for serdev related patches)
> >
> > - Collected Acked-by from Rob (for watchdog DT bindings)
> >
> > Changes since [v8]:
> >
> > - Driver moved from drivers/platform to drivers/mfd
> >
> > - Collected Reviewed-by from Guenter (for patches 1, 2 and 3)
> >
> > - Incorporated feedback from Guenter into watchdog driver
> >
> > - Incorporated feedback from Rob into watchdog DT bindings
> >
> > - Removed struct rave_sp_rsp_status, which was a leftover from v5
> > -> v6 code removal.
> >
> > - Fixed minor problems reported by checkpatch
> >
> > Changes since [v7]:
> >
> > - Added watchdog driver to the patchset, so it would be easier to
> > understand how parent/children drivers are tied together
> >
> > - Added serdev patches to implement devm_serdev_device_open() and make .remove optional
> >
> > - "Added" missing serdev_device_close() by converting the driver
> > to use devm_serdev_device_open()
> >
> > - Converted the driver to use devm_of_platform_populate()
> >
> > - Removed needless dependency on MFD_CORE
> >
> > - Removed dependency on SERIAL_DEV_CTRL_TTYPORT
> >
> > Changes since [v6]:
> >
> > - Patch 2/2 has been applied by Lee so it is no longer a part of the series
> >
> > - Removed all sysfs and debugfs attribute to reduce the scope of
> > the driver propsed for inclusion. This is not a critical to have
> > feature and can be added/discussed later.
> >
> > Changes since [v5]:
> >
> > - Fixed a build break, introduced by a last minute change in [v5]
> >
> > - Moved majority of attributes that were exposed over sysfs to debugfs
> >
> > - Document remaining sysfs attributes in Documentation/ABI/testing/sysfs-platform-rave-sp
> >
> > Changes since [v4]:
> >
> > - Replaced usage of DEVICE_ATTR with DEVICE_ATTR_RW
> >
> > - Fixed a number of warnings produces by sparse tool
> >
> > - Incorporated event more feedback from Andy Shevchenko
> >
> > - Collected Reviewed-by from Andy
> >
> > Changes since [v3]:
> >
> > - Re-collected lost Acked-by from Rob
> >
> > - Incorporated further feedback from Andy Shevchenko
> >
> > - Dropped useless change (stray newline) to drivers/mfd/Makefile
> >
> > Changes since [v2]:
> >
> > - Fixed swapped command codes in rave_sp_common_get_boot_source()
> > and rave_sp_common_set_boot_source() revealed by further testing
> > of the code
> >
> > - Incorporated feedback from Andy Shevchenko
> >
> > Changes since [v1]:
> >
> > - Updated wording in DT-bindings as per Rob's request.
> >
> > - Collected Rob's Acked-by for patch 2/2
> >
> > Feedback is greatly appreciated!
> >
> > Thanks,
> > Andrey Smirnov
> >
> > [v13] lkml.kernel.org/r/20171204161118.19558-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v12] lkml.kernel.org/r/20171109160556.17018-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v11] lkml.kernel.org/r/20171106152935.16920-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v10] lkml.kernel.org/r/20171031163656.24552-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v9] lkml.kernel.org/r/20171025190421.18415-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v8] lkml.kernel.org/r/20171018170136.12347-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v7] lkml.kernel.org/r/20171013061321.31252-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v6] lkml.kernel.org/r/20170828163131.24815-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v5] lkml.kernel.org/r/20170728142704.11156-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v4] lkml.kernel.org/r/20170725184450.13171-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v3] lkml.kernel.org/r/20170724150915.4824-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v2] lkml.kernel.org/r/20170718175604.11735-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > [v1] lkml.kernel.org/r/20170710170449.4544-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> >
> > Andrey Smirnov (5):
> > serdev: Make .remove in struct serdev_device_driver optional
> > serdev: Introduce devm_serdev_device_open()
> > mfd: Add driver for RAVE Supervisory Processor
> > watchdog: Add RAVE SP watchdog driver
> > dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver
> >
> > .../bindings/watchdog/zii,rave-sp-wdt.txt | 39 ++
> > Documentation/driver-model/devres.txt | 3 +
> > drivers/mfd/Kconfig | 8 +
> > drivers/mfd/Makefile | 2 +
> > drivers/mfd/rave-sp.c | 660 +++++++++++++++++++++
> > drivers/tty/serdev/core.c | 31 +-
> > drivers/watchdog/Kconfig | 7 +
> > drivers/watchdog/Makefile | 1 +
> > drivers/watchdog/rave-sp-wdt.c | 357 +++++++++++
> > include/linux/mfd/rave-sp.h | 56 ++
> > include/linux/serdev.h | 1 +
> > 11 files changed, 1163 insertions(+), 2 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
> > create mode 100644 drivers/mfd/rave-sp.c
> > create mode 100644 drivers/watchdog/rave-sp-wdt.c
> > create mode 100644 include/linux/mfd/rave-sp.h
> >
>
--
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: h3: nanopi-m1-plus: fix missing ethernet 0 in aliases
From: Maxime Ripard @ 2017-12-19 8:54 UTC (permalink / raw)
To: Philipp Rossak
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, wens-jdAy2FN1RRM,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171218123548.32511-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
On Mon, Dec 18, 2017 at 01:35:48PM +0100, Philipp Rossak wrote:
> This patch fixes a missing ethernet 0 alisas in the devicetree on the
> Nanopi M1 Plus.
>
> Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-a83t-tbs-a711: Add missing axp813 compatible
From: Maxime Ripard @ 2017-12-19 8:54 UTC (permalink / raw)
To: megous-5qf/QAjKc83QT0dZR+AlfA
Cc: dev-3kdeTeqwOZ9EV1b7eY7vFQ, Rob Herring, Mark Rutland,
Russell King, Chen-Yu Tsai,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list
In-Reply-To: <20171217012721.5923-1-megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
Hi,
On Sun, Dec 17, 2017 at 02:27:21AM +0100, megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org wrote:
> From: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
>
> Without this the AXP813 PMIC fails to probe on TBS A711.
>
> Signed-off-by: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
This was already posted a couple times :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: sun8i: h3: Enable dwmac-sun8i on the Nanopi M1
From: Maxime Ripard @ 2017-12-19 8:54 UTC (permalink / raw)
To: Philipp Rossak
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, wens-jdAy2FN1RRM,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171215223901.14500-3-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]
On Fri, Dec 15, 2017 at 11:39:01PM +0100, Philipp Rossak wrote:
> The dwmac-sun8i hardware is present on the Nanopi M1.
> It uses the internal PHY
>
> Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
From: Greg Kroah-Hartman @ 2017-12-19 8:52 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Cyprian Wronka, Suresh Punnoose, Thomas Petazzoni, Nishanth Menon,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree
In-Reply-To: <20171214151610.19153-3-boris.brezillon@free-electrons.com>
On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> +/**
> + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> + * @i3cdev: the I3C device we're searching a match for
> + * @id_table: the I3C device ID table
> + *
> + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's
> + * no match.
> + */
> +const struct i3c_device_id *
> +i3c_device_match_id(struct i3c_device *i3cdev,
> + const struct i3c_device_id *id_table)
> +{
> + const struct i3c_device_id *id;
> +
> + /*
> + * The lower 32bits of the provisional ID is just filled with a random
> + * value, try to match using DCR info.
> + */
> + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> +
> + /* First try to match by manufacturer/part ID. */
> + for (id = id_table; id->match_flags != 0; id++) {
> + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> + I3C_MATCH_MANUF_AND_PART)
> + continue;
> +
> + if (manuf != id->manuf_id || part != id->part_id)
> + continue;
> +
> + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> + ext_info != id->extra_info)
> + continue;
> +
> + return id;
> + }
> + }
> +
> + /* Fallback to DCR match. */
> + for (id = id_table; id->match_flags != 0; id++) {
> + if ((id->match_flags & I3C_MATCH_DCR) &&
> + id->dcr == i3cdev->info.dcr)
> + return id;
> + }
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_match_id);
I just picked one random export here, but it feels like you are
exporting a bunch of symbols you don't need to. Why would something
outside of the i3c "core" need to call this function? Have you looked
to see if you really have callers for everything you are exporting?
Other than that, the driver core interaction looks good now, nice job.
greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/6] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Maxime Ripard @ 2017-12-19 8:52 UTC (permalink / raw)
To: Philipp Rossak
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219080747.4507-3-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
On Tue, Dec 19, 2017 at 09:07:43AM +0100, Philipp Rossak wrote:
> This patch updates documentation for Device-Tree bindings for sunxi IR
> controller and adds the new optional property for the base clock
> frequency.
>
> Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board
From: Ludovic BARRE @ 2017-12-19 8:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King, Rob Herring, Linus Walleij, Maxime Coquelin,
Alexandre Torgue, Gerald Baeza, Linux ARM,
Linux Kernel Mailing List, DTML
In-Reply-To: <CAK8P3a14KzxGK8j75UUBfWgexg2fdzrtdgcqUT=uHfjWrVaWbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/18/2017 09:20 PM, Arnd Bergmann wrote:
> On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre-qxv4g6HH51o@public.gmane.org> wrote:
> =
>> +
>> +/ {
>> + model = "STMicroelectronics STM32MP157C eval daughter";
>> + compatible = "st,stm32mp157c-ed1", "st,stm32mp157";
>> +
>> + chosen {
>> + bootargs = "earlyprintk console=ttySTM3,115200 root=/dev/ram";
>> + stdout-path = "serial3:115200n8";
>> + };
>
> I'd remove the bootargs here and let the boot loader take care of
> that, in particular
> since all three arguments are rather old-school: earlycon is preferred over
> earlyprintk, console= should not be needed if you set stdout-path, and
> /dev/ram is obsoleted by initramfs.
OK, thanks
BR
Ludo
>
> Arnd
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Miquel RAYNAL @ 2017-12-19 8:23 UTC (permalink / raw)
To: Baruch Siach
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm, devicetree,
linux-arm-kernel, Thomas Petazzoni, Antoine Tenart, Nadav Haklai,
David Sniatkiwicz
In-Reply-To: <20171219081941.utke7dh5bmmlub6h@sapphire.tkos.co.il>
Hi Baruch,
On Tue, 19 Dec 2017 10:19:41 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miquèl,
>
> On Tue, Dec 19, 2017 at 09:08:14AM +0100, Miquel RAYNAL wrote:
> > On Tue, 19 Dec 2017 07:51:54 +0200
> > Baruch Siach <baruch@tkos.co.il> wrote:
> > > On Tue, Dec 19, 2017 at 01:32:33AM +0100, Miquel RAYNAL wrote:
> > > > On Mon, 18 Dec 2017 22:35:42 +0200
> > > > Baruch Siach <baruch@tkos.co.il> wrote:
> > > > > On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal
> > > > > wrote:
> > > > > > Bindings were incomplete for a long time by only exposing
> > > > > > one of the two available control registers. To ease the
> > > > > > migration to the full bindings (already in use for the
> > > > > > Armada 375 SoC), rename the pointers for clarification.
> > > > > > This way, it will only be needed to add another pointer to
> > > > > > access the other control register when the time comes.
> > > > > >
> > > > > > This avoids dangerous situations where the offset 0 of the
> > > > > > control area can be either one register or the other
> > > > > > depending on the bindings used. After this change, device
> > > > > > trees of other SoCs could be migrated to the "full"
> > > > > > bindings if they may benefit from features from the
> > > > > > unaccessible register, without any change in the driver.
> > > > > >
> > > > > > Signed-off-by: Miquel Raynal
> > > > > > <miquel.raynal@free-electrons.com> Reviewed-by: Gregory
> > > > > > CLEMENT <gregory.clement@free-electrons.com> ---
> > > > >
> > > > > [...]
> > > > >
> > > > > > + /*
> > > > > > + * Legacy DT bindings only described "control1"
> > > > > > register (also referred
> > > > > > + * as "control MSB" on old documentation). New
> > > > > > bindings cover
> > > > > > + * "control0/control LSB" and "control1/control
> > > > > > MSB" registers within
> > > > > > + * the same resource, which is then of size 8
> > > > > > instead of 4.
> > > > > > + */
> > > > > > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > > > > > + /* ->control0 unavailable in this
> > > > > > configuration */
> > > > > > + priv->control1 = control +
> > > > > > LEGACY_CONTROL1_OFFSET;
> > > > > > + } else {
> > > > > > + priv->control0 = control + CONTROL0_OFFSET;
> > > > > > + priv->control1 = control + CONTROL1_OFFSET;
> > > > > > + }
> > > > >
> > > > > The needs_control0 field that you mentioned in the cover page
> > > > > is missing here.
> > > >
> > > > Yes, at this point nobody actually *needs* control0 so the
> > > > limitation is added with the patch that introduce ap806 support
> > > > as it is the first compatible that needs both control0 and
> > > > control1 to work correctly. Does this bother you?
> > >
> > > No. It is just that we agreed to have a verification here that the
> > > size of the control registers resource matches the binding. I
> > > thought that the needs_control0 field that you mention in the
> > > cover page is meant to implement that.
> >
> > That is absolutely right, but at this point in the series, the
> > supported compatible strings are
> > "marvell,armada[370|375|38x|xp]-thermal". All of them can use both
> > bindings so I don't see the point to have a needs_control0 field in
> > this patch. It is introduced in the next patch that adds support
> > for ap806 by only supporting the new bindings though.
>
> OK. Makes sense.
>
> > > necessary. It would just make sure that no one introduces a DT
> > > with the wrong resource size.
> >
> > Not sure I understand what exactly you wanna check, can you
> > give me an example?
>
> I wrote that before it occurred to me that we can use the control
> registers size the distinguish between the old binding and the new
> one.
>
> I still think it would be nice to add needs_control0=true to
> armada375_data, for consistency with the ap806 and cp110.
Oh that is right, I forgot about that. I will add it and move the
need_control0 boolean to this patch.
Thank you,
Miquèl
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Baruch Siach @ 2017-12-19 8:19 UTC (permalink / raw)
To: Miquel RAYNAL
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm, devicetree,
linux-arm-kernel, Thomas Petazzoni, Antoine Tenart, Nadav Haklai,
David Sniatkiwicz
In-Reply-To: <20171219090814.3a53ec3d@xps13>
Hi Miquèl,
On Tue, Dec 19, 2017 at 09:08:14AM +0100, Miquel RAYNAL wrote:
> On Tue, 19 Dec 2017 07:51:54 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
> > On Tue, Dec 19, 2017 at 01:32:33AM +0100, Miquel RAYNAL wrote:
> > > On Mon, 18 Dec 2017 22:35:42 +0200
> > > Baruch Siach <baruch@tkos.co.il> wrote:
> > > > On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal wrote:
> > > > > Bindings were incomplete for a long time by only exposing one of
> > > > > the two available control registers. To ease the migration to
> > > > > the full bindings (already in use for the Armada 375 SoC),
> > > > > rename the pointers for clarification. This way, it will only
> > > > > be needed to add another pointer to access the other control
> > > > > register when the time comes.
> > > > >
> > > > > This avoids dangerous situations where the offset 0 of the
> > > > > control area can be either one register or the other depending
> > > > > on the bindings used. After this change, device trees of other
> > > > > SoCs could be migrated to the "full" bindings if they may
> > > > > benefit from features from the unaccessible register, without
> > > > > any change in the driver.
> > > > >
> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > > > Reviewed-by: Gregory CLEMENT
> > > > > <gregory.clement@free-electrons.com> ---
> > > >
> > > > [...]
> > > >
> > > > > + /*
> > > > > + * Legacy DT bindings only described "control1"
> > > > > register (also referred
> > > > > + * as "control MSB" on old documentation). New bindings
> > > > > cover
> > > > > + * "control0/control LSB" and "control1/control MSB"
> > > > > registers within
> > > > > + * the same resource, which is then of size 8 instead
> > > > > of 4.
> > > > > + */
> > > > > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > > > > + /* ->control0 unavailable in this
> > > > > configuration */
> > > > > + priv->control1 = control +
> > > > > LEGACY_CONTROL1_OFFSET;
> > > > > + } else {
> > > > > + priv->control0 = control + CONTROL0_OFFSET;
> > > > > + priv->control1 = control + CONTROL1_OFFSET;
> > > > > + }
> > > >
> > > > The needs_control0 field that you mentioned in the cover page is
> > > > missing here.
> > >
> > > Yes, at this point nobody actually *needs* control0 so the
> > > limitation is added with the patch that introduce ap806 support as
> > > it is the first compatible that needs both control0 and control1 to
> > > work correctly. Does this bother you?
> >
> > No. It is just that we agreed to have a verification here that the
> > size of the control registers resource matches the binding. I thought
> > that the needs_control0 field that you mention in the cover page is
> > meant to implement that.
>
> That is absolutely right, but at this point in the series, the supported
> compatible strings are "marvell,armada[370|375|38x|xp]-thermal". All of
> them can use both bindings so I don't see the point to have a
> needs_control0 field in this patch. It is introduced in the next patch
> that adds support for ap806 by only supporting the new bindings
> though.
OK. Makes sense.
> > necessary. It would just make sure that no one introduces a DT with
> > the wrong resource size.
>
> Not sure I understand what exactly you wanna check, can you
> give me an example?
I wrote that before it occurred to me that we can use the control registers
size the distinguish between the old binding and the new one.
I still think it would be nice to add needs_control0=true to armada375_data,
for consistency with the ap806 and cp110.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH 23/25] arm: da8: dts: Remove leading 0x and 0s from bindings notation
From: Sekhar Nori @ 2017-12-19 8:11 UTC (permalink / raw)
To: Mathieu Malaterre, Rob Herring
Cc: Kevin Hilman, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215124657.31052-1-malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
On Friday 15 December 2017 06:16 PM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Suggested-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Mathieu Malaterre <malat-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Applied to v4.16/fixes-non-critical with some headline adjustments.
The subject prefix we use for this file is "ARM: dts: da850-lcdk:". You
can check that with 'git log --oneline'
Also, you are not fixing bindings notation here, but the actual device
tree source itself. So:
"
ARM: dts: da850-lcdk: Remove leading 0x and 0s from unit address
"
Thanks for the patch!
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Miquel RAYNAL @ 2017-12-19 8:08 UTC (permalink / raw)
To: Baruch Siach
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171219055154.f23leaob3zndmmqo-MwjkAAnuF3khR1HGirfZ1z4kX+cae0hd@public.gmane.org>
On Tue, 19 Dec 2017 07:51:54 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> Hi Miquèl,
>
> On Tue, Dec 19, 2017 at 01:32:33AM +0100, Miquel RAYNAL wrote:
> > On Mon, 18 Dec 2017 22:35:42 +0200
> > Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > > On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal wrote:
> > > > Bindings were incomplete for a long time by only exposing one of
> > > > the two available control registers. To ease the migration to
> > > > the full bindings (already in use for the Armada 375 SoC),
> > > > rename the pointers for clarification. This way, it will only
> > > > be needed to add another pointer to access the other control
> > > > register when the time comes.
> > > >
> > > > This avoids dangerous situations where the offset 0 of the
> > > > control area can be either one register or the other depending
> > > > on the bindings used. After this change, device trees of other
> > > > SoCs could be migrated to the "full" bindings if they may
> > > > benefit from features from the unaccessible register, without
> > > > any change in the driver.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > > Reviewed-by: Gregory CLEMENT
> > > > <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> ---
> > >
> > > [...]
> > >
> > > > + /*
> > > > + * Legacy DT bindings only described "control1"
> > > > register (also referred
> > > > + * as "control MSB" on old documentation). New bindings
> > > > cover
> > > > + * "control0/control LSB" and "control1/control MSB"
> > > > registers within
> > > > + * the same resource, which is then of size 8 instead
> > > > of 4.
> > > > + */
> > > > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > > > + /* ->control0 unavailable in this
> > > > configuration */
> > > > + priv->control1 = control +
> > > > LEGACY_CONTROL1_OFFSET;
> > > > + } else {
> > > > + priv->control0 = control + CONTROL0_OFFSET;
> > > > + priv->control1 = control + CONTROL1_OFFSET;
> > > > + }
> > >
> > > The needs_control0 field that you mentioned in the cover page is
> > > missing here.
> >
> > Yes, at this point nobody actually *needs* control0 so the
> > limitation is added with the patch that introduce ap806 support as
> > it is the first compatible that needs both control0 and control1 to
> > work correctly. Does this bother you?
>
> No. It is just that we agreed to have a verification here that the
> size of the control registers resource matches the binding. I thought
> that the needs_control0 field that you mention in the cover page is
> meant to implement that.
That is absolutely right, but at this point in the series, the supported
compatible strings are "marvell,armada[370|375|38x|xp]-thermal". All of
them can use both bindings so I don't see the point to have a
needs_control0 field in this patch. It is introduced in the next patch
that adds support for ap806 by only supporting the new bindings
though.
> necessary. It would just make sure that no one introduces a DT with
> the wrong resource size.
Not sure I understand what exactly you wanna check, can you
give me an example?
Thank you,
Miquèl
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 6/6] arm: dts: sun8i: h3-h8: ir register size should be the whole memory block
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219080747.4507-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The size of the register should be the size of the whole memory block,
not just the registers, that are needed.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 8d40c00d64bb..a9caeda4a574 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -674,7 +674,7 @@
clock-names = "apb", "ir";
resets = <&r_ccu RST_APB0_IR>;
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x01f02000 0x40>;
+ reg = <0x01f02000 0x400>;
status = "disabled";
};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 5/6] arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219080747.4507-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The Bananapi M3 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Unlike the other IR receivers this one needs a base clock frequency
of 3000000 Hz (3 MHz), to be able to work.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..ffc6445fd281 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -82,6 +82,13 @@
};
};
+&cir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cir_pins>;
+ clock-frequency = <3000000>;
+ status = "okay";
+};
+
&ehci0 {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
--
2.11.0
^ permalink raw reply related
* [PATCH v3 4/6] arm: dts: sun8i: a83t: Add support for the cir interface
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219080747.4507-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The cir interface is like on the H3 located at 0x01f02000 and is exactly
the same. This patch adds support for the ir interface on the A83T.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 06e96db7c41a..ddc0d592107f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -605,6 +605,16 @@
#reset-cells = <1>;
};
+ cir: cir@01f02000 {
+ compatible = "allwinner,sun5i-a13-ir";
+ clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_APB0_IR>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x01f02000 0x400>;
+ status = "disabled";
+ };
+
r_pio: pinctrl@1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/6] arm: dts: sun8i: a83t: Add the cir pin for the A83T
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219080747.4507-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The CIR Pin of the A83T is located at PL12.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index de5119a2a91c..06e96db7c41a 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -617,6 +617,11 @@
interrupt-controller;
#interrupt-cells = <3>;
+ cir_pins: cir-pins@0 {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
+
r_rsb_pins: r-rsb-pins {
pins = "PL0", "PL1";
function = "s_rsb";
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/6] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219080747.4507-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new optional property for the base clock
frequency.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..278098987edb 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -11,6 +11,8 @@ Required properties:
Optional properties:
- linux,rc-map-name: see rc.txt file in the same directory.
- resets : phandle + reset specifier pair
+- clock-frequency : IR Receiver clock frequency, in Hertz. Defaults to 8 MHz
+ if missing.
Example:
@@ -18,6 +20,7 @@ ir0: ir@1c21800 {
compatible = "allwinner,sun4i-a10-ir";
clocks = <&apb0_gates 6>, <&ir0_clk>;
clock-names = "apb", "ir";
+ clock-frequency = <3000000>;
resets = <&apb0_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171219080747.4507-1-embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch updates the sunxi-ir driver to set the base clock frequency from
devicetree.
This is necessary since there are different ir receivers on the
market, that operate with different frequencies. So this value could be
set if the attached ir receiver needs a different base clock frequency,
than the default 8 MHz.
Signed-off-by: Philipp Rossak <embed3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..f500cea228a9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,8 @@
/* CIR_REG register idle threshold */
#define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
-/* Required frequency for IR0 or IR1 clock in CIR mode */
+/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
#define SUNXI_IR_BASE_CLK 8000000
-/* Frequency after IR internal divider */
-#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
/* Noise threshold in samples */
#define SUNXI_IR_RXNOISE 1
/* Idle Threshold in samples */
@@ -122,7 +118,8 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
- rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+ rawir.duration = ((dt & 0x7f) + 1) *
+ ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, &rawir);
}
}
@@ -148,6 +145,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+ u32 b_clk_freq = SUNXI_IR_BASE_CLK;
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +170,9 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
+ /* Base clock frequency (optional) */
+ of_property_read_u32(dn, "clock-frequency", &b_clk_freq);
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,11 +181,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+ ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
}
+ dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
if (clk_prepare_enable(ir->apb_clk)) {
dev_err(dev, "try to enable apb_ir_clk failed\n");
@@ -225,7 +227,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
- ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+ /* Frequency after IR internal divider with sample period in ns */
+ ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 0/6] arm: sunxi: IR support for A83T
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
This patch series adds support for the sunxi A83T ir module and enhances
the sunxi-ir driver. Right now the base clock frequency for the ir driver
is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3
the ir receiver needs, a 3 MHz base clock frequency to work without
problems with this driver.
This patch series adds support for an optinal property that makes it able
to override the default base clock frequency and enables the ir interface
on the a83t and the Bananapi M3.
changes since v2:
* reorder cir pin (alphabetical)
* fix typo in documentation
changes since v1:
* fix typos, reword Documentation
* initialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' & remove if statement
* change dev_info() to dev_dbg()
* change naming to cir* in dts/dtsi
* Added acked Ackedi-by to related patch
* use whole memory block instead of registers needed + fix for h3/h5
changes since rfc:
* The property is now optinal. If the property is not available in
the dtb the driver uses the default base clock frequency.
* the driver prints out the the selected base clock frequency.
* changed devicetree property from base-clk-frequency to clock-frequency
Regards,
Philipp
Philipp Rossak (6):
media: rc: update sunxi-ir driver to get base clock frequency from
devicetree
media: dt: bindings: Update binding documentation for sunxi IR
controller
arm: dts: sun8i: a83t: Add the cir pin for the A83T
arm: dts: sun8i: a83t: Add support for the cir interface
arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
arm: dts: sun8i: h3-h8: ir register size should be the whole memory
block
Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
5 files changed, 37 insertions(+), 9 deletions(-)
--
2.11.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox