* [PATCH v2 1/5] dt-bindings: clk: meson: add sm1 periph clock controller bindings
From: Neil Armstrong @ 2019-08-26 7:25 UTC (permalink / raw)
To: khilman, jbrunet, devicetree
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190826072539.27725-1-narmstrong@baylibre.com>
Update the documentation to support clock driver for the Amlogic SM1 SoC
and expose the GP1, DSU and the CPU 1, 2 & 3 clocks.
SM1 clock tree is very close, the main differences are :
- each CPU core can achieve a different frequency, albeit a common PLL
- a similar tree as the clock tree has been added for the DynamIQ Shared Unit
- has a new GP1 PLL used for the DynamIQ Shared Unit
- SM1 has additional clocks like for CSI, NanoQ an other components
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
.../devicetree/bindings/clock/amlogic,gxbb-clkc.txt | 1 +
include/dt-bindings/clock/g12a-clkc.h | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
index 6eaa52092313..7ccecd5c02c1 100644
--- a/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
+++ b/Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
@@ -11,6 +11,7 @@ Required Properties:
"amlogic,axg-clkc" for AXG SoC.
"amlogic,g12a-clkc" for G12A SoC.
"amlogic,g12b-clkc" for G12B SoC.
+ "amlogic,sm1-clkc" for SM1 SoC.
- clocks : list of clock phandle, one for each entry clock-names.
- clock-names : should contain the following:
* "xtal": the platform xtal
diff --git a/include/dt-bindings/clock/g12a-clkc.h b/include/dt-bindings/clock/g12a-clkc.h
index 8ccc29ac7a72..0837c1a7ae49 100644
--- a/include/dt-bindings/clock/g12a-clkc.h
+++ b/include/dt-bindings/clock/g12a-clkc.h
@@ -138,5 +138,10 @@
#define CLKID_VDEC_HEVCF 210
#define CLKID_TS 212
#define CLKID_CPUB_CLK 224
+#define CLKID_GP1_PLL 243
+#define CLKID_DSU_CLK 252
+#define CLKID_CPU1_CLK 253
+#define CLKID_CPU2_CLK 254
+#define CLKID_CPU3_CLK 255
#endif /* __G12A_CLKC_H */
--
2.22.0
_______________________________________________
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 v2 0/5] 0/6] arm64: meson-sm1: add support for DVFS
From: Neil Armstrong @ 2019-08-26 7:25 UTC (permalink / raw)
To: khilman, jbrunet
Cc: linux-amlogic, linux-kernel, linux-clk, linux-arm-kernel,
Neil Armstrong
Following DVFS support for the Amlogic G12A and G12B SoCs, this serie
enables DVFS on the SM1 SoC for the SEI610 board.
The SM1 Clock structure is slightly different because of the Cortex-A55
core used, having the capability for each core of a same cluster to run
at a different frequency thanks to the newly used DynamIQ Shared Unit.
This is why SM1 has a CPU clock tree for each core and for DynamIQ Shared Unit,
with a bypass mux to use the CPU0 instead of the dedicated trees.
The DSU uses a new GP1 PLL as default clock, thus GP1 is added as read-only.
The SM1 OPPs has been taken from the Amlogic Vendor tree, and unlike
G12A only a single version of the SoC is available.
Dependencies:
- patch 6 is based on the "arm64: meson: add support for SM1 Power Domains" serie,
but is not a strong dependency, it will work without
Changes since v1:
- exposed GP1, DSU and CPU 1,2,3 clock in patch 1
Neil Armstrong (5):
dt-bindings: clk: meson: add sm1 periph clock controller bindings
clk: meson: g12a: add support for SM1 GP1 PLL
clk: meson: g12a: add support for SM1 DynamIQ Shared Unit clock
clk: meson: g12a: add support for SM1 CPU 1, 2 & 3 clocks
arm64: dts: meson-sm1-sei610: enable DVFS
.../bindings/clock/amlogic,gxbb-clkc.txt | 1 +
.../boot/dts/amlogic/meson-sm1-sei610.dts | 59 +-
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 69 +++
drivers/clk/meson/g12a.c | 544 ++++++++++++++++++
drivers/clk/meson/g12a.h | 24 +-
include/dt-bindings/clock/g12a-clkc.h | 5 +
6 files changed, 697 insertions(+), 5 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-26 7:12 UTC (permalink / raw)
To: Mark Rutland
Cc: will@kernel.org, robin.murphy@arm.com,
linux-arm-kernel@lists.infradead.org, Frank Li, dl-linux-imx
In-Reply-To: <20190823125719.GD55480@lakrids.cambridge.arm.com>
> -----Original Message-----
> From: Mark Rutland <mark.rutland@arm.com>
> Sent: 2019年8月23日 20:57
> To: Joakim Zhang <qiangqing.zhang@nxp.com>
> Cc: robin.murphy@arm.com; will@kernel.org; Frank Li <frank.li@nxp.com>;
> linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
>
> On Thu, Aug 08, 2019 at 06:45:29AM +0000, Joakim Zhang wrote:
> > AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> > writes with an ARID or AXID matching filter setting. Granularity is at
> > subsystem level. Implementation does not allow filtring between
> > masters within a subsystem. Filter is defined with 2 configuration registers.
> >
> > --AXI_ID defines AxID matching value
> > --AXI_MASKING defines which bits of AxID are meaningful for the
> > matching
> >
> > When non-masked bits are matching corresponding AXI_ID bits then
> > counter is incremented. This filter allows counting read or write
> > access from a subsystem or multiple subsystems.
> >
> > Perf counter is incremented if AxID && AXI_MASKING == AXI_ID &&
> > AXI_MASKING
>
> Just to check, the filter does not affect other events, right?
[Joakim] Yes, this filter is only for events 0x41 and 0x42.
> >
> > AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance
> counter.
> >
> > Read and write AXI ID filter should write same value to DPCR1 if want
> > to specify at the same time as this filter is shared between counters.
> >
> > e.g.
> > perf stat -a -e
> >
> imx8_ddr0/axi-id-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axi-id-write,axi_id
> > =0xMMMMDDDD/ cmd
> > MMMM: AXI_MASKING
> > DDDD: AXI_ID
>
> You might want to expose this to userspace as two fields:
>
> axi_id=DDDD
> axi_mask=MMMM
>
> ... where axi_mask is inverted (i.e. set bits are bits to ignore), so that the user
> can just specify axi_id to monitor a specific id, rather than having to specifiy
> axi_id=0xffff<id>.
[Joakim] No, axi_mask is not inverted, should specify axi_id = 0xffff<id> for the particular AXI ID. I will improve the commit message.
0: corresponding bit is masked
1: corresponding bit is not masked, i.e. used to do the matching
> >
> > ChangeLog:
> > V1 -> V2:
> > * add error log if user specifies read/write AXI ID filter at
> > the same time.
> > * of_device_get_match_data() instead of of_match_device(), and
> > remove the check of return value.
> > V2 -> V3:
> > * move the AXI ID check to event_add().
> > * add support for same value of axi_id.
> > V3 -> V4:
> > * move the AXI ID check to event_init().
> > V4 -> V5:
> > * reject event group if AXI ID not consistent in event_init().
> >
> > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > ---
> > drivers/perf/fsl_imx8_ddr_perf.c | 63
> > +++++++++++++++++++++++++++++++-
> > 1 file changed, 61 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/perf/fsl_imx8_ddr_perf.c
> > b/drivers/perf/fsl_imx8_ddr_perf.c
> > index 63fe21600072..f25cf5cbe156 100644
> > --- a/drivers/perf/fsl_imx8_ddr_perf.c
> > +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> > @@ -42,9 +42,22 @@
> >
> > static DEFINE_IDA(ddr_ida);
> >
> > +/* DDR Perf hardware feature */
> > +#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter */
> > +
> > +struct fsl_ddr_devtype_data {
> > + unsigned int quirks; /* quirks needed for different DDR Perf core */
> > +};
> > +
> > +static const struct fsl_ddr_devtype_data imx8_devtype_data;
> > +
> > +static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
> > + .quirks = DDR_CAP_AXI_ID_FILTER,
> > +};
> > +
> > static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> > - { .compatible = "fsl,imx8-ddr-pmu",},
> > - { .compatible = "fsl,imx8m-ddr-pmu",},
> > + { .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
> > + { .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
> > { /* sentinel */ }
> > };
>
> Are new DDR PMUs going to lack this feature?
>
> If all PMUs the driver supports have it, then we don't need this quirk/feature
> list.
>
> That would make the subsequent code a bit nicer, as all the filtering code would
> lose a level of indentation.
[Joakim] This feature may drop, some coming SOCs will improve this AXI ID filtering, let it can filter from different ID separately, and ang other extensions.
> >
> > @@ -57,6 +70,7 @@ struct ddr_pmu {
> > struct perf_event *events[NUM_COUNTERS];
> > int active_events;
> > enum cpuhp_state cpuhp_state;
> > + const struct fsl_ddr_devtype_data *devtype_data;
> > int irq;
> > int id;
> > };
> > @@ -128,6 +142,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
> > IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
> > IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
> > IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
> > + IMX8_DDR_PMU_EVENT_ATTR(axi-id-read, 0x41),
> > + IMX8_DDR_PMU_EVENT_ATTR(axi-id-write, 0x42),
> > NULL,
> > };
> >
> > @@ -137,9 +153,11 @@ static struct attribute_group
> > ddr_perf_events_attr_group = { };
> >
> > PMU_FORMAT_ATTR(event, "config:0-7");
> > +PMU_FORMAT_ATTR(axi_id, "config1:0-31");
> >
> > static struct attribute *ddr_perf_format_attrs[] = {
> > &format_attr_event.attr,
> > + &format_attr_axi_id.attr,
> > NULL,
> > };
> >
> > @@ -189,6 +207,16 @@ static u32 ddr_perf_read_counter(struct ddr_pmu
> *pmu, int counter)
> > return readl_relaxed(pmu->base + COUNTER_READ + counter * 4); }
> >
> > +static bool ddr_perf_is_filtered(struct perf_event *event) {
> > + return event->attr.config == 0x41 || event->attr.config == 0x42; }
> > +
> > +static u32 ddr_perf_filter_val(struct perf_event *event) {
> > + return event->attr.config1;
> > +}
> > +
>
> Let's add another helper:
>
> static bool ddr_perf_filters_compatible(struct perf_event *a,
> struct perf_event *b)
> {
> if (!ddr_perf_is_filtered(a))
> return true;
> if (!ddr_perf_is_filtered(b))
> return true;
> return ddr_perf_filter_val(a) == ddr_perf_filter_val(b); }
>
> > static int ddr_perf_event_init(struct perf_event *event) {
> > struct ddr_pmu *pmu = to_ddr_pmu(event->pmu); @@ -215,6 +243,18
> @@
> > static int ddr_perf_event_init(struct perf_event *event)
> > !is_software_event(event->group_leader))
> > return -EINVAL;
> >
> > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > + bool is_filtered = ddr_perf_is_filtered(event);
> > + u32 filter_val = ddr_perf_filter_val(event);
> > +
> > + for_each_sibling_event(sibling, event->group_leader) {
> > + if (is_filtered && ddr_perf_is_filtered(sibling) &&
> > + ddr_perf_filter_val(sibling) != filter_val) {
> > + return -EINVAL;
> > + }
> > + }
> > + }
>
> ... so this can be:
>
> if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> if (!ddr_perf_filters_compatible(event, event->group_leader))
> return -EINVAL;
> for_each_sibling_event(sibling, event->group_leader) {
> if (!ddr_perf_filters_compatible(event, sibling))
> return -EINVAL;
> }
> }
[Joakim] Got it.
> Note: that checks group_leader, which you mised above. When the event is the
> group leader, it's trivially compatible with itself, so we don't need a special case
> there.
>
> > +
> > for_each_sibling_event(sibling, event->group_leader) {
> > if (sibling->pmu != event->pmu &&
> > !is_software_event(sibling))
> > @@ -288,6 +328,23 @@ static int ddr_perf_event_add(struct perf_event
> *event, int flags)
> > int counter;
> > int cfg = event->attr.config;
> >
> > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > + int i;
> > + bool is_filtered = ddr_perf_is_filtered(event);
> > + u32 filter_val = ddr_perf_filter_val(event);
> > +
> > + for (i = 1; i < NUM_COUNTERS; i++) {
> > + if (is_filtered && pmu->events[i] &&
> > + ddr_perf_is_filtered(pmu->events[i]) &&
> > + ddr_perf_filter_val(pmu->events[i]) != filter_val) {
> > + dev_dbg(pmu->dev, "Contradictory axi id filter value\n");
> > + return -EINVAL;
> > + }
> > + }
>
> ... and likewise:
>
> if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> int i;
>
> for (i = 1; i < NUM_COUNTERS; i++) {
> if (!ddr_perf_filters_compatible(event, pmu->events[i]))
> return -EINVAL;
> }
> }
>
> Please drop the dev_dbg() here, since when perf rotates events this can
> happen many times per second, and it's entirely legitimate.
[Joakim] Got it.
> Otherwise, this looks good to me.
[Joakim] Thanks Mark, I will sent out a V6, please help review.
Best Regards,
Joakim Zhang
> Thanks,
> Mark.
>
> > +
> > + writel(filter_val, pmu->base + COUNTER_DPCR1);
> > + }
> > +
> > counter = ddr_perf_alloc_counter(pmu, cfg);
> > if (counter < 0) {
> > dev_dbg(pmu->dev, "There are not enough counters\n"); @@ -472,6
> > +529,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
> > if (!name)
> > return -ENOMEM;
> >
> > + pmu->devtype_data = of_device_get_match_data(&pdev->dev);
> > +
> > pmu->cpu = raw_smp_processor_id();
> > ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
> > DDR_CPUHP_CB_NAME,
> > --
> > 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
* Re: [PATCH v2 -next] net: mediatek: remove set but not used variable 'status'
From: René van Dorst @ 2019-08-26 7:10 UTC (permalink / raw)
To: Mao Wenan, sr
Cc: nbd, nelson.chang, netdev, sean.wang, kernel-janitors,
linux-kernel, linux-mediatek, john, matthias.bgg, davem,
linux-arm-kernel
In-Reply-To: <20190826013118.22720-1-maowenan@huawei.com>
Let's add Stefan to the conversation.
He is the author of this commit.
Quoting Mao Wenan <maowenan@huawei.com>:
> 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);
Hi Stefan,
You added an extra MTK_PDMA_INT_STATUS read in mtk_handle_irq()
Is that read necessary to work properly?
Greats,
René
> 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
* Re: [PATCH v2 01/11] asm-generic: add dma_zone_size
From: Christoph Hellwig @ 2019-08-26 7:09 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: catalin.marinas, eric, linux-riscv, frowand.list, hch,
m.szyprowski, linux-arch, f.fainelli, will, devicetree,
Arnd Bergmann, 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-2-nsaenzjulienne@suse.de>
On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote:
> Some architectures have platform specific DMA addressing limitations.
> This will allow for hardware description code to provide the constraints
> in a generic manner, so as for arch code to properly setup it's memory
> zones and DMA mask.
I know this just spreads the arm code, but I still kinda hate it.
MAX_DMA_ADDRESS is such an oddly defined concepts. We have the mm
code that uses it to start allocating after the dma zones, but
I think that would better be done using a function returning
1 << max(zone_dma_bits, 32) or so. Then we have about a handful
of drivers using it that all seem rather bogus, and one of which
I think are usable on arm64.
_______________________________________________
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
* 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 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: [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 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: [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: [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: [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: [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 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 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 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: [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: [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
* [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: [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
* 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 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
* [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 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
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