* [PATCH 4/5] arm64: dts: imx8qxp-mek: Enable scu power key
From: Anson Huang @ 2019-08-30 20:53 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
catalin.marinas, will, dmitry.torokhov, aisheng.dong, ulf.hansson,
fugang.duan, peng.fan, daniel.baluta, leonard.crestez, olof,
mripard, arnd, jagan, bjorn.andersson, dinguyen,
marcin.juszkiewicz, hsweeten, tglx, gregkh, stefan, ronald,
ping.bai, m.felsch, andriy.shevchenko, devicetree, linux-kernel,
linux-arm-kernel, linux-input
Cc: Linux-imx
In-Reply-To: <1567198429-27886-1-git-send-email-Anson.Huang@nxp.com>
Enable scu power key for i.MX8QXP MEK board.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 1946805..f3df5c4 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -234,3 +234,7 @@
&adma_dsp {
status = "okay";
};
+
+&scu_pwrkey {
+ status = "okay";
+};
--
2.7.4
_______________________________________________
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 5/5] arm64: defconfig: Enable CONFIG_KEYBOARD_IMX_SC_PWRKEY as module
From: Anson Huang @ 2019-08-30 20:53 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
catalin.marinas, will, dmitry.torokhov, aisheng.dong, ulf.hansson,
fugang.duan, peng.fan, daniel.baluta, leonard.crestez, olof,
mripard, arnd, jagan, bjorn.andersson, dinguyen,
marcin.juszkiewicz, hsweeten, tglx, gregkh, stefan, ronald,
ping.bai, m.felsch, andriy.shevchenko, devicetree, linux-kernel,
linux-arm-kernel, linux-input
Cc: Linux-imx
In-Reply-To: <1567198429-27886-1-git-send-email-Anson.Huang@nxp.com>
Select CONFIG_KEYBOARD_IMX_SC_PWRKEY as module by default to
support i.MX8QXP power key driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 49bb3d4..8178737 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -313,6 +313,7 @@ CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_ADC=m
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_SNVS_PWRKEY=m
+CONFIG_KEYBOARD_IMX_SC_PWRKEY=m
CONFIG_KEYBOARD_CROS_EC=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
From: Christoph Hellwig @ 2019-08-30 8:58 UTC (permalink / raw)
To: Julien Grall
Cc: Peng Fan, sstabellini@kernel.org, Catalin Marinas,
linux@armlinux.org.uk, dl-linux-imx,
xen-devel@lists.xenproject.org, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org, Robin Murphy
In-Reply-To: <d7477406-a8a0-5c3c-13dc-2c84e27b8afa@arm.com>
Can we take a step back and figure out what we want to do here?
AFAICS this function allocates memory for the swiotlb-xen buffer,
and that means it must be <= 32-bit addressable to satisfy the DMA API
guarantees. That means we generally want to use GFP_DMA32 everywhere
that exists, but on systems with odd zones we might want to dip into
GFP_DMA. This also means swiotlb-xen doesn't actually do the right
thing on x86 at the moment. So shouldn't we just have one common
routine in swiotlb-xen.c that checks if we have CONFIG_ZONE_DMA32
set, then try GFP_DMA32, and if not check if CONFIG_ZONE_DMA is set
and then try that, else default to GFP_KERNEL?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 02/11] soc: ti: add initial PRM driver with reset control support
From: Philipp Zabel @ 2019-08-30 9:02 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <049da607-c352-4ed1-9a2d-2374d7a7e372@ti.com>
Hi Tero,
On Fri, 2019-08-30 at 10:28 +0300, Tero Kristo wrote:
> On 29/08/2019 16:12, Philipp Zabel wrote:
[...]
> > I wonder if splitting rstctrl/rstst/rstmap out into a separate structure
> > would make sense. That could be linked from omap_reset_data directly.
> > That only makes sense if there'd be enough cases where it can be reused
> > for multiple PRMs instances.
>
> Hmm, splitting these out would make it possible to share the bits for
> ipu:s across devices, same for dsp:s and eve:s.
>
> However, adding too many levels of abstraction makes it kind of
> difficult to follow what is happening with the code, and it would only
> save maybe ~100 bytes of memory at the moment.
Good point, that is likely not worth the additional complexity.
[...]
> > What does the value read from the rstst register indicate? Is it the
> > current state of the reset line? Is it 0 until deassertion is completed,
> > and then it turns to 1?
>
> Value of 1 indicates that the corresponding IP has been reset
> successfully. Writing back 1 to the same bit clears it out, so the
> status can be polled later on.
Then this should not be returned directly by reset_control_status:
/**
* reset_control_status - returns a negative errno if not supported, a
* positive value if the reset line is asserted, or zero if the reset
* line is not asserted or if the desc is NULL (optional reset).
*/
This should return 0 only if the control bit is deasserted and the
status bit is already set.
If either the control bit is asserted, or if the status bit is still
cleared, this should return 1.
[...]
> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > + if (!res)
> > > + return -ENODEV;
> >
> > This can be merged with devm_ioremap_resource below.
>
> Well, I actually use the "res" later on to map the DT node to the
> corresponding prm_data based on address.
Ok. I glanced over the data->base loop below after questioning whether
it is needed at all.
> >
> > > + match = of_match_device(omap_prm_id_table, &pdev->dev);
> > > + if (!match)
> > > + return -ENOTSUPP;
> > > +
> > > + prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
> > > + if (!prm)
> > > + return -ENOMEM;
> > > +
> > > + data = match->data;
> > > +
> > > + while (data->base != res->start) {
> > > + if (!data->base)
> > > + return -EINVAL;
> > > + data++;
> > > + }
> >
> > Is this not something that you want to have encoded in the compatible
> > string? They all have a different register layout.
>
> With the addition of all the prm instances later on, this changes. Most
> of the prm instances will have same register layout then. See v1 data
> that was posted earlier [1], but which I dropped for now to keep this
> series isolated for reset handling only. In this patch, you see that for
> DRA7, all the power domain handling related PRM instances have identical
> register layout, they just differ based on base address.
>
> [1] https://www.spinics.net/lists/linux-omap/msg149872.html
>
> It would be possible to encode all of this based on different
> compatibles, but then the amount of different compatible strings would
> explode... DRA7 is just one SoC.
I see only 3 different layouts in that patch. All instances with
identical layout could share the same compatible.
Either way, that is DT bindings territory, and not for me to decide. I
just found it unusual to encode the device type by its base address in
the driver.
> >
> > > +
> > > + prm->data = data;
> > > +
> > > + prm->base = devm_ioremap_resource(&pdev->dev, res);
> >
> > prm->base = devm_platform_ioremap_resource(pdev, 0);
>
> I still need the "res" pointer as indicated above.
Got it. If the lookup by base address is needed, this has to stay split.
regards
Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 03/11] soc: ti: omap-prm: poll for reset complete during de-assert
From: Tero Kristo @ 2019-08-30 9:07 UTC (permalink / raw)
To: Philipp Zabel, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1567084467.5345.9.camel@pengutronix.de>
On 29/08/2019 16:14, Philipp Zabel wrote:
> Hi Tero,
>
> On Wed, 2019-08-28 at 10:19 +0300, Tero Kristo wrote:
>> Poll for reset completion status during de-assertion of reset, otherwise
>> the IP in question might be accessed before it has left reset properly.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>> index fd5c431f8736..afeb70761b27 100644
>> --- a/drivers/soc/ti/omap_prm.c
>> +++ b/drivers/soc/ti/omap_prm.c
>> @@ -127,6 +127,7 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>> u32 v;
>> int st_bit;
>> bool has_rstst;
>> + int timeout = 0;
>>
>> if (!_is_valid_reset(reset, id))
>> return -EINVAL;
>> @@ -153,6 +154,25 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>> v &= ~(1 << id);
>> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
>>
>> + if (!has_rstst)
>> + return 0;
>> +
>> + /* wait for the status to be set */
>> + while (1) {
>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>> + v &= 1 << st_bit;
>> + if (v)
>> + break;
>> + timeout++;
>> + if (timeout > OMAP_RESET_MAX_WAIT) {
>> + pr_err("%s: timedout waiting for %s:%lu\n", __func__,
>> + dev_name(rcdev->dev), id);
>> + return -EBUSY;
>> + }
>> +
>> + udelay(1);
>> + }
>
> This looks like you could use
>
> readl_relaxed_poll_timeout(_atomic)
Yeah true, let me change that.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 02/11] soc: ti: add initial PRM driver with reset control support
From: Tero Kristo @ 2019-08-30 9:11 UTC (permalink / raw)
To: Philipp Zabel, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <1567155748.3714.1.camel@pengutronix.de>
On 30/08/2019 12:02, Philipp Zabel wrote:
> Hi Tero,
>
> On Fri, 2019-08-30 at 10:28 +0300, Tero Kristo wrote:
>> On 29/08/2019 16:12, Philipp Zabel wrote:
> [...]
>>> I wonder if splitting rstctrl/rstst/rstmap out into a separate structure
>>> would make sense. That could be linked from omap_reset_data directly.
>>> That only makes sense if there'd be enough cases where it can be reused
>>> for multiple PRMs instances.
>>
>> Hmm, splitting these out would make it possible to share the bits for
>> ipu:s across devices, same for dsp:s and eve:s.
>>
>> However, adding too many levels of abstraction makes it kind of
>> difficult to follow what is happening with the code, and it would only
>> save maybe ~100 bytes of memory at the moment.
>
> Good point, that is likely not worth the additional complexity.
>
> [...]
>>> What does the value read from the rstst register indicate? Is it the
>>> current state of the reset line? Is it 0 until deassertion is completed,
>>> and then it turns to 1?
>>
>> Value of 1 indicates that the corresponding IP has been reset
>> successfully. Writing back 1 to the same bit clears it out, so the
>> status can be polled later on.
>
> Then this should not be returned directly by reset_control_status:
>
> /**
> * reset_control_status - returns a negative errno if not supported, a
> * positive value if the reset line is asserted, or zero if the reset
> * line is not asserted or if the desc is NULL (optional reset).
> */
>
> This should return 0 only if the control bit is deasserted and the
> status bit is already set.
>
> If either the control bit is asserted, or if the status bit is still
> cleared, this should return 1.
Hmm ok, let me fix that a bit also.
>
> [...]
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> + if (!res)
>>>> + return -ENODEV;
>>>
>>> This can be merged with devm_ioremap_resource below.
>>
>> Well, I actually use the "res" later on to map the DT node to the
>> corresponding prm_data based on address.
>
> Ok. I glanced over the data->base loop below after questioning whether
> it is needed at all.
>
>>>
>>>> + match = of_match_device(omap_prm_id_table, &pdev->dev);
>>>> + if (!match)
>>>> + return -ENOTSUPP;
>>>> +
>>>> + prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
>>>> + if (!prm)
>>>> + return -ENOMEM;
>>>> +
>>>> + data = match->data;
>>>> +
>>>> + while (data->base != res->start) {
>>>> + if (!data->base)
>>>> + return -EINVAL;
>>>> + data++;
>>>> + }
>>>
>>> Is this not something that you want to have encoded in the compatible
>>> string? They all have a different register layout.
>>
>> With the addition of all the prm instances later on, this changes. Most
>> of the prm instances will have same register layout then. See v1 data
>> that was posted earlier [1], but which I dropped for now to keep this
>> series isolated for reset handling only. In this patch, you see that for
>> DRA7, all the power domain handling related PRM instances have identical
>> register layout, they just differ based on base address.
>>
>> [1] https://www.spinics.net/lists/linux-omap/msg149872.html
>>
>> It would be possible to encode all of this based on different
>> compatibles, but then the amount of different compatible strings would
>> explode... DRA7 is just one SoC.
>
> I see only 3 different layouts in that patch. All instances with
> identical layout could share the same compatible.
>
> Either way, that is DT bindings territory, and not for me to decide. I
> just found it unusual to encode the device type by its base address in
> the driver.
I'll try to poke Rob for comment on that on the bindings patch.
>
>>>
>>>> +
>>>> + prm->data = data;
>>>> +
>>>> + prm->base = devm_ioremap_resource(&pdev->dev, res);
>>>
>>> prm->base = devm_platform_ioremap_resource(pdev, 0);
>>
>> I still need the "res" pointer as indicated above.
>
> Got it. If the lookup by base address is needed, this has to stay split.
Ok thanks for the reviews, much appreciated. I'll see if I can get reply
from Rob on the binding item, otherwise I might just send v2 with the
existing bindings out and send a v3 with updated bindings if necessary.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 v5 10/10] arm64: atomics: Use K constraint when toolchain appears to support it
From: Andrew Murray @ 2019-08-30 9:11 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, peterz, catalin.marinas, ndesaulniers,
Ard.Biesheuvel, natechancellor, robin.murphy, linux-arm-kernel
In-Reply-To: <20190830075220.6xyyctvgd2ssrsjf@willie-the-truck>
On Fri, Aug 30, 2019 at 08:52:20AM +0100, Will Deacon wrote:
> On Fri, Aug 30, 2019 at 01:08:03AM +0100, Andrew Murray wrote:
> > On Thu, Aug 29, 2019 at 05:54:58PM +0100, Will Deacon wrote:
> > > On Thu, Aug 29, 2019 at 04:48:34PM +0100, Will Deacon wrote:
> > > > diff --git a/arch/arm64/include/asm/atomic_ll_sc.h b/arch/arm64/include/asm/atomic_ll_sc.h
> > > > index 95091f72228b..7fa042f5444e 100644
> > > > --- a/arch/arm64/include/asm/atomic_ll_sc.h
> > > > +++ b/arch/arm64/include/asm/atomic_ll_sc.h
> > > > @@ -23,6 +23,10 @@ asm_ops "\n" \
> > > > #define __LL_SC_FALLBACK(asm_ops) asm_ops
> > > > #endif
I downloaded your original patches and tried them, and also got the
build error. After playing with this I think something isn't quite right...
This is your current test:
echo 'int main(void) {asm volatile("and w0, w0, %w0" :: "K" (4294967295)); return 0; }' | aarch64-linux-gnu-gcc -S -x c - ; echo $?
But on my machine this returns 0, i.e. no error. If I drop the -S:
echo 'int main(void) {asm volatile("and w0, w0, %w0" :: "K" (4294967295)); return 0; }' | aarch64-linux-gnu-gcc -x c - ; echo $?
Then this returns 1.
So I guess the -S flag or something similar is needed.
> > > >
> > > > +#ifndef CONFIG_CC_HAS_K_CONSTRAINT
> > > > +#define K
> > > > +#endif
Also, isn't this the wrong way around?
It looks like when using $(call try-run,echo - it's the last argument that is
used when the condition is false. Thus at present we seem to be setting
CONFIG_CC_HAS_K_CONSTRAINT when 'K' is broken.
> > >
> > > Bah, I need to use something like __stringify when the constraint is used
> > > in order for this to get expanded properly. Updated diff below.
> >
> > I don't think the changes in your updated diff are required. We successfully
> > combine 'asm_op' with the remainder of the assembly string without using
> > __stringify, and this is no different to how the original patch combined
> > 'constraint' with "r".
>
> It's a hack: __stringify expands its arguments, so I figured I may as well
> use that rather than do it manually with an extra macro.
>
> > You can verify this by looking at the preprocessed .i files generated with
> > something like:
> >
> > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- drivers/spi/spi-rockchip.i
> >
> > I see no difference (with GCC 7.3.1) between the original approach and your
> > use of __stringify. Incidentally you end up with "K" "r" instead of "Kr" but
> > it seems to have the desired effect (e.g. supress/emit out of range errors).
> > I have a couple of macros that resolves this to "Kr" but I don't think it's
> > necessary.
> >
> > Did you find that it didn't work without your changes? I found it hard to
> > reproduce the out-of-range errors until I made the following change, I could
> > then easily see the effect of changing the constraint:
> >
> > : "=&r" (result), "=&r" (tmp), "+Q" (v->counter) \
> > - : #constraint "r" (i)); \
> > + : #constraint) "r" (4294967295)); \
> > }
>
> Without the __stringify I get a compilation failure when building
> kernel/panic.o because it tries to cmpxchg a 32-bit variable with -1
> (PANIC_CPU_INVALID). Looking at panic.s, I see that constraint parameter
> isn't being expanded. For example if I do:
>
> #ifndef CONFIG_CC_HAS_K_CONSTRAINT
> #define INVALID_CONSTRAINT
> #else
> #define INVALID_CONSTRAINT K
> #endif
>
> and then pass INVALID_CONSTRAINT to the generator macros, we'll end up
> with INVALID_CONSTRAINT in the .s file and gas will barf.
This still isn't an issue for me. Your patches cause the build to fail because
it's using the K flag - if I invert the CONFIG_CC_HAS_K_CONSTRAINT test then
it builds correctly (because it expands the K to nothing).
If there is an issue with the expansion of constraint, shouldn't we also
__stringify 'asm_op'?
Thanks,
Andrew Murray
>
> The reason I didn't see this initially is because my silly testcase had
> a typo and was using atomic_add instead of atomic_and.
>
> 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: [PATCHv2 01/11] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-08-30 9:18 UTC (permalink / raw)
To: ssantosh, linux-arm-kernel, linux-omap, robh+dt, p.zabel; +Cc: tony, devicetree
In-Reply-To: <20190828071941.32378-2-t-kristo@ti.com>
Hi Rob,
Quick question below based on some discussion on the implementation
details of the PRM support.
On 28/08/2019 10:19, Tero Kristo wrote:
> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
> of these will act as a power domain controller and potentially as a reset
> provider.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> .../devicetree/bindings/arm/omap/prm-inst.txt | 31 +++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> new file mode 100644
> index 000000000000..7c7527c37734
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
> @@ -0,0 +1,31 @@
> +OMAP PRM instance bindings
> +
> +Power and Reset Manager is an IP block on OMAP family of devices which
> +handle the power domains and their current state, and provide reset
> +handling for the domains and/or separate IP blocks under the power domain
> +hierarchy.
> +
> +Required properties:
> +- compatible: Must be one of:
> + "ti,am3-prm-inst"
> + "ti,am4-prm-inst"
> + "ti,omap4-prm-inst"
> + "ti,omap5-prm-inst"
> + "ti,dra7-prm-inst"
Each of these bindings describes multiple PRM instances, like
ti,dra7-prm-inst maps eventually into 21 different PRM instances. I end
up matching these in the kernel based on base address to map additional
details, like support for reset handling, supported reset bits, etc.
What is your take on this, should I just provide individual compatible
strings for these all, the total amount of them would end up being like
70+, or keep them like this? I find it rather cumbersome if I would have
to deal with 70+ different compatibles... Also, I would need to keep
updating the bindings doc once I add new instances on the supported list.
-Tero
> +- reg: Contains PRM instance register address range
> + (base address and length)
> +
> +Optional properties:
> +- #reset-cells: Should be 1 if the PRM instance in question supports resets.
> +- clocks: Associated clocks for the reset signals if any. Certain reset
> + signals can't be toggled properly without functional clock
> + being active for them.
> +
> +Example:
> +
> +prm_dsp2: prm@1b00 {
> + compatible = "ti,dra7-prm-inst";
> + reg = <0x1b00 0x40>;
> + #reset-cells = <1>;
> + clocks = <&dsp2_clkctrl DRA7_DSP2_MMU0_DSP2_CLKCTRL 0>;
> +};
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/3] Add IMX290 CMOS image sensor support
From: Manivannan Sadhasivam @ 2019-08-30 9:19 UTC (permalink / raw)
To: mchehab, robh+dt, sakari.ailus
Cc: devicetree, c.barrett, linux-kernel, a.brela,
Manivannan Sadhasivam, linux-arm-kernel, linux-media
Hello,
This patchset adds support for IMX290 CMOS image sensor from Sony.
Sensor can be programmed through I2C and 4-wire interface but the
current driver only supports I2C interface. Also, the sensor is
capable of outputting frames in following 3 interfaces:
* CMOS logic parallel SDR output
* Low voltage LVDS serial DDR output
* CSI-2 serial data output
But the current driver only supports CSI-2 output available from 4 lanes.
In the case of sensor resolution, driver only supports 1920x1080 and
1280x720 at mid data rate of 445.5 Mpbs.
The driver has been validated using Framos IMX290 module interfaced to
96Boards Dragonboard410c.
Thanks,
Mani
Changes in v3:
As per the review by Sakari:
* Switched to pm runtime
* Used link-frequency property
* Removed useless read calls from buffered read function
* Some other misc changes to the driver and binding
Changes in v2:
* Added Reviewed-by tag from Rob for bindings patch
Manivannan Sadhasivam (3):
dt-bindings: media: i2c: Add IMX290 CMOS sensor binding
media: i2c: Add IMX290 CMOS image sensor driver
MAINTAINERS: Add entry for IMX290 CMOS image sensor driver
.../devicetree/bindings/media/i2c/imx290.txt | 57 ++
MAINTAINERS | 8 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/imx290.c | 881 ++++++++++++++++++
5 files changed, 958 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/imx290.txt
create mode 100644 drivers/media/i2c/imx290.c
--
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 v3 1/3] dt-bindings: media: i2c: Add IMX290 CMOS sensor binding
From: Manivannan Sadhasivam @ 2019-08-30 9:19 UTC (permalink / raw)
To: mchehab, robh+dt, sakari.ailus
Cc: devicetree, c.barrett, linux-kernel, a.brela,
Manivannan Sadhasivam, linux-arm-kernel, linux-media
In-Reply-To: <20190830091943.22646-1-manivannan.sadhasivam@linaro.org>
Add devicetree binding for IMX290 CMOS image sensor.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/media/i2c/imx290.txt | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/imx290.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/imx290.txt b/Documentation/devicetree/bindings/media/i2c/imx290.txt
new file mode 100644
index 000000000000..a3cc21410f7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/imx290.txt
@@ -0,0 +1,57 @@
+* Sony IMX290 1/2.8-Inch CMOS Image Sensor
+
+The Sony IMX290 is a 1/2.8-Inch CMOS Solid-state image sensor with
+Square Pixel for Color Cameras. It is programmable through I2C and 4-wire
+interfaces. The sensor output is available via CMOS logic parallel SDR output,
+Low voltage LVDS DDR output and CSI-2 serial data output. The CSI-2 bus is the
+default. No bindings have been defined for the other busses.
+
+Required Properties:
+- compatible: Should be "sony,imx290"
+- reg: I2C bus address of the device
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- clock-frequency: Frequency of the xclk clock in Hz.
+- vdddo-supply: Sensor digital IO regulator.
+- vdda-supply: Sensor analog regulator.
+- vddd-supply: Sensor digital core regulator.
+
+Optional Properties:
+- reset-gpios: Sensor reset GPIO
+
+The imx290 device node should contain one 'port' child node with
+an 'endpoint' subnode. For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required Properties on endpoint:
+- data-lanes: check ../video-interfaces.txt
+- link-frequencies: check ../video-interfaces.txt
+- remote-endpoint: check ../video-interfaces.txt
+
+Example:
+ &i2c1 {
+ ...
+ imx290: camera-sensor@1a {
+ compatible = "sony,imx290";
+ reg = <0x1a>;
+
+ reset-gpios = <&msmgpio 35 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&camera_rear_default>;
+
+ clocks = <&gcc GCC_CAMSS_MCLK0_CLK>;
+ clock-names = "xclk";
+ clock-frequency = <37125000>;
+
+ vdddo-supply = <&camera_vdddo_1v8>;
+ vdda-supply = <&camera_vdda_2v8>;
+ vddd-supply = <&camera_vddd_1v5>;
+
+ port {
+ imx290_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <445500000>;
+ remote-endpoint = <&csiphy0_ep>;
+ };
+ };
+ };
--
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 v3 2/3] media: i2c: Add IMX290 CMOS image sensor driver
From: Manivannan Sadhasivam @ 2019-08-30 9:19 UTC (permalink / raw)
To: mchehab, robh+dt, sakari.ailus
Cc: devicetree, c.barrett, linux-kernel, a.brela,
Manivannan Sadhasivam, linux-arm-kernel, linux-media
In-Reply-To: <20190830091943.22646-1-manivannan.sadhasivam@linaro.org>
Add driver for Sony IMX290 CMOS image sensor driver. The driver only
supports I2C interface for programming and MIPI CSI-2 for sensor output.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/imx290.c | 881 +++++++++++++++++++++++++++++++++++++
3 files changed, 893 insertions(+)
create mode 100644 drivers/media/i2c/imx290.c
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 79ce9ec6fc1b..4ebb80b18748 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -595,6 +595,17 @@ config VIDEO_IMX274
This is a V4L2 sensor driver for the Sony IMX274
CMOS image sensor.
+config VIDEO_IMX290
+ tristate "Sony IMX290 sensor support"
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ depends on MEDIA_CAMERA_SUPPORT
+ help
+ This is a Video4Linux2 sensor driver for the Sony
+ IMX290 camera sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx290.
+
config VIDEO_IMX319
tristate "Sony IMX319 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index fd4ea86dedd5..04411ddb4922 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
obj-$(CONFIG_VIDEO_IMX214) += imx214.o
obj-$(CONFIG_VIDEO_IMX258) += imx258.o
obj-$(CONFIG_VIDEO_IMX274) += imx274.o
+obj-$(CONFIG_VIDEO_IMX290) += imx290.o
obj-$(CONFIG_VIDEO_IMX319) += imx319.o
obj-$(CONFIG_VIDEO_IMX355) += imx355.o
obj-$(CONFIG_VIDEO_ST_MIPID02) += st-mipid02.o
diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
new file mode 100644
index 000000000000..db5bb0d69eb8
--- /dev/null
+++ b/drivers/media/i2c/imx290.c
@@ -0,0 +1,881 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Sony IMX290 CMOS Image Sensor Driver
+ *
+ * Copyright (C) 2019 FRAMOS GmbH.
+ *
+ * Copyright (C) 2019 Linaro Ltd.
+ * Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <media/media-entity.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-fwnode.h>
+#include <media/v4l2-subdev.h>
+
+#define IMX290_STANDBY 0x3000
+#define IMX290_REGHOLD 0x3001
+#define IMX290_XMSTA 0x3002
+#define IMX290_GAIN 0x3014
+
+#define IMX290_DEFAULT_LINK_FREQ 445500000
+
+static const char * const imx290_supply_name[] = {
+ "vdda",
+ "vddd",
+ "vdddo",
+};
+
+#define IMX290_NUM_SUPPLIES ARRAY_SIZE(imx290_supply_name)
+
+struct imx290_regval {
+ u16 reg;
+ u8 val;
+};
+
+struct imx290_mode {
+ u32 width;
+ u32 height;
+ u32 pixel_rate;
+ u32 link_freq_index;
+
+ const struct imx290_regval *data;
+ u32 data_size;
+};
+
+struct imx290 {
+ struct device *dev;
+ struct clk *xclk;
+ struct regmap *regmap;
+
+ struct v4l2_subdev sd;
+ struct v4l2_fwnode_endpoint ep;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt current_format;
+ const struct imx290_mode *current_mode;
+
+ struct regulator_bulk_data supplies[IMX290_NUM_SUPPLIES];
+ struct gpio_desc *rst_gpio;
+
+ struct v4l2_ctrl_handler ctrls;
+ struct v4l2_ctrl *link_freq;
+ struct v4l2_ctrl *pixel_rate;
+
+ struct mutex lock;
+};
+
+struct imx290_pixfmt {
+ u32 code;
+};
+
+static const struct imx290_pixfmt imx290_formats[] = {
+ { MEDIA_BUS_FMT_SRGGB10_1X10 },
+};
+
+static struct regmap_config imx290_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static const struct imx290_regval imx290_global_init_settings[] = {
+ { 0x3007, 0x00 },
+ { 0x3009, 0x00 },
+ { 0x3018, 0x65 },
+ { 0x3019, 0x04 },
+ { 0x301a, 0x00 },
+ { 0x3443, 0x03 },
+ { 0x3444, 0x20 },
+ { 0x3445, 0x25 },
+ { 0x3407, 0x03 },
+ { 0x303a, 0x0c },
+ { 0x3040, 0x00 },
+ { 0x3041, 0x00 },
+ { 0x303c, 0x00 },
+ { 0x303d, 0x00 },
+ { 0x3042, 0x9c },
+ { 0x3043, 0x07 },
+ { 0x303e, 0x49 },
+ { 0x303f, 0x04 },
+ { 0x304b, 0x0a },
+ { 0x300f, 0x00 },
+ { 0x3010, 0x21 },
+ { 0x3012, 0x64 },
+ { 0x3016, 0x09 },
+ { 0x3070, 0x02 },
+ { 0x3071, 0x11 },
+ { 0x309b, 0x10 },
+ { 0x309c, 0x22 },
+ { 0x30a2, 0x02 },
+ { 0x30a6, 0x20 },
+ { 0x30a8, 0x20 },
+ { 0x30aa, 0x20 },
+ { 0x30ac, 0x20 },
+ { 0x30b0, 0x43 },
+ { 0x3119, 0x9e },
+ { 0x311c, 0x1e },
+ { 0x311e, 0x08 },
+ { 0x3128, 0x05 },
+ { 0x313d, 0x83 },
+ { 0x3150, 0x03 },
+ { 0x317e, 0x00 },
+ { 0x32b8, 0x50 },
+ { 0x32b9, 0x10 },
+ { 0x32ba, 0x00 },
+ { 0x32bb, 0x04 },
+ { 0x32c8, 0x50 },
+ { 0x32c9, 0x10 },
+ { 0x32ca, 0x00 },
+ { 0x32cb, 0x04 },
+ { 0x332c, 0xd3 },
+ { 0x332d, 0x10 },
+ { 0x332e, 0x0d },
+ { 0x3358, 0x06 },
+ { 0x3359, 0xe1 },
+ { 0x335a, 0x11 },
+ { 0x3360, 0x1e },
+ { 0x3361, 0x61 },
+ { 0x3362, 0x10 },
+ { 0x33b0, 0x50 },
+ { 0x33b2, 0x1a },
+ { 0x33b3, 0x04 },
+};
+
+static const struct imx290_regval imx290_1080p_settings[] = {
+ /* mode settings */
+ { 0x3007, 0x00 },
+ { 0x303a, 0x0c },
+ { 0x3414, 0x0a },
+ { 0x3472, 0x80 },
+ { 0x3473, 0x07 },
+ { 0x3418, 0x38 },
+ { 0x3419, 0x04 },
+ { 0x3012, 0x64 },
+ { 0x3013, 0x00 },
+ { 0x305c, 0x18 },
+ { 0x305d, 0x03 },
+ { 0x305e, 0x20 },
+ { 0x305f, 0x01 },
+ { 0x315e, 0x1a },
+ { 0x3164, 0x1a },
+ { 0x3480, 0x49 },
+ /* data rate settings */
+ { 0x3009, 0x01 },
+ { 0x3405, 0x10 },
+ { 0x3446, 0x57 },
+ { 0x3447, 0x00 },
+ { 0x3448, 0x37 },
+ { 0x3449, 0x00 },
+ { 0x344a, 0x1f },
+ { 0x344b, 0x00 },
+ { 0x344c, 0x1f },
+ { 0x344d, 0x00 },
+ { 0x344e, 0x1f },
+ { 0x344f, 0x00 },
+ { 0x3450, 0x77 },
+ { 0x3451, 0x00 },
+ { 0x3452, 0x1f },
+ { 0x3453, 0x00 },
+ { 0x3454, 0x17 },
+ { 0x3455, 0x00 },
+ { 0x301c, 0x98 },
+ { 0x301d, 0x08 },
+};
+
+static const struct imx290_regval imx290_720p_settings[] = {
+ /* mode settings */
+ { 0x3007, 0x10 },
+ { 0x303a, 0x06 },
+ { 0x3414, 0x04 },
+ { 0x3472, 0x00 },
+ { 0x3473, 0x05 },
+ { 0x3418, 0xd0 },
+ { 0x3419, 0x02 },
+ { 0x3012, 0x64 },
+ { 0x3013, 0x00 },
+ { 0x305c, 0x20 },
+ { 0x305d, 0x00 },
+ { 0x305e, 0x20 },
+ { 0x305f, 0x01 },
+ { 0x315e, 0x1a },
+ { 0x3164, 0x1a },
+ { 0x3480, 0x49 },
+ /* data rate settings */
+ { 0x3009, 0x01 },
+ { 0x3405, 0x10 },
+ { 0x3446, 0x4f },
+ { 0x3447, 0x00 },
+ { 0x3448, 0x2f },
+ { 0x3449, 0x00 },
+ { 0x344a, 0x17 },
+ { 0x344b, 0x00 },
+ { 0x344c, 0x17 },
+ { 0x344d, 0x00 },
+ { 0x344e, 0x17 },
+ { 0x344f, 0x00 },
+ { 0x3450, 0x57 },
+ { 0x3451, 0x00 },
+ { 0x3452, 0x17 },
+ { 0x3453, 0x00 },
+ { 0x3454, 0x17 },
+ { 0x3455, 0x00 },
+ { 0x301c, 0xe4 },
+ { 0x301d, 0x0c },
+};
+
+static const struct imx290_regval imx290_10bit_settings[] = {
+ { 0x3005, 0x00},
+ { 0x3046, 0x00},
+ { 0x3129, 0x1d},
+ { 0x317c, 0x12},
+ { 0x31ec, 0x37},
+ { 0x3441, 0x0a},
+ { 0x3442, 0x0a},
+ { 0x300a, 0x3c},
+ { 0x300b, 0x00},
+};
+
+/* supported link frequencies */
+static const s64 imx290_link_freq[] = {
+ IMX290_DEFAULT_LINK_FREQ,
+};
+
+/* Mode configs */
+static const struct imx290_mode imx290_modes[] = {
+ {
+ .width = 1920,
+ .height = 1080,
+ .data = imx290_1080p_settings,
+ .data_size = ARRAY_SIZE(imx290_1080p_settings),
+ .pixel_rate = 178200000,
+ .link_freq_index = 0,
+ },
+ {
+ .width = 1280,
+ .height = 720,
+ .data = imx290_720p_settings,
+ .data_size = ARRAY_SIZE(imx290_720p_settings),
+ .pixel_rate = 178200000,
+ .link_freq_index = 0,
+ },
+};
+
+static inline struct imx290 *to_imx290(struct v4l2_subdev *_sd)
+{
+ return container_of(_sd, struct imx290, sd);
+}
+
+static inline int imx290_read_reg(struct imx290 *imx290, u16 addr, u8 *value)
+{
+ u32 regval;
+ int ret;
+
+ ret = regmap_read(imx290->regmap, addr, ®val);
+ if (ret) {
+ dev_err(imx290->dev, "I2C read failed for addr: %x\n", addr);
+ return ret;
+ }
+
+ *value = regval & 0xff;
+
+ return 0;
+}
+
+static int imx290_write_reg(struct imx290 *imx290, u16 addr, u8 value)
+{
+ int ret;
+
+ ret = regmap_write(imx290->regmap, addr, value);
+ if (ret) {
+ dev_err(imx290->dev, "I2C write failed for addr: %x\n", addr);
+ return ret;
+ }
+
+ return ret;
+}
+
+static int imx290_set_register_array(struct imx290 *imx290,
+ const struct imx290_regval *settings,
+ unsigned int num_settings)
+{
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < num_settings; ++i, ++settings) {
+ ret = imx290_write_reg(imx290, settings->reg, settings->val);
+ if (ret < 0)
+ return ret;
+
+ /* Settle time is 10ms for all registers */
+ msleep(10);
+ }
+
+ return 0;
+}
+
+static int imx290_write_buffered_reg(struct imx290 *imx290, u16 address_low,
+ u8 nr_regs, u32 value)
+{
+ unsigned int i;
+ int ret;
+
+ ret = imx290_write_reg(imx290, IMX290_REGHOLD, 0x01);
+ if (ret) {
+ dev_err(imx290->dev, "Error setting hold register\n");
+ return ret;
+ }
+
+ for (i = 0; i < nr_regs; i++) {
+ ret = imx290_write_reg(imx290, address_low + i,
+ (u8)(value >> (i * 8)));
+ if (ret) {
+ dev_err(imx290->dev, "Error writing buffered registers\n");
+ return ret;
+ }
+ }
+
+ ret = imx290_write_reg(imx290, IMX290_REGHOLD, 0x00);
+ if (ret) {
+ dev_err(imx290->dev, "Error setting hold register\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+static int imx290_set_gain(struct imx290 *imx290, u32 value)
+{
+ int ret;
+
+ u32 adjusted_value = (value * 10) / 3;
+
+ ret = imx290_write_buffered_reg(imx290, IMX290_GAIN, 1, adjusted_value);
+ if (ret)
+ dev_err(imx290->dev, "Unable to write gain\n");
+
+ return ret;
+}
+
+static int imx290_set_power_on(struct imx290 *imx290)
+{
+ int ret;
+
+ ret = clk_prepare_enable(imx290->xclk);
+ if (ret) {
+ dev_err(imx290->dev, "Failed to enable clock\n");
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(IMX290_NUM_SUPPLIES,
+ imx290->supplies);
+ if (ret) {
+ dev_err(imx290->dev, "Failed to enable regulators\n");
+ goto xclk_off;
+ }
+
+ usleep_range(1, 2);
+ gpiod_set_value_cansleep(imx290->rst_gpio, 1);
+ usleep_range(30000, 31000);
+
+ return 0;
+
+xclk_off:
+ clk_disable_unprepare(imx290->xclk);
+ return ret;
+}
+
+/* Stop streaming */
+static int imx290_stop_streaming(struct imx290 *imx290)
+{
+ int ret;
+
+ ret = imx290_write_reg(imx290, IMX290_STANDBY, 0x01);
+ if (ret < 0)
+ return ret;
+
+ msleep(30);
+
+ return imx290_write_reg(imx290, IMX290_XMSTA, 0x01);
+}
+
+static void imx290_set_power_off(struct imx290 *imx290)
+{
+ clk_disable_unprepare(imx290->xclk);
+ gpiod_set_value_cansleep(imx290->rst_gpio, 0);
+ regulator_bulk_disable(IMX290_NUM_SUPPLIES, imx290->supplies);
+}
+
+static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct imx290 *imx290 = container_of(ctrl->handler,
+ struct imx290, ctrls);
+ int ret = 0;
+
+ /* V4L2 controls values will be applied only when power is already up */
+ if (!pm_runtime_get_if_in_use(imx290->dev))
+ return 0;
+
+ switch (ctrl->id) {
+ case V4L2_CID_GAIN:
+ ret = imx290_set_gain(imx290, ctrl->val);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ pm_runtime_put(imx290->dev);
+
+ return ret;
+}
+
+static const struct v4l2_ctrl_ops imx290_ctrl_ops = {
+ .s_ctrl = imx290_set_ctrl,
+};
+
+static int imx290_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ if (code->index >= ARRAY_SIZE(imx290_formats))
+ return -EINVAL;
+
+ code->code = imx290_formats[code->index].code;
+
+ return 0;
+}
+
+static int imx290_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct imx290 *imx290 = to_imx290(sd);
+ struct v4l2_mbus_framefmt *framefmt;
+
+ mutex_lock(&imx290->lock);
+
+ if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)
+ framefmt = v4l2_subdev_get_try_format(&imx290->sd, cfg,
+ fmt->pad);
+ else
+ framefmt = &imx290->current_format;
+
+ fmt->format = *framefmt;
+
+ mutex_unlock(&imx290->lock);
+
+ return 0;
+}
+
+static int imx290_set_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+ struct imx290 *imx290 = to_imx290(sd);
+ const struct imx290_mode *mode;
+ struct v4l2_mbus_framefmt *format;
+ int i, ret = 0;
+
+ mutex_lock(&imx290->lock);
+
+ mode = v4l2_find_nearest_size(imx290_modes,
+ ARRAY_SIZE(imx290_modes),
+ width, height,
+ fmt->format.width, fmt->format.height);
+
+ fmt->format.width = mode->width;
+ fmt->format.height = mode->height;
+
+ for (i = 0; i < ARRAY_SIZE(imx290_formats); i++)
+ if (imx290_formats[i].code == fmt->format.code)
+ break;
+
+ if (i >= ARRAY_SIZE(imx290_formats))
+ i = 0;
+
+ fmt->format.code = imx290_formats[i].code;
+ fmt->format.field = V4L2_FIELD_NONE;
+
+ if (fmt->which == V4L2_SUBDEV_FORMAT_TRY) {
+ format = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
+ } else {
+ format = &imx290->current_format;
+ __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
+ __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate, mode->pixel_rate);
+
+ imx290->current_mode = mode;
+ }
+
+ *format = fmt->format;
+
+ mutex_unlock(&imx290->lock);
+
+ return ret;
+}
+
+static int imx290_entity_init_cfg(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_pad_config *cfg)
+{
+ struct v4l2_subdev_format fmt = { 0 };
+
+ fmt.which = cfg ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
+ fmt.format.width = 1920;
+ fmt.format.height = 1080;
+
+ imx290_set_fmt(subdev, cfg, &fmt);
+
+ return 0;
+}
+
+static int imx290_write_current_format(struct imx290 *imx290,
+ struct v4l2_mbus_framefmt *format)
+{
+ int ret;
+
+ switch (format->code) {
+ case MEDIA_BUS_FMT_SRGGB10_1X10:
+ ret = imx290_set_register_array(imx290, imx290_10bit_settings,
+ ARRAY_SIZE(imx290_10bit_settings));
+ if (ret < 0) {
+ dev_err(imx290->dev, "Could not set format registers\n");
+ return ret;
+ }
+ break;
+ default:
+ dev_err(imx290->dev, "Unknown pixel format\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/* Start streaming */
+static int imx290_start_streaming(struct imx290 *imx290)
+{
+ int ret;
+
+ /* Set init register settings */
+ ret = imx290_set_register_array(imx290, imx290_global_init_settings,
+ ARRAY_SIZE(imx290_global_init_settings));
+ if (ret < 0) {
+ dev_err(imx290->dev, "Could not set init registers\n");
+ return ret;
+ }
+
+ /* Set current frame format */
+ ret = imx290_write_current_format(imx290, &imx290->current_format);
+ if (ret < 0) {
+ dev_err(imx290->dev, "Could not set frame format\n");
+ return ret;
+ }
+
+ /* Apply default values of current mode */
+ ret = imx290_set_register_array(imx290, imx290->current_mode->data,
+ imx290->current_mode->data_size);
+ if (ret < 0) {
+ dev_err(imx290->dev, "Could not set current mode\n");
+ return ret;
+ }
+
+ /* Apply customized values from user */
+ ret = v4l2_ctrl_handler_setup(imx290->sd.ctrl_handler);
+ if (ret) {
+ dev_err(imx290->dev, "Could not sync v4l2 controls\n");
+ return ret;
+ }
+
+ ret = imx290_write_reg(imx290, IMX290_STANDBY, 0x00);
+ if (ret < 0)
+ return ret;
+
+ msleep(30);
+
+ /* Start streaming */
+ return imx290_write_reg(imx290, IMX290_XMSTA, 0x00);
+}
+
+static int imx290_set_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct imx290 *imx290 = to_imx290(sd);
+ int ret = 0;
+
+ if (enable) {
+ ret = pm_runtime_get_sync(imx290->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(imx290->dev);
+ goto unlock_and_return;
+ }
+
+ ret = imx290_start_streaming(imx290);
+ if (ret) {
+ dev_err(imx290->dev, "Start stream failed\n");
+ pm_runtime_put(imx290->dev);
+ goto unlock_and_return;
+ }
+ } else {
+ imx290_stop_streaming(imx290);
+ pm_runtime_put(imx290->dev);
+ }
+
+unlock_and_return:
+
+ return ret;
+}
+
+static int imx290_get_regulators(struct device *dev, struct imx290 *imx290)
+{
+ unsigned int i;
+
+ for (i = 0; i < IMX290_NUM_SUPPLIES; i++)
+ imx290->supplies[i].supply = imx290_supply_name[i];
+
+ return devm_regulator_bulk_get(dev, IMX290_NUM_SUPPLIES,
+ imx290->supplies);
+}
+
+static int __maybe_unused imx290_runtime_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct imx290 *imx290 = to_imx290(sd);
+
+ return imx290_set_power_on(imx290);
+}
+
+static int __maybe_unused imx290_runtime_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct imx290 *imx290 = to_imx290(sd);
+
+ imx290_set_power_off(imx290);
+
+ return 0;
+}
+
+static const struct dev_pm_ops imx290_pm_ops = {
+ SET_RUNTIME_PM_OPS(imx290_runtime_suspend,
+ imx290_runtime_resume, NULL)
+};
+
+static const struct v4l2_subdev_video_ops imx290_video_ops = {
+ .s_stream = imx290_set_stream,
+};
+
+static const struct v4l2_subdev_pad_ops imx290_pad_ops = {
+ .init_cfg = imx290_entity_init_cfg,
+ .enum_mbus_code = imx290_enum_mbus_code,
+ .get_fmt = imx290_get_fmt,
+ .set_fmt = imx290_set_fmt,
+};
+
+static const struct v4l2_subdev_ops imx290_subdev_ops = {
+ .video = &imx290_video_ops,
+ .pad = &imx290_pad_ops,
+};
+
+static const struct media_entity_operations imx290_subdev_entity_ops = {
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static int imx290_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct fwnode_handle *endpoint;
+ struct imx290 *imx290;
+ u32 xclk_freq;
+ int ret;
+
+ imx290 = devm_kzalloc(dev, sizeof(*imx290), GFP_KERNEL);
+ if (!imx290)
+ return -ENOMEM;
+
+ imx290->dev = dev;
+ imx290->regmap = devm_regmap_init_i2c(client, &imx290_regmap_config);
+ if (IS_ERR(imx290->regmap)) {
+ dev_err(dev, "Unable to initialize I2C\n");
+ return -ENODEV;
+ }
+
+ endpoint = fwnode_graph_get_next_endpoint(dev_fwnode(dev), NULL);
+ if (!endpoint) {
+ dev_err(dev, "Endpoint node not found\n");
+ return -EINVAL;
+ }
+
+ ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &imx290->ep);
+ fwnode_handle_put(endpoint);
+ if (ret) {
+ dev_err(dev, "Parsing endpoint node failed\n");
+ return ret;
+ }
+
+ if (!imx290->ep.nr_of_link_frequencies) {
+ dev_err(dev, "link-frequency property not found in DT\n");
+ return -EINVAL;
+ }
+
+ if (imx290->ep.link_frequencies[0] != IMX290_DEFAULT_LINK_FREQ) {
+ dev_err(dev, "Unsupported link frequency\n");
+ return -EINVAL;
+ }
+
+ /* Only CSI2 is supported for now */
+ if (imx290->ep.bus_type != V4L2_MBUS_CSI2_DPHY) {
+ dev_err(dev, "Unsupported bus type, should be CSI2\n");
+ return -EINVAL;
+ }
+
+ /* Set default mode to max resolution */
+ imx290->current_mode = &imx290_modes[0];
+
+ /* get system clock (xclk) */
+ imx290->xclk = devm_clk_get(dev, "xclk");
+ if (IS_ERR(imx290->xclk)) {
+ dev_err(dev, "Could not get xclk");
+ return PTR_ERR(imx290->xclk);
+ }
+
+ ret = of_property_read_u32(dev->of_node, "clock-frequency", &xclk_freq);
+ if (ret) {
+ dev_err(dev, "Could not get xclk frequency\n");
+ return ret;
+ }
+
+ /* external clock must be 37.125 MHz */
+ if (xclk_freq != 37125000) {
+ dev_err(dev, "External clock frequency %u is not supported\n",
+ xclk_freq);
+ return -EINVAL;
+ }
+
+ ret = clk_set_rate(imx290->xclk, xclk_freq);
+ if (ret) {
+ dev_err(dev, "Could not set xclk frequency\n");
+ return ret;
+ }
+
+ ret = imx290_get_regulators(dev, imx290);
+ if (ret < 0) {
+ dev_err(dev, "Cannot get regulators\n");
+ return ret;
+ }
+
+ imx290->rst_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
+ if (IS_ERR(imx290->rst_gpio)) {
+ dev_err(dev, "Cannot get reset gpio\n");
+ return PTR_ERR(imx290->rst_gpio);
+ }
+
+ mutex_init(&imx290->lock);
+
+ v4l2_ctrl_handler_init(&imx290->ctrls, 3);
+
+ v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
+ V4L2_CID_GAIN, 0, 72, 1, 0);
+ imx290->link_freq = v4l2_ctrl_new_int_menu(&imx290->ctrls,
+ &imx290_ctrl_ops,
+ V4L2_CID_LINK_FREQ,
+ ARRAY_SIZE(imx290_link_freq) - 1,
+ 0, imx290_link_freq);
+ if (imx290->link_freq)
+ imx290->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
+
+ imx290->pixel_rate = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
+ V4L2_CID_PIXEL_RATE, 1,
+ INT_MAX, 1,
+ imx290_modes[0].pixel_rate);
+
+ imx290->sd.ctrl_handler = &imx290->ctrls;
+
+ if (imx290->ctrls.error) {
+ dev_err(dev, "Control initialization error %d\n",
+ imx290->ctrls.error);
+ ret = imx290->ctrls.error;
+ goto free_ctrl;
+ }
+
+ v4l2_i2c_subdev_init(&imx290->sd, client, &imx290_subdev_ops);
+ imx290->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ imx290->sd.dev = &client->dev;
+ imx290->sd.entity.ops = &imx290_subdev_entity_ops;
+ imx290->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+
+ imx290->pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_pads_init(&imx290->sd.entity, 1, &imx290->pad);
+ if (ret < 0) {
+ dev_err(dev, "Could not register media entity\n");
+ goto free_ctrl;
+ }
+
+ ret = v4l2_async_register_subdev(&imx290->sd);
+ if (ret < 0) {
+ dev_err(dev, "Could not register v4l2 device\n");
+ goto free_entity;
+ }
+
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ pm_runtime_idle(dev);
+
+ return 0;
+
+free_entity:
+ media_entity_cleanup(&imx290->sd.entity);
+free_ctrl:
+ v4l2_ctrl_handler_free(&imx290->ctrls);
+ mutex_destroy(&imx290->lock);
+
+ return ret;
+}
+
+static int imx290_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct imx290 *imx290 = to_imx290(sd);
+
+ v4l2_async_unregister_subdev(sd);
+ media_entity_cleanup(&sd->entity);
+ v4l2_ctrl_handler_free(sd->ctrl_handler);
+
+ mutex_destroy(&imx290->lock);
+
+ pm_runtime_disable(imx290->dev);
+ if (!pm_runtime_status_suspended(imx290->dev))
+ imx290_set_power_off(imx290);
+ pm_runtime_set_suspended(imx290->dev);
+
+ return 0;
+}
+
+static const struct of_device_id imx290_of_match[] = {
+ { .compatible = "sony,imx290" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx290_of_match);
+
+static struct i2c_driver imx290_i2c_driver = {
+ .probe_new = imx290_probe,
+ .remove = imx290_remove,
+ .driver = {
+ .name = "imx290",
+ .pm = &imx290_pm_ops,
+ .of_match_table = of_match_ptr(imx290_of_match),
+ },
+};
+
+module_i2c_driver(imx290_i2c_driver);
+
+MODULE_DESCRIPTION("Sony IMX290 CMOS Image Sensor Driver");
+MODULE_AUTHOR("FRAMOS GmbH");
+MODULE_AUTHOR("Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>");
+MODULE_LICENSE("GPL v2");
--
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 v3 3/3] MAINTAINERS: Add entry for IMX290 CMOS image sensor driver
From: Manivannan Sadhasivam @ 2019-08-30 9:19 UTC (permalink / raw)
To: mchehab, robh+dt, sakari.ailus
Cc: devicetree, c.barrett, linux-kernel, a.brela,
Manivannan Sadhasivam, linux-arm-kernel, linux-media
In-Reply-To: <20190830091943.22646-1-manivannan.sadhasivam@linaro.org>
Add MAINTAINERS entry for Sony IMX290 CMOS image sensor driver.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f7c84004187d..0ee261fca602 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14962,6 +14962,14 @@ S: Maintained
F: drivers/media/i2c/imx274.c
F: Documentation/devicetree/bindings/media/i2c/imx274.txt
+SONY IMX290 SENSOR DRIVER
+M: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx290.c
+F: Documentation/devicetree/bindings/media/i2c/imx290.txt
+
SONY IMX319 SENSOR DRIVER
M: Bingbu Cao <bingbu.cao@intel.com>
L: linux-media@vger.kernel.org
--
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: [RESEND PATCH 0/5] Add bluetooth support for Orange Pi 3
From: Maxime Ripard @ 2019-08-30 9:21 UTC (permalink / raw)
To: Marcel Holtmann
Cc: megous, Mark Rutland, Johan Hedberg, devicetree, netdev,
linux-kernel, linux-bluetooth, Chen-Yu Tsai, Rob Herring,
David S. Miller, linux-arm-kernel
In-Reply-To: <5524D5E9-FA82-4244-A91F-78CF1C3FB3FB@holtmann.org>
[-- Attachment #1.1: Type: text/plain, Size: 1512 bytes --]
Hi Marcel,
On Fri, Aug 30, 2019 at 09:53:16AM +0200, Marcel Holtmann wrote:
> > (Resend to add missing lists, sorry for the noise.)
> >
> > This series implements bluetooth support for Xunlong Orange Pi 3 board.
> >
> > The board uses AP6256 WiFi/BT 5.0 chip.
> >
> > Summary of changes:
> >
> > - add more delay to let initialize the chip
> > - let the kernel detect firmware file path
> > - add new compatible and update dt-bindings
> > - update Orange Pi 3 / H6 DTS
> >
> > Please take a look.
> >
> > thank you and regards,
> > Ondrej Jirman
> >
> > Ondrej Jirman (5):
> > dt-bindings: net: Add compatible for BCM4345C5 bluetooth device
> > bluetooth: bcm: Add support for loading firmware for BCM4345C5
> > bluetooth: hci_bcm: Give more time to come out of reset
> > arm64: dts: allwinner: h6: Add pin configs for uart1
> > arm64: dts: allwinner: orange-pi-3: Enable UART1 / Bluetooth
> >
> > .../bindings/net/broadcom-bluetooth.txt | 1 +
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts | 19 +++++++++++++++++++
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++++++++++
> > drivers/bluetooth/btbcm.c | 3 +++
> > drivers/bluetooth/hci_bcm.c | 3 ++-
> > 5 files changed, 35 insertions(+), 1 deletion(-)
>
> all 5 patches have been applied to bluetooth-next tree.
The DTS patches (last 2) should go through the arm-soc tree, can you
drop them?
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 01/10] KVM: arm64: Document PV-time interface
From: Christoffer Dall @ 2019-08-30 9:22 UTC (permalink / raw)
To: Steven Price
Cc: kvm, linux-doc, Marc Zyngier, linux-kernel, Russell King,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <37eaf54b-8a22-8483-a372-419bfa1475f1@arm.com>
On Wed, Aug 28, 2019 at 01:09:15PM +0100, Steven Price wrote:
> On 27/08/2019 09:57, Christoffer Dall wrote:
> > On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
> >> Introduce a paravirtualization interface for KVM/arm64 based on the
> >> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
> >>
> >> This only adds the details about "Stolen Time" as the details of "Live
> >> Physical Time" have not been fully agreed.
> >>
> >> User space can specify a reserved area of memory for the guest and
> >> inform KVM to populate the memory with information on time that the host
> >> kernel has stolen from the guest.
> >>
> >> A hypercall interface is provided for the guest to interrogate the
> >> hypervisor's support for this interface and the location of the shared
> >> memory structures.
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> ---
> >> Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
> >> 1 file changed, 100 insertions(+)
> >> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
> >>
> >> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
> >> new file mode 100644
> >> index 000000000000..1ceb118694e7
> >> --- /dev/null
> >> +++ b/Documentation/virt/kvm/arm/pvtime.txt
> >> @@ -0,0 +1,100 @@
> >> +Paravirtualized time support for arm64
> >> +======================================
> >> +
> >> +Arm specification DEN0057/A defined a standard for paravirtualised time
> >> +support for AArch64 guests:
> >> +
> >> +https://developer.arm.com/docs/den0057/a
> >> +
> >> +KVM/arm64 implements the stolen time part of this specification by providing
> >> +some hypervisor service calls to support a paravirtualized guest obtaining a
> >> +view of the amount of time stolen from its execution.
> >> +
> >> +Two new SMCCC compatible hypercalls are defined:
> >> +
> >> +PV_FEATURES 0xC5000020
> >> +PV_TIME_ST 0xC5000022
> >> +
> >> +These are only available in the SMC64/HVC64 calling convention as
> >> +paravirtualized time is not available to 32 bit Arm guests. The existence of
> >> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
> >> +mechanism before calling it.
> >> +
> >> +PV_FEATURES
> >> + Function ID: (uint32) : 0xC5000020
> >> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
> >> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> >> + PV-time feature is supported by the hypervisor.
> >> +
> >> +PV_TIME_ST
> >> + Function ID: (uint32) : 0xC5000022
> >> + Return value: (int64) : IPA of the stolen time data structure for this
> >> + (V)CPU. On failure:
> >> + NOT_SUPPORTED (-1)
> >> +
> >> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
> >> +with inner and outer write back caching attributes, in the inner shareable
> >> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
> >> +meaningfully filled by the hypervisor (see structure below).
> >> +
> >> +PV_TIME_ST returns the structure for the calling VCPU.
> >> +
> >> +Stolen Time
> >> +-----------
> >> +
> >> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> >> +
> >> + Field | Byte Length | Byte Offset | Description
> >> + ----------- | ----------- | ----------- | --------------------------
> >> + Revision | 4 | 0 | Must be 0 for version 0.1
> >> + Attributes | 4 | 4 | Must be 0
> >> + Stolen time | 8 | 8 | Stolen time in unsigned
> >> + | | | nanoseconds indicating how
> >> + | | | much time this VCPU thread
> >> + | | | was involuntarily not
> >> + | | | running on a physical CPU.
> >> +
> >> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
> >> +will be present within a reserved region of the normal memory given to the
> >> +guest. The guest should not attempt to write into this memory. There is a
> >> +structure per VCPU of the guest.
> >> +
> >> +User space interface
> >> +====================
> >> +
> >> +User space can request that KVM provide the paravirtualized time interface to
> >> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
> >> +
> >> + struct kvm_create_device pvtime_device = {
> >> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
> >> + .attr = 0,
> >> + .flags = 0,
> >> + };
> >> +
> >> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
> >> +
> >> +Creation of the device should be done after creating the vCPUs of the virtual
> >> +machine.
> >> +
> >> +The IPA of the structures must be given to KVM. This is the base address
> >> +of an array of stolen time structures (one for each VCPU). The base address
> >> +must be page aligned. The size must be at least 64 * number of VCPUs and be a
> >> +multiple of PAGE_SIZE.
> >> +
> >> +The memory for these structures should be added to the guest in the usual
> >> +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
> >> +
> >> +For example:
> >> +
> >> + struct kvm_dev_arm_st_region region = {
> >> + .gpa = <IPA of guest base address>,
> >> + .size = <size in bytes>
> >> + };
> >
> > This feel fragile; how are you handling userspace creating VCPUs after
> > setting this up,
>
> In this case as long as the structures all fit within the region created
> VCPUs can be created/destroyed at will. If the VCPU index is too high
> then the kernel will bail out in kvm_update_stolen_time() so the
> structure will not be written. I consider this case as user space
> messing up, so beyond protecting the host from the mess, user space gets
> to keep the pieces.
>
> > the GPA overlapping guest memory, etc.
>
> Again, the (host) kernel is protected against this, but clearly this
> will end badly for the guest.
>
> > Is the
> > philosophy here that the VMM can mess up the VM if it wants, but that
> > this should never lead attacks on the host (we better hope not) and so
> > we don't care?
>
> Yes. For things like GPA overlapping guest memory it's not really the
> host's position to work out what is "guest memory". It's quite possible
> that user space could decide to place the stolen time structures right
> in the middle of guest memory - it's just up to user space to inform the
> guest what memory is usable. Obviously the expectation is that the
> shared structures would be positioned "out of the way" in GPA space in
> any normal arrangement.
>
> > It seems to me setting the IPA per vcpu throught the VCPU device would
> > avoid a lot of these issues. See
> > Documentation/virt/kvm/devices/vcpu.txt.
>
> That is certainly a possibility, I'm not really sure what the benefit is
> though? It would still lead to corner cases:
>
> * What if only some VCPUs had stolen time setup on them?
> * What if multiple VCPUs pointed to the same location?
> * The structures can still overlap with guest memory
>
> It's also more work to setup in user space with the only "benefit" being
> that user space could choose to organise the structures however it sees
> fit (e.g. no need for them to be contiguous in memory). But I'm not sure
> I see a use case for that flexibility.
>
> Perhaps there's some benefit I'm not seeing?
>
So this is now mostly moot as you said you were going to change this,
but overall I think the assumption that it's trivial to maintain an
interface such the one proposed here to never be an attack vector for
the host is not as easy as it may sound. In the past, we've had
numerous bugs related to things like calculating an offset into some
region based on some index and a size, because suddenly someone changed
how an index is calculated, and it had unintended side-effects etc.
So if an API is used to specify something which is effectively per-CPU,
it's better to use the per-CPU handles (VCPU fds) to directly describe
this relationship.
Thanks,
Christoffer
_______________________________________________
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 1/4] vmalloc: lift the arm flag for coherent mappings to common code
From: Russell King - ARM Linux admin @ 2019-08-30 9:29 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, linux-kernel, linux-mm, iommu, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190830062924.21714-2-hch@lst.de>
On Fri, Aug 30, 2019 at 08:29:21AM +0200, Christoph Hellwig wrote:
> The arm architecture had a VM_ARM_DMA_CONSISTENT flag to mark DMA
> coherent remapping for a while. Lift this flag to common code so
> that we can use it generically. We also check it in the only place
> VM_USERMAP is directly check so that we can entirely replace that
> flag as well (although I'm not even sure why we'd want to allow
> remapping DMA appings, but I'd rather not change behavior).
Good, because if you did change that behaviour, you'd break almost
every ARM framebuffer and cripple ARM audio drivers.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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 v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Sudeep Holla @ 2019-08-30 9:30 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com, Jassi Brar,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
Sudeep Holla, linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB448161C632722DF10989008088BD0@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Fri, Aug 30, 2019 at 07:37:41AM +0000, Peng Fan wrote:
> Hi Jassi,
> > > I think there could be channel for TEE, and channel for Linux.
> > > For virtualization case, there could be dedicated channel for each VM.
> > >
> > I am talking from Linux pov. Functions 0xfe and 0xff above, can't both be
> > active at the same time, right?
>
> If I get your point correctly,
> On UP, both could not be active. On SMP, tx/rx could be both active, anyway
> this depends on secure firmware and Linux firmware design.
>
Just to confirm, we can't have SMC/HVC based Rx channel as there's no
*architectural* way to achieve it. So it can be based on some interrupt
from secure side and hence will be a *different* type of channel/controller.
Sorry to make this point repeatedly, but juts to be absolutely clear:
as it stands, SMC/HVC can be used only for Tx today.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH 1/1] rtc: sun6i: Allow using as wakeup source from suspend
From: Chen-Yu Tsai @ 2019-08-30 9:31 UTC (permalink / raw)
To: Alejandro González
Cc: linux-rtc, Alessandro Zummo, Alexandre Belloni, Maxime Ripard,
linux-kernel, linux-sunxi, linux-arm-kernel
In-Reply-To: <20190821210056.11995-1-alejandro.gonzalez.correo@gmail.com>
On Thu, Aug 22, 2019 at 5:01 AM Alejandro González
<alejandro.gonzalez.correo@gmail.com> wrote:
>
> This patch allows userspace to set up wakeup alarms on any RTC handled by the
> sun6i driver, and adds the necessary PM operations to allow resuming from
> suspend when the configured wakeup alarm fires a IRQ. Of course, that the
> device actually resumes depends on the suspend state and how a particular
> hardware reacts to it, but that is out of scope for this patch.
>
> I've tested these changes on a Pine H64 model B, which contains a
> Allwinner H6 SoC, with the help of CONFIG_PM_TEST_SUSPEND kernel option.
> These are the interesting outputs from the kernel and commands which
> show that it works. As every RTC handled by this driver is largely the
> same, I think that it shouldn't introduce any regression on other SoCs,
> but I may be wrong.
>
> [ 1.092705] PM: test RTC wakeup from 'freeze' suspend
> [ 1.098230] PM: suspend entry (s2idle)
> [ 1.212907] PM: suspend devices took 0.080 seconds
> (The SoC freezes for some seconds)
> [ 3.197604] PM: resume devices took 0.104 seconds
> [ 3.215937] PM: suspend exit
>
> [ 1.092812] PM: test RTC wakeup from 'mem' suspend
> [ 1.098089] PM: suspend entry (deep)
> [ 1.102033] PM: suspend exit
> [ 1.105205] PM: suspend test failed, error -22
>
> In any case, the RTC alarm interrupt gets fired as exptected:
>
> $ echo +5 > /sys/class/rtc/rtc0/wakealarm && sleep 5 && grep rtc /proc/interrupts
> 29: 1 0 0 0 GICv2 133 Level 7000000.rtc
>
> Signed-off-by: Alejandro González <alejandro.gonzalez.correo@gmail.com>
This seems like standard PM stuff. Nothing sunxi-specific.
FWIW, for sunxi,
Acked-by: Chen-Yu Tsai <wens@csie.org>
_______________________________________________
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 v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Sudeep Holla @ 2019-08-30 9:32 UTC (permalink / raw)
To: Jassi Brar
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, andre.przywara@arm.com,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
Sudeep Holla, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY2SrMF8e1iLyLqb-rJyBx4ajA0hZ6D=LFtuMNtXYjgccA@mail.gmail.com>
On Fri, Aug 30, 2019 at 02:52:40AM -0500, Jassi Brar wrote:
> On Fri, Aug 30, 2019 at 2:37 AM Peng Fan <peng.fan@nxp.com> wrote:
[...]
> >
> > If I get your point correctly,
> > On UP, both could not be active. On SMP, tx/rx could be both active, anyway
> > this depends on secure firmware and Linux firmware design.
> >
> > Do you have any suggestions about arm,func-ids here?
> >
> I was thinking if this is just an instruction, why can't each channel
> be represented as a controller, i.e, have exactly one func-id per
> controller node. Define as many controllers as you need channels ?
>
I might have missed to follow this, but what's the advantage of doing so ?
Which can't single controller instance deal with all the channels ?
--
Regards,
Sudeep
_______________________________________________
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] ARM: dts: imx7: fix USB controller 'size' parameter
From: Peter Chen @ 2019-08-30 9:33 UTC (permalink / raw)
To: Thomas Schäfer
Cc: marex@denx.de, shawnguo@kernel.org, s.hauer@pengutronix.de,
dl-linux-imx, kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <b227eb4da9214b33b44f33b2a84f4205@kontron.com>
On 19-08-30 07:11:42, Thomas Schaefer wrote:
> -----Ursprüngliche Nachricht-----
> Von: Peter Chen <peter.chen@nxp.com>
> Gesendet: Freitag, 30. August 2019 04:26
> > On 19-08-29 17:49:13, Thomas Schaefer wrote:
> > > Currently the size parameter in the reg property of usbotg and usbh
> > > nodes in imx7s and imx7d dts includes is set to 0x200 which is wrong
> > > for the i.MX7 CPU. According to reference manual, spacing of USB
> > > controller registers is 0x10000 instead.
> > >
> > > This patch will fix this and set the 'size' to 0x10000.
> > >
> > > Signed-off-by: Thomas Schaefer <thomas.schaefer@kontron.com>
> > > ---
> > > arch/arm/boot/dts/imx7d.dtsi | 2 +-
> > > arch/arm/boot/dts/imx7s.dtsi | 4 ++--
> > > 2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/imx7d.dtsi
> > > b/arch/arm/boot/dts/imx7d.dtsi index 42528d2812a2..f1b098d28b6e 100644
> > > --- a/arch/arm/boot/dts/imx7d.dtsi
> > > +++ b/arch/arm/boot/dts/imx7d.dtsi
> > > @@ -117,7 +117,7 @@
> > > &aips3 {
> > > usbotg2: usb@30b20000 {
> > > compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> > > - reg = <0x30b20000 0x200>;
> > > + reg = <0x30b20000 0x10000>;
> > > interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
> > > clocks = <&clks IMX7D_USB_CTRL_CLK>;
> > > fsl,usbphy = <&usbphynop2>;
> > > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > > b/arch/arm/boot/dts/imx7s.dtsi index c1a4fff5ceda..9e25fccf33f0 100644
> > > --- a/arch/arm/boot/dts/imx7s.dtsi
> > > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > > @@ -1088,7 +1088,7 @@
> > >
> > > usbotg1: usb@30b10000 {
> > > compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> > > - reg = <0x30b10000 0x200>;
> > > + reg = <0x30b10000 0x10000>;
> > > interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
> > > clocks = <&clks IMX7D_USB_CTRL_CLK>;
> > > fsl,usbphy = <&usbphynop1>;
> > > @@ -1099,7 +1099,7 @@
> > >
> > > usbh: usb@30b30000 {
> > > compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> > > - reg = <0x30b30000 0x200>;
> > > + reg = <0x30b30000 0x10000>;
> > > interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> > > clocks = <&clks IMX7D_USB_CTRL_CLK>;
> > > fsl,usbphy = <&usbphynop3>;
> >
> > Hi Thomos,
> >
> > The core controller range is 0x200, from offset 0x200, it is non-core register, which is used by usbmisc. Fabio said you met problem at u-boot for this size, what's the problem about it?
> >
> > Thanks,
> > Peter
>
> Hi Peter,
>
> When porting one of our i.MX7 based modules to u-boot v2019.07, I found that scanning USB with 'usb start' crashes when trying to scan the _second_ controller enabled in the device tree (the first controller was detected properly). After some investigation I found that the problem was introduced with Marek Vasuts 'usb: ehci-mx6: Fix bus enumeration for DM case' (u-boot commit 501547cec1f7f0438cae388a104ff60f18576c01). This patch uses the 'reg' property in the usbotg and usbh nodes to calculate the device index number for the driver.
>
> Actually, controller range on i.MX6 is 0x200, thus the calculation is correct for i.MX6, but on i.MX7 the base addresses of the controller registers differ by 0x10000 and calculation will fail if more than one USB controller is enabled in the device tree. This is why I suggested to fix this problem in the imx7s and imx7d device tree include files.
>
At dts, each USB controller has its reg property to describe its base
address, we do not need additional calculation.
For controller index, it is only needed for imx6 since we share non-core
register from 0x800 among controllers. From imx7, we have dedicate
non-core region for each controller, it can be described at dts well.
At dts, we use usbmisc to describe the non core part, and the related
Linux code is at drivers/usb/chipidea/usbmisc_imx.c
--
Thanks,
Peter Chen
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 0/3] Odroid c2 missing regulator linking
From: Anand Moon @ 2019-08-30 9:34 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Martin Blumenstingl, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <101a12ac-1464-8864-4f8c-56bb46034a08@baylibre.com>
Hi Neil,
On Fri, 30 Aug 2019 at 13:01, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> On 29/08/2019 20:35, Anand Moon wrote:
> > Hi Neil,
> >
> > On Thu, 29 Aug 2019 at 13:58, Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>
> >> On 28/08/2019 22:27, Anand Moon wrote:
> >>> Below small changes help re-configure or fix missing inter linking
> >>> of regulator node.
> >>>
> >>> Changes based top on my prevoius series.
> >>
> >> For the serie:
> >> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> >>
> >
> > Thanks for your review.
> >
> >>>
> >>> [0] https://patchwork.kernel.org/cover/11113091/
> >>>
> >>> TOOD: Add support for DVFS GXBB odroid board in next series.
> >>
> >> I'm curious how you will do this !
> >
> > I was just studying you previous series on how you have implemented
> > this feature for C1, N2 and VIM3 boards.
> >
> > [0] https://patchwork.kernel.org/cover/11114125/
> >
> > I started gathering key inputs needed for this ie *clk / pwm*
> > like VDDCPU and VDDE clk changes.
> >
> > But it looks like of the complex clk framework needed, so I leave this to the
> > expert like your team of developers to do this much quick and efficiently.
>
> On GXBB, GXL, GXM and AXG SoCs, CPU Frequency setting and PWM Regulator setup is
> done by the SCPI Co-processor via the SCPI protocol.
>
> Thus, we should not handle it from Linux, and even if we could, we don't have the
> registers documentation of the CPU clusters clock tree.
>
Ok thanks.
> SCPI works fine on all tested devices, except Odroid-C2, because Hardkernel left
> the > 1.5GHz freq in the initial SCPI tables loaded by the BL2, i.e. packed with U-Boot.
> Nowadays they have removed the bad frequencies, but still some devices uses the old
> bootloader.
>
> But in the SCPI case we trust the table returned by the firmware and use it as-in,
> and there is no (simple ?) way to override the table and set a max frequency.
>
> This is why we disabled SCPI.
>
> See https://patchwork.kernel.org/patch/9500175/
I have quickly enable this on my board and here the cpufreq info
[alarm@alarm ~]$ cpupower frequency-info
analyzing CPU 0:
driver: scpi-cpufreq
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 200 us
hardware limits: 100.0 MHz - 1.54 GHz
available frequency steps: 100.0 MHz, 250 MHz, 500 MHz, 1000 MHz,
1.30 GHz, 1.54 GHz
available cpufreq governors: conservative ondemand userspace
powersave performance schedutil
current policy: frequency should be within 100.0 MHz and 1.54 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 250 MHz (asserted by call to kernel)
I did some simple stress testing and observed the freq scaling is
working fine when cpufreq governor is set to ondemand.
Powertop output.
Package | CPU 0
100 MHz 5.2% | 100 MHz 1.6%
250 MHz 4.4% | 250 MHz 4.3%
500 MHz 2.6% | 500 MHz 2.4%
1000 MHz 0.5% | 1000 MHz 0.3%
1296 MHz 0.2% | 1296 MHz 0.1%
1.54 GHz 0.2% | 1.54 GHz 0.1%
Idle 86.9% | Idle 91.2%
Here the output on the linaro's pm-qa testing for cpufreq.
[1] https://pastebin.com/h880WATn
Almost all the test case pass with this one as off now.
Best Regards
-Anand
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/8] videodev2.h: add V4L2_DEC_CMD_FLUSH
From: Alexandre Courbot @ 2019-08-30 9:38 UTC (permalink / raw)
To: Jernej Skrabec
Cc: devel, Linux Media Mailing List, Pawel Osciak, jonas, gregkh,
Chen-Yu Tsai, mripard, Tomasz Figa, Paul Kocialkowski,
Kyungmin Park, moderated list:ARM/Mediatek SoC support,
Hans Verkuil, Mauro Carvalho Chehab, Ezequiel Garcia, LKML,
Marek Szyprowski
In-Reply-To: <20190822194500.2071-3-jernej.skrabec@siol.net>
On Fri, Aug 23, 2019 at 4:45 AM Jernej Skrabec <jernej.skrabec@siol.net> wrote:
>
> From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
>
> Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
>
> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++++++++++-
> Documentation/media/videodev2.h.rst.exceptions | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> index 57f0066f4cff..0bffef6058f7 100644
> --- a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> @@ -208,7 +208,16 @@ introduced in Linux 3.3. They are, however, mandatory for stateful mem2mem decod
> been started yet, the driver will return an ``EPERM`` error code. When
> the decoder is already running, this command does nothing. No
> flags are defined for this command.
> -
> + * - ``V4L2_DEC_CMD_FLUSH``
> + - 4
> + - Flush any held capture buffers. Only valid for stateless decoders,
> + and only if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` was set.
> + This command is typically used when the application reached the
> + end of the stream and the last output buffer had the
> + ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
> + dequeueing the last capture buffer containing the last decoded frame.
> + So this command can be used to explicitly flush that last decoded
> + frame.
Just for safety, can we also specify that it is valid to call this
command even if no buffer was held (in which case it is a no-op), as
this can help make user-space code simpler?
>
> Return Value
> ============
> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
> index adeb6b7a15cb..a79028e4d929 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -434,6 +434,7 @@ replace define V4L2_DEC_CMD_START decoder-cmds
> replace define V4L2_DEC_CMD_STOP decoder-cmds
> replace define V4L2_DEC_CMD_PAUSE decoder-cmds
> replace define V4L2_DEC_CMD_RESUME decoder-cmds
> +replace define V4L2_DEC_CMD_FLUSH decoder-cmds
>
> replace define V4L2_DEC_CMD_START_MUTE_AUDIO decoder-cmds
> replace define V4L2_DEC_CMD_PAUSE_TO_BLACK decoder-cmds
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 4fa9f543742d..91a79e16089c 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1978,6 +1978,7 @@ struct v4l2_encoder_cmd {
> #define V4L2_DEC_CMD_STOP (1)
> #define V4L2_DEC_CMD_PAUSE (2)
> #define V4L2_DEC_CMD_RESUME (3)
> +#define V4L2_DEC_CMD_FLUSH (4)
>
> /* Flags for V4L2_DEC_CMD_START */
> #define V4L2_DEC_CMD_START_MUTE_AUDIO (1 << 0)
> --
> 2.22.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH ARM64 v4.4 V3 01/44] arm64: barrier: Add CSDB macros to control data-value prediction
From: Mark Rutland @ 2019-08-30 9:39 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <4ba4e0d015f2e044e3eaf57e1239ae3e12d5a80e.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:46PM +0530, Viresh Kumar wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> commit 669474e772b952b14f4de4845a1558fd4c0414a4 upstream.
>
> For CPUs capable of data value prediction, CSDB waits for any outstanding
> predictions to architecturally resolve before allowing speculative execution
> to continue. Provide macros to expose it to the arch code.
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/assembler.h | 7 +++++++
> arch/arm64/include/asm/barrier.h | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index f68abb17aa4b..683c2875278f 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -95,6 +95,13 @@
> dmb \opt
> .endm
>
> +/*
> + * Value prediction barrier
> + */
> + .macro csdb
> + hint #20
> + .endm
> +
> #define USER(l, x...) \
> 9999: x; \
> .section __ex_table,"a"; \
> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index f2d2c0bbe21b..574486634c62 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -28,6 +28,8 @@
> #define dmb(opt) asm volatile("dmb " #opt : : : "memory")
> #define dsb(opt) asm volatile("dsb " #opt : : : "memory")
>
> +#define csdb() asm volatile("hint #20" : : : "memory")
> +
> #define mb() dsb(sy)
> #define rmb() dsb(ld)
> #define wmb() dsb(st)
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 v4.4 V3 02/44] arm64: Implement array_index_mask_nospec()
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <a01785b993e2b39864ee0cab09695ae23a02b2f5.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:47PM +0530, Viresh Kumar wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> commit 022620eed3d0bc4bf2027326f599f5ad71c2ea3f upstream.
>
> Provide an optimised, assembly implementation of array_index_mask_nospec()
> for arm64 so that the compiler is not in a position to transform the code
> in ways which affect its ability to inhibit speculation (e.g. by introducing
> conditional branches).
>
> This is similar to the sequence used by x86, modulo architectural differences
> in the carry/borrow flags.
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/barrier.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
> index 574486634c62..7c25e3e11b6d 100644
> --- a/arch/arm64/include/asm/barrier.h
> +++ b/arch/arm64/include/asm/barrier.h
> @@ -37,6 +37,27 @@
> #define dma_rmb() dmb(oshld)
> #define dma_wmb() dmb(oshst)
>
> +/*
> + * Generate a mask for array_index__nospec() that is ~0UL when 0 <= idx < sz
> + * and 0 otherwise.
> + */
> +#define array_index_mask_nospec array_index_mask_nospec
> +static inline unsigned long array_index_mask_nospec(unsigned long idx,
> + unsigned long sz)
> +{
> + unsigned long mask;
> +
> + asm volatile(
> + " cmp %1, %2\n"
> + " sbc %0, xzr, xzr\n"
> + : "=r" (mask)
> + : "r" (idx), "Ir" (sz)
> + : "cc");
> +
> + csdb();
> + return mask;
> +}
> +
> #define smp_mb() dmb(ish)
> #define smp_rmb() dmb(ishld)
> #define smp_wmb() dmb(ishst)
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 v4.4 V3 03/44] arm64: move TASK_* definitions to <asm/processor.h>
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <687d13717c9736bc33b9128bd09371fc0453fbdd.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:48PM +0530, Viresh Kumar wrote:
> From: Yury Norov <ynorov@caviumnetworks.com>
>
> commit eef94a3d09aab437c8c254de942d8b1aa76455e2 upstream.
>
> ILP32 series [1] introduces the dependency on <asm/is_compat.h> for
> TASK_SIZE macro. Which in turn requires <asm/thread_info.h>, and
> <asm/thread_info.h> include <asm/memory.h>, giving a circular dependency,
> because TASK_SIZE is currently located in <asm/memory.h>.
>
> In other architectures, TASK_SIZE is defined in <asm/processor.h>, and
> moving TASK_SIZE there fixes the problem.
>
> Discussion: https://patchwork.kernel.org/patch/9929107/
>
> [1] https://github.com/norov/linux/tree/ilp32-next
>
> CC: Will Deacon <will.deacon@arm.com>
> CC: Laura Abbott <labbott@redhat.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/memory.h | 15 ---------------
> arch/arm64/include/asm/processor.h | 21 +++++++++++++++++++++
> arch/arm64/kernel/entry.S | 2 +-
> 3 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b42b930cc19a..959a1e9188fe 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -43,8 +43,6 @@
> * (VA_BITS - 1))
> * VA_BITS - the maximum number of bits for virtual addresses.
> * VA_START - the first kernel virtual address.
> - * TASK_SIZE - the maximum size of a user space task.
> - * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
> * The module space lives between the addresses given by TASK_SIZE
> * and PAGE_OFFSET - it must be within 128MB of the kernel text.
> */
> @@ -58,19 +56,6 @@
> #define PCI_IO_END (MODULES_VADDR - SZ_2M)
> #define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE)
> #define FIXADDR_TOP (PCI_IO_START - SZ_2M)
> -#define TASK_SIZE_64 (UL(1) << VA_BITS)
> -
> -#ifdef CONFIG_COMPAT
> -#define TASK_SIZE_32 UL(0x100000000)
> -#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
> - TASK_SIZE_32 : TASK_SIZE_64)
> -#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
> - TASK_SIZE_32 : TASK_SIZE_64)
> -#else
> -#define TASK_SIZE TASK_SIZE_64
> -#endif /* CONFIG_COMPAT */
> -
> -#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
>
> /*
> * Physical vs virtual RAM address space conversion. These are
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index d08559528927..75d9ef6c457c 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -19,6 +19,10 @@
> #ifndef __ASM_PROCESSOR_H
> #define __ASM_PROCESSOR_H
>
> +#define TASK_SIZE_64 (UL(1) << VA_BITS)
> +
> +#ifndef __ASSEMBLY__
> +
> /*
> * Default implementation of macro that returns current
> * instruction pointer ("program counter").
> @@ -36,6 +40,22 @@
> #include <asm/types.h>
>
> #ifdef __KERNEL__
> +/*
> + * TASK_SIZE - the maximum size of a user space task.
> + * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
> + */
> +#ifdef CONFIG_COMPAT
> +#define TASK_SIZE_32 UL(0x100000000)
> +#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
> + TASK_SIZE_32 : TASK_SIZE_64)
> +#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
> + TASK_SIZE_32 : TASK_SIZE_64)
> +#else
> +#define TASK_SIZE TASK_SIZE_64
> +#endif /* CONFIG_COMPAT */
> +
> +#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
> +
> #define STACK_TOP_MAX TASK_SIZE_64
> #ifdef CONFIG_COMPAT
> #define AARCH32_VECTORS_BASE 0xffff0000
> @@ -188,4 +208,5 @@ static inline void spin_lock_prefetch(const void *x)
>
> int cpu_enable_pan(void *__unused);
>
> +#endif /* __ASSEMBLY__ */
> #endif /* __ASM_PROCESSOR_H */
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 586326981769..c849be9231bb 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -27,7 +27,7 @@
> #include <asm/cpufeature.h>
> #include <asm/errno.h>
> #include <asm/esr.h>
> -#include <asm/memory.h>
> +#include <asm/processor.h>
> #include <asm/thread_info.h>
> #include <asm/asm-uaccess.h>
> #include <asm/unistd.h>
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 v4.4 V3 04/44] arm64: Make USER_DS an inclusive limit
From: Mark Rutland @ 2019-08-30 9:40 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <55f8561f1ee207237fdcfbc8c5dc043be06d3de6.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:49PM +0530, Viresh Kumar wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> commit 51369e398d0d33e8f524314e672b07e8cf870e79 upstream.
>
> Currently, USER_DS represents an exclusive limit while KERNEL_DS is
> inclusive. In order to do some clever trickery for speculation-safe
> masking, we need them both to behave equivalently - there aren't enough
> bits to make KERNEL_DS exclusive, so we have precisely one option. This
> also happens to correct a longstanding false negative for a range
> ending on the very top byte of kernel memory.
>
> Mark Rutland points out that we've actually got the semantics of
> addresses vs. segments muddled up in most of the places we need to
> amend, so shuffle the {USER,KERNEL}_DS definitions around such that we
> can correct those properly instead of just pasting "-1"s everywhere.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> [ 4.4: Dropped changes from fault.c and fixed minor rebase conflict ]
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com> [v4.4 backport]
Mark.
> ---
> arch/arm64/include/asm/processor.h | 3 ++
> arch/arm64/include/asm/uaccess.h | 45 +++++++++++++++++-------------
> arch/arm64/kernel/entry.S | 4 +--
> 3 files changed, 31 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 75d9ef6c457c..ff1449c25bf4 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -21,6 +21,9 @@
>
> #define TASK_SIZE_64 (UL(1) << VA_BITS)
>
> +#define KERNEL_DS UL(-1)
> +#define USER_DS (TASK_SIZE_64 - 1)
> +
> #ifndef __ASSEMBLY__
>
> /*
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 829fa6d3e561..c625cc5531fc 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -56,10 +56,7 @@ struct exception_table_entry
>
> extern int fixup_exception(struct pt_regs *regs);
>
> -#define KERNEL_DS (-1UL)
> #define get_ds() (KERNEL_DS)
> -
> -#define USER_DS TASK_SIZE_64
> #define get_fs() (current_thread_info()->addr_limit)
>
> static inline void set_fs(mm_segment_t fs)
> @@ -87,22 +84,32 @@ static inline void set_fs(mm_segment_t fs)
> * Returns 1 if the range is valid, 0 otherwise.
> *
> * This is equivalent to the following test:
> - * (u65)addr + (u65)size <= current->addr_limit
> - *
> - * This needs 65-bit arithmetic.
> + * (u65)addr + (u65)size <= (u65)current->addr_limit + 1
> */
> -#define __range_ok(addr, size) \
> -({ \
> - unsigned long __addr = (unsigned long __force)(addr); \
> - unsigned long flag, roksum; \
> - __chk_user_ptr(addr); \
> - asm("adds %1, %1, %3; ccmp %1, %4, #2, cc; cset %0, ls" \
> - : "=&r" (flag), "=&r" (roksum) \
> - : "1" (__addr), "Ir" (size), \
> - "r" (current_thread_info()->addr_limit) \
> - : "cc"); \
> - flag; \
> -})
> +static inline unsigned long __range_ok(unsigned long addr, unsigned long size)
> +{
> + unsigned long limit = current_thread_info()->addr_limit;
> +
> + __chk_user_ptr(addr);
> + asm volatile(
> + // A + B <= C + 1 for all A,B,C, in four easy steps:
> + // 1: X = A + B; X' = X % 2^64
> + " adds %0, %0, %2\n"
> + // 2: Set C = 0 if X > 2^64, to guarantee X' > C in step 4
> + " csel %1, xzr, %1, hi\n"
> + // 3: Set X' = ~0 if X >= 2^64. For X == 2^64, this decrements X'
> + // to compensate for the carry flag being set in step 4. For
> + // X > 2^64, X' merely has to remain nonzero, which it does.
> + " csinv %0, %0, xzr, cc\n"
> + // 4: For X < 2^64, this gives us X' - C - 1 <= 0, where the -1
> + // comes from the carry in being clear. Otherwise, we are
> + // testing X' - C == 0, subject to the previous adjustments.
> + " sbcs xzr, %0, %1\n"
> + " cset %0, ls\n"
> + : "+r" (addr), "+r" (limit) : "Ir" (size) : "cc");
> +
> + return addr;
> +}
>
> /*
> * When dealing with data aborts, watchpoints, or instruction traps we may end
> @@ -111,7 +118,7 @@ static inline void set_fs(mm_segment_t fs)
> */
> #define untagged_addr(addr) sign_extend64(addr, 55)
>
> -#define access_ok(type, addr, size) __range_ok(addr, size)
> +#define access_ok(type, addr, size) __range_ok((unsigned long)(addr), size)
> #define user_addr_max get_fs
>
> /*
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index c849be9231bb..4c5013b09dcb 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -96,10 +96,10 @@
> .else
> add x21, sp, #S_FRAME_SIZE
> get_thread_info tsk
> - /* Save the task's original addr_limit and set USER_DS (TASK_SIZE_64) */
> + /* Save the task's original addr_limit and set USER_DS */
> ldr x20, [tsk, #TI_ADDR_LIMIT]
> str x20, [sp, #S_ORIG_ADDR_LIMIT]
> - mov x20, #TASK_SIZE_64
> + mov x20, #USER_DS
> str x20, [tsk, #TI_ADDR_LIMIT]
> .endif /* \el == 0 */
> mrs x22, elr_el1
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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