* Re: [PATCH v2 3/6] arm64: dts: amlogic: g12: add temperature sensor
From: guillaume La Roque @ 2019-08-05 9:41 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <CAFBinCBYPiLgmTNk+7Db3EPSPePwbnAshCbomYPXWdse8i0oJw@mail.gmail.com>
hi Martin,
thanks for comments i will fix in v3.
guillaume
On 8/3/19 7:52 PM, Martin Blumenstingl wrote:
> Hi Guillaume,
>
> On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
> <glaroque@baylibre.com> wrote:
>> Add cpu and ddr temperature sensors for G12 Socs
>>
>> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> with the nit-pick below addressed:
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
>> ---
>> .../boot/dts/amlogic/meson-g12-common.dtsi | 22 +++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
>> index 06e186ca41e3..7f862a3490fb 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
>> @@ -1353,6 +1353,28 @@
>> };
>> };
>>
>> + cpu_temp: temperature-sensor@34800 {
>> + compatible = "amlogic,g12-cpu-thermal",
>> + "amlogic,g12-thermal";
>> + reg = <0x0 0x34800 0x0 0x50>;
>> + interrupts = <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&clkc CLKID_TS>;
>> + status = "okay";
> I believe nodes are enabled automatically if they don't have a status property
>
>> + #thermal-sensor-cells = <0>;
>> + amlogic,ao-secure = <&sec_AO>;
>> + };
>> +
>> + ddr_temp: temperature-sensor@34c00 {
>> + compatible = "amlogic,g12-ddr-thermal",
>> + "amlogic,g12-thermal";
>> + reg = <0x0 0x34c00 0x0 0x50>;
>> + interrupts = <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&clkc CLKID_TS>;
>> + status = "okay";
> same here
>
>
> Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] gpio: mpc8xxx: Add new platforms GPIO DT node description
From: Alexander Stein @ 2019-08-05 9:47 UTC (permalink / raw)
To: Hui Song
Cc: linux-devel, linux-gpio, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190805091432.9656-2-hui.song_1@nxp.com>
On Monday, August 5, 2019, 11:14:32 AM CEST Hui Song wrote:
> From: Song Hui <hui.song_1@nxp.com>
>
> Update the NXP GPIO node dt-binding file for QorIQ and
> Layerscape platforms, and add one more example with
> ls1028a GPIO node.
>
> Signed-off-by: Song Hui <hui.song_1@nxp.com>
> ---
> Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
> index 69d4616..fbe6d75 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
> @@ -28,7 +28,7 @@ gpio0: gpio@1100 {
> Example of gpio-controller node for a ls2080a SoC:
^^^^^^^ ^^^^^^^
This is an example for ls2080a...
> gpio0: gpio@2300000 {
> - compatible = "fsl,ls2080a-gpio", "fsl,qoriq-gpio";
> + compatible = "fsl,ls1028a-gpio","fsl,ls2080a-gpio", "fsl,qoriq-gpio";
so I doubt there should be a ls1028a compatible here though.
> reg = <0x0 0x2300000 0x0 0x10000>;
> interrupts = <0 36 0x4>; /* Level high type */
> gpio-controller;
Best regards,
Alexander
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/cache: fix -Woverride-init compiler warnings
From: Will Deacon @ 2019-08-05 9:52 UTC (permalink / raw)
To: Qian Cai; +Cc: mark.rutland, catalin.marinas, linux-kernel, linux-arm-kernel
In-Reply-To: <1564759944-2197-1-git-send-email-cai@lca.pw>
On Fri, Aug 02, 2019 at 11:32:24AM -0400, Qian Cai wrote:
> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> VIVT I-caches") introduced some compiation warnings from GCC,
>
> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VIPT] = "VIPT",
> ^~~~~~
> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> 'icache_policy_str[2]')
> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_PIPT] = "PIPT",
> ^~~~~~
> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> 'icache_policy_str[3]')
> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> overwritten [-Woverride-init]
> [ICACHE_POLICY_VPIPT] = "VPIPT",
> ^~~~~~~
> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> 'icache_policy_str[0]')
>
> because it initializes icache_policy_str[0 ... 3] twice.
>
> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/arm64/kernel/cpuinfo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 876055e37352..193b38da8d96 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -34,10 +34,10 @@
> static struct cpuinfo_arm64 boot_cpu_data;
>
> static char *icache_policy_str[] = {
> - [0 ... ICACHE_POLICY_PIPT] = "RESERVED/UNKNOWN",
> + [ICACHE_POLICY_VPIPT] = "VPIPT",
> + [ICACHE_POLICY_VPIPT + 1] = "RESERVED/UNKNOWN",
> [ICACHE_POLICY_VIPT] = "VIPT",
> [ICACHE_POLICY_PIPT] = "PIPT",
> - [ICACHE_POLICY_VPIPT] = "VPIPT",
I really don't like this patch. Using "[0 ... MAXIDX] = <default>" is a
useful idiom and I think the code is more error-prone the way you have
restructured it.
Why are you passing -Woverride-init to the compiler anyway? There's only
one Makefile that references that option, and it's specific to a pinctrl
driver.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
From: Michal Simek @ 2019-08-05 9:53 UTC (permalink / raw)
To: Luis Araneda, Russell King - ARM Linux admin
Cc: Michal Simek, linux-arm-kernel, linux-kernel
In-Reply-To: <CAHbBuxoMBiq23Rkt7-jm42O4ePY=23ZsgNEVf3UJKQ2Dg+3fbg@mail.gmail.com>
On 31. 07. 19 6:12, Luis Araneda wrote:
> Hi Russell,
>
> Thanks for reviewing.
>
> On Tue, Jul 30, 2019 at 6:47 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
>>
>> On Tue, Jul 30, 2019 at 12:43:26AM -0400, Luis Araneda wrote:
>>> This fixes a kernel panic (read overflow) on memcpy when
>>> FORTIFY_SOURCE is enabled.
> [...]
>>
>> I'm not convinced that this is correct. It looks like
>> zynq_secondary_trampoline could be either ARM or Thumb code - there is
>> no .arm directive before it. If it's ARM code, then this is fine. If
>> Thumb code, then zynq_secondary_trampoline will be offset by one, and
>> we will miss copying the first byte of code.
>
> You're right, I tested what happens if the zynq_secondary_trampoline
> is ARM or Thumb by editing the file where it's defined, headsmp.S
>
> When the .arm directive is used, the CPU is brought-up correctly,
> but if I use .thumb, I get the following message (no panic):
>> CPU1: failed to come online
>
> This seems unrelated to solving the panic, as the message
> even appears with memcpy and FORTIFY_SOURCE disabled.
>
> I could add the .arm directive to headsmp.S
> Is that your expected solution?
> Should that change be on a separate commit?
>
> I'd like to know Michal's opinion, as he wrote the code.
>
There are two things together. Thanks Russel to pointing to it.
1. How to support SMP in thumb2 mode?
Adding .arm mode to headsmp.S which ensure that cpu starts in proper
mode and correct code size is copied.
And also point to secondary_startup_arm in zynq_boot_secondary to switch
cpu from arm to thumb mode.
2. And the second is this patch to fix FORTIFY_SOURCE.
Feel free to create the first patch too or I will do it myself.
Thanks,
Michal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 6/6] ARM: dts: mmp2: add OLPC XO 1.75 machine
From: Lubomir Rintel @ 2019-08-05 9:56 UTC (permalink / raw)
To: Pavel Machek
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring,
Olof Johansson, linux-arm-kernel
In-Reply-To: <20190803085824.GB8224@amd>
----- On Aug 3, 2019, at 10:58 AM, Pavel Machek pavel@ucw.cz wrote:
> On Fri 2019-08-02 12:33:26, Lubomir Rintel wrote:
>> This is a fairly complete description of an OLPC XO 1.75 laptop.
>> What's missing for now is the GPU, LCD controller, DCON, the panel and
>> audio.
>
> Ok, but I need GPU/LCD/panel... that's my only output. Is video
> expected to work in 5.2? Does the firmware pass right device tree,
> including the GPU/LCD/DCON?
The firmware (and the dts) uses a simple-framebuffer. You won't get
any nifty features, but you'll get a framebuffer.
Hopefully we'll get a proper DRM video soon. The status is roughly
as follows:
LCDC: potentially supported by the Armada DRM driver. Patches sent to
Russell King some months ago, not there yet. I'd prefer not to nag him.
DCON: Russell dislikes the idea of a DRM bridge, DRM maintainers prefer
if the driver was not a DRM encoder driver. This seems to require
quite some work to fix [1].
[1] https://www.spinics.net/lists/dri-devel/msg201927.html
GPU: supported by the etnaviv driver, good enough for 2D acceleration
to work with xorg-x11-video-armada driver. 3D (weston and mutter alike)
is broken. To add this to the device tree, the clock and power needs
to be figured out.
> Is there config somewhere I could use?
>
> Thanks a lot,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
From: Krzysztof Kozlowski @ 2019-08-05 9:56 UTC (permalink / raw)
To: Artur Świgoń
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
Bartłomiej Żołnierkiewicz, Seung Woo Kim,
linux-kernel@vger.kernel.org, dri-devel, Inki Dae, Chanwoo Choi,
myungjoo.ham, georgi.djakov, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <bda10bcc66aae96355e74c4739229d72bcc95b0d.camel@partner.samsung.com>
On Wed, 31 Jul 2019 at 15:00, Artur Świgoń <a.swigon@partner.samsung.com> wrote:
>
> Hi,
>
> On Wed, 2019-07-24 at 21:07 +0200, Krzysztof Kozlowski wrote:
> > On Tue, Jul 23, 2019 at 02:20:06PM +0200, Artur Świgoń wrote:
> > > This patch adds a new static function, exynos_bus_profile_init(), extracted
> > > from exynos_bus_probe().
> > >
> > > Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> > > ---
> > > drivers/devfreq/exynos-bus.c | 106 ++++++++++++++++++++---------------
> > > 1 file changed, 60 insertions(+), 46 deletions(-)
> > >
> > > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > > index d9f377912c10..d8f1efaf2d49 100644
> > > --- a/drivers/devfreq/exynos-bus.c
> > > +++ b/drivers/devfreq/exynos-bus.c
> > > @@ -372,12 +372,69 @@ static int exynos_bus_parse_of(struct device_node *np,
> > > return ret;
> > > }
> > >
> > > +static int exynos_bus_profile_init(struct exynos_bus *bus,
> > > + struct devfreq_dev_profile *profile)
> > > +{
> > > + struct device *dev = bus->dev;
> > > + struct devfreq_simple_ondemand_data *ondemand_data;
> > > + int ret;
> > > +
> > > + /* Initialize the struct profile and governor data for parent device */
> > > + profile->polling_ms = 50;
> > > + profile->target = exynos_bus_target;
> > > + profile->get_dev_status = exynos_bus_get_dev_status;
> > > + profile->exit = exynos_bus_exit;
> > > +
> > > + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > > + if (!ondemand_data) {
> > > + ret = -ENOMEM;
> > > + goto err;
> >
> > Just return proper error code. Less lines, obvious code since you do not
> > have any cleanup in error path.
>
> I was advised to avoid modifying code being moved (in one patch). I do make
> changes in these places in patch 04/11, i.e. change the original label 'err' to
> 'out'. What's your opinion on making the proposed changes to patches 01 and 02
> (s/goto err/return ret/) in patch 04 instead?
Yes, you're right. I also prefer not to touch moved code.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V4 0/3] mmc: mmci: add busy detect for stm32 sdmmc variant
From: Ludovic Barre @ 2019-08-05 9:56 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: devicetree, Alexandre Torgue, linux-mmc, linux-kernel,
srinivas.kandagatla, Ludovic Barre, Maxime Coquelin, linux-stm32,
linux-arm-kernel
From: Ludovic Barre <ludovic.barre@st.com>
This patch series adds busy detect for stm32 sdmmc variant.
Some adaptations are required:
-On sdmmc the data timer is started on data transfert
and busy state, so we must add hardware busy timeout support.
-Add busy_complete callback at mmci_host_ops to allow to define
a specific busy completion by variant.
-Add sdmmc busy_complete calback.
V4:
-Re-work with busy_complete callback
-In series, move "mmc: mmci: add hardware busy timeout feature" in
first to simplify busy_complete prototype with err_msk parameter.
V3:
-rebase on latest mmc next
-replace re-read by status parameter.
V2:
-mmci_cmd_irq cleanup in separate patch.
-simplify the busy_detect_flag exclude
-replace sdmmc specific comment in
"mmc: mmci: avoid fake busy polling in mmci_irq"
to focus on common behavior
Ludovic Barre (3):
mmc: mmci: add hardware busy timeout feature
mmc: mmci: add busy_complete callback
mmc: mmci: sdmmc: add busy_complete callback
drivers/mmc/host/mmci.c | 178 +++++++++++++++++-----------
drivers/mmc/host/mmci.h | 7 +-
drivers/mmc/host/mmci_stm32_sdmmc.c | 38 ++++++
3 files changed, 151 insertions(+), 72 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V4 2/3] mmc: mmci: add busy_complete callback
From: Ludovic Barre @ 2019-08-05 9:56 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: devicetree, Alexandre Torgue, linux-mmc, linux-kernel,
srinivas.kandagatla, Ludovic Barre, Maxime Coquelin, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190805095626.25998-1-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
This patch adds busy_completion callback at mmci_host_ops
to allow to define a specific busy completion by variant.
The legacy code corresponding to busy completion used
by ux500 variants is moved to ux500_busy_complete function.
The busy_detect boolean property is replaced by
busy_complete callback definition.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 140 +++++++++++++++++++++-------------------
drivers/mmc/host/mmci.h | 3 +-
2 files changed, 75 insertions(+), 68 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index e79c9148af84..17948615d4a5 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -47,6 +47,7 @@
#define DRIVER_NAME "mmci-pl18x"
static void mmci_variant_init(struct mmci_host *host);
+static void ux500_variant_init(struct mmci_host *host);
static void ux500v2_variant_init(struct mmci_host *host);
static unsigned int fmax = 515633;
@@ -178,7 +179,6 @@ static struct variant_data variant_ux500 = {
.f_max = 100000000,
.signal_direction = true,
.pwrreg_clkgate = true,
- .busy_detect = true,
.busy_dpsm_flag = MCI_DPSM_ST_BUSYMODE,
.busy_detect_flag = MCI_ST_CARDBUSY,
.busy_detect_mask = MCI_ST_BUSYENDMASK,
@@ -187,7 +187,7 @@ static struct variant_data variant_ux500 = {
.irq_pio_mask = MCI_IRQ_PIO_MASK,
.start_err = MCI_STARTBITERR,
.opendrain = MCI_OD,
- .init = mmci_variant_init,
+ .init = ux500_variant_init,
};
static struct variant_data variant_ux500v2 = {
@@ -211,7 +211,6 @@ static struct variant_data variant_ux500v2 = {
.f_max = 100000000,
.signal_direction = true,
.pwrreg_clkgate = true,
- .busy_detect = true,
.busy_dpsm_flag = MCI_DPSM_ST_BUSYMODE,
.busy_detect_flag = MCI_ST_CARDBUSY,
.busy_detect_mask = MCI_ST_BUSYENDMASK,
@@ -613,6 +612,67 @@ static u32 ux500v2_get_dctrl_cfg(struct mmci_host *host)
return MCI_DPSM_ENABLE | (host->data->blksz << 16);
}
+static bool ux500_busy_complete(struct mmci_host *host, u32 status, u32 err_msk)
+{
+ void __iomem *base = host->base;
+
+ /*
+ * Before unmasking for the busy end IRQ, confirm that the
+ * command was sent successfully. To keep track of having a
+ * command in-progress, waiting for busy signaling to end,
+ * store the status in host->busy_status.
+ *
+ * Note that, the card may need a couple of clock cycles before
+ * it starts signaling busy on DAT0, hence re-read the
+ * MMCISTATUS register here, to allow the busy bit to be set.
+ * Potentially we may even need to poll the register for a
+ * while, to allow it to be set, but tests indicates that it
+ * isn't needed.
+ */
+ if (!host->busy_status && !(status & err_msk) &&
+ (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
+ writel(readl(base + MMCIMASK0) |
+ host->variant->busy_detect_mask,
+ base + MMCIMASK0);
+
+ host->busy_status = status & (MCI_CMDSENT | MCI_CMDRESPEND);
+ return false;
+ }
+
+ /*
+ * If there is a command in-progress that has been successfully
+ * sent, then bail out if busy status is set and wait for the
+ * busy end IRQ.
+ *
+ * Note that, the HW triggers an IRQ on both edges while
+ * monitoring DAT0 for busy completion, but there is only one
+ * status bit in MMCISTATUS for the busy state. Therefore
+ * both the start and the end interrupts needs to be cleared,
+ * one after the other. So, clear the busy start IRQ here.
+ */
+ if (host->busy_status &&
+ (status & host->variant->busy_detect_flag)) {
+ writel(host->variant->busy_detect_mask, base + MMCICLEAR);
+ return false;
+ }
+
+ /*
+ * If there is a command in-progress that has been successfully
+ * sent and the busy bit isn't set, it means we have received
+ * the busy end IRQ. Clear and mask the IRQ, then continue to
+ * process the command.
+ */
+ if (host->busy_status) {
+ writel(host->variant->busy_detect_mask, base + MMCICLEAR);
+
+ writel(readl(base + MMCIMASK0) &
+ ~host->variant->busy_detect_mask, base + MMCIMASK0);
+ host->busy_status = 0;
+ }
+
+ return true;
+}
+
/*
* All the DMA operation mode stuff goes inside this ifdef.
* This assumes that you have a generic DMA device interface,
@@ -956,9 +1016,16 @@ void mmci_variant_init(struct mmci_host *host)
host->ops = &mmci_variant_ops;
}
+void ux500_variant_init(struct mmci_host *host)
+{
+ host->ops = &mmci_variant_ops;
+ host->ops->busy_complete = ux500_busy_complete;
+}
+
void ux500v2_variant_init(struct mmci_host *host)
{
host->ops = &mmci_variant_ops;
+ host->ops->busy_complete = ux500_busy_complete;
host->ops->get_datactrl_cfg = ux500v2_get_dctrl_cfg;
}
@@ -1242,68 +1309,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
return;
/* Handle busy detection on DAT0 if the variant supports it. */
- if (busy_resp && host->variant->busy_detect) {
-
- /*
- * Before unmasking for the busy end IRQ, confirm that the
- * command was sent successfully. To keep track of having a
- * command in-progress, waiting for busy signaling to end,
- * store the status in host->busy_status.
- *
- * Note that, the card may need a couple of clock cycles before
- * it starts signaling busy on DAT0, hence re-read the
- * MMCISTATUS register here, to allow the busy bit to be set.
- * Potentially we may even need to poll the register for a
- * while, to allow it to be set, but tests indicates that it
- * isn't needed.
- */
- if (!host->busy_status && !(status & err_msk) &&
- (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
-
- writel(readl(base + MMCIMASK0) |
- host->variant->busy_detect_mask,
- base + MMCIMASK0);
-
- host->busy_status =
- status & (MCI_CMDSENT|MCI_CMDRESPEND);
- return;
- }
-
- /*
- * If there is a command in-progress that has been successfully
- * sent, then bail out if busy status is set and wait for the
- * busy end IRQ.
- *
- * Note that, the HW triggers an IRQ on both edges while
- * monitoring DAT0 for busy completion, but there is only one
- * status bit in MMCISTATUS for the busy state. Therefore
- * both the start and the end interrupts needs to be cleared,
- * one after the other. So, clear the busy start IRQ here.
- */
- if (host->busy_status &&
- (status & host->variant->busy_detect_flag)) {
- writel(host->variant->busy_detect_mask,
- host->base + MMCICLEAR);
+ if (busy_resp && host->ops->busy_complete)
+ if (!host->ops->busy_complete(host, status, err_msk))
return;
- }
-
- /*
- * If there is a command in-progress that has been successfully
- * sent and the busy bit isn't set, it means we have received
- * the busy end IRQ. Clear and mask the IRQ, then continue to
- * process the command.
- */
- if (host->busy_status) {
-
- writel(host->variant->busy_detect_mask,
- host->base + MMCICLEAR);
-
- writel(readl(base + MMCIMASK0) &
- ~host->variant->busy_detect_mask,
- base + MMCIMASK0);
- host->busy_status = 0;
- }
- }
host->cmd = NULL;
@@ -1544,7 +1552,7 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
* clear the corresponding IRQ.
*/
status &= readl(host->base + MMCIMASK0);
- if (host->variant->busy_detect)
+ if (host->ops->busy_complete)
writel(status & ~host->variant->busy_detect_mask,
host->base + MMCICLEAR);
else
@@ -1971,7 +1979,7 @@ static int mmci_probe(struct amba_device *dev,
/*
* Enable busy detection.
*/
- if (variant->busy_detect) {
+ if (host->ops->busy_complete) {
u32 max_busy_timeout = 0;
mmci_ops.card_busy = mmci_card_busy;
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 8f86130af566..03eb21f1c258 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -289,7 +289,6 @@ struct mmci_host;
* @f_max: maximum clk frequency supported by the controller.
* @signal_direction: input/out direction of bus signals can be indicated
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
- * @busy_detect: true if the variant supports busy detection on DAT0.
* @busy_timeout: true if the variant starts data timer when the DPSM
* enter in Wait_R or Busy state.
* @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
@@ -337,7 +336,6 @@ struct variant_data {
u32 f_max;
u8 signal_direction:1;
u8 pwrreg_clkgate:1;
- u8 busy_detect:1;
u8 busy_timeout:1;
u32 busy_dpsm_flag;
u32 busy_detect_flag;
@@ -372,6 +370,7 @@ struct mmci_host_ops {
void (*dma_error)(struct mmci_host *host);
void (*set_clkreg)(struct mmci_host *host, unsigned int desired);
void (*set_pwrreg)(struct mmci_host *host, unsigned int pwr);
+ bool (*busy_complete)(struct mmci_host *host, u32 status, u32 err_msk);
};
struct mmci_host {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V4 1/3] mmc: mmci: add hardware busy timeout feature
From: Ludovic Barre @ 2019-08-05 9:56 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: devicetree, Alexandre Torgue, linux-mmc, linux-kernel,
srinivas.kandagatla, Ludovic Barre, Maxime Coquelin, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190805095626.25998-1-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
In some variants, the data timer starts and decrements
when the DPSM enters in Wait_R or Busy state
(while data transfer or MMC_RSP_BUSY), and generates a
data timeout error if the counter reach 0.
-Define max_busy_timeout (in ms) according to clock.
-Set data timer register if the command has rsp_busy flag.
If busy_timeout is not defined by framework, the busy
length after Data Burst is defined as 1 second
(refer: 4.6.2.2 Write of sd specification part1 v6-0).
-Add MCI_DATATIMEOUT error management in mmci_cmd_irq.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 37 ++++++++++++++++++++++++++++++++-----
drivers/mmc/host/mmci.h | 3 +++
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 4c35e7609c89..e79c9148af84 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -1078,6 +1078,7 @@ static void
mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
{
void __iomem *base = host->base;
+ unsigned long long clks = 0;
dev_dbg(mmc_dev(host->mmc), "op %02x arg %08x flags %08x\n",
cmd->opcode, cmd->arg, cmd->flags);
@@ -1100,6 +1101,19 @@ mmci_start_command(struct mmci_host *host, struct mmc_command *cmd, u32 c)
else
c |= host->variant->cmdreg_srsp;
}
+
+ if (host->variant->busy_timeout && !cmd->data) {
+ if (cmd->flags & MMC_RSP_BUSY) {
+ if (!cmd->busy_timeout)
+ cmd->busy_timeout = 1000;
+
+ clks = (unsigned long long)cmd->busy_timeout;
+ clks *= host->cclk;
+ do_div(clks, MSEC_PER_SEC);
+ }
+ writel_relaxed(clks, host->base + MMCIDATATIMER);
+ }
+
if (/*interrupt*/0)
c |= MCI_CPSM_INTERRUPT;
@@ -1206,6 +1220,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
{
void __iomem *base = host->base;
bool sbc, busy_resp;
+ u32 err_msk;
if (!cmd)
return;
@@ -1218,8 +1233,12 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
* handling. Note that we tag on any latent IRQs postponed
* due to waiting for busy status.
*/
- if (!((status|host->busy_status) &
- (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT|MCI_CMDSENT|MCI_CMDRESPEND)))
+ err_msk = MCI_CMDCRCFAIL | MCI_CMDTIMEOUT;
+ if (host->variant->busy_timeout && busy_resp)
+ err_msk |= MCI_DATATIMEOUT;
+
+ if (!((status | host->busy_status) &
+ (err_msk | MCI_CMDSENT | MCI_CMDRESPEND)))
return;
/* Handle busy detection on DAT0 if the variant supports it. */
@@ -1238,8 +1257,7 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
* while, to allow it to be set, but tests indicates that it
* isn't needed.
*/
- if (!host->busy_status &&
- !(status & (MCI_CMDCRCFAIL|MCI_CMDTIMEOUT)) &&
+ if (!host->busy_status && !(status & err_msk) &&
(readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) {
writel(readl(base + MMCIMASK0) |
@@ -1293,6 +1311,9 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
cmd->error = -ETIMEDOUT;
} else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
cmd->error = -EILSEQ;
+ } else if (host->variant->busy_timeout && busy_resp &&
+ status & MCI_DATATIMEOUT) {
+ cmd->error = -ETIMEDOUT;
} else {
cmd->resp[0] = readl(base + MMCIRESPONSE0);
cmd->resp[1] = readl(base + MMCIRESPONSE1);
@@ -1951,6 +1972,8 @@ static int mmci_probe(struct amba_device *dev,
* Enable busy detection.
*/
if (variant->busy_detect) {
+ u32 max_busy_timeout = 0;
+
mmci_ops.card_busy = mmci_card_busy;
/*
* Not all variants have a flag to enable busy detection
@@ -1960,7 +1983,11 @@ static int mmci_probe(struct amba_device *dev,
mmci_write_datactrlreg(host,
host->variant->busy_dpsm_flag);
mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
- mmc->max_busy_timeout = 0;
+
+ if (variant->busy_timeout)
+ max_busy_timeout = ~0UL / (mmc->f_max / MSEC_PER_SEC);
+
+ mmc->max_busy_timeout = max_busy_timeout;
}
/* Prepare a CMD12 - needed to clear the DPSM on some variants. */
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 4f071bd34e59..8f86130af566 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -290,6 +290,8 @@ struct mmci_host;
* @signal_direction: input/out direction of bus signals can be indicated
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
* @busy_detect: true if the variant supports busy detection on DAT0.
+ * @busy_timeout: true if the variant starts data timer when the DPSM
+ * enter in Wait_R or Busy state.
* @busy_dpsm_flag: bitmask enabling busy detection in the DPSM
* @busy_detect_flag: bitmask identifying the bit in the MMCISTATUS register
* indicating that the card is busy
@@ -336,6 +338,7 @@ struct variant_data {
u8 signal_direction:1;
u8 pwrreg_clkgate:1;
u8 busy_detect:1;
+ u8 busy_timeout:1;
u32 busy_dpsm_flag;
u32 busy_detect_flag;
u32 busy_detect_mask;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V4 3/3] mmc: mmci: sdmmc: add busy_complete callback
From: Ludovic Barre @ 2019-08-05 9:56 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: devicetree, Alexandre Torgue, linux-mmc, linux-kernel,
srinivas.kandagatla, Ludovic Barre, Maxime Coquelin, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190805095626.25998-1-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
This patch adds a specific busy_complete callback for sdmmc variant.
sdmmc has 2 status flags:
-busyd0: This is a hardware status flag (inverted value of d0 line).
it does not generate an interrupt.
-busyd0end: This indicates only end of busy following a CMD response.
On busy to Not busy changes, an interrupt is generated (if unmask)
and BUSYD0END status flag is set. Status flag is cleared by writing
corresponding interrupt clear bit in MMCICLEAR.
The legacy busy completion monitors step by step the busy progression
start/in-progress/end. On sdmmc variant, the monitoring of busy steps
is difficult and not adapted (the software can miss a step and locks
the monitoring), the sdmmc has just need to wait the busyd0end bit
without monitoring all the changes.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 3 +++
drivers/mmc/host/mmci.h | 1 +
drivers/mmc/host/mmci_stm32_sdmmc.c | 38 +++++++++++++++++++++++++++++
3 files changed, 42 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 17948615d4a5..2751415d0fd1 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -263,6 +263,9 @@ static struct variant_data variant_stm32_sdmmc = {
.datalength_bits = 25,
.datactrl_blocksz = 14,
.stm32_idmabsize_mask = GENMASK(12, 5),
+ .busy_timeout = true,
+ .busy_detect_flag = MCI_STM32_BUSYD0,
+ .busy_detect_mask = MCI_STM32_BUSYD0ENDMASK,
.init = sdmmc_variant_init,
};
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 03eb21f1c258..64ae7720477c 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -167,6 +167,7 @@
#define MCI_ST_CARDBUSY (1 << 24)
/* Extended status bits for the STM32 variants */
#define MCI_STM32_BUSYD0 BIT(20)
+#define MCI_STM32_BUSYD0END BIT(21)
#define MMCICLEAR 0x038
#define MCI_CMDCRCFAILCLR (1 << 0)
diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
index 8e83ae6920ae..bb5499cc9e81 100644
--- a/drivers/mmc/host/mmci_stm32_sdmmc.c
+++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
@@ -282,6 +282,43 @@ static u32 sdmmc_get_dctrl_cfg(struct mmci_host *host)
return datactrl;
}
+bool sdmmc_busy_complete(struct mmci_host *host, u32 status, u32 err_msk)
+{
+ void __iomem *base = host->base;
+ u32 busy_d0, busy_d0end, mask;
+
+ mask = readl_relaxed(base + MMCIMASK0);
+ busy_d0end = readl_relaxed(base + MMCISTATUS) & MCI_STM32_BUSYD0END;
+ busy_d0 = readl_relaxed(base + MMCISTATUS) & MCI_STM32_BUSYD0;
+
+ /* complete if there is an error or busy_d0end */
+ if ((status & err_msk) || busy_d0end)
+ goto complete;
+
+ /*
+ * On response the busy signaling is reflected in the BUSYD0 flag.
+ * if busy_d0 is in-progress we must activate busyd0end interrupt
+ * to wait this completion. Else this request has no busy step.
+ */
+ if (busy_d0) {
+ if (!host->busy_status) {
+ writel_relaxed(mask | host->variant->busy_detect_mask,
+ base + MMCIMASK0);
+ host->busy_status = status &
+ (MCI_CMDSENT | MCI_CMDRESPEND);
+ }
+ return false;
+ }
+
+complete:
+ writel_relaxed(mask & ~host->variant->busy_detect_mask,
+ base + MMCIMASK0);
+ writel_relaxed(host->variant->busy_detect_mask, base + MMCICLEAR);
+ host->busy_status = 0;
+
+ return true;
+}
+
static struct mmci_host_ops sdmmc_variant_ops = {
.validate_data = sdmmc_idma_validate_data,
.prep_data = sdmmc_idma_prep_data,
@@ -292,6 +329,7 @@ static struct mmci_host_ops sdmmc_variant_ops = {
.dma_finalize = sdmmc_idma_finalize,
.set_clkreg = mmci_sdmmc_set_clkreg,
.set_pwrreg = mmci_sdmmc_set_pwrreg,
+ .busy_complete = sdmmc_busy_complete,
};
void sdmmc_variant_init(struct mmci_host *host)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Rafael J. Wysocki @ 2019-08-05 9:59 UTC (permalink / raw)
To: Ran Wang
Cc: Mark Rutland, Li Biwen, Len Brown, Greg Kroah-Hartman, linux-pm,
linux-kernel, Li Yang, devicetree, Rob Herring, Pavel Machek,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190724074722.12270-1-ran.wang_1@nxp.com>
On Wednesday, July 24, 2019 9:47:20 AM CEST Ran Wang wrote:
> Some user might want to go through all registered wakeup sources
> and doing things accordingly. For example, SoC PM driver might need to
> do HW programming to prevent powering down specific IP which wakeup
> source depending on. So add this API to help walk through all registered
> wakeup source objects on that list and return them one by one.
>
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> ---
> Change in v5:
> - Update commit message, add decription of walk through all wakeup
> source objects.
> - Add SCU protection in function wakeup_source_get_next().
> - Rename wakeup_source member 'attached_dev' to 'dev' and move it up
> (before wakeirq).
>
> Change in v4:
> - None.
>
> Change in v3:
> - Adjust indentation of *attached_dev;.
>
> Change in v2:
> - None.
>
> drivers/base/power/wakeup.c | 24 ++++++++++++++++++++++++
> include/linux/pm_wakeup.h | 3 +++
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index ee31d4f..2fba891 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -14,6 +14,7 @@
> #include <linux/suspend.h>
> #include <linux/seq_file.h>
> #include <linux/debugfs.h>
> +#include <linux/of_device.h>
> #include <linux/pm_wakeirq.h>
> #include <trace/events/power.h>
>
> @@ -226,6 +227,28 @@ void wakeup_source_unregister(struct wakeup_source *ws)
> }
> }
> EXPORT_SYMBOL_GPL(wakeup_source_unregister);
> +/**
> + * wakeup_source_get_next - Get next wakeup source from the list
> + * @ws: Previous wakeup source object, null means caller want first one.
> + */
> +struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws)
> +{
> + struct list_head *ws_head = &wakeup_sources;
> + struct wakeup_source *next_ws = NULL;
> + int idx;
> +
> + idx = srcu_read_lock(&wakeup_srcu);
> + if (ws)
> + next_ws = list_next_or_null_rcu(ws_head, &ws->entry,
> + struct wakeup_source, entry);
> + else
> + next_ws = list_entry_rcu(ws_head->next,
> + struct wakeup_source, entry);
> + srcu_read_unlock(&wakeup_srcu, idx);
> +
This is incorrect.
The SRCU cannot be unlocked until the caller of this is done
with the object returned by it, or that object can be freed
while it is still being accessed.
Besides, this patch conflicts with some general wakeup sources
changes in the works, so it needs to be deferred and rebased on
top of those changes.
> + return next_ws;
> +}
> +EXPORT_SYMBOL_GPL(wakeup_source_get_next);
>
> /**
> * device_wakeup_attach - Attach a wakeup source object to a device object.
> @@ -242,6 +265,7 @@ static int device_wakeup_attach(struct device *dev, struct wakeup_source *ws)
> return -EEXIST;
> }
> dev->power.wakeup = ws;
> + ws->dev = dev;
> if (dev->power.wakeirq)
> device_wakeup_attach_irq(dev, dev->power.wakeirq);
> spin_unlock_irq(&dev->power.lock);
> diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
> index 9102760..fc23c1a 100644
> --- a/include/linux/pm_wakeup.h
> +++ b/include/linux/pm_wakeup.h
> @@ -23,6 +23,7 @@ struct wake_irq;
> * @name: Name of the wakeup source
> * @entry: Wakeup source list entry
> * @lock: Wakeup source lock
> + * @dev: The device it attached to
> * @wakeirq: Optional device specific wakeirq
> * @timer: Wakeup timer list
> * @timer_expires: Wakeup timer expiration
> @@ -42,6 +43,7 @@ struct wakeup_source {
> const char *name;
> struct list_head entry;
> spinlock_t lock;
> + struct device *dev;
> struct wake_irq *wakeirq;
> struct timer_list timer;
> unsigned long timer_expires;
> @@ -88,6 +90,7 @@ extern void wakeup_source_add(struct wakeup_source *ws);
> extern void wakeup_source_remove(struct wakeup_source *ws);
> extern struct wakeup_source *wakeup_source_register(const char *name);
> extern void wakeup_source_unregister(struct wakeup_source *ws);
> +extern struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws);
> extern int device_wakeup_enable(struct device *dev);
> extern int device_wakeup_disable(struct device *dev);
> extern void device_set_wakeup_capable(struct device *dev, bool capable);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64/prefetch: fix a -Wtype-limits warning
From: Will Deacon @ 2019-08-05 10:00 UTC (permalink / raw)
To: Qian Cai
Cc: rrichter, catalin.marinas, robin.murphy, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190803003358.992-1-cai@lca.pw>
On Fri, Aug 02, 2019 at 08:33:58PM -0400, Qian Cai wrote:
> The commit d5370f754875 ("arm64: prefetch: add alternative pattern for
> CPUs without a prefetcher") introduced MIDR_IS_CPU_MODEL_RANGE() to be
> used in has_no_hw_prefetch() with rv_min=0 which generates a compilation
> warning from GCC,
>
> In file included from ./arch/arm64/include/asm/cache.h:8,
> from ./include/linux/cache.h:6,
> from ./include/linux/printk.h:9,
> from ./include/linux/kernel.h:15,
> from ./include/linux/cpumask.h:10,
> from arch/arm64/kernel/cpufeature.c:11:
> arch/arm64/kernel/cpufeature.c: In function 'has_no_hw_prefetch':
> ./arch/arm64/include/asm/cputype.h:59:26: warning: comparison of
> unsigned expression >= 0 is always true [-Wtype-limits]
> _model == (model) && rv >= (rv_min) && rv <= (rv_max); \
> ^~
> arch/arm64/kernel/cpufeature.c:889:9: note: in expansion of macro
> 'MIDR_IS_CPU_MODEL_RANGE'
> return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
> ^~~~~~~~~~~~~~~~~~~~~~~
>
> Fix it by making "rv" a "s32".
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
>
> v2: Use "s32" for "rv", so "variant 0/revision 0" can be covered.
>
> arch/arm64/include/asm/cputype.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index e7d46631cc42..d52fe8651c2d 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -54,7 +54,7 @@
> #define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max) \
> ({ \
> u32 _model = (midr) & MIDR_CPU_MODEL_MASK; \
> - u32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
> + s32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
Hmm, but this really isn't a signed quantity: it's two fields extracted
from an ID register. I think the code is fine. Are you explicitly enabling
-Wtype-limits somehow?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/9] arm/arm64: Provide a wrapper for SMCCC 1.1 calls
From: Will Deacon @ 2019-08-05 10:03 UTC (permalink / raw)
To: Steven Price
Cc: kvm, Radim Krčmář, Catalin Marinas,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, linux-arm-kernel, Marc Zyngier, Paolo Bonzini,
kvmarm, Julien Thierry
In-Reply-To: <20190802145017.42543-8-steven.price@arm.com>
On Fri, Aug 02, 2019 at 03:50:15PM +0100, Steven Price wrote:
> SMCCC 1.1 calls may use either HVC or SMC depending on the PSCI
> conduit. Rather than coding this in every call site provide a macro
> which uses the correct instruction. The macro also handles the case
> where no PSCI conduit is configured returning a not supported error
> in res, along with returning the conduit used for the call.
>
> This allow us to remove some duplicated code and will be useful later
> when adding paravirtualized time hypervisor calls.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> include/linux/arm-smccc.h | 44 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
Acked-by: Will Deacon <will@kernel.org>
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 00/11] add USB GPIO based connection detection driver
From: Linus Walleij @ 2019-08-05 10:06 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heikki Krogerus, Hans de Goede, Greg Kroah-Hartman, linux-usb,
linux-kernel@vger.kernel.org, Biju Das, Badhri Jagan Sridharan,
Andy Shevchenko, Rob Herring,
moderated list:ARM/Mediatek SoC support, Min Guo,
Matthias Brugger, Adam Thomson, Linux ARM, Li Jun
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
> Because the USB Connector is introduced and the requirement of
> usb-connector.txt binding, the old way using extcon to support
> USB Dual-Role switch is now deprecated, meanwhile there is no
> available common driver when use Type-B connector, typically
> using an input GPIO to detect USB ID pin.
However while this was going on,
drivers/extcon/extcon-fsa9480.c was merged and that detects
not only GPIO on the USB port but multiplexed usecases such
as UART over the USB micro PHY (and no that UART is not
a USB UART, but an actual RX/TX over D-/D+).
That driver also measure a whole slew of funny resistance
values on the ID pin, that is how it does its job.
But for just "hey I'm plugged in" we can surely keep this
ID on GPIO detection in the USB subsystem.
I just get a bit insecure about how we should ideally
handle these "funny-PHY's".
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC,v3 6/9] media: platform: Add Mediatek ISP P1 V4L2 functions
From: Tomasz Figa @ 2019-08-05 9:59 UTC (permalink / raw)
To: Jungo Lin
Cc: devicetree, Sean Cheng (鄭昇弘),
Mauro Carvalho Chehab, Rynn Wu (吳育恩),
srv_heupstream, Rob Herring, Ryan Yu (余孟修),
Frankie Chiu (邱文凱), Hans Verkuil,
Matthias Brugger, Sj Huang,
moderated list:ARM/Mediatek SoC support, Laurent Pinchart,
ddavenport, Frederic Chen (陳俊元),
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <1564451089.1212.649.camel@mtksdccf07>
Hi Jungo,
On Tue, Jul 30, 2019 at 10:45 AM Jungo Lin <jungo.lin@mediatek.com> wrote:
>
> On Mon, 2019-07-29 at 19:04 +0900, Tomasz Figa wrote:
> > On Mon, Jul 29, 2019 at 10:18 AM Jungo Lin <jungo.lin@mediatek.com> wrote:
> > > On Fri, 2019-07-26 at 14:49 +0900, Tomasz Figa wrote:
> > > > On Wed, Jul 24, 2019 at 1:31 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> > > > > On Tue, 2019-07-23 at 19:21 +0900, Tomasz Figa wrote:
> > > > > > On Thu, Jul 18, 2019 at 1:39 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> > > > > > > On Wed, 2019-07-10 at 18:54 +0900, Tomasz Figa wrote:
> > > > > > > > On Tue, Jun 11, 2019 at 11:53:41AM +0800, Jungo Lin wrote:
[snip]
> > > > > > > > > +
> > > > > > > > > + dev_dbg(dev, "%s: node:%d fd:%d idx:%d\n",
> > > > > > > > > + __func__,
> > > > > > > > > + node->id,
> > > > > > > > > + buf->vbb.request_fd,
> > > > > > > > > + buf->vbb.vb2_buf.index);
> > > > > > > > > +
> > > > > > > > > + /* For request buffers en-queue, handled in mtk_cam_req_try_queue */
> > > > > > > > > + if (vb->vb2_queue->uses_requests)
> > > > > > > > > + return;
> > > > > > > >
> > > > > > > > I'd suggest removing non-request support from this driver. Even if we end up
> > > > > > > > with a need to provide compatibility for non-request mode, then it should be
> > > > > > > > built on top of the requests mode, so that the driver itself doesn't have to
> > > > > > > > deal with two modes.
> > > > > > > >
> > > > > > >
> > > > > > > The purpose of non-request function in this driver is needed by
> > > > > > > our camera middle-ware design. It needs 3A statistics buffers before
> > > > > > > image buffers en-queue. So we need to en-queue 3A statistics with
> > > > > > > non-request mode in this driver. After MW got the 3A statistics data, it
> > > > > > > will en-queue the images, tuning buffer and other meta buffers with
> > > > > > > request mode. Based on this requirement, do you have any suggestion?
> > > > > > > For upstream driver, should we only consider request mode?
> > > > > > >
> > > > > >
> > > > > > Where does that requirement come from? Why the timing of queuing of
> > > > > > the buffers to the driver is important?
> > > > > >
> > > > > > [snip]
> > > > >
> > > > > Basically, this requirement comes from our internal camera
> > > > > middle-ware/3A hal in user space. Since this is not generic requirement,
> > > > > we will follow your original suggestion to keep the request mode only
> > > > > and remove other non-request design in other files. For upstream driver,
> > > > > it should support request mode only.
> > > > >
> > > >
> > > > Note that Chromium OS will use the "upstream driver" and we don't want
> > > > to diverge, so please make the userspace also use only requests. I
> > > > don't see a reason why there would be any need to submit any buffers
> > > > outside of a request.
> > > >
> > > > [snip]
> > >
> > > Ok, I have raised your concern to our colleagues and let him to discuss
> > > with you in another communication channel.
> > >
> >
> > Thanks!
> >
> > Best regards,
> > Tomasz
>
> Our colleague is preparing material to explain the our 3A/MW design. If
> he is ready, he will discuss this with you.
Thanks!
>
> In the original plan, we will deliver P1 v4 patch set tomorrow (31th
> Jul.). But, there are some comments waiting for other experts' input.
> Do you suggest it is better to resolve all comments before v4 patch set
> submitting or continue to discuss these comments on v4?
For the remaining v4l2-compliance issues, we can postpone them and
keep on a TODO list in the next version.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 03/11] dt-bindings: usb: add binding for USB GPIO based connection detection driver
From: Linus Walleij @ 2019-08-05 10:08 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heikki Krogerus, Hans de Goede, Greg Kroah-Hartman, linux-usb,
linux-kernel@vger.kernel.org, Biju Das, Badhri Jagan Sridharan,
Andy Shevchenko, Rob Herring,
moderated list:ARM/Mediatek SoC support, Min Guo,
Matthias Brugger, Adam Thomson, Linux ARM, Li Jun
In-Reply-To: <1563958245-6321-4-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
> It's used to support dual role switch via GPIO when use Type-B
> receptacle, typically the USB ID pin is connected to an input
> GPIO, and also used to enable/disable device when the USB Vbus
> pin is connected to an input GPIO.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v8 changes:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 02/11] dt-bindings: connector: add optional properties for Type-B
From: Linus Walleij @ 2019-08-05 10:09 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heikki Krogerus, Hans de Goede, Greg Kroah-Hartman, linux-usb,
linux-kernel@vger.kernel.org, Biju Das, Badhri Jagan Sridharan,
Andy Shevchenko, Rob Herring,
moderated list:ARM/Mediatek SoC support, Min Guo,
Matthias Brugger, Adam Thomson, Linux ARM, Li Jun
In-Reply-To: <1563958245-6321-3-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
> Add id-gpios, vbus-gpios, vbus-supply and pinctrl properties for
> usb-b-connector
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> v8 no changes
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 10/11] usb: common: add USB GPIO based connection detection driver
From: Linus Walleij @ 2019-08-05 10:10 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Heikki Krogerus, Hans de Goede, Greg Kroah-Hartman, linux-usb,
linux-kernel@vger.kernel.org, Biju Das, Badhri Jagan Sridharan,
Andy Shevchenko, Rob Herring,
moderated list:ARM/Mediatek SoC support, Min Guo,
Matthias Brugger, Adam Thomson, Linux ARM, Li Jun
In-Reply-To: <1563958245-6321-11-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Jul 24, 2019 at 10:51 AM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
> Due to the requirement of usb-connector.txt binding, the old way
> using extcon to support USB Dual-Role switch is now deprecated
> when use Type-B connector.
> This patch introduces a driver of Type-B connector which typically
> uses an input GPIO to detect USB ID pin, and try to replace the
> function provided by extcon-usb-gpio driver
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> Tested-by: Nagarjuna Kristam <nkristam@nvidia.com>
> ---
> v8 changes:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl: stmfx: update pinconf settings
From: Linus Walleij @ 2019-08-05 10:15 UTC (permalink / raw)
To: Amelie Delaunay
Cc: Alexandre Torgue, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Maxime Coquelin, linux-stm32, Linux ARM
In-Reply-To: <1564053416-32192-1-git-send-email-amelie.delaunay@st.com>
On Thu, Jul 25, 2019 at 1:16 PM Amelie Delaunay <amelie.delaunay@st.com> wrote:
> From: Alexandre Torgue <alexandre.torgue@st.com>
>
> According to the following tab (coming from STMFX datasheet), updates
> have to done in stmfx_pinconf_set function:
>
> -"type" has to be set when "bias" is configured as "pull-up or pull-down"
> -PIN_CONFIG_DRIVE_PUSH_PULL should only be used when gpio is configured as
> output. There is so no need to check direction.
>
> DIR | TYPE | PUPD | MFX GPIO configuration
> ----|------|------|---------------------------------------------------
> 1 | 1 | 1 | OUTPUT open drain with internal pull-up resistor
> ----|------|------|---------------------------------------------------
> 1 | 1 | 0 | OUTPUT open drain with internal pull-down resistor
> ----|------|------|---------------------------------------------------
> 1 | 0 | 0/1 | OUTPUT push pull no pull
> ----|------|------|---------------------------------------------------
> 0 | 1 | 1 | INPUT with internal pull-up resistor
> ----|------|------|---------------------------------------------------
> 0 | 1 | 0 | INPUT with internal pull-down resistor
> ----|------|------|---------------------------------------------------
> 0 | 0 | 1 | INPUT floating
> ----|------|------|---------------------------------------------------
> 0 | 0 | 0 | analog (GPIO not used, default setting)
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] pinctrl: mvebu: Add CP110 missing pin functionality
From: Miquel Raynal @ 2019-08-05 10:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: devicetree, Yan Markman, Antoine Tenart, Grzegorz Jaszczyk,
Gregory Clement, Maxime Chevallier, Nadav Haklai, linux-gpio,
Thomas Petazzoni, Miquel Raynal, Konstantin Porotchkin,
Stefan Chulski, Marcin Wojtas, Linus Walleij, linux-arm-kernel
In-Reply-To: <20190805101607.29811-1-miquel.raynal@bootlin.com>
From: Konstantin Porotchkin <kostap@marvell.com>
Add missing definition for function 0xe on CP-110 MPP-62.
The pin function is Data Strobe for SDIO interface.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/pinctrl/mvebu/pinctrl-armada-cp110.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c b/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
index 584952b2ba47..85ade9761885 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
@@ -597,7 +597,8 @@ static struct mvebu_mpp_mode armada_cp110_mpp_modes[] = {
MPP_FUNCTION(7, "uart0", "rxd"),
MPP_FUNCTION(8, "uart2", "rxd"),
MPP_FUNCTION(9, "sata0", "present_act"),
- MPP_FUNCTION(10, "ge", "mdc")),
+ MPP_FUNCTION(10, "ge", "mdc"),
+ MPP_FUNCTION(14, "sdio", "ds")),
};
static const struct of_device_id armada_cp110_pinctrl_of_match[] = {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] CP115 pinctrl support
From: Miquel Raynal @ 2019-08-05 10:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: devicetree, Yan Markman, Antoine Tenart, Grzegorz Jaszczyk,
Gregory Clement, Maxime Chevallier, Nadav Haklai, linux-gpio,
Thomas Petazzoni, Miquel Raynal, Stefan Chulski, Marcin Wojtas,
Linus Walleij, linux-arm-kernel
Hello,
This is the second batch of changes (out of three) to support the brand
new Marvell CN9130 SoCs which are made of one AP807 and one CP115.
We add a new compatible (and the relevant support in the pinctrl
driver) before the addition in batch 3/3 of CN9130 SoCs DT using it.
1st batch was clocks support and is independent from this one.
Thanks,
Miquèl
Grzegorz Jaszczyk (2):
dt-bindings: cp110: document the new CP115 pinctrl compatible
pinctrl: mvebu: add additional variant for standalone CP115
Konstantin Porotchkin (1):
pinctrl: mvebu: Add CP110 missing pin functionality
.../arm/marvell/cp110-system-controller.txt | 4 ++--
drivers/pinctrl/mvebu/pinctrl-armada-cp110.c | 20 ++++++++++++++-----
2 files changed, 17 insertions(+), 7 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] dt-bindings: cp110: document the new CP115 pinctrl compatible
From: Miquel Raynal @ 2019-08-05 10:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: devicetree, Yan Markman, Antoine Tenart, Grzegorz Jaszczyk,
Gregory Clement, Maxime Chevallier, Nadav Haklai, linux-gpio,
Thomas Petazzoni, Miquel Raynal, Stefan Chulski, Marcin Wojtas,
Linus Walleij, linux-arm-kernel
In-Reply-To: <20190805101607.29811-1-miquel.raynal@bootlin.com>
From: Grzegorz Jaszczyk <jaz@semihalf.com>
A new compatible is going to be used for Armada CP115 pinctrl block,
document it.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
[<miquel.raynal@bootlin.com>: split the documentation out of the
driver commit]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
.../bindings/arm/marvell/cp110-system-controller.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
index 4db4119a6d19..f982a8ed9396 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
@@ -78,8 +78,8 @@ Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
Required properties:
-- compatible: "marvell,armada-7k-pinctrl",
- "marvell,armada-8k-cpm-pinctrl" or "marvell,armada-8k-cps-pinctrl"
+- compatible: "marvell,armada-7k-pinctrl", "marvell,armada-8k-cpm-pinctrl",
+ "marvell,armada-8k-cps-pinctrl" or "marvell,cp115-standalone-pinctrl"
depending on the specific variant of the SoC being used.
Available mpp pins/groups and functions:
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] pinctrl: mvebu: add additional variant for standalone CP115
From: Miquel Raynal @ 2019-08-05 10:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: devicetree, Yan Markman, Antoine Tenart, Grzegorz Jaszczyk,
Gregory Clement, Maxime Chevallier, Nadav Haklai, linux-gpio,
Thomas Petazzoni, Miquel Raynal, Stefan Chulski, Marcin Wojtas,
Linus Walleij, linux-arm-kernel
In-Reply-To: <20190805101607.29811-1-miquel.raynal@bootlin.com>
From: Grzegorz Jaszczyk <jaz@semihalf.com>
With CP115 standalone modules, all MPP configuration are
possible. Handle this new possibility thanks to the new
"marvell,cp115-standalone-pinctrl" compatible property.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
[<miquel.raynal@bootlin.com>: mention the new compatible in the
commit log]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/pinctrl/mvebu/pinctrl-armada-cp110.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c b/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
index 85ade9761885..17491b27e487 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
@@ -32,6 +32,7 @@ enum {
V_ARMADA_7K = BIT(0),
V_ARMADA_8K_CPM = BIT(1),
V_ARMADA_8K_CPS = BIT(2),
+ V_CP115_STANDALONE = BIT(3),
V_ARMADA_7K_8K_CPM = (V_ARMADA_7K | V_ARMADA_8K_CPM),
V_ARMADA_7K_8K_CPS = (V_ARMADA_7K | V_ARMADA_8K_CPS),
};
@@ -614,6 +615,10 @@ static const struct of_device_id armada_cp110_pinctrl_of_match[] = {
.compatible = "marvell,armada-8k-cps-pinctrl",
.data = (void *) V_ARMADA_8K_CPS,
},
+ {
+ .compatible = "marvell,cp115-standalone-pinctrl",
+ .data = (void *) V_CP115_STANDALONE,
+ },
{ },
};
@@ -655,16 +660,20 @@ static int armada_cp110_pinctrl_probe(struct platform_device *pdev)
switch (i) {
case 0 ... 31:
- mvebu_pinctrl_assign_variant(m, V_ARMADA_7K_8K_CPS);
+ mvebu_pinctrl_assign_variant(m, (V_ARMADA_7K_8K_CPS |
+ V_CP115_STANDALONE));
break;
case 32 ... 38:
- mvebu_pinctrl_assign_variant(m, V_ARMADA_7K_8K_CPM);
+ mvebu_pinctrl_assign_variant(m, (V_ARMADA_7K_8K_CPM |
+ V_CP115_STANDALONE));
break;
case 39 ... 43:
- mvebu_pinctrl_assign_variant(m, V_ARMADA_8K_CPM);
+ mvebu_pinctrl_assign_variant(m, (V_ARMADA_8K_CPM |
+ V_CP115_STANDALONE));
break;
case 44 ... 62:
- mvebu_pinctrl_assign_variant(m, V_ARMADA_7K_8K_CPM);
+ mvebu_pinctrl_assign_variant(m, (V_ARMADA_7K_8K_CPM |
+ V_CP115_STANDALONE));
break;
}
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [linux-sunxi] [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Chen-Yu Tsai @ 2019-08-05 10:16 UTC (permalink / raw)
To: Ondřej Jirman
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, devicetree,
Maxime Ripard, linux-kernel, linux-sunxi, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190412120730.473-3-megous@megous.com>
On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
<linux-sunxi@googlegroups.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> mostly in features that are not yet supported by this driver.
>
> Some differences are already stated in the comments in existing code.
> One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
>
> It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> external low speed oscillator is working correctly.
>
> This patch adds support for enabling LOSC when necessary:
>
> - during reparenting
> - when probing the clock
>
> H6 also has capacbility to automatically reparent RTC clock from
> external crystal oscillator, to internal RC oscillator, if external
> oscillator fails. This is enabled by default. Disable it during
> probe.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index 11f56de52179..7375a530c565 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -41,9 +41,11 @@
> /* Control register */
> #define SUN6I_LOSC_CTRL 0x0000
> #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
The rest looks ok.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl: oxnas: remove set but not used variable 'arg'
From: Linus Walleij @ 2019-08-05 10:16 UTC (permalink / raw)
To: YueHaibing
Cc: open list:GPIO SUBSYSTEM, linux-oxnas,
linux-kernel@vger.kernel.org, Linux ARM, Neil Armstrong
In-Reply-To: <20190725142419.29892-1-yuehaibing@huawei.com>
On Thu, Jul 25, 2019 at 4:24 PM YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/pinctrl/pinctrl-oxnas.c: In function oxnas_ox810se_pinconf_set:
> drivers/pinctrl/pinctrl-oxnas.c:905:6: warning: variable arg set but not used [-Wunused-but-set-variable]
> drivers/pinctrl/pinctrl-oxnas.c: In function oxnas_ox820_pinconf_set:
> drivers/pinctrl/pinctrl-oxnas.c:944:6: warning: variable arg set but not used [-Wunused-but-set-variable]
>
> It is never used since commit 4b0c0c25fa79 ("pinctrl:
> oxnas: Add support for OX820"), so can be removed.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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