* Re: [PATCH v5 6/9] coresight: add support for CPU debug module
From: Suzuki K Poulose @ 2017-03-29 15:50 UTC (permalink / raw)
To: Leo Yan
Cc: Mark Rutland, linux-doc, Catalin Marinas, Michael Turquette,
Will Deacon, David Brown, linux-clk, Jonathan Corbet, Wei Xu,
Andy Gross, mike.leach, devicetree, linux-arm-msm, Rob Herring,
John Stultz, linux-soc, linux-arm-kernel, Mathieu Poirier,
Guodong Xu, Stephen Boyd, linux-kernel, sudeep.holla
In-Reply-To: <20170329103712.GA22480@leoy-linaro>
On 29/03/17 11:37, Leo Yan wrote:
> On Wed, Mar 29, 2017 at 11:31:03AM +0100, Suzuki K Poulose wrote:
>> On 29/03/17 11:27, Leo Yan wrote:
>>> On Wed, Mar 29, 2017 at 10:07:07AM +0100, Suzuki K Poulose wrote:
>>>
>>> [...]
>>>
>>>>>>> + if (mode == EDDEVID_IMPL_NONE) {
>>>>>>> + drvdata->edpcsr_present = false;
>>>>>>> + drvdata->edcidsr_present = false;
>>>>>>> + drvdata->edvidsr_present = false;
>>>>>>> + } else if (mode == EDDEVID_IMPL_EDPCSR) {
>>>>>>> + drvdata->edpcsr_present = true;
>>>>>>> + drvdata->edcidsr_present = false;
>>>>>>> + drvdata->edvidsr_present = false;
>>>>>>> + } else if (mode == EDDEVID_IMPL_EDPCSR_EDCIDSR) {
>>>>>>> + if (!IS_ENABLED(CONFIG_64BIT) &&
>>>>>>> + (pcsr_offset == EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32))
>>>>>>> + drvdata->edpcsr_present = false;
>>>>>>> + else
>>>>>>> + drvdata->edpcsr_present = true;
>>>>>>
>>>>>> Sorry, I forgot why we do this check only in this mode. Shouldn't this be
>>>>>> common to all modes (of course which implies PCSR is present) ?
>>>>>
>>>>> No. PCSROffset is defined differently in ARMv7 and ARMv8; So finally we
>>>>> simplize PCSROffset value :
>>>>> 0000 - Sample offset applies based on the instruction state (indicated by PCSR[0])
>>>>> 0001 - No offset applies.
>>>>> 0010 - No offset applies, but do not use in AArch32 mode!
>>>>>
>>>>> So we need handle the corner case is when CPU runs AArch32 mode and
>>>>> PCSRoffset = 'b0010. Other cases the pcsr should be present.
>>>>
>>>> I understand that reasoning. But my question is, why do we check for PCSROffset
>>>> only when mode == EDDEVID_IMPL_EDPCSR_EDCIDSR and not for say mode == EDDEVID_IMPL_EDPCSR or
>>>> any other mode where PCSR is present.
>>>
>>> Sorry I misunderstood your question.
>>>
>>> I made mistake when I analyzed the possbile combination for mode and
>>> PCSROffset so I thought it's the only case should handle:
>>> { EDDEVID_IMPL_EDPCSR_EDCIDSR, EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32 }
>>>
>>> Below three combinations are possible to exist; so you are right, I
>>> should move this out for the checking:
>>> { EDDEVID_IMPL_NONE, EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32 }
>>
>> That need not be covered, as IMPL_NONE says PCSR is not implemented hence you
>> don't worry about anything as the functionality is missing. This should rather be:
>> EDDEVID_IMPL_EDPCSR, where only PCSR is implemented.
>
> I think below combination doesn't really exist:
> { EDDEVID_IMPL_EDPCSR, EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32 };
>
> EDDEVID_IMPL_EDPCSR is only defined in ARMv7 ARM, and
> EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32 is only defined in ARMv8 ARM.
It is not wrong to check the PCSROffset in all cases where PCSR is available, as if
we hit PCSR on ARMv7 then PCSROffset shouldn't be DIS_AARCH32. And in fact that
would make the code a bit more cleaner. Anyways, I am not particular about this.
Suzuki
^ permalink raw reply
* Re: [PATCH v3 1/2] PCI: Add tango MSI controller support
From: Mason @ 2017-03-29 15:50 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner
Cc: Marc Gonzalez, Bjorn Helgaas, Robin Murphy, Lorenzo Pieralisi,
Liviu Dudau, David Laight, linux-pci, Linux ARM, Thibaud Cornic,
Phuong Nguyen, LKML, DT
In-Reply-To: <0541e62a-c87a-2e69-a7d1-28f886ad04c2-GANU6spQydw@public.gmane.org>
On 29/03/2017 15:16, Mason wrote:
> But I don't understand how to get my pcie pointer back in irq_ack
> or irq_unmask, or the relevant msi. Can you throw me a clue?
Let's see... the irq_chip call-backs receive an irq_data pointer.
struct irq_data - per irq chip data passed down to chip functions
struct irq_chip - hardware interrupt chip descriptor
irq_data contains a void *chip_data member.
Can I use chip_data to stash a struct tango_pcie pointer?
/**
* irq_set_chip_data - set irq chip data for an irq
* @irq: Interrupt number
* @data: Pointer to chip specific data
*
* Set the hardware irq chip data for an irq
*/
int irq_set_chip_data(unsigned int irq, void *data)
But where would I call it? And for which irq?
Otherwise, I found by trial-and-error that I can reach pcie through
data->domain->parent->host_data
data->domain == msi_dom
msi_dom->parent == irq_dom
irq_dom->host_data == pcie
But data->irq and data->hwirq don't hold the MSI index :-(
I suppose I have to ask for some mapping?
Regards.
--
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 v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header
From: jacopo @ 2017-03-29 15:56 UTC (permalink / raw)
To: Linus Walleij
Cc: Jacopo Mondi, Bjorn Andersson, Geert Uytterhoeven,
Laurent Pinchart, Chris Brandt, Rob Herring, Mark Rutland,
Russell King, Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdZ4Z6c2YDu-e6kZ8-K7Dv_tRGxZj0vAqgPBx7rWwmHU-g@mail.gmail.com>
Hi Linus,
another reply to your email, please don't feel assaulted :)
On Wed, Mar 29, 2017 at 03:22:23PM +0200, Linus Walleij wrote:
> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>
> > Add dt-bindings for Renesas r7s72100 pin controller header file.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> > +/*
> > + * Pin is bi-directional.
> > + * An alternate function that needs both input/output functionalities shall
> > + * be configured as bidirectional.
> > + * Eg. SDA/SCL pins of an I2c interface.
> > + */
> > +#define BI_DIR (1 << 3)
>
> Any specific reason why this should not simply be added to
> include/linux/pinctrl/pinconf-generic.h
> as PIN_CONFIG_BIDIRECTIONAL and parsed in
> drivers/pinctrl/pinconf-generic.c
> from the (new) DT property "bidirectional" simply?
>
I can try to give you a few reasons why I don't see those flags fit in
the pin configuration flags definition.
*) those flags are used during pin multiplexing procedure only and that
procedure has a specific order to be respected:
You can have a look here:
https://www.spinics.net/lists/linux-renesas-soc/msg12793.html
In "rza1_alternate_function_conf()" function, we need to set bidir
before setting every other register.
The same applies some lines below:, the PIPC, PMC and PM register set order
has to be respected, and depends on those BIDIR and SWIO_* parameters.
This implies those configuration cannot be applied after pin muxing,
certainly not in pin_config[_group]_set() whose invocation time
is independent from pin_mux_set()'s one.
One way forward would be, every time we mux a pin, look for a pinconf group
that includes the pin we're muxing. That would happen for each pin,
for no added benefits imo.
*) as Geert already pointed out, we may need dedicated subnodes to
specify those pin configuration flags, not only because of what Chris
said, but because pinconf_generic_dt_subnode_to_map() wants "pins" or
"groups" to be there in the subnode, and in our pin multiplexing
sub-nodes we only have "pinmux" property (say: we cannot specify
pin_conf flags in the same sub-node where we describe pin
multiplexing, we always need a dedicated sub-node).
Chris and Geert gave some examples in their replies on how that would
like, and how it makes the bindings a little more complex.
*) those flags, according to Chris, won't be used in RZ/A2, and
reasonably not in any other RZ device. Do we want to add them to the
generic bindings, being them so specific to this hardware platform?
One thing I suggest considering is to get rid of those flags, at
least in bindings, and introduce 3 variants for each pin multiplexing
function identifier.
Say:
include/dt-bindings/pinctrl/r7s72100-pinctrl.h:
#define MUX_1 (1 << 16)
#define MUX_1_BIDIR (1 << 16 | 1 << 24)
#define MUX_1_SWIO_IN (1 << 16 | 2 << 24)
#define MUX_1_SWIO_OUT (1 << 16 | 3 << 24)
...
#define MUX_8 (8 << 16)
#define MUX_8_BIDIR (8 << 16 | 1 << 24)
....
this way we get rid of those extra flag values and squeeze pin id
and mux function id in a single integer, part of the "pinmux"
arguments list.
i2c_pins {
pinmux = <(PIN(1, 6) | MUX_1_BIDIR)>,
<(PIN(1, 7) | MUX_2_BIDIR)>;
};
The driver will parse the bits from [31:24] to find out if it needs
to enable some special multiplexing property, and performs
multiplexing as it is doing right now.
> > +/*
> > + * Flags used to ask software to drive the pin I/O direction overriding the
> > + * alternate function configuration.
> > + * Some alternate functions require software to force I/O direction of a pin,
> > + * overriding the designated one.
> > + * Refer to the HW manual to know when this flag shall be used.
> > + */
> > +#define SWIO_IN (1 << 4)
> > +#define SWIO_OUT (1 << 5)
>
> What is wrong in doing this with generic pin config using
> PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT
> (ignoring the argument)?
>
> In the device tree use input-enable and add a new output-enable
> (with unspecified value) with proper description and DT bindings?
>
> And if you think these have no general applicability, by the end
> of the day they are *still* pin config, not magic flags we can choose to
> toss in with the muxing, so you can do what the Qualcomm driver
> does and add custom pin configurations extending the generic
> pin config, see drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> qcom,pull-up-strength etc.
>
I see, but that custom pin configuration flag can be applied
independently from pin muxing procedure and it can be applied to pins
while they're configured in GPIO mode.
Our "flags" are not of that nature, and only apply to some register
setting during pinmux, as I hopefully tried to clarify above.
Thanks for time and patience in this long email thread.
j
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Rob Herring @ 2017-03-29 15:58 UTC (permalink / raw)
To: michael.hennerich
Cc: wsa, peda, mark.rutland, linus.walleij, linux-i2c, devicetree,
linux-gpio, linux-kernel
In-Reply-To: <1490278978-28357-1-git-send-email-michael.hennerich@analog.com>
On Thu, Mar 23, 2017 at 03:22:58PM +0100, michael.hennerich@analog.com wrote:
> From: Michael Hennerich <michael.hennerich@analog.com>
>
> This patch adds support for the Analog Devices / Linear Technology
> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
> The LTC4306 optionally provides two general purpose input/output pins
> (GPIOs) that can be configured as logic inputs, opendrain outputs or
> push-pull outputs via the generic GPIOLIB framework.
>
> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
> ---
> .../devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 61 ++++
It's preferred to split bindings to separate patch. In any case,
Acked-by: Rob Herring <robh@kernel.org>
> MAINTAINERS | 8 +
> drivers/i2c/muxes/Kconfig | 10 +
> drivers/i2c/muxes/Makefile | 1 +
> drivers/i2c/muxes/i2c-mux-ltc4306.c | 365 +++++++++++++++++++++
> 5 files changed, 445 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
> create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: imx-gpc: add i.MX6 QuadPlus compatible
From: Rob Herring @ 2017-03-29 15:59 UTC (permalink / raw)
To: Lucas Stach
Cc: Shawn Guo, Fabio Estevam, Dong Aisheng,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
patchwork-lst-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170323144418.30977-2-l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Thu, Mar 23, 2017 at 03:44:17PM +0100, Lucas Stach wrote:
> While the GPC on i.MX6QP is mostly comptible to the i.MX6Q one,
> the QuadPlus requires special workarounds for hardware erratum
> ERR009619.
>
> Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/power/fsl,imx-gpc.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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 v4 1/2] power: supply: ltc2941-battery-gauge: Add vendor to compatibles in binding
From: Javier Martinez Canillas @ 2017-03-29 16:00 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Rob Herring,
Javier Martinez Canillas, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Sebastian Reichel
The DT binding document for LTC2941 and LTC2943 battery gauges did not use
a vendor prefix in the listed compatible strings. The driver says that the
manufacturer is Linear Technology which is "lltc" in vendor-prefixes.txt.
There isn't an upstream Device Tree source file that has nodes defined for
these devices, so there's no need to keep the old compatible strings.
Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/power/supply/ltc2941.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/supply/ltc2941.txt b/Documentation/devicetree/bindings/power/supply/ltc2941.txt
index ea42ae12d924..a9d7aa60558b 100644
--- a/Documentation/devicetree/bindings/power/supply/ltc2941.txt
+++ b/Documentation/devicetree/bindings/power/supply/ltc2941.txt
@@ -6,8 +6,8 @@ temperature monitoring, and uses a slightly different conversion
formula for the charge counter.
Required properties:
-- compatible: Should contain "ltc2941" or "ltc2943" which also indicates the
- type of I2C chip attached.
+- compatible: Should contain "lltc,ltc2941" or "lltc,ltc2943" which also
+ indicates the type of I2C chip attached.
- reg: The 7-bit I2C address.
- lltc,resistor-sense: The sense resistor value in milli-ohms. Can be a 32-bit
negative value when the battery has been connected to the wrong end of the
@@ -20,7 +20,7 @@ Required properties:
Example from the Topic Miami Florida board:
fuelgauge: ltc2943@64 {
- compatible = "ltc2943";
+ compatible = "lltc,ltc2943";
reg = <0x64>;
lltc,resistor-sense = <15>;
lltc,prescaler-exponent = <5>; /* 2^(2*5) = 1024 */
--
2.9.3
--
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 related
* [PATCH v4 2/2] power: supply: ltc2941-battery-gauge: Add OF device ID table
From: Javier Martinez Canillas @ 2017-03-29 16:00 UTC (permalink / raw)
To: linux-kernel
Cc: devicetree, Mark Rutland, Rob Herring, Javier Martinez Canillas,
Sebastian Reichel, linux-pm
In-Reply-To: <20170329160057.8298-1-javier@osg.samsung.com>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
Changes in v4:
- Add a vendor prefix to OF device compatible strings (Sebastian Reichel).
Changes in v3:
- Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
Changes in v2:
- Fix build warning reported by kbuild test robot.
- Fix wrong compatible strings due a copy & paste error.
drivers/power/supply/ltc2941-battery-gauge.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/power/supply/ltc2941-battery-gauge.c b/drivers/power/supply/ltc2941-battery-gauge.c
index 4adf2ba021ce..7efb908f4451 100644
--- a/drivers/power/supply/ltc2941-battery-gauge.c
+++ b/drivers/power/supply/ltc2941-battery-gauge.c
@@ -9,6 +9,7 @@
*/
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/of_device.h>
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/swab.h>
@@ -61,7 +62,7 @@ struct ltc294x_info {
struct power_supply *supply; /* Supply pointer */
struct power_supply_desc supply_desc; /* Supply description */
struct delayed_work work; /* Work scheduler */
- int num_regs; /* Number of registers (chip type) */
+ unsigned long num_regs; /* Number of registers (chip type) */
int charge; /* Last charge register content */
int r_sense; /* mOhm */
int Qlsb; /* nAh */
@@ -387,7 +388,7 @@ static int ltc294x_i2c_probe(struct i2c_client *client,
np = of_node_get(client->dev.of_node);
- info->num_regs = id->driver_data;
+ info->num_regs = (unsigned long)of_device_get_match_data(&client->dev);
info->supply_desc.name = np->name;
/* r_sense can be negative, when sense+ is connected to the battery
@@ -497,9 +498,23 @@ static const struct i2c_device_id ltc294x_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ltc294x_i2c_id);
+static const struct of_device_id ltc294x_i2c_of_match[] = {
+ {
+ .compatible = "lltc,ltc2941",
+ .data = (void *)LTC2941_NUM_REGS
+ },
+ {
+ .compatible = "lltc,ltc2943",
+ .data = (void *)LTC2943_NUM_REGS
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, ltc294x_i2c_of_match);
+
static struct i2c_driver ltc294x_driver = {
.driver = {
.name = "LTC2941",
+ .of_match_table = ltc294x_i2c_of_match,
.pm = LTC294X_PM_OPS,
},
.probe = ltc294x_i2c_probe,
--
2.9.3
^ permalink raw reply related
* RE: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD driver
From: A.S. Dong @ 2017-03-29 16:08 UTC (permalink / raw)
To: Lucas Stach, Shawn Guo
Cc: Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
patchwork-lst-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
In-Reply-To: <20170323144418.30977-3-l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Lucas,
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org]
> Sent: Thursday, March 23, 2017 10:44 PM
> To: Shawn Guo
> Cc: Fabio Estevam; A.S. Dong; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org; patchwork-
> lst-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
> Subject: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD
> driver
>
> On i.MX6QP, due to hardware erratum ERR009619, the PRE clocks may be
> stalled during the power up sequencing of the PU power domain. As this may
> lead to a complete loss of display output, the recommended workaround is
> to keep the PU domain enabled during normal system operation.
>
> Implement this by rejecting the domain power down request on the affected
> SoC.
>
> Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> drivers/soc/imx/gpc.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c index
> 4294287e5f6c..599e1e46f694 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -45,6 +45,7 @@ struct imx_pm_domain {
> unsigned int reg_offs;
> signed char cntr_pdn_bit;
> unsigned int ipg_rate_mhz;
> + bool allow_dynamic_pd;
> };
>
> static inline struct imx_pm_domain *
> @@ -59,6 +60,9 @@ static int imx6_pm_domain_power_off(struct
> generic_pm_domain *genpd)
> int iso, iso2sw;
> u32 val;
>
> + if (!pd->allow_dynamic_pd)
> + return -EBUSY;
> +
> /* Read ISO and ISO2SW power down delays */
> regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
> iso = val & 0x3f;
> @@ -255,6 +259,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> },
> .reg_offs = 0x260,
> .cntr_pdn_bit = 0,
> + .allow_dynamic_pd = true,
> }, {
> .base = {
> .name = "DISPLAY",
> @@ -263,23 +268,33 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> },
> .reg_offs = 0x240,
> .cntr_pdn_bit = 4,
> + .allow_dynamic_pd = true,
Just a Nitpick, besides shawn's comment in another mail,
if we use a domain flag like IMX_PD_ALWAYS_ON set by SoC errata flag,
then probably we can save all the default allow_dynamic_pd lines.
This also release the life when adding new domains.
Otherwise, the two patch seems good to me.
Regards
Dong Aisheng
> }
> };
>
> struct imx_gpc_dt_data {
> int num_domains;
> + bool err009619_present;
> };
>
> static const struct imx_gpc_dt_data imx6q_dt_data = {
> .num_domains = 2,
> + .err009619_present = false,
> +};
> +
> +static const struct imx_gpc_dt_data imx6qp_dt_data = {
> + .num_domains = 2,
> + .err009619_present = true,
> };
>
> static const struct imx_gpc_dt_data imx6sl_dt_data = {
> .num_domains = 3,
> + .err009619_present = false,
> };
>
> static const struct of_device_id imx_gpc_dt_ids[] = {
> { .compatible = "fsl,imx6q-gpc", .data = &imx6q_dt_data },
> + { .compatible = "fsl,imx6qp-gpc", .data = &imx6qp_dt_data },
> { .compatible = "fsl,imx6sl-gpc", .data = &imx6sl_dt_data },
> { }
> };
> @@ -377,6 +392,10 @@ static int imx_gpc_probe(struct platform_device *pdev)
> return ret;
> }
>
> + /* Disable PU power down in normal operation if ERR009619 is present
> */
> + if (of_id_data->err009619_present)
> + imx_gpc_domains[1].allow_dynamic_pd = false;
> +
> if (!pgc_node) {
> ret = imx_gpc_old_dt_init(&pdev->dev, regmap,
> of_id_data->num_domains);
> --
> 2.11.0
--
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] ARM: dts: keystone-k2l: fix broken Ethernet due to disabled OSR
From: santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA @ 2017-03-29 16:13 UTC (permalink / raw)
To: arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: Sekhar Nori, Santosh Shilimkar, Rob Herring, Mark Rutland,
Russell King, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Tero Kristo,
Murali Karicheri
In-Reply-To: <59ba5ef37f17ff1c10d9d52ca06ef341b2d476eb.1490782833.git.nsekhar-l0cyMroinI0@public.gmane.org>
Hi Arnd, Olof,
On 3/29/17 5:32 AM, Sekhar Nori wrote:
> From: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
>
> Ethernet networking on K2L has been broken since v4.11-rc1. This was
> caused by commit 32a34441a9bd ("ARM: keystone: dts: fix netcp clocks
> and add names"). This commit inadvertently moves on-chip static RAM
> clock to the end of list of clocks provided for netcp. Since keystone
> PM domain support does not have a list of recognized con_ids, only the
> first clock in the list comes under runtime PM management. This means
> the OSR (On-chip Static RAM) clock remains disabled and that broke
> networking on K2L.
>
> The OSR is used by QMSS on K2L as an external linking RAM. However this
> is a standalone RAM that can be used for non-QMSS usage (as well as from
> DSP side). So add a SRAM device node for the same and add the OSR clock
> to the node.
>
> Remove the now redundant OSR clock node from netcp.
>
> To manage all clocks defined for netCP's use by runtime PM needs keystone
> generic power domain (genpd) driver support which is under works.
> Meanwhile, this patch restores K2L networking and is correct irrespective
> of any future genpd work since OSR is an independent module and not part
> of NetCP anyway.
>
> Signed-off-by: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
> Acked-by: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> [nsekhar-l0cyMroinI0@public.gmane.org: commit message updates, port to latest mainline]
> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
> ---
Acked-by: Santosh Shilimkar <ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Can you please pick this up for rcx fixes ?
Regards,
Santosh
--
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 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD driver
From: Lucas Stach @ 2017-03-29 16:13 UTC (permalink / raw)
To: A.S. Dong
Cc: Shawn Guo, Fabio Estevam,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
patchwork-lst-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
In-Reply-To: <DB5PR04MB1431A7CC91F55ECFE5BE31FB80350-rqLcZCCNzVwrYIBjo4yUUM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Am Mittwoch, den 29.03.2017, 16:08 +0000 schrieb A.S. Dong:
> Hi Lucas,
>
> > -----Original Message-----
> > From: Lucas Stach [mailto:l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org]
> > Sent: Thursday, March 23, 2017 10:44 PM
> > To: Shawn Guo
> > Cc: Fabio Estevam; A.S. Dong; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
> > kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org; patchwork-
> > lst-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
> > Subject: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD
> > driver
> >
> > On i.MX6QP, due to hardware erratum ERR009619, the PRE clocks may be
> > stalled during the power up sequencing of the PU power domain. As this may
> > lead to a complete loss of display output, the recommended workaround is
> > to keep the PU domain enabled during normal system operation.
> >
> > Implement this by rejecting the domain power down request on the affected
> > SoC.
> >
> > Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> > drivers/soc/imx/gpc.c | 19 +++++++++++++++++++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c index
> > 4294287e5f6c..599e1e46f694 100644
> > --- a/drivers/soc/imx/gpc.c
> > +++ b/drivers/soc/imx/gpc.c
> > @@ -45,6 +45,7 @@ struct imx_pm_domain {
> > unsigned int reg_offs;
> > signed char cntr_pdn_bit;
> > unsigned int ipg_rate_mhz;
> > + bool allow_dynamic_pd;
> > };
> >
> > static inline struct imx_pm_domain *
> > @@ -59,6 +60,9 @@ static int imx6_pm_domain_power_off(struct
> > generic_pm_domain *genpd)
> > int iso, iso2sw;
> > u32 val;
> >
> > + if (!pd->allow_dynamic_pd)
> > + return -EBUSY;
> > +
> > /* Read ISO and ISO2SW power down delays */
> > regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
> > iso = val & 0x3f;
> > @@ -255,6 +259,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > },
> > .reg_offs = 0x260,
> > .cntr_pdn_bit = 0,
> > + .allow_dynamic_pd = true,
> > }, {
> > .base = {
> > .name = "DISPLAY",
> > @@ -263,23 +268,33 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > },
> > .reg_offs = 0x240,
> > .cntr_pdn_bit = 4,
> > + .allow_dynamic_pd = true,
>
> Just a Nitpick, besides shawn's comment in another mail,
> if we use a domain flag like IMX_PD_ALWAYS_ON set by SoC errata flag,
> then probably we can save all the default allow_dynamic_pd lines.
> This also release the life when adding new domains.
If other things like that show up we can certainly switch to a flags
field. In the meantime I like that the current style is more explicit
about it.
Regards,
Lucas
--
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 1/1] of: Move OF property and graph API from base.c to property.c
From: Frank Rowand @ 2017-03-29 16:28 UTC (permalink / raw)
To: Sakari Ailus, linux-acpi, devicetree, robh
Cc: sudeep.holla, lorenzo.pieralisi, mika.westerberg, rafael,
mark.rutland, broonie, ahs3
In-Reply-To: <fb9cdd4e-e837-f925-da2b-9e4d25602e1e@linux.intel.com>
On 03/29/17 02:14, Sakari Ailus wrote:
> Hi Frank,
>
> Thank you for the review.
>
> Frank Rowand wrote:
>> Hi Sakari,
>>
>> On 03/24/17 03:59, Sakari Ailus wrote:
>>> base.c contains both core OF functions and increasingly other
>>> functionality such as accessing properties and graphs, including
>>> convenience functions. In the near future this would also include OF
>>> specific implementation of the fwnode property and graph APIs. Prepare for
>>> this by moving the functionality to property.c.
>>
>> For future me, for when I look back and read this commit, please add something
>> to the effect of:
>>
>> Create driver/of/property.c to contain procedures for accessing and
>> interpreting device tree properties. The procedures are moved from
>> drivers/of/base.c, with no changes other than copying only the
>> includes required by the moved procedures.
>
> How about this as the commit message combining the two and dropping the last sentence from the original description:
>
> base.c contains both core OF functions and increasingly other
> functionality such as accessing properties and graphs, including
> convenience functions. In the near future this would also include OF
> specific implementation of the fwnode property and graph APIs.
>
> Create driver/of/property.c to contain procedures for accessing and
> interpreting device tree properties. The procedures are moved from
> drivers/of/base.c, with no changes other than copying only the
> includes required by the moved procedures.
Sounds good (and same for your below comments).
-Frank
>
> ...
>
>>> diff --git a/drivers/of/property.c b/drivers/of/property.c
>>> new file mode 100644
>>> index 0000000..afcf00a
>>> --- /dev/null
>>> +++ b/drivers/of/property.c
>>> @@ -0,0 +1,727 @@
>>> +/*
>>> + * drivers/of/property.c - Devicetree properties and graphs.
>>
>> * drivers/of/property.c - Procedures for accessing and interpreting
>> * Devicetree properties and graphs.
>> *
>> * Initially created by copying procedures from drivers/of/base.c
>>
>> The reference to base.c provides a documentation trail to all of the
>> earlier git commits that created and modified the procedures.
>
> I'll add that.
>
>>
>> It would also be useful to say what procedures do and do not belong
>> in this file. My understanding is that the intent is for
>> drivers/of/property.c and drivers/acpi/property.c to provide the
>> respective functionality that is used by drivers/base/property.c
>> and that drivers also may directly access the procedures in
>> drivers/of/property.c.
>
> I'll add something along those lines. The fwnode op struct and the operations in that will be in this file as well.
>
^ permalink raw reply
* Re: [PATCH 2/2] mtd: spi-nor: add driver for STM32 quad spi flash controller
From: Ludovic BARRE @ 2017-03-29 16:38 UTC (permalink / raw)
To: Marek Vasut, Cyrille Pitchen
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Alexandre Torgue, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0e7da44f-c41b-de15-62c3-7509e556f623-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 03/29/2017 03:57 PM, Marek Vasut wrote:
> On 03/29/2017 03:35 PM, Ludovic BARRE wrote:
>
> [...]
>
>>>>>> + writel_relaxed(CR_PRESC(presc) | CR_FTHRES(3) | CR_TCEN |
>>>>>> CR_SSHIFT
>>>>>> + | CR_EN, qspi->io_base + QUADSPI_CR);
>>>>>> +
>>>>>> + /* a minimum fsize must be set to sent the command id */
>>>>>> + flash->fsize = 25;
>>>>> I don't understand why this is needed and the comment doesn't make
>>>>> sense. Please fix.
>>>> fsize field defines the size of external memory.
>>> What external memory ? Unclear
>> oops, fsize field defined the size of "flash memory" in stm32 qspi
>> controller.
> Errr, now I am totally lost :) Is that some internal SPI NOR ? Shouldn't
> the size be coming from DT or something ?
>
>> Number of bytes in Flash memory = 2 ^[FSIZE+1].
>> To sent a nor cmd this field must be set (hardware issue),
>> but before "spi_nor_scan" the size of flash nor is not know.
>> So I set a temporary value (workaround).
> Is it needed before the scan ?
yes it's needed before scan (fix a "stm32 qspi controller" issue)
sorry, I try to reformulate:
The nor flash (external component like micron n25q128a13
or spansion s25fl512s ...) is connected to stm32 by classic
spi-nor interface cs, clock and 1/2/4 IO lines.
the stm32 microprocessor has a dedicated controller to
manage spi-nor interface, it's stm32 qspi.
In stm32 qspi controller there is a register with fsize field
which define the size of nor flash (n25q128a13 or s25fl512s...).
fsize can't be null, else the stm32 qspi controller doesn't send
spi-nor command. it's "stm32 qspi controller" issue.
Before the "spi_nor_scan" the size of nor flash (n25q128a13
or s25fl512s...) is not know. So we set a temporary value just
to discover the nor flash with "spi_nor_scan". After we can
set the right value (mtd->size) in fsize.
>> After "spi_nor_scan" the fsize is overwritten by the right value
>> flash->fsize = __fls(mtd->size) - 1;
>>>> Normaly, this field is used only for memory map mode,
>>>> but in fact is check in indirect mode.
>>>> So while flash scan "spi_nor_scan":
>>>> -I can't let 0.
>>>> -I not know yet the size of flash.
>>>> So I fix a temporary value
>>>>
>>>> I will update my comment
>>> Please do, also please consider that I'm reading the comment and I
>>> barely have any clue about this hardware , so make sure I can
>>> understand it.
>>>
>>>>>> + ret = spi_nor_scan(&flash->nor, NULL, flash_read);
>>>>>> + if (ret) {
>>>>>> + dev_err(qspi->dev, "device scan failed\n");
>>>>>> + return ret;
>>>>>> + }
>>>>>> +
>>>>>> + flash->fsize = __fls(mtd->size) - 1;
>>>>>> +
>>>>>> + writel_relaxed(DCR_CSHT(1), qspi->io_base + QUADSPI_DCR);
>>>>>> +
>>>>>> + ret = mtd_device_register(mtd, NULL, 0);
>>>>>> + if (ret) {
>>>>>> + dev_err(qspi->dev, "mtd device parse failed\n");
>>>>>> + return ret;
>>>>>> + }
>>>>>> +
>>>>>> + dev_dbg(qspi->dev, "read mm:%s cs:%d bus:%d\n",
>>>>>> + qspi->read_mode == CCR_FMODE_MM ? "yes" : "no", cs_num,
>>>>>> width);
>>>>>> +
>>>>>> + return 0;
>>>>>> +}
>>>>> [...]
>>>>>
>
--
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] Add hardware PTP support.
From: David Miller @ 2017-03-29 16:39 UTC (permalink / raw)
To: rafalo-vna1KIf7WgpBDgjK7y7TUQ
Cc: nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
harinikatakamlinux-Re5JQEeQqe8AvxtiuMwx3w,
harini.katakam-gjFFaj9aHVfQT0dZR+AlfA,
richardcochran-Re5JQEeQqe8AvxtiuMwx3w,
Andrei.Pistirica-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <1490796051-28527-1-git-send-email-rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
From: Rafal Ozieblo <rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
Date: Wed, 29 Mar 2017 15:00:51 +0100
> This patch is based on original Harini's patch and Andrei's patch,
> implemented in aseparate file to ease the review/maintanance
> and integration with other platforms.
>
> In case that macb is compiled as a module, it has been renamed to
> cadence-macb.ko to avoid naming confusion in Makefile.
>
> This driver does support GEM-GXL:
> - Enable HW time stamp
> - Register ptp clock framework
> - Initialize PTP related registers
> - Updated dma buffer descriptor read/write mechanism
> - HW time stamp on the PTP Ethernet packets are received using the
> SO_TIMESTAMPING API. Where timers are obtained from the dma buffer
> descriptors
> - Added tsu_clk to device tree
>
> Note: Patch on net-next, on March 15th.
>
> Signed-off-by: Rafal Ozieblo <rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
Your subject should provide a proper subsystem prefix such as
"cadence: " after "[PATCH] ".
Also, March 15th is nearly half a month ago, you should generate
patches against the current tree.
--
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 0/2] mtd: spi-nor: add stm32 qspi driver
From: Cyrille Pitchen @ 2017-03-29 16:51 UTC (permalink / raw)
To: Ludovic Barre, Cyrille Pitchen, Marek Vasut
Cc: Boris Brezillon, Alexandre Torgue,
devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris,
David Woodhouse
In-Reply-To: <1490619296-8168-1-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
Hi Ludovic,
Le 27/03/2017 à 14:54, Ludovic Barre a écrit :
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>
> This patch set adds a SPI-NOR driver for stm32 QSPI controller.
> It is a specialized SPI interface for serial Flash devices.
> It supports 1 or 2 Flash device with single, dual and quad SPI Flash memories.
>
> It can operate in any of the following modes:
> -indirect mode: all the operations are performed using the quadspi
> registers
> -read memory-mapped mode: the external Flash memory is mapped to the
> microcontroller address space and is seen by the system as if it was
> an internal memory
>
> Ludovic Barre (2):
> dt-bindings: Document the STM32 QSPI bindings
> mtd: spi-nor: add driver for STM32 quad spi flash controller
>
> .../devicetree/bindings/mtd/stm32-quadspi.txt | 45 ++
> drivers/mtd/spi-nor/Kconfig | 7 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/stm32-quadspi.c | 679 +++++++++++++++++++++
> 4 files changed, 732 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
> create mode 100644 drivers/mtd/spi-nor/stm32-quadspi.c
>
Just a small word to warn you that I'm likely to ask you to rebase this
series onto the patch "mtd: spi-nor: introduce more SPI protocols and
the Dual Transfer Mode". Indeed, I need to synchronize with Marek first
but I plan to merge this patch within few days.
Best regards,
Cyrille
--
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 v5 6/9] coresight: add support for CPU debug module
From: Mathieu Poirier @ 2017-03-29 16:55 UTC (permalink / raw)
To: Leo Yan
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Michael Turquette, Stephen Boyd, Guodong Xu, John Stultz,
linux-doc, linux-kernel, devicetree, linux-arm-kernel,
linux-arm-msm, linux-soc, linux-clk, mike.leach, Suzuki.Poulose,
sudeep.holla
In-Reply-To: <20170329015423.GA5035@leoy-linaro>
On Wed, Mar 29, 2017 at 09:54:23AM +0800, Leo Yan wrote:
> Hi Mathieu,
>
> On Tue, Mar 28, 2017 at 10:50:10AM -0600, Mathieu Poirier wrote:
> > On Sun, Mar 26, 2017 at 02:23:14AM +0800, Leo Yan wrote:
>
> [...]
>
> > > +static void debug_force_cpu_powered_up(struct debug_drvdata *drvdata)
> > > +{
> > > + int timeout = DEBUG_WAIT_TIMEOUT;
> > > +
> > > + drvdata->edprsr = readl_relaxed(drvdata->base + EDPRSR);
> > > +
> > > + CS_UNLOCK(drvdata->base);
> > > +
> > > + /* Bail out if CPU is powered up yet */
> > > + if (drvdata->edprsr & EDPRSR_PU)
> > > + goto out_powered_up;
> > > +
> > > + /*
> > > + * Send request to power management controller and assert
> > > + * DBGPWRUPREQ signal; if power management controller has
> > > + * sane implementation, it should enable CPU power domain
> > > + * in case CPU is in low power state.
> > > + */
> > > + drvdata->edprsr = readl(drvdata->base + EDPRCR);
> > > + drvdata->edprsr |= EDPRCR_COREPURQ;
> > > + writel(drvdata->edprsr, drvdata->base + EDPRCR);
> >
> > Here ->edprsr is used but EDPRCR is accessed. Is this intentional or a
> > copy/paste error? The same is true for accesses in the out_powered_up section.
>
> Thanks for pointing out. This is a typo error and will fix.
>
> > > +
> > > + /* Wait for CPU to be powered up (timeout~=32ms) */
> > > + while (timeout--) {
> > > + drvdata->edprsr = readl_relaxed(drvdata->base + EDPRSR);
> > > + if (drvdata->edprsr & EDPRSR_PU)
> > > + break;
> > > +
> > > + usleep_range(1000, 2000);
> > > + }
> >
> > See if function readx_poll_timeout() can be used.
>
> Will use it.
>
> > > +
> > > + /*
> > > + * Unfortunately the CPU cannot be powered up, so return
> > > + * back and later has no permission to access other
> > > + * registers. For this case, should set 'idle_constraint'
> > > + * to ensure CPU power domain is enabled!
> > > + */
> > > + if (!(drvdata->edprsr & EDPRSR_PU)) {
> > > + pr_err("%s: power up request for CPU%d failed\n",
> > > + __func__, drvdata->cpu);
> > > + goto out;
> > > + }
> > > +
> > > +out_powered_up:
> > > + debug_os_unlock(drvdata);
> > > +
> > > + /*
> > > + * At this point the CPU is powered up, so set the no powerdown
> > > + * request bit so we don't lose power and emulate power down.
> > > + */
> > > + drvdata->edprsr = readl(drvdata->base + EDPRCR);
> > > + drvdata->edprsr |= EDPRCR_COREPURQ | EDPRCR_CORENPDRQ;
> >
> > If we are here the core is already up. Shouldn't we need to set
> > EDPRCR_CORENPDRQ only?
>
> Yeah. Will fix.
>
> > > + writel(drvdata->edprsr, drvdata->base + EDPRCR);
> >
> > This section is a little racy - between the time the PU bit has been
> > checked and the time COREPDRQ has been flipped, the state of PU may have
> > changed. You can probably get around this by checking edprsr.PU rigth here. If
> > it is not set you go through the process again. Note that doing this will
> > probably force a refactoring of the whole function.
>
> Agree. Will handle this.
>
> [...]
>
> > > +static ssize_t debug_func_knob_write(struct file *f,
> > > + const char __user *buf, size_t count, loff_t *ppos)
> > > +{
> > > e u8 on;
> > > + int ret;
> > > +
> > > + ret = kstrtou8_from_user(buf, count, 2, &on);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + mutex_lock(&debug_lock);
> > > +
> > > + if (!on ^ debug_enable)
> > > + goto out;
> >
> > I had to read this condition too many times - please refactor.
>
> Will do it.
>
> > > +
> > > + if (on) {
> > > + ret = debug_enable_func();
> > > + if (ret) {
> > > + pr_err("%s: unable to disable debug function: %d\n",
> > > + __func__, ret);
> >
> > Based on the semantic this is the wrong error message.
>
> Yeah. Will fix.
>
> > > + goto err;
> > > + }
> > > + } else
> > > + debug_disable_func();
> >
> > Did checkpatch.pl complain about extra curly braces? If not please add them.
>
> checkpatch.pl doesn't report for this. Will add.
>
> > > +
> > > + debug_enable = on;
> >
> > Here we can't set debug_enable if we just called debug_disable_func(). Maybe
> > I'm missing something. If that's the case a comment in the code would be worth
> > it.
>
> After called debug_disable_func(), debug_enable is set to 0 (on = 0).
>
> > > +
> > > +out:
> > > + ret = count;
> > > +err:
> > > + mutex_unlock(&debug_lock);
> > > + return ret;
> > > +}
> > > +
> > > +static ssize_t debug_func_knob_read(struct file *f,
> > > + char __user *ubuf, size_t count, loff_t *ppos)
> > > +{
> > > + char val[] = { '0' + debug_enable, '\n' };
> > > +
> > > + return simple_read_from_buffer(ubuf, count, ppos, val, sizeof(val));
> >
> > Use the debug_lock to avoid race conditions.
>
> Will do it.
>
> > > +}
> > > +
> > > +static ssize_t debug_idle_constraint_write(struct file *f,
> > > + const char __user *buf, size_t count, loff_t *ppos)
> > > +{
> > > + int val;
> > > + ssize_t ret;
> > > +
> > > + ret = kstrtoint_from_user(buf, count, 10, &val);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + mutex_lock(&debug_lock);
> > > + idle_constraint = val;
> > > +
> > > + if (debug_enable)
> > > + pm_qos_update_request(&debug_qos_req, idle_constraint);
> > > +
> > > + mutex_unlock(&debug_lock);
> > > + return count;
> > > +}
> > > +
> > > +static ssize_t debug_idle_constraint_read(struct file *f,
> > > + char __user *ubuf, size_t count, loff_t *ppos)
> > > +{
> > > + char buf[32];
> > > + int len;
> > > +
> > > + if (*ppos)
> > > + return 0;
> > > +
> > > + len = sprintf(buf, "%d\n", idle_constraint);
> > > + return simple_read_from_buffer(ubuf, count, ppos, buf, len);
> >
> > Use the debug_lock to avoid race conditions.
>
> Will do it.
>
> > > +}
> > > +
> > > +static const struct file_operations debug_func_knob_fops = {
> > > + .open = simple_open,
> > > + .read = debug_func_knob_read,
> > > + .write = debug_func_knob_write,
> > > +};
> > > +
> > > +static const struct file_operations debug_idle_constraint_fops = {
> > > + .open = simple_open,
> > > + .read = debug_idle_constraint_read,
> > > + .write = debug_idle_constraint_write,
> > > +};
> > > +
> > > +static int debug_func_init(void)
> > > +{
> > > + struct dentry *file;
> > > + int ret;
> > > +
> > > + /* Create debugfs node */
> > > + debug_debugfs_dir = debugfs_create_dir("coresight_cpu_debug", NULL);
> > > + if (!debug_debugfs_dir) {
> > > + pr_err("%s: unable to create debugfs directory\n", __func__);
> > > + return -ENOMEM;
> >
> > return PTR_ERR(debug_debugfs_dir);
>
> Here cannot use PTR_ERR(debug_debugfs_dir). If create debugfs failed
> the pointer is NULL value, so finally we will return zero value for
> PTR_ERR(debug_debugfs_dir).
>
> [...]
>
> > > + }
> > > +
> > > + file = debugfs_create_file("enable", S_IRUGO | S_IWUSR,
> > > + debug_debugfs_dir, NULL, &debug_func_knob_fops);
> > > + if (!file) {
> > > + pr_err("%s: unable to create enable knob file\n", __func__);
> > > + ret = -ENOMEM;
> >
> > Same as above.
> >
> > > + goto err;
> > > + }
> > > +
> > > + file = debugfs_create_file("idle_constraint", S_IRUGO | S_IWUSR,
> > > + debug_debugfs_dir, NULL, &debug_idle_constraint_fops);
> > > + if (!file) {
> > > + pr_err("%s: unable to create idle constraint file\n", __func__);
> > > + ret = -ENOMEM;
> >
> > Same as above.
> >
> > > + goto err;
> > > + }
> > > +
> > > + /* Use sysfs node to enable functionality */
> > > + if (!debug_enable)
> > > + return 0;
> > > +
> > > + /* Enable debug module at boot time */
> > > + ret = debug_enable_func();
> > > + if (ret) {
> > > + pr_err("%s: unable to disable debug function: %d\n",
> > > + __func__, ret);
> > > + goto err;
> > > + }
> >
> > Use the debug_lock to avoid race conditions.
>
> I'm struggling to understand what's race condition at here? The
> function pairs debug_func_init()/debug_func_exit() are used for
> module's probing and removing, so naturally module's probing and
> removing are sequential, right?
You are correct - void that comment.
>
> > > +
> > > + return 0;
> > > +
> > > +err:
> > > + debugfs_remove_recursive(debug_debugfs_dir);
> > > + return ret;
> > > +}
> > > +
> > > +static void debug_func_exit(void)
> > > +{
> > > + debugfs_remove_recursive(debug_debugfs_dir);
> > > +
> > > + /* Disable functionality if has enabled */
> > > + if (debug_enable)
> > > + debug_disable_func();
> > > +}
> > > +
> > > +static int debug_probe(struct amba_device *adev, const struct amba_id *id)
> > > +{
> > > + void __iomem *base;
> > > + struct device *dev = &adev->dev;
> > > + struct debug_drvdata *drvdata;
> > > + struct resource *res = &adev->res;
> > > + struct device_node *np = adev->dev.of_node;
> > > + int ret;
> > > +
> > > + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> > > + if (!drvdata)
> > > + return -ENOMEM;
> > > +
> > > + drvdata->cpu = np ? of_coresight_get_cpu(np) : 0;
> > > + if (per_cpu(debug_drvdata, drvdata->cpu)) {
> > > + dev_err(dev, "CPU's drvdata has been initialized\n");
> >
> > Might be worth adding the CPU number in the error message.
>
> Yeah, will add it.
>
> [...]
>
> > This driver doesn't call the pm_runtime_put/get() operations needed to handle the
> > debug power domain. See the other CoreSight drivers for details.
>
> Sure, will do it.
>
> > Also, from the conversation that followed the previous post we agreed that we wouldn't
> > deal with CPUidle issues in this driver. We deal with the CPU power domain
> > using the EDPRCR register (like you did) and that's it. System that don't honor that register
> > can use other (external) means to solve this. As such please remove the
> > pm_qos_xyz() functions.
>
> From previous discussion, Mike reminds the CPU power domain design is
> quite SoC specific and usually the SoC has many different low power
> states, e.g. except CPU level and cluster level low power states, they
> also can define SoC level low power states. Any SoC with any power
> state is possible finally impact CPU power domain, so this is why I add
> this interface to let user can have the final decision based on their
> working platform.
Mike is correct but there are other ways to deal with these cases, i.e cpuidle
interface from cmd line.
>
> We can rely on "nohlt" and "cpuidle.off=1" in kernel command line to
> disable whole SoC low power states at boot time; or we can use sysfs
> node "echo 1 > /sys/devices/system/cpu/cpuX/cpuidle/stateX/disble" to
> disable CPU low power states at runtime. But that means we need use
> different interfaces to control CPU power domain for booting and
> runtime, it's not nice for usage.
That is a different topic altogether.
>
> So this is why add "idle_constraint" as a central place to control
> power domain for CPU debug purpose and I also think this is more
> friendly for hardware design, e.g. some platforms can enable partial
> low power states to save power and avoid overheat after using this
> driver.
>
> How about you think for this?
Like Sudeep pointed out we should concentrate on doing the right thing, that is
work with EDPRSR.PU, EDPRCR.COREPURQ and EDPRCR.CORENPDRQ. Anything
outside of that becomes platform specific and can't be handled in
this driver.
>
> Thanks,
> Leo Yan
^ permalink raw reply
* [PATCH v3 0/7] rtc: Reuse rtc-sh driver to support RZ/A1
From: Chris Brandt @ 2017-03-29 17:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, Geert Uytterhoeven
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
Basically, the same RTC that was used in SuperH devices is now used in
RZ/A1 devices. Therefore with some slight changes, that driver can be
reused.
Additionally, since ARM architectures require Device Tree configurations,
device tree support has been added.
This was tested on RZ/A1H RSK board. Once the correct time was programmed
into the RTC running off a 32.768kHz crystal, you can retain an accurate
system clock between reboots (hard and soft) until power is finally removed
from the board (there is no batter backup on the RSK board).
v3:
* remove 'power-domains' from example in documentation
* update commit message subject and body of dt-bindings
v2:
* removed HAVE_CLK from Kconfig
* when using DT, look for "fck" instead of "rtc0"
* changed (res == NULL) to (!res)
* added Reviewed-by for rtc-sh.c
* added interrupt-names and clock-names
* clocks now include counting sources
* added clock-names "fck", "rtc_x1", "rtc_x3", "extal"
* changed 'is a RTC' to 'is an RTC' in commit message
* changed "rtc0" to "rtc"
* Added clock nodes for RTC_X1 and RTC_X3 pin inputs
* each commit now has a log message
Chris Brandt (7):
rtc: rtc-sh: add support for rza series
dt-bindings: rtc: document the rtc-sh bindings
ARM: dts: r7s72100: add rtc clock to device tree
ARM: dts: r7s72100: add RTC_X clock inputs to device tree
ARM: dts: r7s72100: add rtc to device tree
ARM: dts: rskrza1: set rtc_x1 clock value
ARM: dts: rskrza1: add rtc DT support
Documentation/devicetree/bindings/rtc/rtc-sh.txt | 28 ++++++++++++++++++
arch/arm/boot/dts/r7s72100-rskrza1.dts | 8 +++++
arch/arm/boot/dts/r7s72100.dtsi | 37 ++++++++++++++++++++++++
drivers/rtc/Kconfig | 4 +--
drivers/rtc/rtc-sh.c | 33 +++++++++++++++++----
include/dt-bindings/clock/r7s72100-clock.h | 3 ++
6 files changed, 106 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-sh.txt
--
2.11.0
--
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 1/7] rtc: rtc-sh: add support for rza series
From: Chris Brandt @ 2017-03-29 17:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, Geert Uytterhoeven
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
In-Reply-To: <20170329173035.67477-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
This same RTC is used in RZ/A series MPUs, therefore with some slight
changes, this driver can be reused. Additionally, since ARM architectures
require Device Tree configurations, device tree support has been added.
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
v2:
* removed HAVE_CLK from Kconfig
* when using DT, look for "fck" instead of "rtc0"
* changed (res == NULL) to (!res)
* added Reviewed-by
---
drivers/rtc/Kconfig | 4 ++--
drivers/rtc/rtc-sh.c | 33 ++++++++++++++++++++++++++++-----
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index ee1b0e9dde79..c2d1f0ed47a1 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1303,10 +1303,10 @@ config RTC_DRV_SA1100
config RTC_DRV_SH
tristate "SuperH On-Chip RTC"
- depends on SUPERH && HAVE_CLK
+ depends on SUPERH || ARCH_RENESAS
help
Say Y here to enable support for the on-chip RTC found in
- most SuperH processors.
+ most SuperH processors. This RTC is also found in RZ/A SoCs.
To compile this driver as a module, choose M here: the
module will be called rtc-sh.
diff --git a/drivers/rtc/rtc-sh.c b/drivers/rtc/rtc-sh.c
index c626e43a9cbb..00b396e96cbe 100644
--- a/drivers/rtc/rtc-sh.c
+++ b/drivers/rtc/rtc-sh.c
@@ -27,7 +27,15 @@
#include <linux/log2.h>
#include <linux/clk.h>
#include <linux/slab.h>
+#ifdef CONFIG_SUPERH
#include <asm/rtc.h>
+#else
+/* Default values for RZ/A RTC */
+#define rtc_reg_size sizeof(u16)
+#define RTC_BIT_INVERTED 0 /* no chip bugs */
+#define RTC_CAP_4_DIGIT_YEAR (1 << 0)
+#define RTC_DEF_CAPABILITIES RTC_CAP_4_DIGIT_YEAR
+#endif
#define DRV_NAME "sh-rtc"
@@ -570,6 +578,8 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
rtc->alarm_irq = platform_get_irq(pdev, 2);
res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (!res)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (unlikely(res == NULL)) {
dev_err(&pdev->dev, "No IO resource\n");
return -ENOENT;
@@ -587,12 +597,15 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
if (unlikely(!rtc->regbase))
return -EINVAL;
- clk_id = pdev->id;
- /* With a single device, the clock id is still "rtc0" */
- if (clk_id < 0)
- clk_id = 0;
+ if (!pdev->dev.of_node) {
+ clk_id = pdev->id;
+ /* With a single device, the clock id is still "rtc0" */
+ if (clk_id < 0)
+ clk_id = 0;
- snprintf(clk_name, sizeof(clk_name), "rtc%d", clk_id);
+ snprintf(clk_name, sizeof(clk_name), "rtc%d", clk_id);
+ } else
+ snprintf(clk_name, sizeof(clk_name), "fck");
rtc->clk = devm_clk_get(&pdev->dev, clk_name);
if (IS_ERR(rtc->clk)) {
@@ -608,6 +621,8 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
clk_enable(rtc->clk);
rtc->capabilities = RTC_DEF_CAPABILITIES;
+
+#ifdef CONFIG_SUPERH
if (dev_get_platdata(&pdev->dev)) {
struct sh_rtc_platform_info *pinfo =
dev_get_platdata(&pdev->dev);
@@ -618,6 +633,7 @@ static int __init sh_rtc_probe(struct platform_device *pdev)
*/
rtc->capabilities |= pinfo->capabilities;
}
+#endif
if (rtc->carry_irq <= 0) {
/* register shared periodic/carry/alarm irq */
@@ -738,10 +754,17 @@ static int sh_rtc_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(sh_rtc_pm_ops, sh_rtc_suspend, sh_rtc_resume);
+static const struct of_device_id sh_rtc_of_match[] = {
+ { .compatible = "renesas,sh-rtc", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sh_rtc_of_match);
+
static struct platform_driver sh_rtc_platform_driver = {
.driver = {
.name = DRV_NAME,
.pm = &sh_rtc_pm_ops,
+ .of_match_table = sh_rtc_of_match,
},
.remove = __exit_p(sh_rtc_remove),
};
--
2.11.0
--
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 related
* [PATCH v3 2/7] dt-bindings: rtc: document the rtc-sh bindings
From: Chris Brandt @ 2017-03-29 17:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, Geert Uytterhoeven
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
In-Reply-To: <20170329173035.67477-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Add the binding documentation for rtc-sh which is an RTC for
SuperH and RZ/A SoCs.
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
v3:
* remove 'power-domains' from example
* update commit message subject and body
v2:
* added interrupt-names and clock-names
* clocks now include counting sources
* changed 'is a RTC' to 'is an RTC' in commit message
---
Documentation/devicetree/bindings/rtc/rtc-sh.txt | 28 ++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-sh.txt
diff --git a/Documentation/devicetree/bindings/rtc/rtc-sh.txt b/Documentation/devicetree/bindings/rtc/rtc-sh.txt
new file mode 100644
index 000000000000..7676c7d28874
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-sh.txt
@@ -0,0 +1,28 @@
+* Real Time Clock for Renesas SH and ARM SoCs
+
+Required properties:
+- compatible: Should be "renesas,r7s72100-rtc" and "renesas,sh-rtc" as a
+ fallback.
+- reg: physical base address and length of memory mapped region.
+- interrupts: 3 interrupts for alarm, period, and carry.
+- interrupt-names: The interrupts should be labeled as "alarm", "period", and
+ "carry".
+- clocks: The functional clock source for the RTC controller must be listed
+ first (if exists). Additionally, potential clock counting sources are to be
+ listed.
+- clock-names: The functional clock must be labeled as "fck". Other clocks
+ may be named in accordance to the SoC hardware manuals.
+
+
+Example:
+rtc: rtc@fcff1000 {
+ compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
+ reg = <0xfcff1000 0x2e>;
+ interrupts = <GIC_SPI 276 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 277 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "alarm", "period", "carry";
+ clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
+ <&rtc_x3_clk>, <&extal_clk>;
+ clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
+};
--
2.11.0
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* [PATCH v3 3/7] ARM: dts: r7s72100: add rtc clock to device tree
From: Chris Brandt @ 2017-03-29 17:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, Geert Uytterhoeven
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
In-Reply-To: <20170329173035.67477-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Add the realtime clock functional clock source.
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
v2:
* changed "rtc0" to "rtc"
* added Reviewed-by
---
arch/arm/boot/dts/r7s72100.dtsi | 9 +++++++++
include/dt-bindings/clock/r7s72100-clock.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 34994afa9d15..6a1448be4e10 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -117,6 +117,15 @@
clock-output-names = "ostm0", "ostm1";
};
+ mstp6_clks: mstp6_clks@fcfe042c {
+ #clock-cells = <1>;
+ compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
+ reg = <0xfcfe042c 4>;
+ clocks = <&p0_clk>;
+ clock-indices = <R7S72100_CLK_RTC>;
+ clock-output-names = "rtc";
+ };
+
mstp7_clks: mstp7_clks@fcfe0430 {
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks";
diff --git a/include/dt-bindings/clock/r7s72100-clock.h b/include/dt-bindings/clock/r7s72100-clock.h
index cd2ed5194255..bc256d31099a 100644
--- a/include/dt-bindings/clock/r7s72100-clock.h
+++ b/include/dt-bindings/clock/r7s72100-clock.h
@@ -29,6 +29,9 @@
#define R7S72100_CLK_OSTM0 1
#define R7S72100_CLK_OSTM1 0
+/* MSTP6 */
+#define R7S72100_CLK_RTC 0
+
/* MSTP7 */
#define R7S72100_CLK_ETHER 4
--
2.11.0
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* [PATCH v3 4/7] ARM: dts: r7s72100: add RTC_X clock inputs to device tree
From: Chris Brandt @ 2017-03-29 17:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, Geert Uytterhoeven
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
In-Reply-To: <20170329173035.67477-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Add the RTC clocks to device tree. The frequencies must be fixed values
according to the hardware manual.
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/r7s72100.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 6a1448be4e10..632a6a481be8 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -51,6 +51,20 @@
clock-frequency = <0>;
};
+ rtc_x1_clk: rtc_x1 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ /* If clk present, value must be set by board to 32678 */
+ clock-frequency = <0>;
+ };
+
+ rtc_x3_clk: rtc_x3 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ /* If clk present, value must be set by board to 4000000 */
+ clock-frequency = <0>;
+ };
+
/* Fixed factor clocks */
b_clk: b {
#clock-cells = <0>;
--
2.11.0
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* [PATCH v3 5/7] ARM: dts: r7s72100: add rtc to device tree
From: Chris Brandt @ 2017-03-29 17:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, Geert Uytterhoeven
Cc: rtc-linux, devicetree, linux-renesas-soc, Chris Brandt
In-Reply-To: <20170329173035.67477-1-chris.brandt@renesas.com>
Add the realtime clock device node.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
* added interrupt-names
* added clock counting sources
* added clock-names "fck", "rtc_x1", "rtc_x3", "extal"
---
arch/arm/boot/dts/r7s72100.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 632a6a481be8..f74a8ec385b6 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -652,4 +652,18 @@
power-domains = <&cpg_clocks>;
status = "disabled";
};
+
+ rtc: rtc@fcff1000 {
+ compatible = "renesas,r7s72100-rtc", "renesas,sh-rtc";
+ reg = <0xfcff1000 0x2e>;
+ interrupts = <GIC_SPI 276 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 277 IRQ_TYPE_EDGE_RISING
+ GIC_SPI 278 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "alarm", "period", "carry";
+ clocks = <&mstp6_clks R7S72100_CLK_RTC>, <&rtc_x1_clk>,
+ <&rtc_x3_clk>, <&extal_clk>;
+ clock-names = "fck", "rtc_x1", "rtc_x3", "extal";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+ };
};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 6/7] ARM: dts: rskrza1: set rtc_x1 clock value
From: Chris Brandt @ 2017-03-29 17:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, Geert Uytterhoeven
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Chris Brandt
In-Reply-To: <20170329173035.67477-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Enable the 32.768 kHz RTC_X1 clock by setting the frequency value to
non-zero.
Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts b/arch/arm/boot/dts/r7s72100-rskrza1.dts
index 02b59c5b3c53..cab5857bfb41 100644
--- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
+++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
@@ -43,6 +43,10 @@
clock-frequency = <48000000>;
};
+&rtc_x1_clk {
+ clock-frequency = <32768>;
+};
+
&mtu2 {
status = "okay";
};
--
2.11.0
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply related
* [PATCH v3 7/7] ARM: dts: rskrza1: add rtc DT support
From: Chris Brandt @ 2017-03-29 17:30 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, Geert Uytterhoeven
Cc: rtc-linux, devicetree, linux-renesas-soc, Chris Brandt
In-Reply-To: <20170329173035.67477-1-chris.brandt@renesas.com>
Enable the realtime clock.
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
---
arch/arm/boot/dts/r7s72100-rskrza1.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/r7s72100-rskrza1.dts b/arch/arm/boot/dts/r7s72100-rskrza1.dts
index cab5857bfb41..72df20a04320 100644
--- a/arch/arm/boot/dts/r7s72100-rskrza1.dts
+++ b/arch/arm/boot/dts/r7s72100-rskrza1.dts
@@ -73,6 +73,10 @@
status = "okay";
};
+&rtc {
+ status = "okay";
+};
+
&scif2 {
status = "okay";
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 7/8] bus: brcmstb_gisb: add notifier handling
From: Doug Berger @ 2017-03-29 17:39 UTC (permalink / raw)
To: Mark Rutland
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA, james.morse-5wv7dgnIgG8,
mingo-DgEjT+Ai2ygdnm+yROfE0A,
sandeepa.s.prabhu-Re5JQEeQqe8AvxtiuMwx3w,
shijie.huang-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
olof-nZhT3qVonbNeoWH0uzbU5w, mirza.krak-Re5JQEeQqe8AvxtiuMwx3w,
suzuki.poulose-5wv7dgnIgG8, bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170329101357.GB23442@leverpostej>
On 03/29/2017 03:13 AM, Mark Rutland wrote:
snip
>> +/*
>> + * Dump out gisb errors on die or panic.
>> + */
>> +static int dump_gisb_error(struct notifier_block *self, unsigned long v,
>> + void *p)
>> +{
>> + struct brcmstb_gisb_arb_device *gdev;
>> +
>> + /* iterate over each GISB arb registered handlers */
>> + list_for_each_entry(gdev, &brcmstb_gisb_arb_device_list, next)
>> + brcmstb_gisb_arb_decode_addr(gdev, "async abort");
>> +
>> + return 0;
>
> I think this should be NOTIFY_OK.
>
I used dump_mem_limit() as a template and didn't catch this (work to
do...). Upon review I think I would prefer NOTIFY_DONE since this call
is opportunistic (i.e. it is taking the opportunity to check whether
additional diagnostic data is available to display) and has no interest
in affecting the overall handling of the event.
>> +}
>> +
>> +static struct notifier_block gisb_error_notifier = {
>> + .notifier_call = dump_gisb_error,
>> +};
>> +
>> static DEVICE_ATTR(gisb_arb_timeout, S_IWUSR | S_IRUGO,
>> gisb_arb_get_timeout, gisb_arb_set_timeout);
>>
>> @@ -408,6 +429,12 @@ static int __init brcmstb_gisb_arb_probe(struct platform_device *pdev)
>> board_be_handler = brcmstb_bus_error_handler;
>> #endif
>>
>> + if (list_is_singular(&brcmstb_gisb_arb_device_list)) {
>> + register_die_notifier(&gisb_error_notifier);
>> + atomic_notifier_chain_register(&panic_notifier_list,
>> + &gisb_error_notifier);
>
> I don't think this is quite right. A notifier_block can only be
> registered to one notifier chain at a time, and this has the potential
> to corrupt both chains.
>
A VERY good point thanks for pointing this out.
> I also think you only need to register the panic notifier. An SError
> should always result in a panic.
>
That was my initial thought as well. However, testing revealed that the
bad mode Oops actually exits the user space process and doesn't reach
the panic so there was no helpful diagnostic message. This may be in
line with your comments about insufficient fatality of failures in PATCH
v2 6/8, but it actually is more in line with our desired behavior for
the aborted write. Setting the notify on die gave us the result we are
looking for, but as noted above I should have created a separate notifier.
I had hoped that the same approach (i.e. die notifier) would remove the
need for PATCH v2 6/8 as well, but I found that the Unhandled fault
error didn't actually die from user mode.
> Thanks,
> Mark.
>
Thank you for your help with this,
Doug
--
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: [RFC PATCH] of: Fix DMA configuration for non-DT masters
From: Robin Murphy @ 2017-03-29 17:42 UTC (permalink / raw)
To: Oza Oza
Cc: Linux IOMMU, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAMSpPPcSWxua_6ECZd4iEbTiAYk-KtapBDcOUxNdGaQkFF-LOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 29/03/17 06:46, Oza Oza wrote:
> On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>> On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
>>> For PCI masters not represented in DT, we pass the OF node of their
>>> associated host bridge to of_dma_configure(), such that they can inherit
>>> the appropriate DMA configuration from whatever is described there.
>>> Unfortunately, whilst this has worked for the "dma-coherent" property,
>>> it turns out to miss the case where the host bridge node has a non-empty
>>> "dma-ranges", since nobody is expecting the 'device' to be a bus itself.
>>>
>>> It transpires, though, that the de-facto interface since the prototype
>>> change in 1f5c69aa51f9 ("of: Move of_dma_configure() to device.c to help
>>> re-use") is very clear-cut: either the master_np argument is redundant
>>> with dev->of_node, or dev->of_node is NULL and master_np is the relevant
>>> parent bus. Let's ratify that behaviour, then teach the whole
>>> of_dma_configure() pipeline to cope with both cases properly.
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
[...]
>>
>> pci and memory mapped device world is different.
???
No they aren't. There is nothing magic about PCI. PCI *is* a
memory-mapped bus.
The only PCI-specific aspect here is the Linux code path which passes a
host controller node into of_dma_configure() where the latter expects a
node for the actual endpoint device. It managed to work for
"dma-coherent", because that may appear either directly on a device node
or on any of its parent buses, but "dma-ranges" is *only* valid for DT
nodes representing buses, thus reveals that using a parent bus to stand
in for a device isn't actually correct. I only posted that horrible hack
patch to prove the point that having a child node to represent the
actual device is indeed sufficient to make of_dma_configure() work
correctly for PCI masters as-is (modulo the other issues).
> of course if you talk
>> from iommu perspective, all the master are same for IOMMU
I don't understand what you mean by that. There's nothing about IOMMUs
here, it's purely about parsing DT properties correctly.
>> but the original intention of the patch is to try to solve 2 problems.
>> please refer to https://lkml.org/lkml/2017/3/29/10
One patch should not solve two separate problems anyway. Taking a step
back, there are at least 3 things that this discussion has brought up:
1) The way in which we call of_dma_configure() for PCI devices causes
the "dma-ranges" property on PCI host controllers to be ignored.
2) of_dma_get_range() only considers the first entry in any "dma-ranges"
property.
3) When of_dma_configure() does set a DMA mask, there is nothing on
arm64 and other architectures to prevent drivers overriding that with a
wider mask later.
Those are 3 separate problems, to solve with 3 or more separate patches,
and I have deliberately put the second and third to one side for the
moment. This patch fixes problem 1.
>> 1) expose generic API for pci world clients to configure their
>> dma-ranges. right now there is none.
>> 2) same API can be used by IOMMU to derive dma_mask.
>>
>> while the current patch posted to handle dma-ranges for both memory
>> mapped and pci devices, which I think is overdoing.
No, of_dma_configure() handles the "dma-ranges" property as it is
defined in the DT spec to describe the mapping between a child bus
address space and a parent bus address space. Whether those
memory-mapped parent and child buses are PCI, ISA, AMBA, HyperTransport,
or anything else is irrelevant other than for the encoding of the
address specifiers. All this patch does is sort out the cases where we
have a real device node to start at, from the cases where we don't and
so start directly at the device's parent bus node instead.
>> besides we have different configuration of dma-ranges based on iommu
>> is enabled or not enabled.
That doesn't sound right, unless you mean the firmware actually programs
the host controller's AXI bridge differently for system configurations
where the IOMMU is expected to be used or not? (and even then, I don't
really see why it would be necessary to do that...)
>> #define PCIE_DMA_RANGES dma-ranges = <0x43000000 0x00 0x80000000 0x00
>> 0x80000000 0x00 0x80000000 \
>> 0x43000000 0x08 0x00000000 0x08
>> 0x00000000 0x08 0x00000000 \
>> 0x43000000 0x80 0x00000000 0x80
>> 0x00000000 0x40 0x00000000>;
>> Not sure if this patch will consider above dma-ranges.
>>
>> my suggestion is to leave existing of_dma_get_range as is, and have
>> new function for pci world as discussed in
>> please refer to https://lkml.org/lkml/2017/3/29/10
And then we keep adding new functions to do the exact same thing for
every other discoverable bus type whose bridge is be described in DT? I
fail to see how that is in any way better than simply fixing the
existing code to work as it was intended to.
of_dma_get_ranges() uses of_translate_dma_address() just the same way as
existing PowerPC PCI code does, which further disproves your assertion
that parsing PCI addresses is somehow special - it's really only a
matter of getting the right number of address cells in order to to read
a child address to give to of_translate_dma_address() in the first
place. Incidentally, I now notice that the proposed
of_pci_get_dma_ranges() is incomplete as it doesn't use
of_translate_dma_address() or otherwise traverse upwards through the
dma-ranges of any further parent buses.
>>
>> Regards,
>> Oza.
>
> also I see that, in case of multiple ranges of_dma_get_range doesnt handle that.
> and also it is not meant to handle.
Yes, the existing code doesn't handle multiple dma-ranges entries,
because nobody's had the need to implement that so far, and this patch
does not change that because it's fixing a separate problem.
Now, of course of_dma_get_range() *should* be capable of handling
multiple entries regardless of this patch, and I'm going to write *that*
patch right now (it's going to be a case of adding a handful of lines
which probably won't even conflict with this one at all). If we had a
bunch of different range parsing functions, we'd then have to duplicate
the equivalent logic across all of them, which is clearly undesirable
when it can easily be avoided altogether.
Robin.
> so with this patch will return wrong size and hence wrong dma_mask.
> having said, I think it is better to separate pci world dma-ranges
> function on of_pci.c
>
> for which my discussion with Rob already, (same thread)
> https://lkml.org/lkml/2017/3/29/10
> Waiting for Rob's viewpoint on this.
>
>
> Regards,
> Oza.
>
--
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
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