* Re: [PATCH v2 4/5] arm64: dts: meson-sm1-sei610: add HDMI display support
From: Martin Blumenstingl @ 2019-08-25 20:00 UTC (permalink / raw)
To: Neil Armstrong
Cc: ulf.hansson, linux-pm, khilman, linux-kernel, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20190823090418.17148-5-narmstrong@baylibre.com>
On Fri, Aug 23, 2019 at 11:06 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Add the HDMI support nodes for the Amlogic SM1 Based SEI610 Board.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
this looks sane so feel free to add my:
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: at91: DT for 5.4
From: Alexandre Belloni @ 2019-08-25 20:26 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm, soc
Cc: Ludovic Desroches, linux-arm-kernel, linux-kernel
Hi,
A few DT changes affecting only the style but not the DTB output. There
may be some late DT changes a bit later (but hopefully not too late).
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-5.4-dt
for you to fetch changes up to bb3e9c767c6134a5761470038e8c75cdb6f04867:
ARM: dts: at91: at91sam9x5dm.dtsi: Style cleanup (2019-08-21 18:41:36 +0200)
----------------------------------------------------------------
AT91 DT for 5.4
- style cleanup for at91sam9x5 based boards
- avoid colliding node and property names
----------------------------------------------------------------
Rob Herring (1):
ARM: dts: at91: Avoid colliding 'display' node and property names
Uwe Kleine-König (10):
dt-bindings: add vendor prefix "acme" for "Acme Systems srl"
ARM: dts: at91: Add label for sam9x5's internal RTC
ARM: dts: at91: ariag25: Style cleanup
ARM: dts: at91: ariettag25: style cleanup
ARM: dts: at91: cosino: Style cleanup
ARM: dts: at91: kizboxmini: Style cleanup
ARM: dts: at91: at91sam9g15: Style cleanup
ARM: dts: at91: at91sam9xx5ek: Style cleanup
ARM: dts: at91: at91sam9x5_lcd.dtsi: Style cleanup
ARM: dts: at91: at91sam9x5dm.dtsi: Style cleanup
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/at91-ariag25.dts | 255 ++++++++++----------
arch/arm/boot/dts/at91-ariettag25.dts | 100 ++++----
arch/arm/boot/dts/at91-cosino.dtsi | 203 ++++++++--------
arch/arm/boot/dts/at91-cosino_mega2560.dts | 93 ++++----
arch/arm/boot/dts/at91-kizboxmini.dts | 179 +++++++-------
arch/arm/boot/dts/at91sam9261ek.dts | 2 +-
arch/arm/boot/dts/at91sam9263ek.dts | 2 +-
arch/arm/boot/dts/at91sam9g15.dtsi | 28 +--
arch/arm/boot/dts/at91sam9g15ek.dts | 12 +-
arch/arm/boot/dts/at91sam9g25ek.dts | 89 ++++---
arch/arm/boot/dts/at91sam9g35ek.dts | 22 +-
arch/arm/boot/dts/at91sam9m10g45ek.dts | 2 +-
arch/arm/boot/dts/at91sam9rlek.dts | 2 +-
arch/arm/boot/dts/at91sam9x25ek.dts | 36 ++-
arch/arm/boot/dts/at91sam9x35ek.dts | 43 ++--
arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
arch/arm/boot/dts/at91sam9x5_lcd.dtsi | 194 +++++++--------
arch/arm/boot/dts/at91sam9x5dm.dtsi | 86 ++++---
arch/arm/boot/dts/at91sam9x5ek.dtsi | 265 ++++++++++-----------
20 files changed, 785 insertions(+), 832 deletions(-)
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: at91: SoC for 5.4
From: Alexandre Belloni @ 2019-08-25 20:32 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm, soc
Cc: Ludovic Desroches, linux-arm-kernel, linux-kernel
Hello,
A non urgent fix for the generated header in mach-at91 and mostly
MAINTAINERS updates.
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-5.4-soc
for you to fetch changes up to 2cb831e0f152e483ab797b44787a4ff426267fbc:
mailmap: map old company name to new one @microchip.com (2019-08-23 21:53:40 +0200)
----------------------------------------------------------------
AT91 SoC for 5.4
- MAINTAINERS updates
- a generated headers parallel build fix
----------------------------------------------------------------
Masahiro Yamada (1):
ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91
Nicolas Ferre (3):
MAINTAINERS: at91: Collect all pinctrl/gpio drivers in same entry
MAINTAINERS: at91: remove the TC entry
mailmap: map old company name to new one @microchip.com
.mailmap | 1 +
MAINTAINERS | 14 +-------------
arch/arm/mach-at91/.gitignore | 1 +
arch/arm/mach-at91/Makefile | 5 +++--
arch/arm/mach-at91/pm_suspend.S | 2 +-
5 files changed, 7 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/mach-at91/.gitignore
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/5] soc: amlogic: Add support for Everything-Else power domains controller
From: Martin Blumenstingl @ 2019-08-25 21:10 UTC (permalink / raw)
To: Neil Armstrong
Cc: ulf.hansson, linux-pm, khilman, linux-kernel, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20190823090418.17148-3-narmstrong@baylibre.com>
Hi Neil,
thank you for this update
I haven't tried this on the 32-bit SoCs yet, but I am confident that I
can make it work by "just" adding the SoC specific bits!
On Fri, Aug 23, 2019 at 11:06 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
[...]
> +/* AO Offsets */
> +
> +#define AO_RTI_GEN_PWR_SLEEP0 (0x3a << 2)
> +#define AO_RTI_GEN_PWR_ISO0 (0x3b << 2)
> +
> +/* HHI Offsets */
> +
> +#define HHI_MEM_PD_REG0 (0x40 << 2)
> +#define HHI_VPU_MEM_PD_REG0 (0x41 << 2)
> +#define HHI_VPU_MEM_PD_REG1 (0x42 << 2)
> +#define HHI_VPU_MEM_PD_REG3 (0x43 << 2)
> +#define HHI_VPU_MEM_PD_REG4 (0x44 << 2)
> +#define HHI_AUDIO_MEM_PD_REG0 (0x45 << 2)
> +#define HHI_NANOQ_MEM_PD_REG0 (0x46 << 2)
> +#define HHI_NANOQ_MEM_PD_REG1 (0x47 << 2)
> +#define HHI_VPU_MEM_PD_REG2 (0x4d << 2)
should we switch to the actual register offsets like we did in the
clock drivers?
[...]
> +static struct meson_ee_pwrc_top_domain sm1_pwrc_vpu = SM1_EE_PD(8);
nit-pick: maybe name it sm1_pwrc_vpu_hdmi as the datasheet states that
it's for "VPU/HDMI"
[...]
> +#define VPU_HHI_MEMPD(__reg) \
> + { __reg, BIT(8) }, \
> + { __reg, BIT(9) }, \
> + { __reg, BIT(10) }, \
> + { __reg, BIT(11) }, \
> + { __reg, BIT(12) }, \
> + { __reg, BIT(13) }, \
> + { __reg, BIT(14) }, \
> + { __reg, BIT(15) }
the Amlogic implementation from buildroot-openlinux-A113-201901 (the
latest one I have)
kernel/aml-4.9/drivers/amlogic/media/vout/hdmitx/hdmi_tx_20/hw/hdmi_tx_hw.c
uses:
hd_set_reg_bits(P_HHI_MEM_PD_REG0, 0, 8, 8)
that basically translates to: GENMASK(15, 8) (which means we could
drop this macro)
the datasheet also states: 15~8 [...] HDMI memory PD (as a single
8-bit wide register)
[...]
> +static struct meson_ee_pwrc_domain_desc g12a_pwrc_domains[] = {
> + [PWRC_G12A_VPU_ID] = VPU_PD("VPU", &g12a_pwrc_vpu, g12a_pwrc_mem_vpu,
> + pwrc_ee_get_power, 11, 2),
> + [PWRC_G12A_ETH_ID] = MEM_PD("ETH", g12a_pwrc_mem_eth),
> +};
> +
> +static struct meson_ee_pwrc_domain_desc sm1_pwrc_domains[] = {
> + [PWRC_SM1_VPU_ID] = VPU_PD("VPU", &sm1_pwrc_vpu, sm1_pwrc_mem_vpu,
> + pwrc_ee_get_power, 11, 2),
> + [PWRC_SM1_NNA_ID] = TOP_PD("NNA", &sm1_pwrc_nna, sm1_pwrc_mem_nna,
> + pwrc_ee_get_power),
> + [PWRC_SM1_USB_ID] = TOP_PD("USB", &sm1_pwrc_usb, sm1_pwrc_mem_usb,
> + pwrc_ee_get_power),
> + [PWRC_SM1_PCIE_ID] = TOP_PD("PCI", &sm1_pwrc_pci, sm1_pwrc_mem_pcie,
> + pwrc_ee_get_power),
> + [PWRC_SM1_GE2D_ID] = TOP_PD("GE2D", &sm1_pwrc_ge2d, sm1_pwrc_mem_ge2d,
> + pwrc_ee_get_power),
> + [PWRC_SM1_AUDIO_ID] = MEM_PD("AUDIO", sm1_pwrc_mem_audio),
> + [PWRC_SM1_ETH_ID] = MEM_PD("ETH", g12a_pwrc_mem_eth),
> +};
my impression: I find this hard to read as it merges the TOP and
Memory PD domains from above, adding some seemingly random "11, 2" for
the VPU PD as well as pwrc_ee_get_power for some of the power domains
personally I like the way we describe clk_regmap because it's easy to
read (even though it adds a bit of boilerplate). I'm not sure if we
can make it work here, but this (not compile tested) is what I have in
mind (I chose two random power domains):
[PWRC_SM1_VPU_ID] = {
.name = "VPU",
.top_pd = SM1_EE_PD(8),
.mem_pds = {
VPU_MEMPD(HHI_VPU_MEM_PD_REG0),
VPU_MEMPD(HHI_VPU_MEM_PD_REG1),
VPU_MEMPD(HHI_VPU_MEM_PD_REG2),
VPU_MEMPD(HHI_VPU_MEM_PD_REG3),
{ HHI_VPU_MEM_PD_REG4, GENMASK(1, 0) },
{ HHI_VPU_MEM_PD_REG4, GENMASK(3, 2) },
{ HHI_VPU_MEM_PD_REG4, GENMASK(5, 4) },
{ HHI_VPU_MEM_PD_REG4, GENMASK(7, 6) },
{ HHI_MEM_PD_REG0, GENMASK(15, 8) },
},
.num_mem_pds = 9,
.reset_names_count = 11,
.clk_names_count = 2,
},
[PWRC_SM1_ETH_ID] = {
.name = "ETH",
.mem_pds = { HHI_MEM_PD_REG0, GENMASK(3, 2) },
.num_mem_pds = 1,
},
...
I'd like to get Kevin's feedback on this
what you have right now is probably good enough for the initial
version of this driver. I'm bringing this discussion up because we
will add support for more SoCs to this driver (we migrate GX over to
it and I want to add 32-bit SoC support, which probably means at least
Meson8 - assuming they kept the power domains identical between
Meson8/8b/8m2).
[...]
> +struct meson_ee_pwrc_domain {
> + struct generic_pm_domain base;
> + bool enabled;
> + struct meson_ee_pwrc *pwrc;
> + struct meson_ee_pwrc_domain_desc desc;
> + struct clk_bulk_data *clks;
> + int num_clks;
> + struct reset_control *rstc;
> + int num_rstc;
> +};
> +
> +struct meson_ee_pwrc {
> + struct regmap *regmap_ao;
> + struct regmap *regmap_hhi;
> + struct meson_ee_pwrc_domain *domains;
> + struct genpd_onecell_data xlate;
> +};
(my impressions on this: I was surprised to find more structs down
here, I expected them to be together with the other structs further
up)
> +static bool pwrc_ee_get_power(struct meson_ee_pwrc_domain *pwrc_domain)
> +{
> + u32 reg;
> +
> + regmap_read(pwrc_domain->pwrc->regmap_ao,
> + pwrc_domain->desc.top_pd->sleep_reg, ®);
> +
> + return (reg & pwrc_domain->desc.top_pd->sleep_mask);
should this also check for top_pd->iso_* as well as mem_pd->*?
if the top_pd part was optional we could even use the get_power
callback for *all* power domains in this driver (right now audio and
Ethernet don't have any get_power callback)
> +}
> +
> +static int meson_ee_pwrc_off(struct generic_pm_domain *domain)
> +{
> + struct meson_ee_pwrc_domain *pwrc_domain =
> + container_of(domain, struct meson_ee_pwrc_domain, base);
> + int i;
> +
> + if (pwrc_domain->desc.top_pd)
> + regmap_update_bits(pwrc_domain->pwrc->regmap_ao,
> + pwrc_domain->desc.top_pd->sleep_reg,
> + pwrc_domain->desc.top_pd->sleep_mask,
> + pwrc_domain->desc.top_pd->sleep_mask);
> + udelay(20);
all four udelay(20) occurrences should probably be usleep_range(20,
100); (or some other max value), see [0]
[...]
> + /*
> + * TOFIX: This is a special case for the VPU power domain, which can
> + * be enabled previously by the bootloader. In this case the VPU
nit-pick: the indentation seems to be off here
[...]
> +static int meson_ee_pwrc_probe(struct platform_device *pdev)
> +{
> + const struct meson_ee_pwrc_domain_data *match;
> + struct regmap *regmap_ao, *regmap_hhi;
> + struct meson_ee_pwrc *pwrc;
> + int i, ret;
> +
> + match = of_device_get_match_data(&pdev->dev);
> + if (!match) {
> + dev_err(&pdev->dev, "failed to get match data\n");
> + return -ENODEV;
> + }
> +
> + pwrc = devm_kzalloc(&pdev->dev, sizeof(*pwrc), GFP_KERNEL);
> + if (!pwrc)
> + return -ENOMEM;
> +
> + pwrc->xlate.domains = devm_kcalloc(&pdev->dev, match->count,
> + sizeof(*pwrc->xlate.domains),
> + GFP_KERNEL);
> + if (!pwrc->xlate.domains)
> + return -ENOMEM;
> +
> + pwrc->domains = devm_kcalloc(&pdev->dev, match->count,
> + sizeof(*pwrc->domains), GFP_KERNEL);
> + if (!pwrc->domains)
> + return -ENOMEM;
> +
> + pwrc->xlate.num_domains = match->count;
> +
> + regmap_hhi = syscon_node_to_regmap(of_get_parent(pdev->dev.of_node));
> + if (IS_ERR(regmap_hhi)) {
> + dev_err(&pdev->dev, "failed to get HHI regmap\n");
> + return PTR_ERR(regmap_hhi);
> + }
> +
> + regmap_ao = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> + "amlogic,ao-sysctrl");
> + if (IS_ERR(regmap_ao)) {
> + dev_err(&pdev->dev, "failed to get AO regmap\n");
> + return PTR_ERR(regmap_ao);
> + }
> +
> + pwrc->regmap_ao = regmap_ao;
> + pwrc->regmap_hhi = regmap_hhi;
> +
> + platform_set_drvdata(pdev, pwrc);
> +
> + for (i = 0 ; i < match->count ; ++i) {
> + struct meson_ee_pwrc_domain *dom = &pwrc->domains[i];
> +
> + memcpy(&dom->desc, &match->domains[i], sizeof(dom->desc));
> +
> + ret = meson_ee_pwrc_init_domain(pdev, pwrc, dom);
> + if (ret)
> + return ret;
> +
> + pwrc->xlate.domains[i] = &dom->base;
> + }
> +
> + of_genpd_add_provider_onecell(pdev->dev.of_node, &pwrc->xlate);
return of_genpd_add_provider_onecell(...) to propagate errors (if any)
bonus question: what about the video decoder power domains?
here is an example from vdec_1_start
(drivers/staging/media/meson/vdec/vdec_1.c):
/* Enable power for VDEC_1 */
regmap_update_bits(core->regmap_ao, AO_RTI_GEN_PWR_SLEEP0,
GEN_PWR_VDEC_1, 0);
usleep_range(10, 20);
[...]
/* enable VDEC Memories */
amvdec_write_dos(core, DOS_MEM_PD_VDEC, 0);
/* Remove VDEC1 Isolation */
regmap_write(core->regmap_ao, AO_RTI_GEN_PWR_ISO0, 0);
(my point here is that it mixes video decoder "DOS" registers with
AO_RTI_GEN_PWR registers)
do we also want to add support for these "DOS" power domains to the
meson-ee-pwrc driver?
what about the AO_RTI_GEN_PWR part then - should we keep management
for the video decoder power domain bits in AO_RTI_GEN_PWR as part of
the video decoder driver?
Martin
[0] https://www.kernel.org/doc/Documentation/timers/timers-howto.rst
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] PCI: mediatek: Remove surplus return from a void function
From: Krzysztof Wilczynski @ 2019-08-25 22:10 UTC (permalink / raw)
To: Matthias Brugger
Cc: Lorenzo Pieralisi, linux-pci, linux-kernel, Ryder Lee,
Bjorn Helgaas, linux-mediatek, linux-arm-kernel
Remove unnecessary empty return statement at the
end of a void function mtk_pcie_intr_handler() in
the drivers/pci/controller/pcie-mediatek.c.
The surplus return statement was added as part of
the work in commit 42fe2f91b4eb ("PCI: mediatek:
Implement chained IRQ handling setup").
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
---
drivers/pci/controller/pcie-mediatek.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
index 3eaa7081ab2a..626a7c352dfd 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -635,8 +635,6 @@ static void mtk_pcie_intr_handler(struct irq_desc *desc)
}
chained_irq_exit(irqchip, desc);
-
- return;
}
static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
--
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 related
* Re: [PATCH v9 1/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
From: Chris Packham @ 2019-08-26 0:46 UTC (permalink / raw)
To: linux@armlinux.org.uk
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jlu@pengutronix.de, linux-edac@vger.kernel.org,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
james.morse@arm.com, gregory.clement@free-electrons.com,
bp@alien8.de, mchehab@kernel.org,
linux-arm-kernel@lists.infradead.org, patches@armlinux.org.uk
In-Reply-To: <20190823105020.GZ13294@shell.armlinux.org.uk>
Hi Russell,
On Fri, 2019-08-23 at 11:50 +0100, Russell King - ARM Linux admin
wrote:
> On Fri, Aug 23, 2019 at 11:46:21AM +0100, Russell King - ARM Linux
> admin wrote:
> > On Fri, Jul 12, 2019 at 03:48:57PM +1200, Chris Packham wrote:
> > > From: Jan Luebbe <jlu@pengutronix.de>
> > >
> > > The macro name is too generic, so add a AURORA_ prefix.
> > >
> > > Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
> > > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> > > ---
> > > arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
> >
> > I can't apply this series - this file does not exist in my tree,
> > and
> > from what git tells me, it never has existed. Maybe it's in
> > someone
> > elses tree?
>
> I think the file is in my tree, just as arch/arm/mm/cache-aurora-l2.h
> which is where it has been since it was originally submitted in 2012.
>
Sorry there is a missing patch that moves it next to the
hardware/cache-*.h. I can send the missing patch or I can re-send the
whole series. If I do send the whole series do you want me to rebase it
against a particular tag/tree?
> >
> > > arch/arm/mm/cache-l2x0.c | 4 ++--
> > > 2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > > b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > > index c86124769831..dc5c479ec4c3 100644
> > > --- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > > +++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
> > > @@ -41,7 +41,7 @@
> > > #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
> > > (2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
> > >
> > > -#define MAX_RANGE_SIZE 1024
> > > +#define AURORA_MAX_RANGE_SIZE 1024
> > >
> > > #define AURORA_WAY_SIZE_SHIFT 2
> > >
> > > diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> > > index 428d08718107..83b733a1f1e6 100644
> > > --- a/arch/arm/mm/cache-l2x0.c
> > > +++ b/arch/arm/mm/cache-l2x0.c
> > > @@ -1352,8 +1352,8 @@ static unsigned long
> > > aurora_range_end(unsigned long start, unsigned long end)
> > > * since cache range operations stall the CPU pipeline
> > > * until completion.
> > > */
> > > - if (end > start + MAX_RANGE_SIZE)
> > > - end = start + MAX_RANGE_SIZE;
> > > + if (end > start + AURORA_MAX_RANGE_SIZE)
> > > + end = start + AURORA_MAX_RANGE_SIZE;
> > >
> > > /*
> > > * Cache range operations can't straddle a page boundary.
> > > --
> > > 2.22.0
> > >
> > >
> >
> > --
> > 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
* [PATCH v2 -next] net: mediatek: remove set but not used variable 'status'
From: Mao Wenan @ 2019-08-26 1:31 UTC (permalink / raw)
To: nbd, john, sean.wang, nelson.chang, davem, matthias.bgg
Cc: netdev, kernel-janitors, linux-kernel, Mao Wenan, linux-mediatek,
linux-arm-kernel
In-Reply-To: <20190824.142158.1506174328495468705.davem@davemloft.net>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function mtk_handle_irq:
drivers/net/ethernet/mediatek/mtk_eth_soc.c:1951:6: warning: variable status set but not used [-Wunused-but-set-variable]
Fixes: 296c9120752b ("net: ethernet: mediatek: Add MT7628/88 SoC support")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
v2: change format of 'Fixes' tag.
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8ddbb8d..bb7d623 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1948,9 +1948,7 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void *_eth)
static irqreturn_t mtk_handle_irq(int irq, void *_eth)
{
struct mtk_eth *eth = _eth;
- u32 status;
- status = mtk_r32(eth, MTK_PDMA_INT_STATUS);
if (mtk_r32(eth, MTK_PDMA_INT_MASK) & MTK_RX_DONE_INT) {
if (mtk_r32(eth, MTK_PDMA_INT_STATUS) & MTK_RX_DONE_INT)
mtk_handle_irq_rx(irq, _eth);
--
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 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Masahiro Yamada @ 2019-08-26 1:56 UTC (permalink / raw)
To: Nicolin Chen
Cc: Tony Lindgren, Catalin Marinas, Will Deacon, Max Filippov,
Christoph Hellwig, Marek Szyprowski, Stephen Rothwell,
Joerg Roedel, Russell King, Thierry Reding, linux-xtensa,
Kees Cook, Andrew Morton, linux-arm-kernel, Chris Zankel,
Wolfram Sang, Robin Murphy, Linux Kernel Mailing List, iommu,
iamjoonsoo.kim, David Woodhouse
In-Reply-To: <20190823221103.GA3604@Asurada-Nvidia.nvidia.com>
Hi Nicolin,
On Sat, Aug 24, 2019 at 7:10 AM Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>
> On Fri, Aug 23, 2019 at 09:49:46PM +0900, Masahiro Yamada wrote:
> >
> > Reverting this commit fixed the problem.
>
> We are having another problem with the new API and Christoph
> submitted a patch at: https://lkml.org/lkml/2019/8/20/86
>
> Would it be possible for you to test to see if it can fix?
It is included in 5.3-rc6
I tested 5.3-rc6 in on my board,
but I still see the same DMA fauilure.
Masahiro
> We can revert my fallback change after all, if Christoph's
> patch doesn't work for you either.
>
> Thanks
> Nicolin
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Masahiro Yamada @ 2019-08-26 2:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ulf Hansson, Tony Lindgren, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Max Filippov, Marek Szyprowski,
Stephen Rothwell, Joerg Roedel, Russell King, Thierry Reding,
linux-xtensa, Kees Cook, Nicolin Chen, Andrew Morton,
linux-arm-kernel, Chris Zankel, Wolfram Sang, David Woodhouse,
linux-mmc, Adrian Hunter, iommu, iamjoonsoo.kim, Robin Murphy
In-Reply-To: <20190825011025.GA23410@lst.de>
Christoph,
On Sun, Aug 25, 2019 at 10:10 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Fri, Aug 23, 2019 at 09:56:52PM +0900, Masahiro Yamada wrote:
> > + linux-mmc, Ulf Hansson, Adrian Hunter,
> >
> >
> > ADMA of SDHCI is not working
> > since bd2e75633c8012fc8a7431c82fda66237133bf7e
>
> Does it work for you with this commit:
>
> http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/90ae409f9eb3bcaf38688f9ec22375816053a08e
This is included in v5.3-rc6
so I tested it.
No, it did not fix the problem.
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 -next] net: mediatek: remove set but not used variable 'status'
From: David Miller @ 2019-08-26 2:06 UTC (permalink / raw)
To: maowenan
Cc: nbd, nelson.chang, netdev, sean.wang, kernel-janitors,
linux-kernel, linux-mediatek, john, matthias.bgg,
linux-arm-kernel
In-Reply-To: <20190826013118.22720-1-maowenan@huawei.com>
From: Mao Wenan <maowenan@huawei.com>
Date: Mon, 26 Aug 2019 09:31:18 +0800
> Fixes gcc '-Wunused-but-set-variable' warning:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function mtk_handle_irq:
> drivers/net/ethernet/mediatek/mtk_eth_soc.c:1951:6: warning: variable status set but not used [-Wunused-but-set-variable]
>
> Fixes: 296c9120752b ("net: ethernet: mediatek: Add MT7628/88 SoC support")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Are you sure the register isn't being read in order to make some
hardware side effect happen?
Have you tested this on effected hardware?
I'm not applying this without definitive answers to these questions.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: mmc: aspeed: Update example ranges property
From: Andrew Jeffery @ 2019-08-26 2:16 UTC (permalink / raw)
To: linux-mmc
Cc: mark.rutland, devicetree, ulf.hansson, linux-aspeed,
Andrew Jeffery, linux-kernel, robh+dt, joel, linux-arm-kernel
The example node in the binding uses the AST2500 compatible string for
the SD controller with a 64kiB ranges property, but the SD controller is
allocated 128kiB of MMIO space according to the AST2500 datasheet. Fix
the example to correctly reflect the hardware in the AST2500, however it
should be noted that the MMIO region is reduced to 64kiB in the AST2600
where a second SD controller block has been introduced into the address
space.
Also add the IBM copyright header that I left out of the initial patch.
Suggested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
Hi Ulf, this is the follow-up fix as discussed here:
http://patchwork.ozlabs.org/patch/1143090/
Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
index 570f8c72662b..200de9396036 100644
--- a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-or-later
+# Copyright 2019 IBM Corp.
%YAML 1.2
---
$id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml#
@@ -84,7 +85,7 @@ examples:
reg = <0x1e740000 0x100>;
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0 0x1e740000 0x10000>;
+ ranges = <0 0x1e740000 0x20000>;
clocks = <&syscon ASPEED_CLK_GATE_SDCLK>;
sdhci0: sdhci@100 {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC V2 0/1] mm/debug: Add tests for architecture exported page table helpers
From: Anshuman Khandual @ 2019-08-26 2:29 UTC (permalink / raw)
To: Mark Rutland, Matthew Wilcox
Cc: linux-ia64, linux-sh, Tetsuo Handa, James Hogan, Heiko Carstens,
Michal Hocko, linux-mm, Dave Hansen, Paul Mackerras, sparclinux,
Thomas Gleixner, linux-s390, Michael Ellerman, x86,
Russell King - ARM Linux, Steven Price, Jason Gunthorpe,
linux-arm-kernel, linux-snps-arc, Kees Cook, Masahiro Yamada,
Mark Brown, Dan Williams, Vlastimil Babka, Sri Krishna chowdary,
Ard Biesheuvel, Greg Kroah-Hartman, linux-mips, Ralf Baechle,
linux-kernel, Peter Zijlstra, Mike Rapoport, Paul Burton,
Vineet Gupta, Martin Schwidefsky, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20190809114450.GF48423@lakrids.cambridge.arm.com>
On 08/09/2019 05:14 PM, Mark Rutland wrote:
> On Fri, Aug 09, 2019 at 03:16:33AM -0700, Matthew Wilcox wrote:
>> On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote:
>>> Should alloc_gigantic_page() be made available as an interface for general
>>> use in the kernel. The test module here uses very similar implementation from
>>> HugeTLB to allocate a PUD aligned memory block. Similar for mm_alloc() which
>>> needs to be exported through a header.
>>
>> Why are you allocating memory at all instead of just using some
>> known-to-exist PFNs like I suggested?
>
> IIUC the issue is that there aren't necessarily known-to-exist PFNs that
> are sufficiently aligned -- they may not even exist.
>
> For example, with 64K pages, a PMD covers 512M. The kernel image is
> (generally) smaller than 512M, and will be mapped at page granularity.
> In that case, any PMD entry for a kernel symbol address will point to
> the PTE level table, and that will only necessarily be page-aligned, as
> any P?D level table is only necessarily page-aligned.
Right.
>
> In the same configuration, you could have less than 512M of total
> memory, and none of this memory is necessarily aligned to 512M. So
> beyond the PTE level, I don't think you can guarantee a known-to-exist
> valid PFN.
Right a PMD aligned valid PFN might not even exist. This proposed patch
which attempts to allocate memory chunk with required alignment will just
fail indicating that such a valid PFN does not exist and hence will skip
any relevant tests. At present this is done for PUD aligned allocation
failure but we can similarly skip PMD relevant tests as well if PMD
aligned memory chunk is not allocated.
>
> I also believe that synthetic PFNs could fail pfn_valid(), so that might
> cause us pain too...
Agreed. So do we have an agreement that it is better to use allocated
memory with required alignment for the tests than known-to-exist PFNs ?
- Anshuman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC V2 0/1] mm/debug: Add tests for architecture exported page table helpers
From: Anshuman Khandual @ 2019-08-26 2:37 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Steven Price,
Jason Gunthorpe, linux-arm-kernel, linux-snps-arc, Kees Cook,
Masahiro Yamada, Mark Brown, Dan Williams, Vlastimil Babka,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20190809135202.GN5482@bombadil.infradead.org>
On 08/09/2019 07:22 PM, Matthew Wilcox wrote:
> On Fri, Aug 09, 2019 at 04:05:07PM +0530, Anshuman Khandual wrote:
>> On 08/09/2019 03:46 PM, Matthew Wilcox wrote:
>>> On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote:
>>>> Should alloc_gigantic_page() be made available as an interface for general
>>>> use in the kernel. The test module here uses very similar implementation from
>>>> HugeTLB to allocate a PUD aligned memory block. Similar for mm_alloc() which
>>>> needs to be exported through a header.
>>>
>>> Why are you allocating memory at all instead of just using some
>>> known-to-exist PFNs like I suggested?
>>
>> We needed PFN to be PUD aligned for pfn_pud() and PMD aligned for mk_pmd().
>> Now walking the kernel page table for a known symbol like kernel_init()
>
> I didn't say to walk the kernel page table. I said to call virt_to_pfn()
> for a known symbol like kernel_init().
>
>> as you had suggested earlier we might encounter page table page entries at PMD
>> and PUD which might not be PMD or PUD aligned respectively. It seemed to me
>> that alignment requirement is applicable only for mk_pmd() and pfn_pud()
>> which create large mappings at those levels but that requirement does not
>> exist for page table pages pointing to next level. Is not that correct ? Or
>> I am missing something here ?
>
> Just clear the bottom bits off the PFN until you get a PMD or PUD aligned
> PFN. It's really not hard.
As Mark pointed out earlier that might end up being just a synthetic PFN
which might not even exist on a given system.
_______________________________________________
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 V4 02/11] dt-bindings: clock: imx-lpcg: add support to parse clocks from device tree
From: Aisheng Dong @ 2019-08-26 3:14 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree@vger.kernel.org, sboyd@kernel.org,
mturquette@baylibre.com, Rob Herring, dl-linux-imx,
kernel@pengutronix.de, Fabio Estevam, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190824192101.GG16308@X250.getinternet.no>
Hi Shawn,
> From: Shawn Guo <shawnguo@kernel.org>
> Sent: Sunday, August 25, 2019 3:21 AM
> Subject: Re: [PATCH V4 02/11] dt-bindings: clock: imx-lpcg: add support to
> parse clocks from device tree
>
> On Tue, Aug 20, 2019 at 07:13:16AM -0400, Dong Aisheng wrote:
> > MX8QM and MX8QXP LPCG Clocks are mostly the same except they may
> > reside in different subsystems across CPUs and also vary a bit on the
> availability.
> >
> > Same as SCU clock, we want to move the clock definition into device
> > tree which can fully decouple the dependency of Clock ID definition
> > from device tree and make us be able to write a fully generic lpcg clock
> driver.
> >
> > And we can also use the existence of clock nodes in device tree to
> > address the device and clock availability differences across different SoCs.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
Thanks for the review.
Do you think if we have a chance to catch up v5.4?
Will this patch set go through Clock tree or your tree?
Regards
Aisheng
_______________________________________________
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 V4 02/11] dt-bindings: clock: imx-lpcg: add support to parse clocks from device tree
From: Aisheng Dong @ 2019-08-26 3:21 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree@vger.kernel.org, sboyd@kernel.org,
mturquette@baylibre.com, Rob Herring, dl-linux-imx,
kernel@pengutronix.de, Fabio Estevam, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190824192101.GG16308@X250.getinternet.no>
> From: Shawn Guo <shawnguo@kernel.org>
> Sent: Sunday, August 25, 2019 3:21 AM
> Subject: Re: [PATCH V4 02/11] dt-bindings: clock: imx-lpcg: add support to
> parse clocks from device tree
>
> On Tue, Aug 20, 2019 at 07:13:16AM -0400, Dong Aisheng wrote:
> > MX8QM and MX8QXP LPCG Clocks are mostly the same except they may
> > reside in different subsystems across CPUs and also vary a bit on the
> availability.
> >
> > Same as SCU clock, we want to move the clock definition into device
> > tree which can fully decouple the dependency of Clock ID definition
> > from device tree and make us be able to write a fully generic lpcg clock
> driver.
> >
> > And we can also use the existence of clock nodes in device tree to
> > address the device and clock availability differences across different SoCs.
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
Thanks Shawn.
Stephen & Rob,
Would you help review if you're also ok with this binding?
We need this to be finalized early for the following work.
Regards
Aisheng
_______________________________________________
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 V4 01/11] dt-bindings: firmware: imx-scu: new binding to parse clocks from device tree
From: Aisheng Dong @ 2019-08-26 3:24 UTC (permalink / raw)
To: Rob Herring, sboyd@kernel.org
Cc: devicetree@vger.kernel.org, sboyd@kernel.org,
mturquette@baylibre.com, Rob Herring, dl-linux-imx,
kernel@pengutronix.de, Fabio Estevam, Shawn Guo,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190824191957.GF16308@X250.getinternet.no>
> From: Shawn Guo <shawnguo@kernel.org>
> Sent: Sunday, August 25, 2019 3:20 AM
> Subject: Re: [PATCH V4 01/11] dt-bindings: firmware: imx-scu: new binding to
> parse clocks from device tree
>
> On Tue, Aug 20, 2019 at 07:13:15AM -0400, Dong Aisheng wrote:
> > There's a few limitations on the original one cell clock binding
> > (#clock-cells = <1>) that we have to define some SW clock IDs for
> > device tree to reference. This may cause troubles if we want to use
> > common clock IDs for multi platforms support when the clock of those
> > platforms are mostly the same.
> > e.g. Current clock IDs name are defined with SS prefix.
> >
> > However the device may reside in different SS across CPUs, that means
> > the SS prefix may not valid anymore for a new SoC. Furthermore, the
> > device availability of those clocks may also vary a bit.
> >
> > For such situation, we want to eliminate the using of SW Clock IDs and
> > change to use a more close to HW one instead.
> > For SCU clocks usage, only two params required: Resource id + Clock Type.
> > Both parameters are platform independent. So we could use two cells
> > binding to pass those parameters,
> >
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
>
> I'm fine with it.
>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
>
And this one.
Stephen & Rob,
Do you have change to look at it?
We need this to be finalized early for the following work.
Regards
Aisheng
> Shawn
>
> > ---
> > ChangeLog:
> > v3->v4:
> > * add some comments for various clock types
> > v2->v3:
> > * Changed to two cells binding and register all clocks in driver
> > instead of parse from device tree.
> > v1->v2:
> > * changed to one cell binding inspired by arm,scpi.txt
> > Documentation/devicetree/bindings/arm/arm,scpi.txt
> > Resource ID is encoded in 'reg' property.
> > Clock type is encoded in generic clock-indices property.
> > Then we don't have to search all the DT nodes to fetch
> > those two value to construct clocks which is relatively
> > low efficiency.
> > * Add required power-domain property as well.
> > ---
> > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 12 ++++++-----
> > include/dt-bindings/firmware/imx/rsrc.h | 23
> ++++++++++++++++++++++
> > 2 files changed, 30 insertions(+), 5 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index a575e42..8cee5bf 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -89,7 +89,10 @@ Required properties:
> > "fsl,imx8qm-clock"
> > "fsl,imx8qxp-clock"
> > followed by "fsl,scu-clk"
> > -- #clock-cells: Should be 1. Contains the Clock ID value.
> > +- #clock-cells: Should be either
> > + 2: Contains the Resource and Clock ID value.
> > + or
> > + 1: Contains the Clock ID value. (DEPRECATED)
> > - clocks: List of clock specifiers, must contain an entry for
> > each required entry in clock-names
> > - clock-names: Should include entries "xtal_32KHz", "xtal_24MHz"
> > @@ -184,7 +187,7 @@ firmware {
> >
> > clk: clk {
> > compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
> > - #clock-cells = <1>;
> > + #clock-cells = <2>;
> > };
> >
> > iomuxc {
> > @@ -229,8 +232,7 @@ serial@5a060000 {
> > ...
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_lpuart0>;
> > - clocks = <&clk IMX8QXP_UART0_CLK>,
> > - <&clk IMX8QXP_UART0_IPG_CLK>;
> > - clock-names = "per", "ipg";
> > + clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>;
> > + clock-names = "ipg";
> > power-domains = <&pd IMX_SC_R_UART_0>; }; diff --git
> > a/include/dt-bindings/firmware/imx/rsrc.h
> > b/include/dt-bindings/firmware/imx/rsrc.h
> > index 4e61f64..24c153d 100644
> > --- a/include/dt-bindings/firmware/imx/rsrc.h
> > +++ b/include/dt-bindings/firmware/imx/rsrc.h
> > @@ -547,4 +547,27 @@
> > #define IMX_SC_R_ATTESTATION 545
> > #define IMX_SC_R_LAST 546
> >
> > +/*
> > + * Defines for SC PM CLK
> > + */
> > +
> > +/* Normal device resource clock */
> > +#define IMX_SC_PM_CLK_SLV_BUS 0 /* Slave bus clock */
> > +#define IMX_SC_PM_CLK_MST_BUS 1 /* Master bus clock */
> > +#define IMX_SC_PM_CLK_PER 2 /* Peripheral clock */
> > +#define IMX_SC_PM_CLK_PHY 3 /* Phy clock */
> > +#define IMX_SC_PM_CLK_MISC 4 /* Misc clock */
> > +
> > +/* Special clock types which do not belong to above normal clock types */
> > +#define IMX_SC_PM_CLK_MISC0 0 /* Misc 0 clock */
> > +#define IMX_SC_PM_CLK_MISC1 1 /* Misc 1 clock */
> > +#define IMX_SC_PM_CLK_MISC2 2 /* Misc 2 clock */
> > +#define IMX_SC_PM_CLK_MISC3 3 /* Misc 3 clock */
> > +#define IMX_SC_PM_CLK_MISC4 4 /* Misc 4 clock */
> > +
> > +/* Special clock types for CPU/PLL/BYPASS only */
> > +#define IMX_SC_PM_CLK_CPU 2 /* CPU clock */
> > +#define IMX_SC_PM_CLK_PLL 4 /* PLL */
> > +#define IMX_SC_PM_CLK_BYPASS 4 /* Bypass clock */
> > +
> > #endif /* __DT_BINDINGS_RSCRC_IMX_H */
> > --
> > 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 v4 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
From: Z.q. Hou @ 2019-08-26 3:37 UTC (permalink / raw)
To: Xiaowei Bao, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, Leo Li, M.h. Lian, Mingkai Hu, Roy Zang,
lorenzo.pieralisi@arm.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
Cc: bhelgaas@google.com, Xiaowei Bao
In-Reply-To: <20190823082643.10903-2-xiaowei.bao@nxp.com>
Hi Xiaowei,
> -----Original Message-----
> From: Xiaowei Bao <xiaowei.bao@nxp.com>
> Sent: 2019年8月23日 16:27
> To: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org;
> Leo Li <leoyang.li@nxp.com>; M.h. Lian <minghuan.lian@nxp.com>;
> Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> lorenzo.pieralisi@arm.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Z.q.
> Hou <zhiqiang.hou@nxp.com>
> Cc: bhelgaas@google.com; Xiaowei Bao <xiaowei.bao@nxp.com>; Z.q. Hou
> <zhiqiang.hou@nxp.com>
> Subject: [PATCH v4 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
>
> LS1028a implements 2 PCIe 3.0 controllers.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> ---
> v2:
> - Fix up the legacy INTx allocate failed issue.
> v3:
> - No change.
> v4:
> - Remove the num-lanes proparty.
> depends on:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-pci%2Flist%2F%3Fseries%3D162215&a
> mp;data=02%7C01%7Czhiqiang.hou%40nxp.com%7C07a39c8a38114852ad8
> 808d727a50ea8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 7021462174809487&sdata=MTVsUPPoy2NrMjpXG4BMocHIN0Gbkh3W
> 8SN622QMLI8%3D&reserved=0
>
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 50
> ++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 72b9a75..a25f9d9 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -625,6 +625,56 @@
> };
> };
>
> + pcie@3400000 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x03400000 0x0 0x00100000 /* controller
> registers */
> + 0x80 0x00000000 0x0 0x00002000>; /* configuration
> space */
> + reg-names = "regs", "config";
> + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME
> interrupt */
> + <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; /* aer
> interrupt */
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0
> 0x00010000 /* downstream I/O */
> + 0x82000000 0x0 0x40000000 0x80 0x40000000 0x0
> 0x40000000>; /* non-prefetchable memory */
> + msi-parent = <&its>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> + <0000 0 0 2 &gic 0 0 GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>,
> + <0000 0 0 3 &gic 0 0 GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> + <0000 0 0 4 &gic 0 0 GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
lost the property num-viewport.
> +
> + pcie@3500000 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x03500000 0x0 0x00100000 /* controller
> registers */
> + 0x88 0x00000000 0x0 0x00002000>; /* configuration
> space */
> + reg-names = "regs", "config";
> + interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0
> 0x00010000 /* downstream I/O */
> + 0x82000000 0x0 0x40000000 0x88 0x40000000 0x0
> 0x40000000>; /* non-prefetchable memory */
> + msi-parent = <&its>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 114
> IRQ_TYPE_LEVEL_HIGH>,
> + <0000 0 0 2 &gic 0 0 GIC_SPI 115
> IRQ_TYPE_LEVEL_HIGH>,
> + <0000 0 0 3 &gic 0 0 GIC_SPI 116
> IRQ_TYPE_LEVEL_HIGH>,
> + <0000 0 0 4 &gic 0 0 GIC_SPI 117
> IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
Ditto
Thanks,
Zhiqiang
> +
> pcie@1f0000000 { /* Integrated Endpoint Root Complex */
> compatible = "pci-host-ecam-generic";
> reg = <0x01 0xf0000000 0x0 0x100000>;
> --
> 2.9.5
_______________________________________________
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 v4 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl,ls1028a-pcie"
From: Xiaowei Bao @ 2019-08-26 3:51 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: mark.rutland@arm.com, Roy Zang, devicetree@vger.kernel.org,
linux-pci@vger.kernel.org, Z.q. Hou,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Leo Li, M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, bhelgaas@google.com,
shawnguo@kernel.org, Mingkai Hu
In-Reply-To: <20190823140447.GA19283@e121166-lin.cambridge.arm.com>
> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: 2019年8月23日 22:05
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu
> <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linuxppc-dev@lists.ozlabs.org; Z.q. Hou <zhiqiang.hou@nxp.com>;
> bhelgaas@google.com
> Subject: Re: [PATCH v4 1/3] dt-bindings: pci: layerscape-pci: add compatible
> strings "fsl,ls1028a-pcie"
>
> On Fri, Aug 23, 2019 at 04:26:41PM +0800, Xiaowei Bao wrote:
> > Add the PCIe compatible string for LS1028A
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > v2:
> > - No change.
> > v3:
> > - No change.
> > v4:
> > - No change.
> >
> > Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > index e20ceaa..99a386e 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > @@ -21,6 +21,7 @@ Required properties:
> > "fsl,ls1046a-pcie"
> > "fsl,ls1043a-pcie"
> > "fsl,ls1012a-pcie"
> > + "fsl,ls1028a-pcie"
> > EP mode:
> > "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
> > - reg: base addresses and lengths of the PCIe controller register blocks.
>
> This series does not apply to v5.3-rc1, what is it based on ?
these set patches base on v5.3-rc3, thanks.
>
> 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: [PATCHv4 0/3] Odroid c2 usb fixs
From: Anand Moon @ 2019-08-26 4:38 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, Neil Armstrong, Kevin Hilman, Linux Kernel,
Rob Herring, linux-amlogic, linux-arm-kernel, Jerome Brunet
In-Reply-To: <CAFBinCCkEE8==-Sqqj_=Ofnx7_H-970dETwEmEPohs74806ZMw@mail.gmail.com>
Hi Martin,
On Sun, 25 Aug 2019 at 02:48, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> Hi Anand,
>
> thank you for the patches
>
> On Sat, Aug 24, 2019 at 8:49 PM Anand Moon <linux.amoon@gmail.com> wrote:
> [...]
> > Anand Moon (3):
> > arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input
> > arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus
> > arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power
> > failed warning
> this whole series is:
> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Thanks, I have some more patch in line for this board.
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: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Tomasz Figa @ 2019-08-26 6:36 UTC (permalink / raw)
To: Jerry-ch Chen
Cc: devicetree@vger.kernel.org, Sean Cheng (鄭昇弘),
Frederic Chen (陳俊元),
Rynn Wu (吳育恩), srv_heupstream,
Po-Yang Huang (黃柏陽), suleiman@chromium.org,
shik@chromium.org, Jungo Lin (林明俊),
Sj Huang (黃信璋), yuzhao@chromium.org,
linux-mediatek@lists.infradead.org, zwisler@chromium.org,
hans.verkuil@cisco.com, matthias.bgg@gmail.com,
Christie Yu (游雅惠), mchehab@kernel.org,
laurent.pinchart+renesas@ideasonboard.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <1566724680.20680.8.camel@mtksdccf07>
Hi Jerry,
On Sun, Aug 25, 2019 at 6:18 PM Jerry-ch Chen
<Jerry-ch.Chen@mediatek.com> wrote:
>
> Hi Tomasz,
>
> On Fri, 2019-08-02 at 16:28 +0800, Tomasz Figa wrote:
> > Hi Jerry,
> >
> > On Tue, Jul 09, 2019 at 04:41:12PM +0800, Jerry-ch Chen wrote:
> > > From: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
> > >
> > > This patch adds the driver of Face Detection (FD) unit in
> > > Mediatek camera system, providing face detection function.
> > >
> > > The mtk-isp directory will contain drivers for multiple IP
> > > blocks found in Mediatek ISP system. It will include ISP Pass 1
> > > driver (CAM), sensor interface driver, DIP driver and face
> > > detection driver.
> > >
> > > Signed-off-by: Jerry-ch Chen <jerry-ch.chen@mediatek.com>
> > > ---
> > > drivers/media/platform/Makefile | 2 +
> > > drivers/media/platform/mtk-isp/fd/Makefile | 5 +
> > > drivers/media/platform/mtk-isp/fd/mtk_fd.h | 157 +++
> > > drivers/media/platform/mtk-isp/fd/mtk_fd_40.c | 1259 +++++++++++++++++++++++++
> > > include/uapi/linux/v4l2-controls.h | 4 +
> > > 5 files changed, 1427 insertions(+)
> > > create mode 100644 drivers/media/platform/mtk-isp/fd/Makefile
> > > create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd.h
> > > create mode 100644 drivers/media/platform/mtk-isp/fd/mtk_fd_40.c
> > >
> >
> > Thanks for the patch! I finally got a chance to fully review the code. Sorry
> > for the delay. Please check my comments inline.
> >
> I appreciate your comments.
> I've fixed most of the comments and verifying them,
> Sorry for the delay, here is the reply.
>
Thanks for replying to all the comments, it's very helpful. I'll snip
the parts that I don't have any further comments.
[snip]
> > > + if (usercount == 1) {
> > > + pm_runtime_get_sync(&fd_dev->pdev->dev);
> > > + if (mtk_fd_hw_enable(fd_hw)) {
> > > + pm_runtime_put_sync(&fd_dev->pdev->dev);
> > > + atomic_dec_return(&fd_hw->fd_user_cnt);
> > > + mutex_unlock(&fd_hw->fd_hw_lock);
> > > + return -EINVAL;
> > > + }
> > > + }
> >
> > This is a simple mem-to-mem device, so there is no reason to keep it active
> > all the time it's streaming. Please just get the runtime PM counter when
> > queuing a job to the hardware and release it when the job finishes.
> >
> > I guess we might still want to do the costly operations like rproc_boot()
> > when we start streaming, though.
> >
> Do you mean by moving the pm_runtime_get/put stuff to the job execution
> and job finish place?
Yes.
> the rproc_boot() operation will be done here.
>
How much time does the rproc_boot() operation take?
[snip]
> > > +
> > > + pm_runtime_put_sync(&fd_dev->pdev->dev);
> >
> > Any reason to use pm_runtime_put_sync() over pm_runtime_put()?
> >
> No special reason to do so, the pm_runtime_put_sync here will be moved
> to the place each job finished.
>
If there is no reason, then the _sync() variant shouldn't be used, as
it could affect the performance negatively.
[snip]
> > > +static int mtk_fd_hw_job_exec(struct mtk_fd_hw *fd_hw,
> > > + struct fd_hw_param *fd_param,
> > > + void *output_vaddr)
> > > +{
> > > + struct fd_user_output *fd_output;
> > > + struct ipi_message fd_ipi_msg;
> > > + int ret;
> > > + u32 num;
> > > +
> > > + if (fd_param->user_param.src_img_fmt == FMT_UNKNOWN)
> > > + goto param_err;
> >
> > Is this possible?
> >
> Only if user set wrong format, I will remove this.
>
It shouldn't be possible to set a wrong format, because TRY_/S_FMT
should adjust what the user set to something that is valid.
> > > +
> > > + mutex_lock(&fd_hw->fd_hw_lock);
> > > + fd_hw->state = FD_ENQ;
> >
> > What is this state for?
> >
> It was for checking status, if a job is processing, the state is
> FD_ENQ,
> then we should wait for the last job to be done when pm_suspend().
>
If so, would it be possible to make it a bool and call is_processing?
[snip]
> > > +static int mtk_fd_vb2_queue_setup(struct vb2_queue *vq,
> > > + unsigned int *num_buffers,
> > > + unsigned int *num_planes,
> > > + unsigned int sizes[],
> > > + struct device *alloc_devs[])
> > > +{
> > > + struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > + struct device *dev = ctx->dev;
> > > + unsigned int size;
> > > +
> > > + switch (vq->type) {
> > > + case V4L2_BUF_TYPE_META_CAPTURE:
> > > + size = ctx->dst_fmt.buffersize;
> > > + break;
> > > + case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> > > + size = ctx->src_fmt.plane_fmt[0].sizeimage;
> > > + break;
> > > + default:
> > > + dev_err(dev, "invalid queue type: %d\n", vq->type);
> >
> > We should need to handle this.
> >
> Do you mean by giving a size instead of return -EINVAL?
>
Sorry, typo. I meant we shouldn't need to handle it, because we can't
get any other queue type here.
[snip]
> > > +static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
> > > +{
> > > + struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > + struct vb2_buffer *vb;
> >
> > How do we guarantee here that the hardware isn't still accessing the buffers
> > removed below?
> >
> Maybe we can check the driver state flag and aborting the unfinished
> jobs?
> (fd_hw->state == FD_ENQ)
>
Yes, we need to either cancel or wait for the currently processing
job. It depends on hardware capabilities, but cancelling is generally
preferred for the lower latency.
> > > +
> > > + if (V4L2_TYPE_IS_OUTPUT(vq->type))
> > > + vb = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> > > + else
> > > + vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > > +
> > > + while (vb) {
> > > + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(vb), VB2_BUF_STATE_ERROR);
> > > + if (V4L2_TYPE_IS_OUTPUT(vq->type))
> > > + vb = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> > > + else
> > > + vb = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > > + }
> >
> > We can use v4l2_m2m_buf_remove(). Also we can move the call into the loop
> > condition:
> >
> > while ((vb == v4l2_m2m_buf_remove(...)))
> > v4l2_m2m_buf_done(...);
> >
> Ok, I will refine as following:
>
> while ((vb = v4l2_m2m_buf_remove(V4L2_TYPE_IS_OUTPUT(vq->type)?
> &m2m_ctx->out_q_ctx :
> &m2m_ctx->cap_q_ctx)))
> v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
Please move the queue type check before the loop and save the queue
context in a local variable.
[snip]
> > > +}
> > > +
> > > +static void mtk_fd_vb2_request_complete(struct vb2_buffer *vb)
> > > +{
> > > + struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> > > +
> > > + v4l2_ctrl_request_complete(vb->req_obj.req, &ctx->hdl);
> > > +}
> > > +
> > > +static void mtk_fd_fill_pixfmt_mp(struct v4l2_pix_format_mplane *dfmt,
> > > + const struct v4l2_pix_format_mplane *sfmt)
> > > +{
> > > + dfmt->width = sfmt->width;
> > > + dfmt->height = sfmt->height;
> > > + dfmt->pixelformat = sfmt->pixelformat;
> > > + dfmt->field = sfmt->field;
> > > + dfmt->colorspace = sfmt->colorspace;
> > > + dfmt->num_planes = sfmt->num_planes;
> > > +
> > > + /* Use default */
> > > + dfmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> > > + dfmt->quantization = V4L2_QUANTIZATION_DEFAULT;
> > > + dfmt->xfer_func =
> > > + V4L2_MAP_XFER_FUNC_DEFAULT(dfmt->colorspace);
> > > + dfmt->plane_fmt[0].bytesperline = dfmt->width * 2;
> > > + dfmt->plane_fmt[0].sizeimage =
> > > + dfmt->height * dfmt->plane_fmt[0].bytesperline;
> > > + memset(dfmt->reserved, 0, sizeof(dfmt->reserved));
> > > +}
> >
> > Could we unify this function with mtk_fd_m2m_try_fmt_out_mp()? That function
> > should be almost directly reusable for the default format initialization +/-
> > the arguments passed to it.
> >
> Ok, I will try to reuse it as following:
>
> static void mtk_fd_fill_pixfmt_mp(struct v4l2_pix_format_mplane *dfmt,
> const struct v4l2_pix_format_mplane *sfmt)
> {
> dfmt->field = V4L2_FIELD_NONE;
> dfmt->colorspace = V4L2_COLORSPACE_BT2020;
> dfmt->num_planes = sfmt->num_planes;
> dfmt->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> dfmt->quantization = V4L2_QUANTIZATION_DEFAULT;
> dfmt->xfer_func =
> V4L2_MAP_XFER_FUNC_DEFAULT(dfmt->colorspace);
>
> /* Keep user setting as possible */
> dfmt->width = clamp(dfmt->width,
> MTK_FD_OUTPUT_MIN_WIDTH,
> MTK_FD_OUTPUT_MAX_WIDTH);
> dfmt->height = clamp(dfmt->height,
> MTK_FD_OUTPUT_MIN_HEIGHT,
> MTK_FD_OUTPUT_MAX_HEIGHT);
>
> if (sfmt->num_planes == 2) {
> /* NV16M and NV61M has 1 byte per pixel */
> dfmt->plane_fmt[0].bytesperline = dfmt->width;
> dfmt->plane_fmt[1].bytesperline = dfmt->width;
> } else {
> /* 2 bytes per pixel */
> dfmt->plane_fmt[0].bytesperline = dfmt->width * 2;
> }
>
> dfmt->plane_fmt[0].sizeimage =
> dfmt->height * dfmt->plane_fmt[0].bytesperline;
> }
How would the implementation of TRY_FMT look in this case?
[snip]
> > > +static int mtk_fd_m2m_enum_fmt_out_mp(struct file *file, void *fh,
> > > + struct v4l2_fmtdesc *f)
> > > +{
> > > + int i;
> > > +
> > > + for (i = 0; i < NUM_FORMATS; ++i) {
> > > + if (i == f->index) {
> > > + f->pixelformat = in_img_fmts[i].pixelformat;
> > > + return 0;
> > > + }
> > > + }
> >
> > Why don't we just check if f->index is within the [0, ARRAY_SIZE()-1] bounds
> > and then just use it to index the array directly?
> >
> I will refine as :
>
> static int mtk_fd_m2m_enum_fmt_out_mp(struct file *file, void *fh,
> struct v4l2_fmtdesc *f)
> {
> if ((f->index >= 0) && (f->index < NUM_FORMATS)) {
f->index is unsigned
> f->pixelformat = in_img_fmts[f->index].pixelformat;
> return 0;
> }
>
> return -EINVAL;
> }
nit: The usual convention is to check for invalid values and return early, i.e.
if (f->index >= NUM_FORMATS)
return -EINVAL;
f->pixelformat = in_img_fmts[f->index].pixelformat;
return 0;
> > > +
> > > + return -EINVAL;
> > > +}
> > > +
> > > +static int mtk_fd_m2m_try_fmt_out_mp(struct file *file,
> > > + void *fh,
> > > + struct v4l2_format *f)
> >
> > I think we could just shorten the function prefixes to "mtk_fd_".
> >
> Do you mean by replace mtk_fd_m2m_* with mtk_fd_ ?
>
Yes.
[snip]
> > > +static int mtk_fd_request_validate(struct media_request *req)
> > > +{
> > > + unsigned int count;
> > > +
> > > + count = vb2_request_buffer_cnt(req);
> > > + if (!count)
> > > + return -ENOENT;
> >
> > Why -ENOENT?
> >
> Reference the return code in vb2_request_validate()
You're right, -ENOENT seems to be the right error code here.
> I consider refining as following:
> static int mtk_fd_request_validate(struct media_request *req)
> {
> if (vb2_request_buffer_cnt(req) > 1)
> return -EINVAL;
>
> return vb2_request_validate(req);
> }
> or maybe I don't need to worry the request count greater than 1,
> just remove this function and set vb2_request_validate as .req_validate
> directly?
>
Given that we only have 1 queue handling requests, we should be able
to just use vb2_request_validate() indeed.
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 v4 00/13] Support CPU frequency scaling on QCS404
From: Jorge Ramirez @ 2019-08-26 6:54 UTC (permalink / raw)
To: bjorn.andersson, sboyd, david.brown, jassisinghbrar, mark.rutland,
mturquette, robh+dt, will.deacon, arnd, horms+renesas, heiko,
sibis, enric.balletbo, jagan, olof
Cc: devicetree, linux-arm-msm, khasim.mohammed, linux-kernel,
amit.kucheria, linux-clk, vkoul, niklas.cassel, georgi.djakov,
linux-arm-kernel
In-Reply-To: <20190731202929.16443-1-jorge.ramirez-ortiz@linaro.org>
On 7/31/19 22:29, Jorge Ramirez-Ortiz wrote:
> The following patchset enables CPU frequency scaling support on the
> QCS404 (with dynamic voltage scaling).
>
> It is important to notice that this functionality will be superseded
> by Core Power Reduction (CPR), a more accurate form of AVS found on
> certain Qualcomm SoCs.
>
> Some of the changes required to support CPR do conflict with the
> configuration required for CPUFreq.
>
> In particular, the following commit for CPR - already merged - will
> need to be reverted in order to enable CPUFreq.
>
> Author: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
> Date: Thu Jul 25 12:41:36 2019 +0200
> cpufreq: Add qcs404 to cpufreq-dt-platdev blacklist
>
> Patch 8 "clk: qcom: hfpll: CLK_IGNORE_UNUSED" is a bit controversial;
> in this platform, this PLL provides the clock signal to a CPU
> core. But in others it might not.
>
> We opted for the minimal ammount of changes without affecting the
> default functionality: simply bypassing the COMMON_CLK_DISABLE_UNUSED
> framework and letting the firwmare chose whether to enable or disable
> the clock at boot. However maybe a DT property and marking the clock
> as critical would be more appropriate for this PLL. we'd appreciate the
> maintainer's input on this topic.
>
> v2:
> - dts: ms8916: apcs mux/divider: new bindings
> (the driver can still support the old bindings)
>
> - qcs404.dtsi
> fix apcs-hfpll definition
> fix cpu_opp_table definition
>
> - GPLL0_AO_OUT operating frequency
> define new alpha_pll_fixed_ops to limit the operating frequency
>
> v3:
> - qcom-apcs-ipc-mailbox
> replace goto to ease readability
>
> - apcs-msm8916.c
> rework patch to use of_clk_parent_fill
>
> - hfpll.c
> add relevant comments to the code
>
> - qcs404.dtsi
> add voltage scaling support
>
> v4:
> - squash OPP definition and DVFS enablement in dts
> (patches 10 and 13 in previous version)
>
> - qcom-apcs-ipc-mailbox
> replace return condition for readability
>
> - answer one question on CLK_IGNORE_UNUSED in mailing list
>
> Jorge Ramirez-Ortiz, Niklas Cassel (13):
> clk: qcom: gcc: limit GPLL0_AO_OUT operating frequency
> mbox: qcom: add APCS child device for QCS404
> mbox: qcom: replace integer with valid macro
> dt-bindings: mailbox: qcom: Add clock-name optional property
> clk: qcom: apcs-msm8916: get parent clock names from DT
> clk: qcom: hfpll: get parent clock names from DT
> clk: qcom: hfpll: register as clock provider
> clk: qcom: hfpll: CLK_IGNORE_UNUSED
> arm64: dts: qcom: msm8916: Add the clocks for the APCS mux/divider
> arm64: dts: qcom: qcs404: Add HFPLL node
> arm64: dts: qcom: qcs404: Add the clocks for APCS mux/divider
> arm64: dts: qcom: qcs404: Add DVFS support
> arm64: defconfig: Enable HFPLL
>
> .../mailbox/qcom,apcs-kpss-global.txt | 24 +++++++++--
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 +-
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 43 +++++++++++++++++++
> arch/arm64/configs/defconfig | 1 +
> drivers/clk/qcom/apcs-msm8916.c | 23 ++++++++--
> drivers/clk/qcom/clk-alpha-pll.c | 8 ++++
> drivers/clk/qcom/clk-alpha-pll.h | 1 +
> drivers/clk/qcom/gcc-qcs404.c | 2 +-
> drivers/clk/qcom/hfpll.c | 25 ++++++++++-
> drivers/mailbox/qcom-apcs-ipc-mailbox.c | 11 +++--
> 10 files changed, 128 insertions(+), 13 deletions(-)
>
any feedback on this set?
TIA
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
From: Tomasz Figa @ 2019-08-26 6:54 UTC (permalink / raw)
To: Sakari Ailus
Cc: Mark Rutland, devicetree, Nicolas Boichat, srv_heupstream,
shengnan.wang, Louis Kuo, Sj Huang, Rob Herring,
moderated list:ARM/Mediatek SoC support, dongchun.zhu,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <20190821110542.GD31967@paasikivi.fi.intel.com>
On Wed, Aug 21, 2019 at 8:05 PM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Tomasz,
>
> On Wed, Aug 21, 2019 at 07:30:38PM +0900, Tomasz Figa wrote:
[snip]
> > Is it really correct to enable the clock before the regulators?
> >
> > According to the datasheet, it should be:
> > - PD pin HIGH,
> > - nRST pin LOW,
> > - DVDDIO and AVDD28 power up and stabilize,
> > - clock enabled,
> > - min 5 ms delay,
> > - PD pin LOW,
> > - min 4 ms delay,
> > - nRST pin HIGH,
> > - min 5 ms delay,
> > - I2C interface ready.
> >
> > > +
> > > + /* Note: set 0 is high, set 1 is low */
> >
> > Why is that? If there is some inverter on the way that should be handled
> > outside of this driver. (GPIO DT bindings have flags for this purpose.
> >
> > If the pins are nRESET and nPOWERDOWN in the hardware datasheet, we should
> > call them like this in the driver too (+/- the lowercase and underscore
> > convention).
> >
> > According to the datasheet, the reset pin is called RST and inverted, so we should
> > call it n_rst, but the powerdown signal, called PD, is not inverted, so pd
> > would be the right name.
>
> For what it's worth sensors generally have xshutdown (or reset) pin that is
> active high. Looking at the code, it is not the case here. It's a bit odd
> since the usual arrangement saves power when the camera is not in use; it's
> not a lot but still. Oh well.
>
I guess we could drive powerdown low after disabling the regulators
and clocks, but that wouldn't work for the cases where the regulators
are actually shared with something else, especially if that is not
related to the same camera module.
> ...
>
> > > +static struct i2c_driver ov02a10_i2c_driver = {
> > > + .driver = {
> > > + .name = "ov02a10",
> > > + .pm = &ov02a10_pm_ops,
> > > + .of_match_table = ov02a10_of_match,
> >
> > Please use of_match_ptr() wrapper.
>
> Not really needed; the driver does expect regulators, GPIOs etc., but by
> leaving out of_match_ptr(), the driver will also probe on ACPI based
> systems.
Good point, I always keep forgetting about the ability to probe OF
drivers from ACPI. Then we also need to remove the #if
IS_ENABLED(CONFIG_OF) from ov02a10_of_match.
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 v2 09/11] dma-direct: turn ARCH_ZONE_DMA_BITS into a variable
From: Christoph Hellwig @ 2019-08-26 7:05 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: catalin.marinas, Heiko Carstens, eric, Paul Mackerras,
linux-riscv, will, hch, Marek Szyprowski, linux-arch, linux-s390,
f.fainelli, frowand.list, Christian Borntraeger,
Benjamin Herrenschmidt, devicetree, Vasily Gorbik, marc.zyngier,
robh+dt, linux-rpi-kernel, linux-arm-kernel, phill, mbrugger,
linux-mm, linuxppc-dev, linux-kernel, iommu, wahrenst,
Michael Ellerman, akpm, Robin Murphy
In-Reply-To: <20190820145821.27214-10-nsaenzjulienne@suse.de>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 10/11] arm64: edit zone_dma_bits to fine tune dma-direct min mask
From: Christoph Hellwig @ 2019-08-26 7:06 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: catalin.marinas, eric, linux-riscv, will, hch, m.szyprowski,
linux-arch, f.fainelli, frowand.list, devicetree, marc.zyngier,
robh+dt, linux-rpi-kernel, linux-arm-kernel, phill, mbrugger,
linux-mm, linux-kernel, iommu, wahrenst, akpm, Robin Murphy
In-Reply-To: <20190820145821.27214-11-nsaenzjulienne@suse.de>
On Tue, Aug 20, 2019 at 04:58:18PM +0200, Nicolas Saenz Julienne wrote:
> - if (IS_ENABLED(CONFIG_ZONE_DMA))
> + if (IS_ENABLED(CONFIG_ZONE_DMA)) {
> arm64_dma_phys_limit = max_zone_dma_phys();
> + zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) & GENMASK_ULL(31, 0)) + 1;
This adds a way too long line. I also find the use of GENMASK_ULL
horribly obsfucating, but I know that opinion is't shared by everyone.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 11/11] mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type'
From: Christoph Hellwig @ 2019-08-26 7:07 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: catalin.marinas, Palmer Dabbelt, eric, linux-riscv, will, hch,
m.szyprowski, linux-arch, f.fainelli, frowand.list, devicetree,
Albert Ou, marc.zyngier, robh+dt, linux-rpi-kernel, Paul Walmsley,
linux-arm-kernel, phill, mbrugger, linux-mm, linux-kernel, iommu,
wahrenst, akpm, Robin Murphy
In-Reply-To: <20190820145821.27214-12-nsaenzjulienne@suse.de>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
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