* [PATCH net-next v3 01/10] net: mvpp2: align the ethtool ops definition
From: Antoine Tenart @ 2018-05-17 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517082939.14598-1-antoine.tenart@bootlin.com>
Cosmetic patch to align the ethtool functions to ops definitions. This
patch does not change in any way the driver's behaviour.
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 6f410235987c..77dd91e3d962 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -7859,18 +7859,18 @@ static const struct net_device_ops mvpp2_netdev_ops = {
};
static const struct ethtool_ops mvpp2_eth_tool_ops = {
- .nway_reset = phy_ethtool_nway_reset,
- .get_link = ethtool_op_get_link,
- .set_coalesce = mvpp2_ethtool_set_coalesce,
- .get_coalesce = mvpp2_ethtool_get_coalesce,
- .get_drvinfo = mvpp2_ethtool_get_drvinfo,
- .get_ringparam = mvpp2_ethtool_get_ringparam,
- .set_ringparam = mvpp2_ethtool_set_ringparam,
- .get_strings = mvpp2_ethtool_get_strings,
- .get_ethtool_stats = mvpp2_ethtool_get_stats,
- .get_sset_count = mvpp2_ethtool_get_sset_count,
- .get_link_ksettings = phy_ethtool_get_link_ksettings,
- .set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .nway_reset = phy_ethtool_nway_reset,
+ .get_link = ethtool_op_get_link,
+ .set_coalesce = mvpp2_ethtool_set_coalesce,
+ .get_coalesce = mvpp2_ethtool_get_coalesce,
+ .get_drvinfo = mvpp2_ethtool_get_drvinfo,
+ .get_ringparam = mvpp2_ethtool_get_ringparam,
+ .set_ringparam = mvpp2_ethtool_set_ringparam,
+ .get_strings = mvpp2_ethtool_get_strings,
+ .get_ethtool_stats = mvpp2_ethtool_get_stats,
+ .get_sset_count = mvpp2_ethtool_get_sset_count,
+ .get_link_ksettings = phy_ethtool_get_link_ksettings,
+ .set_link_ksettings = phy_ethtool_set_link_ksettings,
};
/* Used for PPv2.1, or PPv2.2 with the old Device Tree binding that
--
2.17.0
^ permalink raw reply related
* [PATCH net-next v3 00/10] net: mvpp2: phylink conversion
From: Antoine Tenart @ 2018-05-17 8:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Dave, Russell,
This series convert the Marvell PPv2 driver to phylink (models the MAC
to PHY link).
One important point is the PPv2 driver supports two probe modes: device
tree and ACPI. This series only brings phylink support for the device
tree mode, as the ACPI one will need further work. Still, the driver
should be working as before when using ACPI. This split should be
temporary, and was discussed with Marcin (in Cc.) who added ACPI support
to the driver.
Also as the SFP cages on both DB boards can be considered as non-wired.
We thus chose not to describe those SFP cages and we use fixed-link.
The rest of the series uses phylink to add support for 1000BaseX and
2500BaseX modes in the PPv2 driver. To do this, two patches are needed
in the common PHY framework (patches 3 and 4). The last 4 patches modify
the device tree to use the new PPv2 functionalities.
The series has been tested for the device tree mode on the 7040-db,
8040-db and 8040-mcbin boards, to ensure all the interface where working
as expected.
@Dave: patches 7 to 10 should go through the mvebu tree (Gregory in
Cc.) to avoid any conflict with the other mvebu dt patches taken during
this cycle.
The series is based on today's net-next.
Thanks!
Antoine
Since v2:
- Removed the SFP description from the DB boards, as their SFP cages
are wired properly. We now use fixed-link.
- Because of this rework, split the series in two, so that the SFP
part is reviewed separately.
- Small fixes in the phylink patch.
- Rebased on the latest net-next branch.
Since v1:
- Chose a different approach to the SFP changes, as the previous ones
weren't valid and reworked both BD boards device trees.
- Misc fixes.
- Added Kishon's acked-by on one patch.
- Rebaed on latest net-next branch.
Antoine Tenart (9):
net: mvpp2: align the ethtool ops definition
net: mvpp2: phylink support
phy: add 2.5G SGMII mode to the phy_mode enum
phy: cp110-comphy: 2.5G SGMII mode
net: mvpp2: 1000baseX support
net: mvpp2: 2500baseX support
arm64: dts: marvell: mcbin: enable the fourth network interface
arm64: dts: marvell: 8040-db: describe the 10G interfaces as
fixed-link
arm64: dts: marvell: 7040-db: describe the 10G interface as fixed-link
Russell King (1):
arm64: dts: marvell: mcbin: add 10G SFP support
.../arm64/boot/dts/marvell/armada-7040-db.dts | 5 +
.../arm64/boot/dts/marvell/armada-8040-db.dts | 10 +
.../boot/dts/marvell/armada-8040-mcbin.dts | 70 ++
drivers/net/ethernet/marvell/Kconfig | 1 +
drivers/net/ethernet/marvell/mvpp2.c | 931 +++++++++++-------
drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 +-
include/linux/phy/phy.h | 1 +
7 files changed, 680 insertions(+), 355 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active
From: jacopo mondi @ 2018-05-17 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516215538.GC17948@bigcity.dyn.berto.se>
Hi Niklas,
On Wed, May 16, 2018 at 11:55:38PM +0200, Niklas S?derlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-16 18:32:28 +0200, Jacopo Mondi wrote:
> > Document 'data-active' property in R-Car VIN device tree bindings.
> > The property is optional when running with explicit synchronization
> > (eg. BT.601) but mandatory when embedded synchronization is in use (eg.
> > BT.656) as specified by the hardware manual.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index c53ce4e..17eac8a 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -63,6 +63,11 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> > If both HSYNC and VSYNC polarities are not specified, embedded
> > synchronization is selected.
> >
> > + - data-active: active state of data enable signal (CLOCKENB pin).
>
> I'm not sure what you mean by active state here. video-interfaces.txt
> defines data-active as 'similar to HSYNC and VSYNC, specifies data line
> polarity' so I assume this is the polarity of the CLOCKENB pin?
Yes, I can change this if it feels confusing to you.
>
> > + 0/1 for LOW/HIGH respectively. If not specified, use HSYNC as
> > + data enable signal. When using embedded synchronization this
> > + property is mandatory.
>
> I'm confused, why is this mandatory if we have no embedded sync (that is
> hsync-active and vsync-active not defined)? I can't find any reference
> to this in the Gen2 datasheet but I'm sure I'm just missing it :-)
>
Not exactly, it becomes mandatory IF we have embedded sync.
Here it is my reasoning:
In the documentation of CHS bit of Vn_DMR2 register [1] the following
is specified:
"When using ITU-R BT.601, BT.709, BT.1358 interface, and the
VIn_CLKENB pin is unused, the CHS bit must be set to 1."
And setting the CHS bit to 1:
"HSYNC signal (VIn_HSYNC#) input from the pin is internally used
as the clock enable signal"
So, if 'data-active' property is not specified I assume CLCKENB is not
used, and set the CHS bit. What if we are using BT656 and there is no
HSYNC? Then specifying 'data-active' becomes mandatory, as otherwise we
set the CHS bit and wait for HSYNC pin transitions that won't happen.
This is probably wrong, as in the Koelsch case, there is no guarantee
that CLKENB is connected, and what I should have done is probably set
the CHS bit only when running on V4L2_MBUS_PARALLEL, and leave CHS
(and CES, if 'data-active' is not specified) untouched, as we're doing
today when running on V4L2_MBUS_BT656. Does this work better in your
opinion?
This also makes patch [6/6] (where I was adding 'data-active' to Gen-2
boards) not required.
Thanks
j
[1] 26.2.18 Video n Data Mode Register 2 (VnDMR2) Datasheet version,
R19UH0105EJ0100 Rev.1.00 Apr 30, 2018
> > +
> > - port 1 - sub-nodes describing one or more endpoints connected to
> > the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> > use the following schema.
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas S?derlund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/6971752f/attachment.sig>
^ permalink raw reply
* [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-17 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516141132.aqjif7d5motmmnlo@vireshk-i7>
> -----Original Message-----
> From: ilialin at codeaurora.org <ilialin@codeaurora.org>
> Sent: Thursday, May 17, 2018 10:51
> To: 'Viresh Kumar' <viresh.kumar@linaro.org>; 'Amit Kucheria'
> <amit.kucheria@linaro.org>
> Cc: 'Michael Turquette' <mturquette@baylibre.com>; 'sboyd at kernel.org'
> <sboyd@kernel.org>; 'Rob Herring' <robh@kernel.org>; 'Mark Rutland'
> <mark.rutland@arm.com>; 'nm at ti.com' <nm@ti.com>;
> 'lgirdwood at gmail.com' <lgirdwood@gmail.com>; 'broonie at kernel.org'
> <broonie@kernel.org>; 'Andy Gross' <andy.gross@linaro.org>; 'David Brown'
> <david.brown@linaro.org>; 'catalin.marinas at arm.com'
> <catalin.marinas@arm.com>; 'will.deacon at arm.com'
> <will.deacon@arm.com>; 'Rafael J. Wysocki' <rjw@rjwysocki.net>; 'linux-
> clk at vger.kernel.org' <linux-clk@vger.kernel.org>;
> 'devicetree at vger.kernel.org' <devicetree@vger.kernel.org>; 'LKML' <linux-
> kernel at vger.kernel.org>; 'Linux PM list' <linux-pm@vger.kernel.org>;
'linux-
> arm-msm at vger.kernel.org' <linux-arm-msm@vger.kernel.org>; 'linux-
> soc at vger.kernel.org' <linux-soc@vger.kernel.org>; 'lakml' <linux-arm-
> kernel at lists.infradead.org>; 'Rajendra Nayak' <rnayak@codeaurora.org>;
> 'nicolas.dechesne at linaro.org' <nicolas.dechesne@linaro.org>;
> 'celster at codeaurora.org' <celster@codeaurora.org>;
> 'tfinkel at codeaurora.org' <tfinkel@codeaurora.org>
> Subject: RE: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
>
>
>
> > -----Original Message-----
> > From: Viresh Kumar <viresh.kumar@linaro.org>
> > Sent: Wednesday, May 16, 2018 17:12
> > To: Amit Kucheria <amit.kucheria@linaro.org>
> > Cc: Ilia Lin <ilialin@codeaurora.org>; Michael Turquette
> > <mturquette@baylibre.com>; sboyd at kernel.org; Rob Herring
> > <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>; nm at ti.com;
> > lgirdwood at gmail.com; broonie at kernel.org; Andy Gross
> > <andy.gross@linaro.org>; David Brown <david.brown@linaro.org>;
> > catalin.marinas at arm.com; will.deacon at arm.com; Rafael J. Wysocki
> > <rjw@rjwysocki.net>; linux-clk at vger.kernel.org;
> > devicetree at vger.kernel.org; LKML <linux-kernel@vger.kernel.org>; Linux
> > PM list <linux-pm@vger.kernel.org>; linux-arm-msm at vger.kernel.org;
> > linux- soc at vger.kernel.org; lakml
> > <linux-arm-kernel@lists.infradead.org>;
> > Rajendra Nayak <rnayak@codeaurora.org>; nicolas.dechesne at linaro.org;
> > celster at codeaurora.org; tfinkel at codeaurora.org
> > Subject: Re: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
> >
> > On 16-05-18, 16:12, Amit Kucheria wrote:
> > > > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > > > +
> > dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > > + if (0 > ret)
> > >
> > > Any particular reason to prefer this over (ret < 0) that is
> > > generally used? I've seen it used to avoid the == vs. = typos, but
> > > not for other comparisons.
> > >
> > > Suggest sticking to what is commonly used i.e. ret < 0.
> > >
> > > > + goto free_opp;
> > > > +
> > > > + cpu_dev = get_cpu_device(GOLD_LEAD);
> > >
> > > Error check cpu_dev here?
> > >
> > > > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > > > +
> > dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > > + if (0 > ret)
> > > > + goto free_opp;
> >
> > The goto here is wrong
>
> If we are here, then the first dev_pm_opp_set_supported_hw() succeeded.
> And should be deallocated before exit with error.
My bad. Got you.
>
> >
> > > > +
> > > > +
> > > > + ret =
> > PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-dt",
> > > > + -1,
> > > > + NULL, 0));
> > > > +
> > > > + if (0 == ret)
> > > > + return 0;
> > > > +
> > > > +free_opp:
> > > > + dev_pm_opp_put_supported_hw(opp_temp);
> > >
> > > This is not needed because dev_pm_opp_set_supported_hw will free
> > > memory in case of failure. This call in only needed in case of a
> > > successful get.
> >
> > But this is still required for the case where platform device
registration fails.
> >
> > --
> > viresh
^ permalink raw reply
* [PATCH] KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in unmap_stage2_range
From: Suzuki K Poulose @ 2018-05-17 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526537487-14804-1-git-send-email-hejianet@gmail.com>
Hi Jia,
On 17/05/18 07:11, Jia He wrote:
> I ever met a panic under memory pressure tests(start 20 guests and run
> memhog in the host).
Please avoid using "I" in the commit description and preferably stick to
an objective description.
>
> The root cause might be what I fixed at [1]. But from arm kvm points of
> view, it would be better we caught the exception earlier and clearer.
>
> If the size is not PAGE_SIZE aligned, unmap_stage2_range might unmap the
> wrong(more or less) page range. Hence it caused the "BUG: Bad page
> state"
I don't see why we should ever panic with a "positive" size value. Anyways,
the unmap requests must be in units of pages. So this check might be useful.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>
> [1] https://lkml.org/lkml/2018/5/3/1042
>
> Signed-off-by: jia.he at hxt-semitech.com
> ---
> virt/kvm/arm/mmu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 7f6a944..8dac311 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -297,6 +297,8 @@ static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
> phys_addr_t next;
>
> assert_spin_locked(&kvm->mmu_lock);
> + WARN_ON(size & ~PAGE_MASK);
> +
> pgd = kvm->arch.pgd + stage2_pgd_index(addr);
> do {
> /*
>
^ permalink raw reply
* [PATCH 1/8] firmware: arm_scmi: improve code readability using bitfield accessor macros
From: Jonathan Cameron @ 2018-05-17 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-2-git-send-email-sudeep.holla@arm.com>
On Wed, 9 May 2018 18:07:07 +0100
Sudeep Holla <sudeep.holla@arm.com> wrote:
> By using FIELD_{FIT,GET,PREP} and GENMASK macro accessors we can avoid
> some clumpsy custom shifting and masking macros and also improve the
> code better readability.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Hi Sudeep,
A minor comment inline.
Jonathan
> ---
> drivers/firmware/arm_scmi/common.h | 9 +++++----
> drivers/firmware/arm_scmi/driver.c | 31 ++++++++++++++-----------------
> 2 files changed, 19 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h
> index 0c30234f9098..e8f332c9c469 100644
> --- a/drivers/firmware/arm_scmi/common.h
> +++ b/drivers/firmware/arm_scmi/common.h
> @@ -7,6 +7,7 @@
> * Copyright (C) 2018 ARM Ltd.
> */
>
> +#include <linux/bitfield.h>
> #include <linux/completion.h>
> #include <linux/device.h>
> #include <linux/errno.h>
> @@ -14,10 +15,10 @@
> #include <linux/scmi_protocol.h>
> #include <linux/types.h>
>
> -#define PROTOCOL_REV_MINOR_BITS 16
> -#define PROTOCOL_REV_MINOR_MASK ((1U << PROTOCOL_REV_MINOR_BITS) - 1)
> -#define PROTOCOL_REV_MAJOR(x) ((x) >> PROTOCOL_REV_MINOR_BITS)
> -#define PROTOCOL_REV_MINOR(x) ((x) & PROTOCOL_REV_MINOR_MASK)
> +#define PROTOCOL_REV_MINOR_MASK GENMASK(15, 0)
> +#define PROTOCOL_REV_MAJOR_MASK GENMASK(31, 16)
> +#define PROTOCOL_REV_MAJOR(x) (u16)(FIELD_GET(PROTOCOL_REV_MAJOR_MASK, (x)))
> +#define PROTOCOL_REV_MINOR(x) (u16)(FIELD_GET(PROTOCOL_REV_MINOR_MASK, (x)))
> #define MAX_PROTOCOLS_IMP 16
> #define MAX_OPPS 16
>
> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 14b147135a0c..917786d91f55 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -29,16 +29,12 @@
>
> #include "common.h"
>
> -#define MSG_ID_SHIFT 0
> -#define MSG_ID_MASK 0xff
> -#define MSG_TYPE_SHIFT 8
> -#define MSG_TYPE_MASK 0x3
> -#define MSG_PROTOCOL_ID_SHIFT 10
> -#define MSG_PROTOCOL_ID_MASK 0xff
> -#define MSG_TOKEN_ID_SHIFT 18
> -#define MSG_TOKEN_ID_MASK 0x3ff
> -#define MSG_XTRACT_TOKEN(header) \
> - (((header) >> MSG_TOKEN_ID_SHIFT) & MSG_TOKEN_ID_MASK)
> +#define MSG_ID_MASK GENMASK(7, 0)
> +#define MSG_TYPE_MASK GENMASK(9, 8)
> +#define MSG_PROTOCOL_ID_MASK GENMASK(17, 10)
> +#define MSG_TOKEN_ID_MASK GENMASK(27, 18)
> +#define MSG_XTRACT_TOKEN(hdr) FIELD_GET(MSG_TOKEN_ID_MASK, (hdr))
> +#define MSG_TOKEN_MAX (MSG_XTRACT_TOKEN(MSG_TOKEN_ID_MASK) + 1)
This feels a little odd. It's not the Max value, I think, but rather one more than
it. I would set it to this -1 and use > than in the test below.
>
> enum scmi_error_codes {
> SCMI_SUCCESS = 0, /* Success */
> @@ -255,9 +251,9 @@ static void scmi_rx_callback(struct mbox_client *cl, void *m)
> */
> static inline u32 pack_scmi_header(struct scmi_msg_hdr *hdr)
> {
> - return ((hdr->id & MSG_ID_MASK) << MSG_ID_SHIFT) |
> - ((hdr->seq & MSG_TOKEN_ID_MASK) << MSG_TOKEN_ID_SHIFT) |
> - ((hdr->protocol_id & MSG_PROTOCOL_ID_MASK) << MSG_PROTOCOL_ID_SHIFT);
> + return FIELD_PREP(MSG_ID_MASK, hdr->id) |
> + FIELD_PREP(MSG_TOKEN_ID_MASK, hdr->seq) |
> + FIELD_PREP(MSG_PROTOCOL_ID_MASK, hdr->protocol_id);
> }
>
> /**
> @@ -621,9 +617,9 @@ static int scmi_xfer_info_init(struct scmi_info *sinfo)
> struct scmi_xfers_info *info = &sinfo->minfo;
>
> /* Pre-allocated messages, no more than what hdr.seq can support */
> - if (WARN_ON(desc->max_msg >= (MSG_TOKEN_ID_MASK + 1))) {
> - dev_err(dev, "Maximum message of %d exceeds supported %d\n",
> - desc->max_msg, MSG_TOKEN_ID_MASK + 1);
> + if (WARN_ON(desc->max_msg >= MSG_TOKEN_MAX)) {
> + dev_err(dev, "Maximum message of %d exceeds supported %ld\n",
> + desc->max_msg, MSG_TOKEN_MAX);
> return -EINVAL;
> }
>
> @@ -840,7 +836,8 @@ static int scmi_probe(struct platform_device *pdev)
> if (of_property_read_u32(child, "reg", &prot_id))
> continue;
>
> - prot_id &= MSG_PROTOCOL_ID_MASK;
> + if (!FIELD_FIT(MSG_PROTOCOL_ID_MASK, prot_id))
> + dev_err(dev, "Out of range protocol %d\n", prot_id);
>
> if (!scmi_is_protocol_implemented(handle, prot_id)) {
> dev_err(dev, "SCMI protocol %d not implemented\n",
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-17 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516074333.i2672u435ymwffk3@verge.net.au>
On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>> Hi Gilad,
>>
>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> > Add bindings for CryptoCell instance in the SoC.
>> >
>> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>>
>> Thanks for your patch!
>>
>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> > @@ -528,6 +528,14 @@
>> > status = "disabled";
>> > };
>> >
>> > + arm_cc630p: crypto at e6601000 {
>> > + compatible = "arm,cryptocell-630p-ree";
>> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>> > + #interrupt-cells = <2>;
>>
>> I believe the #interrupt-cells property is not needed.
>>
>> > + reg = <0x0 0xe6601000 0 0x1000>;
>> > + clocks = <&cpg CPG_MOD 229>;
>> > + };
>>
>> The rest looks good, but I cannot verify the register block.
>>
>> > +
>> > i2c3: i2c at e66d0000 {
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>
> Thanks, I have applied this after dropping the #interrupt-cells property.
Thanks you!
Alas, it will not work without the clk patch (the previous one in the
series) so they need to be
taken or dropped together.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock
From: Gilad Ben-Yossef @ 2018-05-17 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXWPwW_p=D56BhNF274m+JLe+mbD2fqQu8-we-uMW4b8Q@mail.gmail.com>
On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> This patch adds the clock used by the CryptoCell 630p instance in the SoC.
>>
>> Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>
> Thanks for your patch!
>
>> --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
>> +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
>> @@ -132,6 +132,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
>> DEF_MOD("sys-dmac2", 217, R8A7795_CLK_S0D3),
>> DEF_MOD("sys-dmac1", 218, R8A7795_CLK_S0D3),
>> DEF_MOD("sys-dmac0", 219, R8A7795_CLK_S0D3),
>> + DEF_MOD("ccree", 229, R8A7795_CLK_S3D2),
>
> I don't know if "ccree" is the proper name for this clock, as there
> may be multiple
> instances.
I'd be happy to rename it to anything else. Suggestions?
> I also can't verify the parent clock.
I'm afraid I can't really help. This is based on code snippet from
Renesas. I verified it works but
I am not an expert on the clock settings :-(
>
>> DEF_MOD("cmt3", 300, R8A7795_CLK_R),
>> DEF_MOD("cmt2", 301, R8A7795_CLK_R),
>> DEF_MOD("cmt1", 302, R8A7795_CLK_R),
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-17 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516141132.aqjif7d5motmmnlo@vireshk-i7>
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Wednesday, May 16, 2018 17:12
> To: Amit Kucheria <amit.kucheria@linaro.org>
> Cc: Ilia Lin <ilialin@codeaurora.org>; Michael Turquette
> <mturquette@baylibre.com>; sboyd at kernel.org; Rob Herring
> <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>; nm at ti.com;
> lgirdwood at gmail.com; broonie at kernel.org; Andy Gross
> <andy.gross@linaro.org>; David Brown <david.brown@linaro.org>;
> catalin.marinas at arm.com; will.deacon at arm.com; Rafael J. Wysocki
> <rjw@rjwysocki.net>; linux-clk at vger.kernel.org;
> devicetree at vger.kernel.org; LKML <linux-kernel@vger.kernel.org>; Linux
> PM list <linux-pm@vger.kernel.org>; linux-arm-msm at vger.kernel.org; linux-
> soc at vger.kernel.org; lakml <linux-arm-kernel@lists.infradead.org>;
> Rajendra Nayak <rnayak@codeaurora.org>; nicolas.dechesne at linaro.org;
> celster at codeaurora.org; tfinkel at codeaurora.org
> Subject: Re: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
>
> On 16-05-18, 16:12, Amit Kucheria wrote:
> > > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > > +
> dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > + if (0 > ret)
> >
> > Any particular reason to prefer this over (ret < 0) that is generally
> > used? I've seen it used to avoid the == vs. = typos, but not for other
> > comparisons.
> >
> > Suggest sticking to what is commonly used i.e. ret < 0.
> >
> > > + goto free_opp;
> > > +
> > > + cpu_dev = get_cpu_device(GOLD_LEAD);
> >
> > Error check cpu_dev here?
> >
> > > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > > +
> dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > > + if (0 > ret)
> > > + goto free_opp;
>
> The goto here is wrong
If we are here, then the first dev_pm_opp_set_supported_hw() succeeded. And
should be deallocated before exit with error.
>
> > > +
> > > +
> > > + ret =
> PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-dt",
> > > + -1,
> > > + NULL, 0));
> > > +
> > > + if (0 == ret)
> > > + return 0;
> > > +
> > > +free_opp:
> > > + dev_pm_opp_put_supported_hw(opp_temp);
> >
> > This is not needed because dev_pm_opp_set_supported_hw will free
> > memory in case of failure. This call in only needed in case of a
> > successful get.
>
> But this is still required for the case where platform device registration
fails.
>
> --
> viresh
^ permalink raw reply
* [PATCH 1/1] ARM:dts:sunxi: Add Olimex A20-SOM-EVB-eMMC board
From: Stefan Mavrodiev @ 2018-05-17 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <96201051.35560.1526541952287@email.1und1.de>
On 05/17/2018 10:25 AM, Stefan Wahren wrote:
> Hi Stefan,
>
>> Stefan Mavrodiev <stefan@olimex.com> hat am 16. Mai 2018 um 13:38 geschrieben:
>>
>>
>> With the new rev.E of A20-SOM-EVB, there is option for 16GB eMMC.
>> Currently used card is KLMAG2GEND, wired to MMC2 slot.
>>
>> Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> .../arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts | 37 ++++++++++++++++++++++
>> 2 files changed, 38 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 1db91ec..7f1ee65 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -959,6 +959,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-m3.dtb \
>> sun7i-a20-mk808c.dtb \
>> sun7i-a20-olimex-som-evb.dtb \
>> + sun7i-a20-olimex-som-evb-emmc.dtb \
>> sun7i-a20-olimex-som204-evb.dtb \
>> sun7i-a20-olimex-som204-evb-emmc.dtb \
>> sun7i-a20-olinuxino-lime.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
>> new file mode 100644
>> index 0000000..81ebc97
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
>> @@ -0,0 +1,37 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Device Tree Source for A20-Olimex-SOM-EVB-eMMC Board
>> + *
>> + * Copyright (C) 2018 Olimex Ltd.
>> + * Author: Stefan Mavrodiev <stefan@olimex.com>
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun7i-a20-olimex-som-evb.dts"
>> +
>> +/ {
>> +
>> + model = "Olimex A20-Olimex-SOM-EVB-eMMC";
>> + compatible = "olimex,a20-olimex-som-evb-emmc", "allwinner,sun7i-a20";
> the file Documentation/devicetree/bindings/arm/olimex.txt seems to be out of date. I cannot find any recent board compatible.
>
> Didn't checkpatch complain about it?
Yes it did. I didn't get is seriously because neither Olimex A20 based
board is documented in the binding.
>
> Regards
> Stefan
Regards,
Stefan Mavrodiev
^ permalink raw reply
* [PATCH 1/1] ARM:dts:sunxi: Add Olimex A20-SOM-EVB-eMMC board
From: Stefan Wahren @ 2018-05-17 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526470689-6275-1-git-send-email-stefan@olimex.com>
Hi Stefan,
> Stefan Mavrodiev <stefan@olimex.com> hat am 16. Mai 2018 um 13:38 geschrieben:
>
>
> With the new rev.E of A20-SOM-EVB, there is option for 16GB eMMC.
> Currently used card is KLMAG2GEND, wired to MMC2 slot.
>
> Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> .../arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts | 37 ++++++++++++++++++++++
> 2 files changed, 38 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 1db91ec..7f1ee65 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -959,6 +959,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> sun7i-a20-m3.dtb \
> sun7i-a20-mk808c.dtb \
> sun7i-a20-olimex-som-evb.dtb \
> + sun7i-a20-olimex-som-evb-emmc.dtb \
> sun7i-a20-olimex-som204-evb.dtb \
> sun7i-a20-olimex-som204-evb-emmc.dtb \
> sun7i-a20-olinuxino-lime.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
> new file mode 100644
> index 0000000..81ebc97
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Device Tree Source for A20-Olimex-SOM-EVB-eMMC Board
> + *
> + * Copyright (C) 2018 Olimex Ltd.
> + * Author: Stefan Mavrodiev <stefan@olimex.com>
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20-olimex-som-evb.dts"
> +
> +/ {
> +
> + model = "Olimex A20-Olimex-SOM-EVB-eMMC";
> + compatible = "olimex,a20-olimex-som-evb-emmc", "allwinner,sun7i-a20";
the file Documentation/devicetree/bindings/arm/olimex.txt seems to be out of date. I cannot find any recent board compatible.
Didn't checkpatch complain about it?
Regards
Stefan
^ permalink raw reply
* [PATCH v7 10/14] dt-bindings: qcom_spmi: Add support for SAW documentation
From: ilialin at codeaurora.org @ 2018-05-17 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHLCerOxcUMTztT75rdkS-rrQWqEEgoVQr45Ueh_JRPE7CCm7Q@mail.gmail.com>
> -----Original Message-----
> From: amit.kucheria at verdurent.com <amit.kucheria@verdurent.com> On
> Behalf Of Amit Kucheria
> Sent: Wednesday, May 16, 2018 16:13
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: Michael Turquette <mturquette@baylibre.com>; sboyd at kernel.org; Rob
> Herring <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Viresh
> Kumar <viresh.kumar@linaro.org>; nm at ti.com; lgirdwood at gmail.com;
> broonie at kernel.org; Andy Gross <andy.gross@linaro.org>; David Brown
> <david.brown@linaro.org>; catalin.marinas at arm.com;
> will.deacon at arm.com; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> clk at vger.kernel.org; devicetree at vger.kernel.org; LKML <linux-
> kernel at vger.kernel.org>; Linux PM list <linux-pm@vger.kernel.org>; linux-
> arm-msm at vger.kernel.org; linux-soc at vger.kernel.org; lakml <linux-arm-
> kernel at lists.infradead.org>; Rajendra Nayak <rnayak@codeaurora.org>;
> nicolas.dechesne at linaro.org; celster at codeaurora.org;
> tfinkel at codeaurora.org
> Subject: Re: [PATCH v7 10/14] dt-bindings: qcom_spmi: Add support for SAW
> documentation
>
> On Tue, May 15, 2018 at 12:13 PM, Ilia Lin <ilialin@codeaurora.org> wrote:
> > Add support for SAW controlled regulators.
> > The regulators defined as SAW controlled in the device tree will be
> > controlled through special CPU registers instead of direct SPMI
> > accesses.
> > This is required especially for CPU supply regulators to synchronize
> > with clock scaling and for Automatic Voltage Switching.
> > Document it.
>
> Replace this boiler plate with what this patch actual does. Besides changing
> the subject, it could be, for example,
>
> "Document the DT bindings for the SAW regulators.
>
> The saw-slave property allows ganging (grouping) of several regulators so
> that their outputs can be combined... blah blah.
>
> The saw-leader is the only one that then is configurable in DT"
Actually, I invested some fantasy to write this explanation. But I'll try to revise it.
>
>
> > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > .../bindings/regulator/qcom,spmi-regulator.txt | 45
> ++++++++++++++++++++++
> > 1 file changed, 45 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
> > b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
> > index 57d2c65..406f2e5 100644
> > ---
> > a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
> > +++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-
> regulator.
> > +++ txt
> > @@ -110,6 +110,11 @@ Qualcomm SPMI Regulators
> > Definition: Reference to regulator supplying the input pin, as
> > described in the data sheet.
> >
> > +- qcom,saw-reg:
> > + Usage: optional
> > + Value type: <phandle>
> > + Description: Reference to syscon node defining the SAW registers.
> > +
> >
> > The regulator node houses sub-nodes for each regulator within the
> > device. Each sub-node is identified using the node's name, with valid
> > values listed for each @@ -201,6 +206,17 @@ see regulator.txt - with
> additional custom properties described below:
> > 2 = 0.55 uA
> > 3 = 0.75 uA
> >
> > +- qcom,saw-slave:
> > + Usage: optional
> > + Value type: <boo>
> > + Description: SAW controlled gang slave. Will not be configured.
> > +
> > +- qcom,saw-leader:
> > + Usage: optional
> > + Value type: <boo>
> > + Description: SAW controlled gang leader. Will be configured as
> > + SAW regulator.
> > +
> > Example:
> >
> > regulators {
> > @@ -221,3 +237,32 @@ Example:
> >
> > ....
> > };
> > +
> > +Example 2:
> > +
> > + saw3: syscon at 9A10000 {
> > + compatible = "syscon";
> > + reg = <0x9A10000 0x1000>;
> > + };
> > +
> > + ...
> > +
> > + spm-regulators {
> > + compatible = "qcom,pm8994-regulators";
> > + qcom,saw-reg = <&saw3>;
> > + s8 {
> > + qcom,saw-slave;
> > + };
> > + s9 {
> > + qcom,saw-slave;
> > + };
> > + s10 {
> > + qcom,saw-slave;
> > + };
> > + pm8994_s11_saw: s11 {
> > + qcom,saw-leader;
> > + regulator-always-on;
> > + regulator-min-microvolt = <900000>;
> > + regulator-max-microvolt = <1140000>;
> > + };
> > + };
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-17 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHLCerOYq4q2GE+m3MQAbMfxM4azPr95XiLKVtoPVG1Kv2Db=A@mail.gmail.com>
> -----Original Message-----
> From: amit.kucheria at verdurent.com <amit.kucheria@verdurent.com> On
> Behalf Of Amit Kucheria
> Sent: Wednesday, May 16, 2018 16:13
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: Michael Turquette <mturquette@baylibre.com>; sboyd at kernel.org; Rob
> Herring <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Viresh
> Kumar <viresh.kumar@linaro.org>; nm at ti.com; lgirdwood at gmail.com;
> broonie at kernel.org; Andy Gross <andy.gross@linaro.org>; David Brown
> <david.brown@linaro.org>; catalin.marinas at arm.com;
> will.deacon at arm.com; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> clk at vger.kernel.org; devicetree at vger.kernel.org; LKML <linux-
> kernel at vger.kernel.org>; Linux PM list <linux-pm@vger.kernel.org>; linux-
> arm-msm at vger.kernel.org; linux-soc at vger.kernel.org; lakml <linux-arm-
> kernel at lists.infradead.org>; Rajendra Nayak <rnayak@codeaurora.org>;
> nicolas.dechesne at linaro.org; celster at codeaurora.org;
> tfinkel at codeaurora.org
> Subject: Re: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
>
> On Tue, May 15, 2018 at 12:13 PM, Ilia Lin <ilialin@codeaurora.org> wrote:
> > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO
> > processors, the CPU ferequencies subset and voltage value of each OPP
> > varies
>
> s/ferequencies/frequency
>
> > based on the silicon variant in use. Qualcomm Process Voltage Scaling
> > Tables defines the voltage and frequency value based on the msm-id in
> > SMEM and speedbin blown in the efuse combination.
> > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
> > SoC to provide the OPP framework with required information.
> > This is used to determine the voltage and frequency value for each OPP
> > of
> > operating-points-v2 table when it is parsed by the OPP framework.
> >
> > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> > ---
> > drivers/cpufreq/Kconfig.arm | 11 +++
> > drivers/cpufreq/Makefile | 1 +
> > drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
> > drivers/cpufreq/qcom-cpufreq-kryo.c | 150
> > +++++++++++++++++++++++++++++++++++
> > 4 files changed, 165 insertions(+)
> > create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
> >
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index de55c7d..5c16f05 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -124,6 +124,17 @@ config ARM_OMAP2PLUS_CPUFREQ
> > depends on ARCH_OMAP2PLUS
> > default ARCH_OMAP2PLUS
> >
> > +config ARM_QCOM_CPUFREQ_KRYO
> > + bool "Qualcomm Technologies, Inc. Kryo based CPUFreq"
>
> "Qualcomm Kryo CPUFreq support" should be enough. Kconfig isn't the place
> for Trademark compliance :-)
This is mandatory requirement of the QTIs legal.
>
> > + depends on QCOM_QFPROM
> > + depends on QCOM_SMEM
> > + select PM_OPP
> > + help
> > + This adds the CPUFreq driver for
> > + Qualcomm Technologies, Inc. Kryo SoC based boards.
> > +
> > + If in doubt, say N.
> > +
> > config ARM_S3C_CPUFREQ
> > bool
> > help
> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index
> > 8d24ade..fb4a2ec 100644
> > --- a/drivers/cpufreq/Makefile
> > +++ b/drivers/cpufreq/Makefile
> > @@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-
> cpufreq.o
> > obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
> > obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
> > obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
> > +obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
> > obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
> > obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
> > obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> > b/drivers/cpufreq/cpufreq-dt-platdev.c
> > index 3b585e4..77d6ab8 100644
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -118,6 +118,9 @@
> >
> > { .compatible = "nvidia,tegra124", },
> >
> > + { .compatible = "qcom,apq8096", },
> > + { .compatible = "qcom,msm8996", },
> > +
> > { .compatible = "st,stih407", },
> > { .compatible = "st,stih410", },
> >
> > diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
> > b/drivers/cpufreq/qcom-cpufreq-kryo.c
> > new file mode 100644
> > index 0000000..10d7236
> > --- /dev/null
> > +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> > @@ -0,0 +1,150 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
>
> Stray space here.
>
> > + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/cpu.h>
> > +#include <linux/err.h>
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/nvmem-consumer.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/pm_opp.h>
> > +#include <linux/slab.h>
> > +#include <linux/soc/qcom/smem.h>
> > +
> > +#define MSM_ID_SMEM 137
> > +#define SILVER_LEAD 0
> > +#define GOLD_LEAD 2
> > +
> > +enum _msm_id {
> > + MSM8996V3 = 0xF6ul,
> > + APQ8096V3 = 0x123ul,
> > + MSM8996SG = 0x131ul,
> > + APQ8096SG = 0x138ul,
> > +};
> > +
> > +enum _msm8996_version {
> > + MSM8996_V3,
> > + MSM8996_SG,
> > + NUM_OF_MSM8996_VERSIONS,
> > +};
> > +
> > +static enum _msm8996_version __init
> > +qcom_cpufreq_kryo_get_msm_id(void)
> > +{
> > + size_t len;
> > + u32 *msm_id;
> > + enum _msm8996_version version;
> > +
> > + msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY,
> MSM_ID_SMEM, &len);
> > + /* The first 4 bytes are format, next to them is the actual msm-id */
> > + msm_id++;
> > +
> > + switch ((enum _msm_id)*msm_id) {
> > + case MSM8996V3:
> > + case APQ8096V3:
> > + version = MSM8996_V3;
> > + break;
> > + case MSM8996SG:
> > + case APQ8096SG:
> > + version = MSM8996_SG;
> > + break;
> > + default:
> > + version = NUM_OF_MSM8996_VERSIONS;
> > + }
> > +
> > + return version;
> > +}
> > +
> > +static int __init qcom_cpufreq_kryo_driver_init(void)
> > +{
> > + size_t len;
> > + int ret;
> > + u32 versions;
> > + enum _msm8996_version msm8996_version;
> > + u8 *speedbin;
> > + struct device *cpu_dev;
> > + struct device_node *np;
> > + struct nvmem_cell *speedbin_nvmem;
> > + struct opp_table *opp_temp = NULL;
> > +
> > + cpu_dev = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev))
> > + return PTR_ERR(cpu_dev);
> > +
> > + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> > + dev_err(cpu_dev, "Not Snapdragon 820/821!");
> > + return -ENODEV;
> > + }
>
> Use tab instead of spaces.
>
> > +
> > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> > + if (IS_ERR_OR_NULL(np))
> > + return PTR_ERR(np);
> > +
> > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
> > + ret = -ENOENT;
> > + goto free_np;
> > + }
> > +
> > + speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> > + if (IS_ERR(speedbin_nvmem)) {
> > + ret = PTR_ERR(speedbin_nvmem);
> > + dev_err(cpu_dev, "Could not get nvmem cell: %d\n", ret);
> > + goto free_np;
> > + }
> > +
> > + speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> > +
> > + switch (msm8996_version) {
> > + case MSM8996_V3:
> > + versions = 1 << (unsigned int)(*speedbin);
> > + break;
> > + case MSM8996_SG:
> > + versions = 1 << ((unsigned int)(*speedbin) + 4);
> > + break;
> > + default:
> > + BUG();
> > + break;
> > + }
> > +
> > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > + dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > + if (0 > ret)
>
> Any particular reason to prefer this over (ret < 0) that is generally used? I've
> seen it used to avoid the == vs. = typos, but not for other comparisons.
>
> Suggest sticking to what is commonly used i.e. ret < 0.
>
> > + goto free_opp;
> > +
> > + cpu_dev = get_cpu_device(GOLD_LEAD);
>
> Error check cpu_dev here?
>
> > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > + dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > + if (0 > ret)
> > + goto free_opp;
> > +
> > +
> > + ret = PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-
> dt",
> > + -1,
> > + NULL, 0));
> > +
> > + if (0 == ret)
> > + return 0;
> > +
> > +free_opp:
> > + dev_pm_opp_put_supported_hw(opp_temp);
>
> This is not needed because dev_pm_opp_set_supported_hw will free
> memory in case of failure. This call in only needed in case of a successful get.
>
> > +
> > +free_np:
> > + of_node_put(np);
> > + return ret;
>
>
> Suggest something like this instead:
>
> .
> .
>
> opp_temp = dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> if (IS_ERR(opp_temp)) {
> dev_err(cpu_dev, "Failed to set supported hardware\n");
> ret = PTR_ERR(opp_temp);
> goto free_np;
> }
>
> cpu_dev = get_cpu_device(GOLD_LEAD);
>
> opp_temp = dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> if (IS_ERR(opp_temp)) {
> dev_err(cpu_dev, "Failed to set supported hardware\n");
> ret = PTR_ERR(opp_temp);
> goto free_np;
> }
>
> ret = platform_device_register_simple("cpufreq-dt", -1, NULL, 0));
>
> if (!IS_ERR_OR_NULL(ret))
> goto out;
>
> free_np:
> of_node_put(np);
> out:
> return ret;
>
> > +}
> > +late_initcall(qcom_cpufreq_kryo_driver_init);
> > +
> > +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq
> > +driver"); MODULE_LICENSE("GPL v2");
> > --
> > 1.9.1
> >
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: jacopo mondi @ 2018-05-17 7:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516222318.GI17948@bigcity.dyn.berto.se>
Hi Niklas,
On Thu, May 17, 2018 at 12:23:18AM +0200, Niklas S?derlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> On 2018-05-16 15:42:09 +0200, Jacopo Mondi wrote:
> > Describe HDMI input connector and ADV7612 HDMI decoder installed on
> > R-Car Gen3 Draak board.
> >
> > The video signal routing to the HDMI decoder to the video input interface
> > VIN4 is multiplexed with CVBS input path, and enabled/disabled through
> > on-board switches SW-49, SW-50, SW-51 and SW-52.
> >
> > As the default board switches configuration connects CVBS input to VIN4,
> > leave the HDMI decoder unconnected in DTS.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> I'm not sure we have a policy about describing hardware which can't be
> used without flipping switches. I have no opinion on if we should do
> that or not I leave that to others, but for the change itself.
>
> Reviewed-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
>
Thanks
> I think it's good we describe it as it's part of the Draak board itself
> and not an expansion board which we have seen a lot of :-) Maybe even
> add a commented out line in the adv7612 port at 2 which hints which VIN
> this is connected to if the switches are flipped?
The only VIN instance that's on Draak, VIN4.
I can add a comment that describes the switch settings that enables
the HDMI video capture path.
Thanks
j
>
> > ---
> > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 38 ++++++++++++++++++++++++++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > index 9aba28f..ea99dc9 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > @@ -59,6 +59,17 @@
> > };
> > };
> >
> > + hdmi-in {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&adv7612_in>;
> > + };
> > + };
> > + };
> > +
> > memory at 48000000 {
> > device_type = "memory";
> > /* first 128MB is reserved for secure area. */
> > @@ -170,6 +181,33 @@
> > };
> > };
> > };
> > +
> > + hdmi-decoder at 4c {
> > + compatible = "adi,adv7612";
> > + reg = <0x4c>;
> > + default-input = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > + adv7612_in: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > + };
> > +
> > + port at 2 {
> > + reg = <2>;
> > + adv7612_out: endpoint {
> > + pclk-sample = <0>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
> > + };
> > + };
> > + };
> > + };
> > };
> >
> > &i2c1 {
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas S?derlund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/b3ae7b35/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 3/6] spi: sun6i: restrict transfer length in PIO-mode
From: Mark Brown @ 2018-05-17 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180330125047.13936-4-ssuloev@orpaltech.com>
On Fri, Mar 30, 2018 at 03:50:44PM +0300, Sergey Suloev wrote:
> There is no need to handle 3/4 empty/full interrupts as
> the maximum supported transfer length in PIO mode is
> 128 bytes for sun6i- and 64 bytes for sun8i-family SoCs.
Surely the whole point of the 3/4 full interrupts is to allow the FIFO
to be refilled and enable longer transfers?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/cc6ac43a/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 2/6] spi: sun6i: handle chip select polarity flag
From: Mark Brown @ 2018-05-17 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180330125047.13936-3-ssuloev@orpaltech.com>
On Fri, Mar 30, 2018 at 03:50:43PM +0300, Sergey Suloev wrote:
> The chip select polarity flag is declared as supported
> but is not handled in the code.
This is more of a fix and should really have come before the cosmetic
changes in patch 1. In general it's best to put fixes fist in a series
unless there's a strong reason to do something else, that makes it
easier to get the fixes in without them getting caught by review issues
with other code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/ba8466ea/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 3/4] coresight: allow to build as modules
From: Greg Kroah-Hartman @ 2018-05-17 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516143322.0eaecaa72f8a65f19fd7dabf@arm.com>
On Wed, May 16, 2018 at 02:33:22PM -0500, Kim Phillips wrote:
> Allow to build coresight as modules. This greatly enhances developer
> efficiency by allowing the development to take place exclusively on the
> target, and without needing to reboot in between changes.
>
> - Kconfig bools become tristates, to allow =m
>
> - MODULE_* macros added: Please correct me if I'm wrong:
> - assume LICENSE is "GPL v2"
> - tried to get as close to original authors for MODULE_AUTHOR
>
> - The 'select' Kconfig statements are replaced with 'depends on'
> clauses, to specify the dependencies between the modules including
> other fixes, e.g., coresight-stm unconditionally calls
> stm_register_device, it therefore depends on STM.
>
> - use -objs to denote merge object directives in Makefile, adds a
> coresight-core nomenclature for the base module.
>
> - add a coresight_exit() that unregisters the coresight bus, add remove
> fns for most others.
>
> - fix up modules with ID tables for autoloading on boot, add missing
> __exit attributes
>
> - move coresight_vpid_to_pid to an externed, single instance in
> coresight-core, to be used by all submodules.
That's a ton of different things to be doing all at once in this patch.
Please break it up into logical steps (like you describe here!) which
will make it much easier and trivial to review.
As it is, I'm not even going to look at the mess-of-a-diff that I
imagine the above results in :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 1/6] spi: sun6i: coding style/readability improvements
From: Mark Brown @ 2018-05-17 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180330125047.13936-2-ssuloev@orpaltech.com>
On Fri, Mar 30, 2018 at 03:50:42PM +0300, Sergey Suloev wrote:
> Minor changes to fulfill the coding style and improve
> the readability of the code.
>
> Changes in v2:
> 1) Fixed issue with misplacing a piece of code that requires access
> to the transfer structure into sun6i_spi_prepare_message() function
> where the transfer structure is not available.
Place inter-version changelogs after the --- as covered in
SubmittingPatches.
>
> Signed-off-by: Sergey Suloev <ssuloev@orpaltech.com>
>
> ---
> drivers/spi/spi-sun6i.c | 97 +++++++++++++++++++++++++++++--------------------
This is a *very* large change doing a whole bunch of different things,
including some fairly substantial changes like moving things into
different functions but the changelog doesn't provide any details at all
on what the changes are supposed to be. This makes it difficult to
review, it should be split into separate patches each doing one clerly
described thing (I'm guessing this might be part of why the AllWinner
maintainers haven't reviewed the series).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/f12fefa3/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: remove no-op macro VMLINUX_SYMBOL()
From: Masahiro Yamada @ 2018-05-17 7:01 UTC (permalink / raw)
To: linux-arm-kernel
VMLINUX_SYMBOL() is no-op unless CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX
is defined. It has ever been selected only by BLACKFIN and METAG.
VMLINUX_SYMBOL() is unneeded for ARM-specific code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
KernelVersion: 4.17-rc5
arch/arm/kernel/vmlinux.lds.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kernel/vmlinux.lds.h b/arch/arm/kernel/vmlinux.lds.h
index 71281e0..ae5fdff 100644
--- a/arch/arm/kernel/vmlinux.lds.h
+++ b/arch/arm/kernel/vmlinux.lds.h
@@ -27,24 +27,24 @@
#define PROC_INFO \
. = ALIGN(4); \
- VMLINUX_SYMBOL(__proc_info_begin) = .; \
+ __proc_info_begin = .; \
*(.proc.info.init) \
- VMLINUX_SYMBOL(__proc_info_end) = .;
+ __proc_info_end = .;
#define HYPERVISOR_TEXT \
- VMLINUX_SYMBOL(__hyp_text_start) = .; \
+ __hyp_text_start = .; \
*(.hyp.text) \
- VMLINUX_SYMBOL(__hyp_text_end) = .;
+ __hyp_text_end = .;
#define IDMAP_TEXT \
ALIGN_FUNCTION(); \
- VMLINUX_SYMBOL(__idmap_text_start) = .; \
+ __idmap_text_start = .; \
*(.idmap.text) \
- VMLINUX_SYMBOL(__idmap_text_end) = .; \
+ __idmap_text_end = .; \
. = ALIGN(PAGE_SIZE); \
- VMLINUX_SYMBOL(__hyp_idmap_text_start) = .; \
+ __hyp_idmap_text_start = .; \
*(.hyp.idmap.text) \
- VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
+ __hyp_idmap_text_end = .;
#define ARM_DISCARD \
*(.ARM.exidx.exit.text) \
--
2.7.4
^ permalink raw reply related
* [PATCH v4] pinctrl: msm: fix gpio-hog related boot issues
From: Stephen Boyd @ 2018-05-17 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3220588.XpgAMh8mx0@debian64>
Quoting Christian Lamparter (2018-05-16 13:29:48)
> On Wednesday, May 16, 2018 5:31:16 PM CEST Stephen Boyd wrote:
> > Why can't we register the gpiochip and tell it about the pin ranges in
> > one API call instead of adding the chip and then adding the ranges? It
> > doesn't look right to have to go and update all the DT nodes to list
> > this information that is already known in the driver because the kernel
> > implementation can't handle the order of operations correctly.
> The problem is that gpiochip_add_pin_range() was not intended for
> DT-based pinctrls... but it got used anyway.
Are there more users of this on DT based systems? A quick grep shows a
couple more potential failures, like the qcom based SPMI gpio controllers
and a mediatek one.
It's almost like we should print a huge WARN_ON() if gpio_chip::of_node
is non-NULL and gpochip_add_pin_range() is called. But that probably
would be noisy and can't be fixed on older DT blobs. It may also be good
to bail out of that function if the node pointer exists and the property
is there in the node so that we don't have to go update each driver for
the backwards compat mode like was done in this patch. Plus the function
should get some sort of comment that calling it is not useful on DT
based platforms so this is all documented.
In general, I'm just asking for this to be made much more obvious that
it's wrong to do and more clearly documented.
>
> This topic came up in an earlier post:
> "Re: pinctrl: qcom: ipq4019: Use of gpio-hog's" [0] (you must have gotten
> this mail too, since you are on the Cc.) which links to a ML thread titled
> "Re: [GIT PULL] SPEAr pinctrl updates for v-3.5"
I get quite a bit of email as you can tell.
>
> For your convenience: (this post is from 2012-09-03 - so it's 5-6 years
> old by now and it looks like it predates even the DT pinctrl-msm driver.
> (Not entirely sure?))
> <http://thread.gmane.org/gmane.linux.ports.arm.kernel/184943>
> |[...]
> |But I want two similar function named:
> |
> |gpiochip_add_pin_range();
> |gpiochip_remove_pin_range();
> |
> |*that can be used for platforms that doesn't support DT.*
> |
> |For example I'd like to convert over some of my existing
> |drivers that do not have DT support to do this thing instead
> |of registering ranges from the pin controller...
>
> I think you must have come across similar issues with the
> "gpio-reserved-ranges" property you recently added. Because
> from what I can glimpse from the
> "[2/3] dt-bindings: pinctrl: Add a ngpios-ranges property"
> <https://patchwork.kernel.org/patch/10153785/> series.
> The gpio-reserved-ranges property would also need to be added
> to existing products (msm8996) as well, right?
> ("I stuck this inside msm8996, but maybe it can go somewhere more generic?")
The gpio-reserved-ranges only affects some SoCs. It should be added to
the bindings on whatever chips are affected by those firmware quirks as
optional properties. It would be great if you could add it to the ones
that may need it. My guess is that it only matters for the pin
controllers that spread out each pin into a big range of I/O memory
because otherwise pins aren't locked away from non-secure systems.
>
> > Furthermore, it looks like this becomes a silent requirement to add the
> > gpio-ranges property into the DT so that hogs work, but none of the
> > bindings have been updated in this patch to indicate that.
> The pinctrl-msm.c driver will fallback to using gpiochip_add_pin_range(),
> if the gpio-ranges property is not present. So all existing and compiled
> devicetree binaries files will remain compatible.
That's good.
>
> As for adding the gpio-ranges to the dt binding text files under
> Documentation/devicetree/bindings/pinctrl/: Sure. No problem. I can add
> them too :).
Great!
>
> But I do have a question: Should I also include the missing declaration
> of the gpio-reserved-ranges properties too? (I can make the patches over
> the long weekend. If I hear nothing from anyone, I'll post them on Monday).
Sure. Do you have the list of pinctrl devices that may need the
gpio-reserved-ranges property?
^ permalink raw reply
* [PATCH v8 09/24] ASoC: qdsp6: q6afe: Add q6afe driver
From: Mark Brown @ 2018-05-17 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509125635.5653-10-srinivas.kandagatla@linaro.org>
On Wed, May 09, 2018 at 01:56:20PM +0100, Srinivas Kandagatla wrote:
> +static struct q6afe_port *afe_find_port(struct q6afe *afe, int token)
> +{
> + struct q6afe_port *p = NULL;
> + struct q6afe_port *ret = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&afe->port_list_lock, flags);
> + list_for_each_entry(p, &afe->port_list, node)
> + if (p->token == token) {
> + ret = p;
> + break;
> + }
> +
> + spin_unlock_irqrestore(&afe->port_list_lock, flags);
> + return ret;
This lock only protects the list, it does nothing to ensure that the
port we look up is still valid by the time we return to the caller.
That means we won't crash during list traversal but does nothing to
ensure we won't crash immediately afterwards if the port is deallocated
just after we look it up. What stops that happening?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/2294767d/attachment-0001.sig>
^ permalink raw reply
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
From: Greg KH @ 2018-05-17 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78b08b68-ff57-8dd8-6eb1-00548f275eac@arm.com>
On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
> Hi Greg,
>
> Have you had a chance to look at the cachinfo parts of this patch?
Nope :)
I didn't write that, and while it is dumped in the driver core section
of the kernel, I know nothing about it. If you get an ack from Sundeep
for this, which you did, that's fine with me, merge away!
thanks,
greg k-h
^ permalink raw reply
* [PATCH v3 2/3] ioremap: Update pgtable free interfaces with addr
From: Michal Hocko @ 2018-05-17 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516233207.1580-3-toshi.kani@hpe.com>
On Wed 16-05-18 17:32:06, Kani Toshimitsu wrote:
> From: Chintan Pandya <cpandya@codeaurora.org>
>
> This patch ("mm/vmalloc: Add interfaces to free unmapped
> page table") adds following 2 interfaces to free the page
> table in case we implement huge mapping.
>
> pud_free_pmd_page() and pmd_free_pte_page()
>
> Some architectures (like arm64) needs to do proper TLB
> maintanance after updating pagetable entry even in map.
> Why ? Read this,
> https://patchwork.kernel.org/patch/10134581/
Please add that information to the changelog.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v5] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE
From: Juergen Gross @ 2018-05-17 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509131612.21107-1-paul.durrant@citrix.com>
On 09/05/18 15:16, Paul Durrant wrote:
> My recent Xen patch series introduces a new HYPERVISOR_memory_op to
> support direct priv-mapping of certain guest resources (such as ioreq
> pages, used by emulators) by a tools domain, rather than having to access
> such resources via the guest P2M.
>
> This patch adds the necessary infrastructure to the privcmd driver and
> Xen MMU code to support direct resource mapping.
>
> NOTE: The adjustment in the MMU code is partially cosmetic. Xen will now
> allow a PV tools domain to map guest pages either by GFN or MFN, thus
> the term 'mfn' has been swapped for 'pfn' in the lower layers of the
> remap code.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Pushed to xen/tip.git for-linus-4.18
Juergen
^ permalink raw reply
* [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
From: Radhey Shyam Pandey @ 2018-05-17 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee1dc551-7c11-6d10-651d-01bf6520f049@ti.com>
Hi,
> -----Original Message-----
> From: Peter Ujfalusi [mailto:peter.ujfalusi at ti.com]
> Sent: Tuesday, April 24, 2018 3:21 PM
> To: Vinod Koul <vinod.koul@intel.com>
> Cc: Lars-Peter Clausen <lars@metafoo.de>; Radhey Shyam Pandey
> <radheys@xilinx.com>; michal.simek at xilinx.com; linux-
> kernel at vger.kernel.org; dmaengine at vger.kernel.org;
> dan.j.williams at intel.com; Appana Durga Kedareswara Rao
> <appanad@xilinx.com>; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words
> to netdev dma client
>
> On 2018-04-24 06:55, Vinod Koul wrote:
> > On Thu, Apr 19, 2018 at 02:40:26PM +0300, Peter Ujfalusi wrote:
> >>
> >> On 2018-04-18 16:06, Lars-Peter Clausen wrote:
> >>>> Hrm, true, but it is hardly the metadata use case. It is more like
> >>>> different DMA transfer type.
> >>>
> >>> When I look at this with my astronaut architect view from high high up
> above
> >>> I do not see a difference between metadata and multi-planar data.
> >>
> >> I tend to disagree.
> >
> > and we will love to hear more :)
>
> It is getting pretty off topic from the subject ;) and I'm sorry about that.
>
> Multi-planar data is _data_, the metadata is
> parameters/commands/information on _how_ to use the data.
> It is more like a replacement or extension of:
> configure peripheral
> send data
>
> to
>
> send data with configuration
>
> In both cases the same data is sent, but the configuration,
> parametrization is 'simplified' to allow per packet changes.
>
> >>> Both split the data that is sent to the peripheral into multiple
> >>> sub-streams, each carrying part of the data. I'm sure there are peripherals
> >>> that interleave data and metadata on the same data stream. Similar to
> how we
> >>> have left and right channel interleaved in a audio stream.
> >>
> >> Slimbus, S/PDIF?
> >>
> >>> What about metadata that is not contiguous and split into multiple
> segments.
> >>> How do you handle passing a sgl to the metadata interface? And then it
> >>> suddenly looks quite similar to the normal DMA descriptor interface.
> >>
> >> Well, the metadata is for the descriptor. The descriptor describe the
> >> data transfer _and_ can convey additional information. Nothing is
> >> interleaved, the data and the descriptor are different things. It is
> >> more like TCP headers detached from the data (but pointing to it).
> >>
> >>> But maybe that's just one abstraction level to high.
> >>
> >> I understand your point, but at the end the metadata needs to end up in
> >> the descriptor which is describing the data that is going to be moved.
> >>
> >> The descriptor is not sent as a separate DMA trasnfer, it is part of the
> >> DMA transfer, it is handled internally by the DMA.
> >
> > That is bit confusing to me. I thought DMA was transparent to meta data and
> > would blindly collect and transfer along with the descriptor. So at high
> > level we are talking about two transfers (probably co-joined at hip and you
> > want to call one transfer)
>
> At the end yes, both the descriptor and the data is going to be sent to
> the other end.
>
> As a reference see [1]
>
> The metadata is not a separate entity, it is part of the descriptor
> (Host Packet Descriptor - HPD).
> Each transfer (packet) is described with a HPD. The HPD have optional
> fields, like EPIB (Extended Packet Info Block), PSdata (Protocol
> Specific data).
>
> When the DMA reads the HPD, is going to move the data described by the
> HPD to the entry point (or from the entry point to memory), copies the
> EPIB/PSdata from the HPD to a destination HPD. The other end will use
> the destination HPD to know the size of the data and to get the metadata
> from the descriptor.
>
> In essence every entity within the Multicore Navigator system have
> pktdma, they all work in a similar way, but their capabilities might
> differ. Our entry to this mesh is via the DMA.
>
> > but why can't we visualize this as just a DMA
> > transfers. maybe you want to signal/attach to transfer, cant we do that with
> > additional flag DMA_METADATA etc..?
>
> For the data we need to call dmaengine_prep_slave_* to create the
> descriptor (HPD). The metadata needs to be present in the HPD, hence I
> was thinking of the attach_metadata as per descriptor API.
>
> If separate dmaengine_prep_slave_* is used for allocating the HPD and
> place the metadata in it then the consequent dmaengine_prep_slave_* call
> must be for the data of the transfer and it is still unclear how the
> prepare call would have any idea where to look for the HPD it needs to
> update with the parameters for the data transfer.
>
> I guess the driver could store the HPD pointer in the channel data if
> the prepare is called with DMA_METADATA and it would be mandatory that
> the next prepare is for the data portion. The driver would pick the
> pointer to the HPD we stored away and update the descriptor belonging to
> different tx_desc.
>
> But if we are here, we could have a flag like DMA_DESCRIPTOR and let
> client drivers to allocate the whole descriptor, fill in the metadata
> and give that to the DMA driver, which will update the rest of the HPD.
>
> Well, let's see where this is going to go when I can send the patches
> for review.
Thanks all. @Peter: If we have metadata patchset ready may be good
to send an RFC?
>
> [1] http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf
>
> - P?ter
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ 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