* Re: [PATCH] [v2] hwrng: exynos - Fix runtime PM imbalance on error
From: Lukasz Stelmach @ 2020-05-22 9:07 UTC (permalink / raw)
To: Dinghao Liu
Cc: linux-samsung-soc, Herbert Xu, Arnd Bergmann,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, kjlu, linux-kernel,
Krzysztof Kozlowski, Kukjin Kim, linux-crypto, Matt Mackall,
linux-arm-kernel
In-Reply-To: <20200522011659.26727-1-dinghao.liu@zju.edu.cn>
[-- Attachment #1.1: Type: text/plain, Size: 1683 bytes --]
It was <2020-05-22 pią 09:16>, when Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
> ---
>
> Changelog:
>
> v2: -- Remove unnecessary 'err_clock' label
> ---
> drivers/char/hw_random/exynos-trng.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
Reviewed-by: Lukasz Stelmach <l.stelmach@samsung.com>
Thank you.
> diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
> index 8e1fe3f8dd2d..8393b898a50e 100644
> --- a/drivers/char/hw_random/exynos-trng.c
> +++ b/drivers/char/hw_random/exynos-trng.c
> @@ -142,13 +142,13 @@ static int exynos_trng_probe(struct platform_device *pdev)
> if (IS_ERR(trng->clk)) {
> ret = PTR_ERR(trng->clk);
> dev_err(&pdev->dev, "Could not get clock.\n");
> - goto err_clock;
> + goto err_pm_get;
> }
>
> ret = clk_prepare_enable(trng->clk);
> if (ret) {
> dev_err(&pdev->dev, "Could not enable the clk.\n");
> - goto err_clock;
> + goto err_pm_get;
> }
>
> ret = devm_hwrng_register(&pdev->dev, &trng->rng);
> @@ -164,10 +164,8 @@ static int exynos_trng_probe(struct platform_device *pdev)
> err_register:
> clk_disable_unprepare(trng->clk);
>
> -err_clock:
> - pm_runtime_put_sync(&pdev->dev);
> -
> err_pm_get:
> + pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> return ret;
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 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] clk: imx8mp: Set the correct parent for audio_root_clk
From: Abel Vesa @ 2020-05-22 9:12 UTC (permalink / raw)
To: Aisheng Dong
Cc: Stephen Boyd, Mike Turquette, Linux Kernel Mailing List,
dl-linux-imx, Sascha Hauer, Shawn Guo, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM6PR04MB49664013B43C46422C0195A780AA0@AM6PR04MB4966.eurprd04.prod.outlook.com>
On 20-04-30 10:18:24, Aisheng Dong wrote:
> > From: Abel Vesa <abel.vesa@nxp.com>
> > Sent: Thursday, April 30, 2020 6:11 PM
> >
Sorry I didn't answer the other ones earlier. See below.
> > On 20-04-28 08:15:51, Aisheng Dong wrote:
> > > > From: Abel Vesa <abel.vesa@nxp.com>
> > > > Sent: Monday, April 27, 2020 11:11 PM
> > > >
> > > > Instead of ipg_root, the parent needs to be ipg_audio_root.
> > > >
> > > > Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> > >
> > > I have a few doubts about this patch:
> > > 1. From latest RM, it seems CCGR101 (0x4650) is a shared gate for many audio
> > instances.
Yes. This is true. I'm working on adding the shared gate now.
> > > 2. If this patch is about AUDIO_AHB_CLK_ROOT, then it's parent is
> > AHB[POST_PODF] from the clock tree in RM.
> > > Not quite understand why this patch changes to IPG[POST_PODF]. Is this RM
> > incorrect issue?
Yes. Right again. It needs to be the IMX8MP_CLK_AUDIO_AHB. Will change that now.
> > >
> > > BTW, if this patch is taken from someone else, we usually better keep the
> > original author if not fundamental changes.
> > >
> >
> > I made this change at the suggestion from S.j. Wang.
> > I'm the original author in linux-nxp (internal tree).
> >
>
> That's fine. Then please ignore my "stupid" reminder. 😊
> BTW, how about other questions?
>
> Regards
> Aisheng
>
> > > Regards
> > > Aisheng
> > >
> > > > ---
> > > > drivers/clk/imx/clk-imx8mp.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/clk/imx/clk-imx8mp.c
> > > > b/drivers/clk/imx/clk-imx8mp.c index 41469e2..dcdfc9d 100644
> > > > --- a/drivers/clk/imx/clk-imx8mp.c
> > > > +++ b/drivers/clk/imx/clk-imx8mp.c
> > > > @@ -727,7 +727,7 @@ static int imx8mp_clocks_probe(struct
> > > > platform_device
> > > > *pdev)
> > > > hws[IMX8MP_CLK_HDMI_ROOT] =
> > imx_clk_hw_gate4("hdmi_root_clk",
> > > > "hdmi_axi", ccm_base + 0x45f0, 0);
> > > > hws[IMX8MP_CLK_TSENSOR_ROOT] =
> > > > imx_clk_hw_gate4("tsensor_root_clk", "ipg_root", ccm_base + 0x4620, 0);
> > > > hws[IMX8MP_CLK_VPU_ROOT] = imx_clk_hw_gate4("vpu_root_clk",
> > > > "vpu_bus", ccm_base + 0x4630, 0);
> > > > - hws[IMX8MP_CLK_AUDIO_ROOT] = imx_clk_hw_gate4("audio_root_clk",
> > > > "ipg_root", ccm_base + 0x4650, 0);
> > > > + hws[IMX8MP_CLK_AUDIO_ROOT] = imx_clk_hw_gate4("audio_root_clk",
> > > > +"ipg_audio_root", ccm_base + 0x4650, 0);
> > > >
> > > > hws[IMX8MP_CLK_ARM] = imx_clk_hw_cpu("arm", "arm_a53_core",
> > > > hws[IMX8MP_CLK_A53_CORE]->clk,
> > > > --
> > > > 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
* Re: [PATCH 04/15] PCI: brcmstb: Add compatibily of other chips
From: Nicolas Saenz Julienne @ 2020-05-22 9:17 UTC (permalink / raw)
To: Jim Quinlan
Cc: Rob Herring, Lorenzo Pieralisi,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS, open list,
Florian Fainelli, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <CA+-6iNyqtFguHJ=sB=nKoghX6PR9ve5OuyafPw88mfSmhe+c8Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 924 bytes --]
On Thu, 2020-05-21 at 15:35 -0400, Jim Quinlan wrote:
> On Wed, May 20, 2020 at 7:51 AM Nicolas Saenz Julienne
[...]
> > > /*
> > > @@ -602,20 +667,21 @@ static struct pci_ops brcm_pcie_ops = {
> > >
> > > static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
> > > u32
> > > val)
> > > {
> > > - u32 tmp;
> > > + u32 tmp, mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
> > > + u32 shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
> >
> > I don't think you need shift here, IIUC u32p_replace_bits() will take care
> > of
> > all the masking and shifting internally, moreover, you'd be able to drop the
> > shift entry from reg_field_info.
> I believe that u32p_replace_bits requires at least one of the value or
> mask to be compile time constants to work and we don't have that here.
Of course, sorry for the noise then.
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 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 04/16] arm64: dts: arm: Fix node address fields
From: André Przywara @ 2020-05-22 9:25 UTC (permalink / raw)
To: Liviu Dudau, Robin Murphy
Cc: Mark Rutland, Rob Herring, Lorenzo Pieralisi, devicetree,
Sudeep Holla, linux-arm-kernel
In-Reply-To: <20200521144059.GZ159988@e110455-lin.cambridge.arm.com>
On 21/05/2020 15:40, Liviu Dudau wrote:
Hi,
> On Tue, May 05, 2020 at 06:18:19PM +0100, Robin Murphy wrote:
>> On 2020-05-05 5:52 pm, Andre Przywara wrote:
>>> The Arm Ltd. boards were using an outdated address convention in the DT
>>> node names, by separating the high from the low 32-bits of an address by
>>> a comma.
>>
>> I thought that historically that was deliberate, since the actual thing
>> being encoded is <chip select>,<address>, rather than just cosmetically
>> splitting a 64-bit address value?
>>
>> Or maybe I'm thinking too far back and things have already changed in the
>> meantime :/
>
> Robin is right, if you look in the "ARM Motherboard Express µATX Technical
> Reference Manual", in the RS1 memory map (aka "Cortex-A Series memory map")
> the Ethernet for example is at CS2 offset 0x02000000. CS2 area is between
> 0x18000000 and 0x1c000000. So actual physical address for LAN9118 is
> 0x1a000000.
>
> You might want to drop this patch or convert to physical addresses.
Well, this patch is purely cosmetically, because it just changes the
node names, which have no particular meaning. But the regexp in
dt-schema for simple-bus denies commas after the '@' sign, so we get a
warning.
The question whether we actually need to model the chip select lines in
the DT is separate: we could of course just use an empty ranges;
property here, but that would be an extra patch.
If people see some value in this, I can surely post something.
Cheers,
Andre.
>> Robin.
>>
>>> Remove the comma from the node name suffix to be DT spec compliant.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 10 +++++-----
>>> arch/arm64/boot/dts/arm/foundation-v8.dtsi | 4 ++--
>>> arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 6 +++---
>>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi | 2 +-
>>> arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 6 +++---
>>> 5 files changed, 14 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>> index 5c183483ec3b..8010cdcdb37a 100644
>>> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>> @@ -31,7 +31,7 @@
>>> #interrupt-cells = <1>;
>>> ranges;
>>> - nor_flash: flash@0,00000000 {
>>> + nor_flash: flash@0 {
>>> compatible = "arm,vexpress-flash", "cfi-flash";
>>> reg = <0 0x00000000 0x04000000>,
>>> <4 0x00000000 0x04000000>;
>>> @@ -41,13 +41,13 @@
>>> };
>>> };
>>> - psram@1,00000000 {
>>> + psram@100000000 {
>>> compatible = "arm,vexpress-psram", "mtd-ram";
>>> reg = <1 0x00000000 0x02000000>;
>>> bank-width = <4>;
>>> };
>>> - ethernet@2,02000000 {
>>> + ethernet@202000000 {
>>> compatible = "smsc,lan9118", "smsc,lan9115";
>>> reg = <2 0x02000000 0x10000>;
>>> interrupts = <15>;
>>> @@ -59,14 +59,14 @@
>>> vddvario-supply = <&v2m_fixed_3v3>;
>>> };
>>> - usb@2,03000000 {
>>> + usb@203000000 {
>>> compatible = "nxp,usb-isp1761";
>>> reg = <2 0x03000000 0x20000>;
>>> interrupts = <16>;
>>> port1-otg;
>>> };
>>> - iofpga@3,00000000 {
>>> + iofpga@300000000 {
>>> compatible = "simple-bus";
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
>>> index 12f039fa3dad..e26b492795c5 100644
>>> --- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi
>>> +++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
>>> @@ -151,7 +151,7 @@
>>> <0 0 41 &gic 0 0 GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
>>> <0 0 42 &gic 0 0 GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
>>> - ethernet@2,02000000 {
>>> + ethernet@202000000 {
>>> compatible = "smsc,lan91c111";
>>> reg = <2 0x02000000 0x10000>;
>>> interrupts = <15>;
>>> @@ -178,7 +178,7 @@
>>> clock-output-names = "v2m:refclk32khz";
>>> };
>>> - iofpga@3,00000000 {
>>> + iofpga@300000000 {
>>> compatible = "simple-bus";
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
>>> index e3983ded3c3c..d5cefddde08c 100644
>>> --- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
>>> +++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
>>> @@ -103,7 +103,7 @@
>>> };
>>> };
>>> - flash@0,00000000 {
>>> + flash@0 {
>>> /* 2 * 32MiB NOR Flash memory mounted on CS0 */
>>> compatible = "arm,vexpress-flash", "cfi-flash";
>>> reg = <0 0x00000000 0x04000000>;
>>> @@ -120,7 +120,7 @@
>>> };
>>> };
>>> - ethernet@2,00000000 {
>>> + ethernet@200000000 {
>>> compatible = "smsc,lan9118", "smsc,lan9115";
>>> reg = <2 0x00000000 0x10000>;
>>> interrupts = <3>;
>>> @@ -133,7 +133,7 @@
>>> vddvario-supply = <&mb_fixed_3v3>;
>>> };
>>> - iofpga@3,00000000 {
>>> + iofpga@300000000 {
>>> compatible = "simple-bus";
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
>>> index 60703b5763c6..350cbf17e8b4 100644
>>> --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
>>> +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi
>>> @@ -9,7 +9,7 @@
>>> motherboard {
>>> arm,v2m-memory-map = "rs2";
>>> - iofpga@3,00000000 {
>>> + iofpga@300000000 {
>>> virtio-p9@140000 {
>>> compatible = "virtio,mmio";
>>> reg = <0x140000 0x200>;
>>> diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>>> index e333c8d2d0e4..d1bfa62ca073 100644
>>> --- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>>> +++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
>>> @@ -17,14 +17,14 @@
>>> #interrupt-cells = <1>;
>>> ranges;
>>> - flash@0,00000000 {
>>> + flash@0 {
>>> compatible = "arm,vexpress-flash", "cfi-flash";
>>> reg = <0 0x00000000 0x04000000>,
>>> <4 0x00000000 0x04000000>;
>>> bank-width = <4>;
>>> };
>>> - ethernet@2,02000000 {
>>> + ethernet@202000000 {
>>> compatible = "smsc,lan91c111";
>>> reg = <2 0x02000000 0x10000>;
>>> interrupts = <15>;
>>> @@ -51,7 +51,7 @@
>>> clock-output-names = "v2m:refclk32khz";
>>> };
>>> - iofpga@3,00000000 {
>>> + iofpga@300000000 {
>>> compatible = "simple-bus";
>>> #address-cells = <1>;
>>> #size-cells = <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: [RESEND PATCH v14 04/11] pwm: clps711x: Cast period to u32 before use as divisor
From: Daniel Thompson @ 2020-05-22 9:37 UTC (permalink / raw)
To: Guru Das Srinagesh
Cc: linux-arm-kernel, linux-pwm, Arnd Bergmann, David Collins,
Stephen Boyd, linux-kernel, Thierry Reding, Geert Uytterhoeven,
Dan Carpenter, Uwe Kleine-König, Joe Perches,
Subbaraman Narayanamurthy, Lee Jones, Guenter Roeck
In-Reply-To: <20200521202525.GA24026@codeaurora.org>
On Thu, May 21, 2020 at 01:25:25PM -0700, Guru Das Srinagesh wrote:
> On Thu, May 21, 2020 at 11:19:34AM +0100, Daniel Thompson wrote:
> > On Wed, May 20, 2020 at 03:55:57PM -0700, Guru Das Srinagesh wrote:
> > > Since the PWM framework is switching struct pwm_args.period's datatype
> > > to u64, prepare for this transition by typecasting it to u32.
> > >
> > > Also, since the dividend is still a 32-bit number, any divisor greater
> > > than the numerator will cause the quotient to be zero, so return 0 in
> > > that case to efficiently skip the division.
> > >
> > > Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> > > ---
> > > drivers/pwm/pwm-clps711x.c | 5 ++++-
> > > 1 file changed, 4 insertions(+), 1 deletion(-)> > >
> > > diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
> > > index 924d39a..da771b1 100644
> > > --- a/drivers/pwm/pwm-clps711x.c
> > > +++ b/drivers/pwm/pwm-clps711x.c
> > > @@ -43,7 +43,10 @@ static void clps711x_pwm_update_val(struct clps711x_chip *priv, u32 n, u32 v)
> > > static unsigned int clps711x_get_duty(struct pwm_device *pwm, unsigned int v)
> > > {
> > > /* Duty cycle 0..15 max */
> > > - return DIV_ROUND_CLOSEST(v * 0xf, pwm->args.period);
> > > + if (pwm->args.period > (v * 0xf))
> > > + return 0;
> >
> > This doesn't look right to me.
> >
> > DIV_ROUND_CLOSEST() does rounded division and the short circuit doesn't
> > implement that.
>
> My initial patch [1] was to simply use DIV64_U64_ROUND_CLOSEST(), but I
> got review feedback to add a short-circuit (same thread, [2]). I feel
> like I should skip the short-circuiting and type casting and simply just
> use DIV64_U64_ROUND_CLOSEST() - what do you think?
A trivial review of pwm-clps711x.c suggests that the period is always
32-bit anyway so why not just throw away the short circuit entirely and
replace with a comment saying that CLPS711X has a hard coded period
that is always >1000000000 ?
Daniel.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V6, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Dongchun Zhu @ 2020-05-22 9:26 UTC (permalink / raw)
To: Tomasz Figa
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, louis.kuo, bgolaszewski,
sj.huang, robh+dt, linux-mediatek, dongchun.zhu, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200521195113.GC14214@chromium.org>
Hi Tomasz,
Thanks for the review. My replies are as below.
On Thu, 2020-05-21 at 19:51 +0000, Tomasz Figa wrote:
> Hi Dongchun, Sakari,
>
> On Mon, May 18, 2020 at 09:27:31PM +0800, Dongchun Zhu wrote:
> > Add a V4L2 sub-device driver for DW9768 voice coil motor, providing
> > control to set the desired focus via IIC serial interface.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/media/i2c/Kconfig | 13 ++
> > drivers/media/i2c/Makefile | 1 +
> > drivers/media/i2c/dw9768.c | 515 +++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 530 insertions(+)
> > create mode 100644 drivers/media/i2c/dw9768.c
> [snip]
> > +/*
> > + * DW9768_AAC_PRESC_REG & DW9768_AAC_TIME_REG determine VCM operation time.
> > + * If DW9768_AAC_PRESC_REG is 0x41, and DW9768_AAC_TIME_REG is 0x39, VCM mode
> > + * would be AAC3, Operation Time would be 0.70xTvib, that is 8.40ms.
> > + */
> > +#define DW9768_MOVE_DELAY_US 8400
> > +#define DW9768_STABLE_TIME_US 20000
>
> These times are only valid with the specific settings mentioned in the
> comment. If one sets different settings in DT, the driver would apply
> incorrect delays. Rather than hardcoded, they should be computed based
> on the configured values.
>
> That said, I wonder if we're not digging too deep now. Sakari, do you
> think we could take a step back, remove the optional DT properties and
> just support the fixed values for now, so that we can get a basic driver
> upstream first without doubling the effort?
>
Thanks for the reminder.
Yes, here DW9768_MOVE_DELAY_US actually represents Operation Time,
which is dependent upon board-specific settings that defined in DT.
For instance, for one given board, if aac-mode is 2, aac-timing is 0x39,
clock-presc is 1, then Operation Time would be 0.70*(6.3ms+57*0.1ms)*1 =
8.4ms.
> > +
> > +static const char * const dw9768_supply_names[] = {
> > + "vin", /* I2C I/O interface power */
> > + "vdd", /* VCM power */
> > +};
> > +
> > +/* dw9768 device structure */
> > +struct dw9768 {
> > + struct regulator_bulk_data supplies[ARRAY_SIZE(dw9768_supply_names)];
> > + struct v4l2_ctrl_handler ctrls;
> > + struct v4l2_ctrl *focus;
> > + struct v4l2_subdev sd;
> > +
> > + u32 aac_mode;
> > + u32 aac_timing;
> > + u32 clock_dividing_rate;
> > + bool aac_mode_control_enable;
> > + bool aact_cnt_select_enable;
> > + bool clock_dividing_rate_select_enable;
>
> nit: Separate types from names with just 1 space.
>
Fixed in next release.
> > +};
> > +
> > +static inline struct dw9768 *sd_to_dw9768(struct v4l2_subdev *subdev)
> > +{
> > + return container_of(subdev, struct dw9768, sd);
> > +}
> > +
> > +struct regval_list {
> > + u8 reg_num;
> > + u8 value;
> > +};
> > +
> > +static int dw9768_read_smbus(struct dw9768 *dw9768, unsigned char reg,
> > + unsigned char *val)
> > +{
> > + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
> > + int ret;
> > +
> > + ret = i2c_smbus_read_byte_data(client, reg);
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val = (unsigned char)ret;
> > +
> > + return 0;
> > +}
>
> Why do we need this function? Couldn't we just call
> i2c_smbus_read_byte_data() directly?
>
Fixed in next release.
> [snip]
> > +static int dw9768_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = &client->dev;
> > + struct dw9768 *dw9768;
> > + unsigned int aac_mode_select;
> > + unsigned int aac_timing_select;
> > + unsigned int clock_dividing_rate_select;
> > + unsigned int i;
> > + int ret;
> > +
> > + dw9768 = devm_kzalloc(dev, sizeof(*dw9768), GFP_KERNEL);
> > + if (!dw9768)
> > + return -ENOMEM;
> > +
> > + v4l2_i2c_subdev_init(&dw9768->sd, client, &dw9768_ops);
> > + dw9768->aac_mode_control_enable = false;
> > + dw9768->aact_cnt_select_enable = false;
> > + dw9768->clock_dividing_rate_select_enable = false;
>
> devm_kzalloc() initializes the memory to zero, so no need to set anything
> to false explicitly.
>
Thanks for the reminder.
Yes, these parameters shall not be needed to initialized as zeros.
> > +
> > + /* Optional indication of AAC mode select */
> > + ret = fwnode_property_read_u32(dev_fwnode(dev), "dongwoon,aac-mode",
> > + &aac_mode_select);
> > +
> > + if (!ret) {
> > + dw9768->aac_mode_control_enable = true;
> > + dw9768->aac_mode = aac_mode_select;
>
> How about making aac_mode a signed int and assigning -1 by
> default? Then we don't need two separate fields in the struct.
>
Good idea.
> > + }
> > +
> > + /* Optional indication of VCM internal clock dividing rate select */
> > + ret = fwnode_property_read_u32(dev_fwnode(dev),
> > + "dongwoon,clock-dividing-rate",
> > + &clock_dividing_rate_select);
> > +
> > + if (!ret) {
> > + dw9768->clock_dividing_rate_select_enable = true;
> > + dw9768->clock_dividing_rate = clock_dividing_rate_select;
>
> Ditto.
>
Got it.
> > + }
> > +
> > + /* Optional indication of AAC Timing */
> > + ret = fwnode_property_read_u32(dev_fwnode(dev), "dongwoon,aac-timing",
> > + &aac_timing_select);
> > +
> > + if (!ret) {
> > + dw9768->aact_cnt_select_enable = true;
> > + dw9768->aac_timing = aac_timing_select;
>
> Ditto.
>
Got it.
> > + }
> > +
> > + for (i = 0; i < ARRAY_SIZE(dw9768_supply_names); i++)
> > + dw9768->supplies[i].supply = dw9768_supply_names[i];
> > +
> > + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dw9768_supply_names),
> > + dw9768->supplies);
> > + if (ret) {
> > + dev_err(dev, "failed to get regulators\n");
> > + return ret;
> > + }
> > +
> > + ret = dw9768_init_controls(dw9768);
> > + if (ret)
> > + goto entity_cleanup;
> > +
> > + dw9768->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > + dw9768->sd.internal_ops = &dw9768_int_ops;
> > +
> > + ret = media_entity_pads_init(&dw9768->sd.entity, 0, NULL);
> > + if (ret < 0)
> > + goto entity_cleanup;
> > +
> > + dw9768->sd.entity.function = MEDIA_ENT_F_LENS;
> > +
> > + pm_runtime_enable(dev);
> > + if (!pm_runtime_enabled(dev)) {
> > + ret = dw9768_runtime_resume(dev);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to power on: %d\n", ret);
> > + goto entity_cleanup;
> > + }
> > + }
> > +
> > + ret = v4l2_async_register_subdev(&dw9768->sd);
> > + if (ret < 0)
> > + goto entity_cleanup;
> > +
> > + return 0;
> > +
> > +entity_cleanup:
>
> Need to power off if the code above powered on.
>
Thanks for the reminder.
If there is something wrong with runtime PM, actuator is to be powered
on via dw9768_runtime_resume() API.
When actuator sub-device is powered on completely and async registered
successfully, we shall power off it afterwards.
> > + v4l2_ctrl_handler_free(&dw9768->ctrls);
> > + media_entity_cleanup(&dw9768->sd.entity);
> > + return ret;
> > +}
> > +
> > +static int dw9768_remove(struct i2c_client *client)
> > +{
> > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > + struct dw9768 *dw9768 = sd_to_dw9768(sd);
> > +
> > + pm_runtime_disable(&client->dev);
>
> First the device must be unregistered from the userspace. Otherwise there
> is a race condition that risks the userspace accessing the device while the
> deinitialization is happening.
>
Fixed in next release by adjusting the sequence of unregistering and
runtime PM disable.
> Best regards,
> Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 09/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus
From: Robin Murphy @ 2020-05-22 9:42 UTC (permalink / raw)
To: Rob Herring, Lorenzo Pieralisi
Cc: devicetree, Hanjun Guo, Catalin Marinas, PCI, Sudeep Holla,
Rafael J. Wysocki, Linux IOMMU, linux-acpi, Makarand Pawagi,
Marc Zyngier, Diana Craciun, Bjorn Helgaas, Will Deacon,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+h18gH2D3B-OZku6ACCgonPUJcUnrN8a5=jApsXHdB5Q@mail.gmail.com>
On 2020-05-22 00:10, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
>>
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> The existing bindings cannot be used to specify the relationship
>> between fsl-mc devices and GIC ITSes.
>>
>> Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
>> msi-map property.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> ---
>> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30 +++++++++++++++++--
>> 1 file changed, 27 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>> index 9134e9bcca56..b0813b2d0493 100644
>> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>> @@ -18,9 +18,9 @@ same hardware "isolation context" and a 10-bit value called an ICID
>> the requester.
>>
>> The generic 'iommus' property is insufficient to describe the relationship
>> -between ICIDs and IOMMUs, so an iommu-map property is used to define
>> -the set of possible ICIDs under a root DPRC and how they map to
>> -an IOMMU.
>> +between ICIDs and IOMMUs, so the iommu-map and msi-map properties are used
>> +to define the set of possible ICIDs under a root DPRC and how they map to
>> +an IOMMU and a GIC ITS respectively.
>>
>> For generic IOMMU bindings, see
>> Documentation/devicetree/bindings/iommu/iommu.txt.
>> @@ -28,6 +28,9 @@ Documentation/devicetree/bindings/iommu/iommu.txt.
>> For arm-smmu binding, see:
>> Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
>>
>> +For GICv3 and GIC ITS bindings, see:
>> +Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
>> +
>> Required properties:
>>
>> - compatible
>> @@ -119,6 +122,15 @@ Optional properties:
>> associated with the listed IOMMU, with the iommu-specifier
>> (i - icid-base + iommu-base).
>>
>> +- msi-map: Maps an ICID to a GIC ITS and associated iommu-specifier
>> + data.
>> +
>> + The property is an arbitrary number of tuples of
>> + (icid-base,iommu,iommu-base,length).
>
> I'm confused because the example has GIC ITS phandle, not an IOMMU.
>
> What is an iommu-base?
Right, I was already halfway through writing a reply to say that all the
copy-pasted "iommu" references here should be using the terminology from
the pci-msi.txt binding instead.
>> +
>> + Any ICID in the interval [icid-base, icid-base + length) is
>> + associated with the listed GIC ITS, with the iommu-specifier
>> + (i - icid-base + iommu-base).
>> Example:
>>
>> smmu: iommu@5000000 {
>> @@ -128,6 +140,16 @@ Example:
>> ...
>> };
>>
>> + gic: interrupt-controller@6000000 {
>> + compatible = "arm,gic-v3";
>> + ...
>> + its: gic-its@6020000 {
>> + compatible = "arm,gic-v3-its";
>> + msi-controller;
>> + ...
>> + };
>> + };
>> +
>> fsl_mc: fsl-mc@80c000000 {
>> compatible = "fsl,qoriq-mc";
>> reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
>> @@ -135,6 +157,8 @@ Example:
>> msi-parent = <&its>;
Side note: is it right to keep msi-parent here? It rather implies that
the MC itself has a 'native' Device ID rather than an ICID, which I
believe is not strictly true. Plus it's extra-confusing that it doesn't
specify an ID either way, since that makes it look like the legacy PCI
case that gets treated implicitly as an identity msi-map, which makes no
sense at all to combine with an actual msi-map.
>> /* define map for ICIDs 23-64 */
>> iommu-map = <23 &smmu 23 41>;
>> + /* define msi map for ICIDs 23-64 */
>> + msi-map = <23 &its 23 41>;
>
> Seeing 23 twice is odd. The numbers to the right of 'its' should be an
> ITS number space.
On about 99% of systems the values in the SMMU Stream ID and ITS Device
ID spaces are going to be the same. Nobody's going to bother carrying
*two* sets of sideband data across the interconnect if they don't have to ;)
Robin.
>> #address-cells = <3>;
>> #size-cells = <1>;
>>
>> --
>> 2.26.1
>>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64/acpi: NULL dereference reports from UBSAN at boot
From: Hanjun Guo @ 2020-05-22 9:43 UTC (permalink / raw)
To: Will Deacon, lorenzo.pieralisi
Cc: mark.rutland, rjw, linux-kernel, linux-arm-kernel
In-Reply-To: <ad521a36-c080-f761-e91b-dc38b8af08ee@huawei.com>
On 2020/5/22 16:07, Hanjun Guo wrote:
> Hi Will,
>
> On 2020/5/21 18:09, Will Deacon wrote:
>> Hi folks,
>>
>> I just tried booting the arm64 for-kernelci branch under QEMU (version
>> 4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a couple
>> of NULL pointer dereferences reported at boot. I think they're both GIC
>> related (log below). I don't see a panic with UBSAN disabled, so
>> something's
>> fishy here.
>>
>> Please can you take a look when you get a chance? I haven't had time
>> to see
>> if this is a regression or not, but I don't think it's particularly
>> serious
>> as I have all sorts of horrible stuff enabled in my .config, since I'm
>> trying to chase down another bug:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/plain/arch/arm64/configs/fuzzing.config?h=fuzzing/arm64-kernelci-20200519&id=c149cf6a51aa4f72d53fc681c6661094e93ef660
>>
>>
>> (on top of defconfig)
>>
>> CONFIG_FAIL_PAGE_ALLOC may be to blame.
>
> I enabled UBSAN and CONFIG_FAIL_PAGE_ALLOC on top of defconfig,
> testing against the for-kernelci branch on the D06 board, I
> can see some UBSAN warnings from megaraid_sas driver [0], but not
> from any other subsystem including ACPI, I will try all your
> configs above to see if I can get more warnings.
Enabled all the configs except "CONFIG_MODULES=n" and
"CONFIG_SHADOW_CALL_STACK=y" (can't do that via make menuconfig,
do it manually?) in the link, but still got the same warnings and
no other warnings as before, the system is in good function, please
let me know I can do anything more to help the debug.
Thanks
Hanjun
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V8, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Dongchun Zhu @ 2020-05-22 9:44 UTC (permalink / raw)
To: Tomasz Figa
Cc: mark.rutland, Rob Herring, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, louis.kuo, bgolaszewski,
sj.huang, drinkcat, linux-mediatek, dongchun.zhu, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200521193525.GB14214@chromium.org>
Hi Tomasz, Rob,
On Thu, 2020-05-21 at 19:35 +0000, Tomasz Figa wrote:
> Hi Rob,
>
> On Mon, May 11, 2020 at 11:02:07AM -0500, Rob Herring wrote:
> > On Sat, May 09, 2020 at 04:06:26PM +0800, Dongchun Zhu wrote:
> > > Add DT bindings documentation for Omnivision OV02A10 image sensor.
> > >
> > > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > ---
> > > .../bindings/media/i2c/ovti,ov02a10.yaml | 184 +++++++++++++++++++++
> > > MAINTAINERS | 7 +
> > > 2 files changed, 191 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > new file mode 100644
> > > index 0000000..5468d1b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
> > > @@ -0,0 +1,184 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +# Copyright (c) 2020 MediaTek Inc.
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Dongchun Zhu <dongchun.zhu@mediatek.com>
> > > +
> > > +description: |-
> > > + The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
> > > + image sensor, which is the latest production derived from Omnivision's CMOS
> > > + image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
> > > + @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
> > > + sensor output is available via CSI-2 serial data output.
> > > +
> > > +properties:
> > > + compatible:
> > > + const: ovti,ov02a10
> > > +
> > > + reg:
> > > + description: I2C device address
> >
> > Drop this. Nothing specific to this device.
> >
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + items:
> > > + - description: top mux camtg clock
> > > + - description: devider clock
> >
> > typo
> >
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: eclk
> > > + - const: freq_mux
> > > +
> > > + clock-frequency:
> > > + description:
> > > + Frequency of the eclk clock in Hertz.
> > > +
> > > + dovdd-supply:
> > > + description:
> > > + Definition of the regulator used as interface power supply.
> > > +
> > > + avdd-supply:
> > > + description:
> > > + Definition of the regulator used as analog power supply.
> > > +
> > > + dvdd-supply:
> > > + description:
> > > + Definition of the regulator used as digital power supply.
> > > +
> > > + powerdown-gpios:
> > > + maxItems: 1
> > > +
> > > + reset-gpios:
> > > + maxItems: 1
>
> I asked a question about defining GPIO polarities some time ago, but I
> guess it slipped through.
>
> The chip documentation calls the reset pin as "RST_PAD (low level
> reset)". Where should the inversion be handled, in the driver or here,
> by having the DT include a necessary flag in the specifier?
>
> Best regards,
> Tomasz
For powerdown-gpios and reset-gpios, I actually defined two totally
different GPIO polarities in DT according to OV02A10 chip documentation.
One is GPIO_ACTIVE_LOW, the other is GPIO_ACTIVE_HIGH (see examples
below).
So I'm wondering if we could add such one polarity-flag that Tomasz
suggested.
_______________________________________________
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 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
From: Lorenzo Pieralisi @ 2020-05-22 9:53 UTC (permalink / raw)
To: Makarand Pawagi
Cc: devicetree@vger.kernel.org, Sudeep Holla, Catalin Marinas,
Will Deacon, linux-pci@vger.kernel.org, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, linux-acpi@vger.kernel.org,
iommu@lists.linux-foundation.org, Rob Herring, Marc Zyngier,
Diana Madalina Craciun (OSS), Bjorn Helgaas, Robin Murphy,
linux-arm-kernel@lists.infradead.org, Laurentiu Tudor
In-Reply-To: <AM6PR04MB49847931D51AD92057043D92EBB40@AM6PR04MB4984.eurprd04.prod.outlook.com>
On Fri, May 22, 2020 at 05:32:02AM +0000, Makarand Pawagi wrote:
[...]
> > Subject: Re: [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
> >
> > Hi Lorenzo,
> >
> > On 5/21/2020 4:00 PM, Lorenzo Pieralisi wrote:
> > > From: Diana Craciun <diana.craciun@oss.nxp.com>
> > >
> > > Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
> > > extract memory and other resources.
> > >
> > > Interrupt (GIC ITS) information is extracted from the MADT table by
> > > drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
> > >
> > > IORT table is parsed to configure DMA.
> > >
> > > Signed-off-by: Makarand Pawagi <makarand.pawagi@nxp.com>
> > > Signed-off-by: Diana Craciun <diana.craciun@oss.nxp.com>
> > > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > > ---
> >
> > The author of this patch should be Makarand. I think I accidentaly broke it when
> > we exchanged the patches. Very sorry about it.
> >
>
> Will you be able to correct this or should I post another patch?
I will update it.
Lorenzo
_______________________________________________
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 09/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus
From: Diana Craciun OSS @ 2020-05-22 9:57 UTC (permalink / raw)
To: Robin Murphy, Rob Herring, Lorenzo Pieralisi
Cc: devicetree, Catalin Marinas, PCI, Hanjun Guo, Rafael J. Wysocki,
Linux IOMMU, linux-acpi, Makarand Pawagi, Marc Zyngier,
Sudeep Holla, Bjorn Helgaas, Will Deacon,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <abca6ecb-5d93-832f-ff7c-de53bb6203f3@arm.com>
On 5/22/2020 12:42 PM, Robin Murphy wrote:
> On 2020-05-22 00:10, Rob Herring wrote:
>> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
>> <lorenzo.pieralisi@arm.com> wrote:
>>>
>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>
>>> The existing bindings cannot be used to specify the relationship
>>> between fsl-mc devices and GIC ITSes.
>>>
>>> Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
>>> msi-map property.
>>>
>>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> ---
>>> .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30
>>> +++++++++++++++++--
>>> 1 file changed, 27 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>> index 9134e9bcca56..b0813b2d0493 100644
>>> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
>>> @@ -18,9 +18,9 @@ same hardware "isolation context" and a 10-bit
>>> value called an ICID
>>> the requester.
>>>
>>> The generic 'iommus' property is insufficient to describe the
>>> relationship
>>> -between ICIDs and IOMMUs, so an iommu-map property is used to define
>>> -the set of possible ICIDs under a root DPRC and how they map to
>>> -an IOMMU.
>>> +between ICIDs and IOMMUs, so the iommu-map and msi-map properties
>>> are used
>>> +to define the set of possible ICIDs under a root DPRC and how they
>>> map to
>>> +an IOMMU and a GIC ITS respectively.
>>>
>>> For generic IOMMU bindings, see
>>> Documentation/devicetree/bindings/iommu/iommu.txt.
>>> @@ -28,6 +28,9 @@ Documentation/devicetree/bindings/iommu/iommu.txt.
>>> For arm-smmu binding, see:
>>> Documentation/devicetree/bindings/iommu/arm,smmu.yaml.
>>>
>>> +For GICv3 and GIC ITS bindings, see:
>>> +Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
>>>
>>> +
>>> Required properties:
>>>
>>> - compatible
>>> @@ -119,6 +122,15 @@ Optional properties:
>>> associated with the listed IOMMU, with the iommu-specifier
>>> (i - icid-base + iommu-base).
>>>
>>> +- msi-map: Maps an ICID to a GIC ITS and associated iommu-specifier
>>> + data.
>>> +
>>> + The property is an arbitrary number of tuples of
>>> + (icid-base,iommu,iommu-base,length).
>>
>> I'm confused because the example has GIC ITS phandle, not an IOMMU.
>>
>> What is an iommu-base?
>
> Right, I was already halfway through writing a reply to say that all
> the copy-pasted "iommu" references here should be using the
> terminology from the pci-msi.txt binding instead.
Right, will change it.
>
>>> +
>>> + Any ICID in the interval [icid-base, icid-base + length) is
>>> + associated with the listed GIC ITS, with the iommu-specifier
>>> + (i - icid-base + iommu-base).
>>> Example:
>>>
>>> smmu: iommu@5000000 {
>>> @@ -128,6 +140,16 @@ Example:
>>> ...
>>> };
>>>
>>> + gic: interrupt-controller@6000000 {
>>> + compatible = "arm,gic-v3";
>>> + ...
>>> + its: gic-its@6020000 {
>>> + compatible = "arm,gic-v3-its";
>>> + msi-controller;
>>> + ...
>>> + };
>>> + };
>>> +
>>> fsl_mc: fsl-mc@80c000000 {
>>> compatible = "fsl,qoriq-mc";
>>> reg = <0x00000008 0x0c000000 0 0x40>, /* MC
>>> portal base */
>>> @@ -135,6 +157,8 @@ Example:
>>> msi-parent = <&its>;
>
> Side note: is it right to keep msi-parent here? It rather implies that
> the MC itself has a 'native' Device ID rather than an ICID, which I
> believe is not strictly true. Plus it's extra-confusing that it
> doesn't specify an ID either way, since that makes it look like the
> legacy PCI case that gets treated implicitly as an identity msi-map,
> which makes no sense at all to combine with an actual msi-map.
Before adding msi-map, the fsl-mc code assumed that ICID and streamID
are equal and used msi-parent just to get the reference to the ITS node.
Removing msi-parent will break the backward compatibility of the already
existing systems. Maybe we should mention that this is legacy and not to
be used for newer device trees.
>
>>> /* define map for ICIDs 23-64 */
>>> iommu-map = <23 &smmu 23 41>;
>>> + /* define msi map for ICIDs 23-64 */
>>> + msi-map = <23 &its 23 41>;
>>
>> Seeing 23 twice is odd. The numbers to the right of 'its' should be an
>> ITS number space.
>
> On about 99% of systems the values in the SMMU Stream ID and ITS
> Device ID spaces are going to be the same. Nobody's going to bother
> carrying *two* sets of sideband data across the interconnect if they
> don't have to ;)
>
> Robin.
Diana
>
>>> #address-cells = <3>;
>>> #size-cells = <1>;
>>>
>>> --
>>> 2.26.1
>>>
>> _______________________________________________
>> iommu mailing list
>> iommu@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>
_______________________________________________
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 -next] mt76: mt7915: Fix build error
From: Kalle Valo @ 2020-05-22 10:11 UTC (permalink / raw)
To: YueHaibing
Cc: ryder.lee, linux-wireless, yf.luo, chih-min.chen, linux-kernel,
matthias.bgg, yiwei.chung, linux-mediatek, netdev,
lorenzo.bianconi83, kuba, shayne.chen, davem, linux-arm-kernel,
nbd
In-Reply-To: <20200522034533.61716-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> writes:
> In file included from ./include/linux/firmware.h:6:0,
> from drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:4:
> In function ‘__mt7915_mcu_msg_send’,
> inlined from ‘mt7915_mcu_send_message’ at drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:370:6:
> ./include/linux/compiler.h:396:38: error: call to ‘__compiletime_assert_545’ declared with attribute error: BUILD_BUG_ON failed: cmd == MCU_EXT_CMD_EFUSE_ACCESS && mcu_txd->set_query != MCU_Q_QUERY
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^
> ./include/linux/compiler.h:377:4: note: in definition of macro ‘__compiletime_assert’
> prefix ## suffix(); \
> ^~~~~~
> ./include/linux/compiler.h:396:2: note: in expansion of macro ‘_compiletime_assert’
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^~~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
> BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> ^~~~~~~~~~~~~~~~
> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:280:2: note: in expansion of macro ‘BUILD_BUG_ON’
> BUILD_BUG_ON(cmd == MCU_EXT_CMD_EFUSE_ACCESS &&
> ^~~~~~~~~~~~
>
> BUILD_BUG_ON is meaningless here, chang it to WARN_ON.
>
> Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
I'm curious why I don't see this build error? I was about to send a pull
request to Dave, should I hold off the pull request due to this problem?
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp
From: Jitao Shi @ 2020-05-22 10:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Daniel Vetter,
David Airlie, dri-devel, linux-kernel
Cc: devicetree, Jitao Shi, srv_heupstream, huijuan.xie, stonea168,
cawa.cheng, linux-mediatek, bibby.hsieh, ck.hu, yingjoe.chen,
eddie.huang, linux-arm-kernel
If panel has too small hfp or hbp, horizontal_frontporch_byte or
horizontal_backporch_byte may become very small value or negative
value. This patch adjusts their values so that they are greater
than minimum value and keep total of them unchanged.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 0ede69830a9d..aebaafd90ceb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -148,6 +148,9 @@
(type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
(type == MIPI_DSI_DCS_READ))
+#define MIN_HFP_BYTE 0x02
+#define MIN_HBP_BYTE 0x02
+
struct mtk_phy_timing {
u32 lpx;
u32 da_hs_prepare;
@@ -450,6 +453,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
u32 horizontal_sync_active_byte;
u32 horizontal_backporch_byte;
u32 horizontal_frontporch_byte;
+ s32 signed_hfp_byte, signed_hbp_byte;
u32 dsi_tmp_buf_bpp, data_phy_cycles;
struct mtk_phy_timing *timing = &dsi->phy_timing;
@@ -519,6 +523,20 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
}
}
+ signed_hfp_byte = (s32)horizontal_frontporch_byte;
+ signed_hbp_byte = (s32)horizontal_backporch_byte;
+
+ if (signed_hfp_byte + signed_hbp_byte < MIN_HFP_BYTE + MIN_HBP_BYTE) {
+ DRM_WARN("Calculated hfp_byte and hbp_byte are too small, "
+ "panel may not work properly.\n");
+ } else if (signed_hfp_byte < MIN_HFP_BYTE) {
+ horizontal_frontporch_byte = MIN_HFP_BYTE;
+ horizontal_backporch_byte -= MIN_HFP_BYTE - signed_hfp_byte;
+ } else if (signed_hbp_byte < MIN_HBP_BYTE) {
+ horizontal_frontporch_byte -= MIN_HBP_BYTE - signed_hbp_byte;
+ horizontal_backporch_byte = MIN_HBP_BYTE;
+ }
+
writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
--
2.25.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 v7 02/20] spi: spi-mem: allow specifying a command's extension
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
the "command extension". There can be 3 types of extensions in xSPI:
repeat, invert, and hex. When the extension type is "repeat", the same
opcode is sent twice. When it is "invert", the second byte is the
inverse of the opcode. When it is "hex" an additional opcode byte based
is sent with the command whose value can be anything.
So, make opcode a 16-bit value and add a 'nbytes', similar to how
multiple address widths are handled.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/spi-mem.c | 5 ++++-
include/linux/spi/spi-mem.h | 6 +++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 93e255287ab9..29dcd1d62710 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -159,6 +159,9 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
return false;
+ if (op->cmd.nbytes != 1)
+ return false;
+
return true;
}
EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
@@ -173,7 +176,7 @@ static bool spi_mem_buswidth_is_valid(u8 buswidth)
static int spi_mem_check_op(const struct spi_mem_op *op)
{
- if (!op->cmd.buswidth)
+ if (!op->cmd.buswidth || !op->cmd.nbytes)
return -EINVAL;
if ((op->addr.nbytes && !op->addr.buswidth) ||
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index e3dcb956bf61..159463cc659c 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -17,6 +17,7 @@
{ \
.buswidth = __buswidth, \
.opcode = __opcode, \
+ .nbytes = 1, \
}
#define SPI_MEM_OP_ADDR(__nbytes, __val, __buswidth) \
@@ -69,6 +70,8 @@ enum spi_mem_data_dir {
/**
* struct spi_mem_op - describes a SPI memory operation
+ * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
+ * sent MSB-first.
* @cmd.buswidth: number of IO lines used to transmit the command
* @cmd.opcode: operation opcode
* @cmd.dtr: whether the command opcode should be sent in DTR mode or not
@@ -94,9 +97,10 @@ enum spi_mem_data_dir {
*/
struct spi_mem_op {
struct {
+ u8 nbytes;
u8 buswidth;
u8 dtr : 1;
- u8 opcode;
+ u16 opcode;
} cmd;
struct {
--
2.26.2
_______________________________________________
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 v7 04/20] spi: spi-mtk-nor: reject DTR ops
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
doesn't support DTR transactions. Since we don't use the default
supports_op(), which rejects all DTR ops, do that explicitly in our
supports_op().
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/spi-mtk-nor.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index 7bc302b50396..d715cf6372fe 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -211,6 +211,12 @@ static bool mtk_nor_supports_op(struct spi_mem *mem,
if (op->cmd.buswidth != 1)
return false;
+ /* DTR ops not supported. */
+ if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+ return false;
+ if (op->cmd.nbytes != 1)
+ return false;
+
if ((op->addr.nbytes == 3) || (op->addr.nbytes == 4)) {
if ((op->data.dir == SPI_MEM_DATA_IN) && mtk_nor_match_read(op))
return true;
--
2.26.2
_______________________________________________
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 06/15] ARM: berlin: Drop unneeded select of HAVE_SMP
From: Jisheng Zhang @ 2020-05-22 10:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Kevin Hilman, linux-kernel, soc, Olof Johansson,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20200505150722.1575-7-geert+renesas@glider.be>
Hi Arnd, Kevin, Olof,
On Tue, 5 May 2020 17:07:13 +0200 Geert Uytterhoeven wrote:
>
>
> Support for Marvell Berlin SoCs depends on ARCH_MULTI_V7.
> As the latter selects HAVE_SMP, there is no need for MACH_BERLIN_BG2 to
> select HAVE_SMP.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
The patch looks good to me. I want to know what will be the mainline
path of this series. SoC maintainers take it then send A PR to arm-soc?
Or each SoC maintainers ack it, arm-soc will take the whole series?
If later, then
Acked-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
This is the first time I see a series touch different SoC platforms.
Thanks in advance,
Jisheng
> ---
> v2:
> - Add Acked-by.
> ---
> arch/arm/mach-berlin/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig
> index 5b1f61fd78780300..01861fa72c9714b7 100644
> --- a/arch/arm/mach-berlin/Kconfig
> +++ b/arch/arm/mach-berlin/Kconfig
> @@ -19,7 +19,6 @@ config MACH_BERLIN_BG2
> select CPU_PJ4B
> select HAVE_ARM_SCU if SMP
> select HAVE_ARM_TWD if SMP
> - select HAVE_SMP
> select PINCTRL_BERLIN_BG2
>
> config MACH_BERLIN_BG2CD
> --
> 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 v7 00/20] mtd: spi-nor: add xSPI Octal DTR support
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
Hi,
This series adds support for octal DTR flashes in the spi-nor framework,
and then adds hooks for the Cypress Semper and Mircom Xcella flashes to
allow running them in octal DTR mode. This series assumes that the flash
is handed to the kernel in Legacy SPI mode.
Tested on TI J721e EVM with 1-bit ECC on the Cypress flash.
Changes in v7:
- Reject ops with more than 1 command byte in
spi_mem_default_supports_op().
- Reject ops with more than 1 command byte in atmel and mtk controllers.
- Reject ops with 0 command bytes in spi_mem_check_op().
- Set cmd.nbytes to 1 when using SPI_MEM_OP_CMD().
- Avoid endianness problems in spi-mxic.
Changes in v6:
- Instead of hard-coding 8D-8D-8D Fast Read dummy cycles to 20, find
them out from the Profile 1.0 table.
Changes in v5:
- Do not enable stateful X-X-X modes if the reset line is broken.
- Instead of setting SNOR_READ_HWCAPS_8_8_8_DTR from Profile 1.0 table
parsing, do it in spi_nor_info_init_params() instead based on the
SPI_NOR_OCTAL_DTR_READ flag instead.
- Set SNOR_HWCAPS_PP_8_8_8_DTR in s28hs post_sfdp hook since this
capability is no longer set in Profile 1.0 parsing.
- Instead of just checking for spi_nor_get_protocol_width() in
spi_nor_octal_dtr_enable(), make sure the protocol is
SNOR_PROTO_8_8_8_DTR since get_protocol_width() only cares about data
width.
- Drop flag SPI_NOR_SOFT_RESET. Instead, discover soft reset capability
via BFPT.
- Do not make an invalid Quad Enable BFPT field a fatal error. Silently
ignore it by assuming no quad enable bit is present.
- Set dummy cycles for Cypress Semper flash to 24 instead of 20. This
allows for 200MHz operation in 8D mode compared to the 166MHz with 20.
- Rename spi_nor_cypress_octal_enable() to
spi_nor_cypress_octal_dtr_enable().
- Update spi-mtk-nor.c to reject DTR ops since it doesn't call
spi_mem_default_supports_op().
Changes in v4:
- Refactor the series to use the new spi-nor framework with the
manufacturer-specific bits separated from the core.
- Add support for Micron MT35XU512ABA.
- Use cmd.nbytes as the criteria of whether the data phase exists or not
instead of cmd.buf.in || cmd.buf.out in spi_nor_spimem_setup_op().
- Update Read FSR to use the same dummy cycles and address width as Read
SR.
- Fix BFPT parsing stopping too early for JESD216 rev B flashes.
- Use 2 byte reads for Read SR and FSR commands in DTR mode.
Changes in v3:
- Drop the DT properties "spi-rx-dtr" and "spi-tx-dtr". Instead, if
later a need is felt to disable DTR in case someone has a board with
Octal DTR capable flash but does not support DTR transactions for some
reason, a property like "spi-no-dtr" can be added.
- Remove mode bits SPI_RX_DTR and SPI_TX_DTR.
- Remove the Cadence Quadspi controller patch to un-block this series. I
will submit it as a separate patch.
- Rebase on latest 'master' and fix merge conflicts.
- Update read and write dirmap templates to use DTR.
- Rename 'is_dtr' to 'dtr'.
- Make 'dtr' a bitfield.
- Reject DTR ops in spi_mem_default_supports_op().
- Update atmel-quadspi to reject DTR ops. All other controller drivers
call spi_mem_default_supports_op() so they will automatically reject
DTR ops.
- Add support for both enabling and disabling DTR modes.
- Perform a Software Reset on flashes that support it when shutting
down.
- Disable Octal DTR mode on suspend, and re-enable it on resume.
- Drop enum 'spi_mem_cmd_ext' and make command opcode u16 instead.
Update spi-nor to use the 2-byte command instead of the command
extension. Since we still need a "extension type", mode that enum to
spi-nor and name it 'spi_nor_cmd_ext'.
- Default variable address width to 3 to fix SMPT parsing.
- Drop non-volatile change to uniform sector mode and rely on parsing
SMPT.
Changes in v2:
- Add DT properties "spi-rx-dtr" and "spi-tx-dtr" to allow expressing
DTR capabilities.
- Set the mode bits SPI_RX_DTR and SPI_TX_DTR when we discover the DT
properties "spi-rx-dtr" and spi-tx-dtr".
- spi_nor_cypress_octal_enable() was updating nor->params.read[] with
the intention of setting the correct number of dummy cycles. But this
function is called _after_ selecting the read so setting
nor->params.read[] will have no effect. So, update nor->read_dummy
directly.
- Fix spi_nor_spimem_check_readop() and spi_nor_spimem_check_pp()
passing nor->read_proto and nor->write_proto to
spi_nor_spimem_setup_op() instead of read->proto and pp->proto
respectively.
- Move the call to cqspi_setup_opcode_ext() inside cqspi_enable_dtr().
This avoids repeating the 'if (f_pdata->is_dtr)
cqspi_setup_opcode_ext()...` snippet multiple times.
- Call the default 'supports_op()' from cqspi_supports_mem_op(). This
makes sure the buswidth requirements are also enforced along with the
DTR requirements.
- Drop the 'is_dtr' argument from spi_check_dtr_req(). We only call it
when a phase is DTR so it is redundant.
Pratyush Yadav (20):
spi: spi-mem: allow specifying whether an op is DTR or not
spi: spi-mem: allow specifying a command's extension
spi: atmel-quadspi: reject DTR ops
spi: spi-mtk-nor: reject DTR ops
spi: mxic: Avoid endianness problems with 2-byte opcodes
mtd: spi-nor: add support for DTR protocol
mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths
mtd: spi-nor: sfdp: prepare BFPT parsing for JESD216 rev D
mtd: spi-nor: sfdp: get command opcode extension type from BFPT
mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
mtd: spi-nor: core: use dummy cycle and address width info from SFDP
mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode
mtd: spi-nor: core: enable octal DTR mode when possible
mtd: spi-nor: sfdp: do not make invalid quad enable fatal
mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPT
mtd: spi-nor: core: perform a Soft Reset on shutdown
mtd: spi-nor: core: disable Octal DTR mode on suspend.
mtd: spi-nor: core: expose spi_nor_default_setup() in core.h
mtd: spi-nor: spansion: add support for Cypress Semper flash
mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode
drivers/mtd/spi-nor/core.c | 446 +++++++++++++++++++++++++++-----
drivers/mtd/spi-nor/core.h | 22 ++
drivers/mtd/spi-nor/micron-st.c | 112 +++++++-
drivers/mtd/spi-nor/sfdp.c | 143 +++++++++-
drivers/mtd/spi-nor/sfdp.h | 13 +-
drivers/mtd/spi-nor/spansion.c | 167 ++++++++++++
drivers/spi/atmel-quadspi.c | 6 +
drivers/spi/spi-mem.c | 8 +-
drivers/spi/spi-mtk-nor.c | 6 +
drivers/spi/spi-mxic.c | 6 +-
include/linux/mtd/spi-nor.h | 53 +++-
include/linux/spi/spi-mem.h | 14 +-
12 files changed, 902 insertions(+), 94 deletions(-)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 03/20] spi: atmel-quadspi: reject DTR ops
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
doesn't support DTR transactions. Since we don't use the default
supports_op(), which rejects all DTR ops, do that explicitly in our
supports_op().
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/atmel-quadspi.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index cb44d1e169aa..a898755fb41e 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -285,6 +285,12 @@ static bool atmel_qspi_supports_op(struct spi_mem *mem,
op->dummy.nbytes == 0)
return false;
+ /* DTR ops not supported. */
+ if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+ return false;
+ if (op->cmd.nbytes != 1)
+ return false;
+
return true;
}
--
2.26.2
_______________________________________________
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 v7 07/20] mtd: spi-nor: sfdp: default to addr_width of 3 for configurable widths
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
JESD216D.01 says that when the address width can be 3 or 4, it defaults
to 3 and enters 4-byte mode when given the appropriate command. So, when
we see a configurable width, default to 3 and let flash that default to
4 change it in a post-bfpt fixup.
This fixes SMPT parsing for flashes with configurable address width. If
the SMPT descriptor advertises variable address width, we use
nor->addr_width as the address width. But since it was not set to any
value from the SFDP table, the read command uses an address width of 0,
resulting in an incorrect read being issued.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/sfdp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index f917631c8110..5cecc4ba2141 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -460,6 +460,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
/* Number of address bytes. */
switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) {
case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY:
+ case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
nor->addr_width = 3;
break;
--
2.26.2
_______________________________________________
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 v7 08/20] mtd: spi-nor: sfdp: prepare BFPT parsing for JESD216 rev D
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
JESD216 rev D makes BFPT 20 DWORDs. Update the BFPT size define to
reflect that.
The check for rev A or later compared the BFPT header length with the
maximum BFPT length, BFPT_DWORD_MAX. Since BFPT_DWORD_MAX was 16, and so
was the BFPT length for both rev A and B, this check worked fine. But
now, since BFPT_DWORD_MAX is 20, it means this check will also stop BFPT
parsing for rev A or B, since their length is 16.
So, instead check for BFPT_DWORD_MAX_JESD216 to stop BFPT parsing for
the first JESD216 version, and check for BFPT_DWORD_MAX_JESD216B for the
next two versions.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/sfdp.c | 7 ++++++-
drivers/mtd/spi-nor/sfdp.h | 5 +++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 5cecc4ba2141..96960f2f3d7a 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -549,7 +549,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
SNOR_ERASE_TYPE_MASK;
/* Stop here if not JESD216 rev A or later. */
- if (bfpt_header->length < BFPT_DWORD_MAX)
+ if (bfpt_header->length == BFPT_DWORD_MAX_JESD216)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
params);
@@ -605,6 +605,11 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
return -EINVAL;
}
+ /* Stop here if JESD216 rev B. */
+ if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
+ return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
+ params);
+
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index e0a8ded04890..f8198af43a63 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -10,11 +10,11 @@
/* Basic Flash Parameter Table */
/*
- * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
+ * JESD216 rev D defines a Basic Flash Parameter Table of 20 DWORDs.
* They are indexed from 1 but C arrays are indexed from 0.
*/
#define BFPT_DWORD(i) ((i) - 1)
-#define BFPT_DWORD_MAX 16
+#define BFPT_DWORD_MAX 20
struct sfdp_bfpt {
u32 dwords[BFPT_DWORD_MAX];
@@ -22,6 +22,7 @@ struct sfdp_bfpt {
/* The first version of JESD216 defined only 9 DWORDs. */
#define BFPT_DWORD_MAX_JESD216 9
+#define BFPT_DWORD_MAX_JESD216B 16
/* 1st DWORD. */
#define BFPT_DWORD1_FAST_READ_1_1_2 BIT(16)
--
2.26.2
_______________________________________________
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 v7 05/20] spi: mxic: Avoid endianness problems with 2-byte opcodes
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
spi-mem now supports 2-byte opcodes. Since we directly use the address
of the opcode in data transfer, the result can be different based on
whether the machine is little endian or big endian. So instead extract
the individual bytes from the opcode before using them.
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/spi-mxic.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index 69491f3a515d..c3f4136a7c1d 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
int nio = 1, i, ret;
u32 ss_ctrl;
u8 addr[8];
+ u8 cmd[2];
ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
if (ret)
@@ -393,7 +394,10 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
mxic->regs + HC_CFG);
- ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
+ for (i = 0; i < op->cmd.nbytes; i++)
+ cmd[i] = op->cmd.opcode >> (8 * (op->cmd.nbytes - i - 1));
+
+ ret = mxic_spi_data_xfer(mxic, cmd, NULL, op->cmd.nbytes);
if (ret)
goto out;
--
2.26.2
_______________________________________________
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 v7 01/20] spi: spi-mem: allow specifying whether an op is DTR or not
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
Each phase is given a separate 'dtr' field so mixed protocols like
4S-4D-4D can be supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/spi/spi-mem.c | 3 +++
include/linux/spi/spi-mem.h | 8 ++++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 9a86cc27fcc0..93e255287ab9 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -156,6 +156,9 @@ bool spi_mem_default_supports_op(struct spi_mem *mem,
op->data.dir == SPI_MEM_DATA_OUT))
return false;
+ if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+ return false;
+
return true;
}
EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index af9ff2f0f1b2..e3dcb956bf61 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -71,9 +71,11 @@ enum spi_mem_data_dir {
* struct spi_mem_op - describes a SPI memory operation
* @cmd.buswidth: number of IO lines used to transmit the command
* @cmd.opcode: operation opcode
+ * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
* @addr.nbytes: number of address bytes to send. Can be zero if the operation
* does not need to send an address
* @addr.buswidth: number of IO lines used to transmit the address cycles
+ * @addr.dtr: whether the address should be sent in DTR mode or not
* @addr.val: address value. This value is always sent MSB first on the bus.
* Note that only @addr.nbytes are taken into account in this
* address value, so users should make sure the value fits in the
@@ -81,7 +83,9 @@ enum spi_mem_data_dir {
* @dummy.nbytes: number of dummy bytes to send after an opcode or address. Can
* be zero if the operation does not require dummy bytes
* @dummy.buswidth: number of IO lanes used to transmit the dummy bytes
+ * @dummy.dtr: whether the dummy bytes should be sent in DTR mode or not
* @data.buswidth: number of IO lanes used to send/receive the data
+ * @data.dtr: whether the data should be sent in DTR mode or not
* @data.dir: direction of the transfer
* @data.nbytes: number of data bytes to send/receive. Can be zero if the
* operation does not involve transferring data
@@ -91,22 +95,26 @@ enum spi_mem_data_dir {
struct spi_mem_op {
struct {
u8 buswidth;
+ u8 dtr : 1;
u8 opcode;
} cmd;
struct {
u8 nbytes;
u8 buswidth;
+ u8 dtr : 1;
u64 val;
} addr;
struct {
u8 nbytes;
u8 buswidth;
+ u8 dtr : 1;
} dummy;
struct {
u8 buswidth;
+ u8 dtr : 1;
enum spi_mem_data_dir dir;
unsigned int nbytes;
union {
--
2.26.2
_______________________________________________
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 v7 09/20] mtd: spi-nor: sfdp: get command opcode extension type from BFPT
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
Some devices in DTR mode expect an extra command byte called the
extension. The extension can either be same as the opcode, bitwise
inverse of the opcode, or another additional byte forming a 16-byte
opcode. Get the extension type from the BFPT. For now, only flashes with
"repeat" and "inverse" extensions are supported.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/sfdp.c | 17 +++++++++++++++++
drivers/mtd/spi-nor/sfdp.h | 6 ++++++
2 files changed, 23 insertions(+)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 96960f2f3d7a..ab086aa4746f 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -609,6 +609,23 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
params);
+ /* 8D-8D-8D command extension. */
+ switch (bfpt.dwords[BFPT_DWORD(18)] & BFPT_DWORD18_CMD_EXT_MASK) {
+ case BFPT_DWORD18_CMD_EXT_REP:
+ nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+ break;
+
+ case BFPT_DWORD18_CMD_EXT_INV:
+ nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
+ break;
+
+ case BFPT_DWORD18_CMD_EXT_RES:
+ return -EINVAL;
+
+ case BFPT_DWORD18_CMD_EXT_16B:
+ dev_err(nor->dev, "16-bit opcodes not supported\n");
+ return -ENOTSUPP;
+ }
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
diff --git a/drivers/mtd/spi-nor/sfdp.h b/drivers/mtd/spi-nor/sfdp.h
index f8198af43a63..e15e30796d62 100644
--- a/drivers/mtd/spi-nor/sfdp.h
+++ b/drivers/mtd/spi-nor/sfdp.h
@@ -84,6 +84,12 @@ struct sfdp_bfpt {
#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD (0x4UL << 20)
#define BFPT_DWORD15_QER_SR2_BIT1 (0x5UL << 20) /* Spansion */
+#define BFPT_DWORD18_CMD_EXT_MASK GENMASK(30, 29)
+#define BFPT_DWORD18_CMD_EXT_REP (0x0UL << 29) /* Repeat */
+#define BFPT_DWORD18_CMD_EXT_INV (0x1UL << 29) /* Invert */
+#define BFPT_DWORD18_CMD_EXT_RES (0x2UL << 29) /* Reserved */
+#define BFPT_DWORD18_CMD_EXT_16B (0x3UL << 29) /* 16-bit opcode */
+
struct sfdp_parameter_header {
u8 id_lsb;
u8 minor;
--
2.26.2
_______________________________________________
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 v7 11/20] mtd: spi-nor: core: use dummy cycle and address width info from SFDP
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
The xSPI Profile 1.0 table specifies how many dummy cycles and address
bytes are needed for the Read Status Register command in octal DTR mode.
Use that information to send the correct Read SR command.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 642e3c07acf9..2ad248140b6c 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -357,6 +357,8 @@ int spi_nor_write_disable(struct spi_nor *nor)
static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
{
int ret;
+ u8 addr_bytes = nor->params->rdsr_addr_nbytes;
+ u8 dummy = nor->params->rdsr_dummy;
if (nor->spimem) {
struct spi_mem_op op =
@@ -365,10 +367,21 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, sr, 1));
+ if (spi_nor_protocol_is_dtr(nor->reg_proto)) {
+ op.addr.nbytes = addr_bytes;
+ op.addr.val = 0;
+ op.dummy.nbytes = dummy;
+ }
+
+ spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_mem_exec_op(nor->spimem, &op);
} else {
- ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR,
- sr, 1);
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ ret = -ENOTSUPP;
+ else
+ ret = nor->controller_ops->read_reg(nor, SPINOR_OP_RDSR,
+ sr, 1);
}
if (ret)
@@ -388,6 +401,8 @@ static int spi_nor_read_sr(struct spi_nor *nor, u8 *sr)
static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
{
int ret;
+ u8 addr_bytes = nor->params->rdsr_addr_nbytes;
+ u8 dummy = nor->params->rdsr_dummy;
if (nor->spimem) {
struct spi_mem_op op =
@@ -396,6 +411,12 @@ static int spi_nor_read_fsr(struct spi_nor *nor, u8 *fsr)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(1, fsr, 1));
+ if (spi_nor_protocol_is_dtr(nor->reg_proto)) {
+ op.addr.nbytes = addr_bytes;
+ op.addr.val = 0;
+ op.dummy.nbytes = dummy;
+ }
+
spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
ret = spi_mem_exec_op(nor->spimem, &op);
--
2.26.2
_______________________________________________
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 v7 10/20] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
From: Pratyush Yadav @ 2020-05-22 10:12 UTC (permalink / raw)
To: Tudor Ambarus, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Mark Brown, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches, Matthias Brugger, linux-mtd, linux-kernel,
linux-spi, linux-arm-kernel, linux-mediatek
Cc: Mason Yang, Boris Brezillon, Sekhar Nori, Pratyush Yadav
In-Reply-To: <20200522101301.26909-1-p.yadav@ti.com>
This table is indication that the flash is xSPI compliant and hence
supports octal DTR mode. Extract information like the fast read opcode,
dummy cycles, the number of dummy cycles needed for a Read Status
Register command, and the number of address bytes needed for a Read
Status Register command.
We don't know what speed the controller is running at. Find the fast
read dummy cycles for the fastest frequency the flash can run at to be
sure we are never short of dummy cycles. If nothing is available,
default to 20. Flashes that use a different value should update it in
their fixup hooks.
Since we want to set read settings, expose spi_nor_set_read_settings()
in core.h.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
---
drivers/mtd/spi-nor/core.c | 2 +-
drivers/mtd/spi-nor/core.h | 10 ++++
drivers/mtd/spi-nor/sfdp.c | 99 ++++++++++++++++++++++++++++++++++++++
3 files changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 388e695e763f..642e3c07acf9 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2355,7 +2355,7 @@ static int spi_nor_check(struct spi_nor *nor)
return 0;
}
-static void
+void
spi_nor_set_read_settings(struct spi_nor_read_command *read,
u8 num_mode_clocks,
u8 num_wait_states,
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index de1e3917889f..7e6df8322da0 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -192,6 +192,9 @@ struct spi_nor_locking_ops {
*
* @size: the flash memory density in bytes.
* @page_size: the page size of the SPI NOR flash memory.
+ * @rdsr_dummy: dummy cycles needed for Read Status Register command.
+ * @rdsr_addr_nbytes: dummy address bytes needed for Read Status Register
+ * command.
* @hwcaps: describes the read and page program hardware
* capabilities.
* @reads: read capabilities ordered by priority: the higher index
@@ -214,6 +217,8 @@ struct spi_nor_locking_ops {
struct spi_nor_flash_parameter {
u64 size;
u32 page_size;
+ u8 rdsr_dummy;
+ u8 rdsr_addr_nbytes;
struct spi_nor_hwcaps hwcaps;
struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
@@ -424,6 +429,11 @@ ssize_t spi_nor_write_data(struct spi_nor *nor, loff_t to, size_t len,
int spi_nor_hwcaps_read2cmd(u32 hwcaps);
u8 spi_nor_convert_3to4_read(u8 opcode);
+void spi_nor_set_read_settings(struct spi_nor_read_command *read,
+ u8 num_mode_clocks,
+ u8 num_wait_states,
+ u8 opcode,
+ enum spi_nor_protocol proto);
void spi_nor_set_pp_settings(struct spi_nor_pp_command *pp, u8 opcode,
enum spi_nor_protocol proto);
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index ab086aa4746f..052cabb52df9 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -4,12 +4,15 @@
* Copyright (C) 2014, Freescale Semiconductor, Inc.
*/
+#include <linux/bitfield.h>
#include <linux/slab.h>
#include <linux/sort.h>
#include <linux/mtd/spi-nor.h>
#include "core.h"
+#define ROUND_UP_TO(x, y) (((x) + (y) - 1) / (y) * (y))
+
#define SFDP_PARAM_HEADER_ID(p) (((p)->id_msb << 8) | (p)->id_lsb)
#define SFDP_PARAM_HEADER_PTP(p) \
(((p)->parameter_table_pointer[2] << 16) | \
@@ -19,12 +22,14 @@
#define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table */
#define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
#define SFDP_4BAIT_ID 0xff84 /* 4-byte Address Instruction Table */
+#define SFDP_PROFILE1_ID 0xff05 /* xSPI Profile 1.0 table. */
#define SFDP_SIGNATURE 0x50444653U
#define SFDP_JESD216_MAJOR 1
#define SFDP_JESD216_MINOR 0
#define SFDP_JESD216A_MINOR 5
#define SFDP_JESD216B_MINOR 6
+#define SFDP_JESD216D_MINOR 8
struct sfdp_header {
u32 signature; /* Ox50444653U <=> "SFDP" */
@@ -70,6 +75,16 @@ struct sfdp_bfpt_erase {
u32 shift;
};
+/* xSPI Profile 1.0 table (from JESD216D.01). */
+#define PROFILE1_DWORD1_RD_FAST_CMD GENMASK(15, 8)
+#define PROFILE1_DWORD1_RDSR_DUMMY BIT(28)
+#define PROFILE1_DWORD1_RDSR_ADDR_BYTES BIT(29)
+#define PROFILE1_DWORD4_DUMMY_200MHZ GENMASK(11, 7)
+#define PROFILE1_DWORD5_DUMMY_166MHZ GENMASK(31, 27)
+#define PROFILE1_DWORD5_DUMMY_133MHZ GENMASK(21, 17)
+#define PROFILE1_DWORD5_DUMMY_100MHZ GENMASK(11, 7)
+#define PROFILE1_DUMMY_DEFAULT 20
+
#define SMPT_CMD_ADDRESS_LEN_MASK GENMASK(23, 22)
#define SMPT_CMD_ADDRESS_LEN_0 (0x0UL << 22)
#define SMPT_CMD_ADDRESS_LEN_3 (0x1UL << 22)
@@ -1110,6 +1125,86 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
return ret;
}
+/**
+ * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
+ * @nor: pointer to a 'struct spi_nor'
+ * @param_header: pointer to the 'struct sfdp_parameter_header' describing
+ * the 4-Byte Address Instruction Table length and version.
+ * @params: pointer to the 'struct spi_nor_flash_parameter' to be.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_parse_profile1(struct spi_nor *nor,
+ const struct sfdp_parameter_header *profile1_header,
+ struct spi_nor_flash_parameter *params)
+{
+ u32 *table, opcode, addr;
+ size_t len;
+ int ret, i;
+ u8 dummy;
+
+ len = profile1_header->length * sizeof(*table);
+ table = kmalloc(len, GFP_KERNEL);
+ if (!table)
+ return -ENOMEM;
+
+ addr = SFDP_PARAM_HEADER_PTP(profile1_header);
+ ret = spi_nor_read_sfdp(nor, addr, len, table);
+ if (ret)
+ goto out;
+
+ /* Fix endianness of the table DWORDs. */
+ for (i = 0; i < profile1_header->length; i++)
+ table[i] = le32_to_cpu(table[i]);
+
+ /* Get 8D-8D-8D fast read opcode and dummy cycles. */
+ opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
+
+ /*
+ * We don't know what speed the controller is running at. Find the
+ * dummy cycles for the fastest frequency the flash can run at to be
+ * sure we are never short of dummy cycles. A value of 0 means the
+ * frequency is not supported.
+ *
+ * Default to PROFILE1_DUMMY_DEFAULT if we don't find anything, and let
+ * flashes set the correct value if needed in their fixup hooks.
+ */
+ dummy = FIELD_GET(PROFILE1_DWORD4_DUMMY_200MHZ, table[3]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_166MHZ, table[4]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_133MHZ, table[4]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_100MHZ, table[4]);
+ if (!dummy)
+ dummy = PROFILE1_DUMMY_DEFAULT;
+
+ /* Round up to an even value to avoid tripping controllers up. */
+ dummy = ROUND_UP_TO(dummy, 2);
+
+ /* Update the fast read settings. */
+ spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
+ 0, dummy, opcode,
+ SNOR_PROTO_8_8_8_DTR);
+
+ /*
+ * Set the Read Status Register dummy cycles and dummy address bytes.
+ */
+ if (table[0] & PROFILE1_DWORD1_RDSR_DUMMY)
+ params->rdsr_dummy = 8;
+ else
+ params->rdsr_dummy = 4;
+
+ if (table[0] & PROFILE1_DWORD1_RDSR_ADDR_BYTES)
+ params->rdsr_addr_nbytes = 4;
+ else
+ params->rdsr_addr_nbytes = 0;
+
+out:
+ kfree(table);
+ return ret;
+}
+
/**
* spi_nor_parse_sfdp() - parse the Serial Flash Discoverable Parameters.
* @nor: pointer to a 'struct spi_nor'
@@ -1211,6 +1306,10 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
err = spi_nor_parse_4bait(nor, param_header, params);
break;
+ case SFDP_PROFILE1_ID:
+ err = spi_nor_parse_profile1(nor, param_header, params);
+ break;
+
default:
break;
}
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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