* Re: [PATCH v3 01/10] KVM: arm64: Document PV-time interface
From: Steven Price @ 2019-08-28 11:23 UTC (permalink / raw)
To: Christoffer Dall
Cc: kvm, linux-doc, Marc Zyngier, linux-kernel, Russell King,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190827084407.GA6541@e113682-lin.lund.arm.com>
On 27/08/2019 09:44, Christoffer Dall wrote:
> On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
>> Introduce a paravirtualization interface for KVM/arm64 based on the
>> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>>
>> This only adds the details about "Stolen Time" as the details of "Live
>> Physical Time" have not been fully agreed.
>>
>> User space can specify a reserved area of memory for the guest and
>> inform KVM to populate the memory with information on time that the host
>> kernel has stolen from the guest.
>>
>> A hypercall interface is provided for the guest to interrogate the
>> hypervisor's support for this interface and the location of the shared
>> memory structures.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
>> 1 file changed, 100 insertions(+)
>> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
>>
>> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
>> new file mode 100644
>> index 000000000000..1ceb118694e7
>> --- /dev/null
>> +++ b/Documentation/virt/kvm/arm/pvtime.txt
>> @@ -0,0 +1,100 @@
>> +Paravirtualized time support for arm64
>> +======================================
>> +
>> +Arm specification DEN0057/A defined a standard for paravirtualised time
>> +support for AArch64 guests:
>> +
>> +https://developer.arm.com/docs/den0057/a
>> +
>> +KVM/arm64 implements the stolen time part of this specification by providing
>> +some hypervisor service calls to support a paravirtualized guest obtaining a
>> +view of the amount of time stolen from its execution.
>> +
>> +Two new SMCCC compatible hypercalls are defined:
>> +
>> +PV_FEATURES 0xC5000020
>> +PV_TIME_ST 0xC5000022
>> +
>> +These are only available in the SMC64/HVC64 calling convention as
>> +paravirtualized time is not available to 32 bit Arm guests. The existence of
>> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
>> +mechanism before calling it.
>> +
>> +PV_FEATURES
>> + Function ID: (uint32) : 0xC5000020
>> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
>> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
>> + PV-time feature is supported by the hypervisor.
>> +
>> +PV_TIME_ST
>> + Function ID: (uint32) : 0xC5000022
>> + Return value: (int64) : IPA of the stolen time data structure for this
>> + (V)CPU. On failure:
>> + NOT_SUPPORTED (-1)
>> +
>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
>> +with inner and outer write back caching attributes, in the inner shareable
>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
>> +meaningfully filled by the hypervisor (see structure below).
>> +
>> +PV_TIME_ST returns the structure for the calling VCPU.
>> +
>> +Stolen Time
>> +-----------
>> +
>> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
>> +
>> + Field | Byte Length | Byte Offset | Description
>> + ----------- | ----------- | ----------- | --------------------------
>> + Revision | 4 | 0 | Must be 0 for version 0.1
>> + Attributes | 4 | 4 | Must be 0
>> + Stolen time | 8 | 8 | Stolen time in unsigned
>> + | | | nanoseconds indicating how
>> + | | | much time this VCPU thread
>> + | | | was involuntarily not
>> + | | | running on a physical CPU.
>> +
>> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
>> +will be present within a reserved region of the normal memory given to the
>> +guest. The guest should not attempt to write into this memory. There is a
>> +structure per VCPU of the guest.
>> +
>> +User space interface
>> +====================
>> +
>> +User space can request that KVM provide the paravirtualized time interface to
>> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
>> +
>
> I feel it would be more consistent to have the details of this in
> Documentation/virt/kvm/devices/arm-pv-time.txt and refer to this
> document from here.
Fair point - I'll move this lower part of the document and add a reference.
Thanks,
Steve
>> + struct kvm_create_device pvtime_device = {
>> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
>> + .attr = 0,
>> + .flags = 0,
>> + };
>> +
>> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
>> +
>> +Creation of the device should be done after creating the vCPUs of the virtual
>> +machine.
>> +
>> +The IPA of the structures must be given to KVM. This is the base address
>> +of an array of stolen time structures (one for each VCPU). The base address
>> +must be page aligned. The size must be at least 64 * number of VCPUs and be a
>> +multiple of PAGE_SIZE.
>> +
>> +The memory for these structures should be added to the guest in the usual
>> +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
>> +
>> +For example:
>> +
>> + struct kvm_dev_arm_st_region region = {
>> + .gpa = <IPA of guest base address>,
>> + .size = <size in bytes>
>> + };
>> +
>> + struct kvm_device_attr st_base = {
>> + .group = KVM_DEV_ARM_PV_TIME_PADDR,
>> + .attr = KVM_DEV_ARM_PV_TIME_ST,
>> + .addr = (u64)®ion
>> + };
>> +
>> + ioctl(pvtime_fd, KVM_SET_DEVICE_ATTR, &st_base);
>> --
>> 2.20.1
>>
>
> Thanks,
>
> Christoffer
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V8 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-28 11:26 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland@arm.com, Frank Li, robin.murphy@arm.com,
dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828095135.gsyqwor7tea2radn@willie-the-truck>
> -----Original Message-----
> From: Will Deacon <will@kernel.org>
> Sent: 2019年8月28日 17:52
> To: Joakim Zhang <qiangqing.zhang@nxp.com>
> Cc: mark.rutland@arm.com; robin.murphy@arm.com; Frank Li
> <frank.li@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH V8 1/3] perf: imx8_ddr_perf: add AXI ID filter support
>
> On Wed, Aug 28, 2019 at 03:05:36AM +0000, Joakim Zhang wrote:
> > AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> > writes with an ARID or AWID matching filter setting. Granularity is at
> > subsystem level. Implementation does not allow filtring between
> > masters within a subsystem. Filter is defined with 2 configuration
> parameters.
> >
> > --AXI_ID defines AxID matching value
> > --AXI_MASKING defines which bits of AxID are meaningful for the matching
> > 0:corresponding bit is masked
> > 1: corresponding bit is not masked, i.e. used to do 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
> >
> > 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/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/
> cmd
> > perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/
> > cmd
> >
> > NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to
> > mask), and it will be reverted in driver automatically. so that the
> > user can just specify axi_id to monitor a specific id, rather than having to
> specify axi_mask.
> > e.g.
> > perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will
> > monitor ARID=0x12
> >
> > 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().
> > V5 -> V6:
> > * change the event name: axi-id-read->axid-read;
> > axi-id-write->axid-write
> > * add another helper: ddr_perf_filters_compatible()
> > * drop the dev_dbg()
> > V6 -> V7:
> > * revert AXI_MASKING at driver.
> > V7 -> V8:
> > * separate axi_id to axi_mask and axi_id these two fileds.
>
> Nit: please don't include the ChangeLog in the commit message (we don't want
> to include this in the linux history). Instead stick it after the cut.
[Joakim] Got it. Thanks.
> > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > ---
> > drivers/perf/fsl_imx8_ddr_perf.c | 72
> > +++++++++++++++++++++++++++++++-
> > 1 file changed, 70 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/perf/fsl_imx8_ddr_perf.c
> > b/drivers/perf/fsl_imx8_ddr_perf.c
> > index 0e3310dbb145..e9bf956f434d 100644
> > --- a/drivers/perf/fsl_imx8_ddr_perf.c
> > +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> > @@ -35,6 +35,8 @@
> > #define EVENT_CYCLES_COUNTER 0
> > #define NUM_COUNTERS 4
> >
> > +#define AXI_MASKING_REVERT 0xffff0000 /* AXI_MASKING(MSB
> 16bits) + AXI_ID(LSB 16bits) */
> > +
> > #define to_ddr_pmu(p) container_of(p, struct ddr_pmu, pmu)
> >
> > #define DDR_PERF_DEV_NAME "imx8_ddr"
> > @@ -42,9 +44,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 */ }
> > };
> > MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids); @@ -58,6 +73,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;
> > };
> > @@ -129,6 +145,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(axid-read, 0x41),
> > + IMX8_DDR_PMU_EVENT_ATTR(axid-write, 0x42),
> > NULL,
> > };
> >
> > @@ -138,9 +156,13 @@ static struct attribute_group
> > ddr_perf_events_attr_group = { };
> >
> > PMU_FORMAT_ATTR(event, "config:0-7");
> > +PMU_FORMAT_ATTR(axi_id, "config1:0-15");
> PMU_FORMAT_ATTR(axi_mask,
> > +"config1:16-31");
> >
> > static struct attribute *ddr_perf_format_attrs[] = {
> > &format_attr_event.attr,
> > + &format_attr_axi_id.attr,
> > + &format_attr_axi_mask.attr,
> > NULL,
> > };
> >
> > @@ -190,6 +212,26 @@ 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;
> > +}
> > +
> > +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); @@ -216,6 +258,15
> @@
> > 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) {
> > + 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;
> > + }
> > + }
> > +
> > for_each_sibling_event(sibling, event->group_leader) {
> > if (sibling->pmu != event->pmu &&
> > !is_software_event(sibling))
> > @@ -288,6 +339,21 @@ static int ddr_perf_event_add(struct perf_event
> *event, int flags)
> > struct hw_perf_event *hwc = &event->hw;
> > int counter;
> > int cfg = event->attr.config;
> > + int cfg1 = event->attr.config1;
> > +
> > + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > + int i;
> > +
> > + for (i = 1; i < NUM_COUNTERS; i++) {
> > + if (pmu->events[i] &&
> > + !ddr_perf_filters_compatible(event, pmu->events[i]))
> > + return -EINVAL;
> > + }
> > +
> > + /* revert axi id masking(axi_mask) value */
> > + cfg1 ^= AXI_MASKING_REVERT;
> > + writel(cfg1, pmu->base + COUNTER_DPCR1);
>
> I was about to queue this up, but then I wondered about the following
> situation:
>
> - I add a filtered event to a group (say 0x41) with a filter of 0
> (which the driver inverts to 0xffff)
>
> - I then add a non-filtered event (say 0x40) but config1 is set
> to 0xffff0000
>
> Won't the logic above result in us corrupting DPCR1 and clobbering the filter for
> the first event? What am I missing?
>
> I think you should only program DPCR1 for filtered events.
[Joakim] Yes, you are right! I will do below change.
if (ddr_perf_is_filtered(event)) {
/* revert axi id masking(axi_mask) value */
cfg1 ^= AXI_MASKING_REVERT;
writel(cfg1, pmu->base + COUNTER_DPCR1);
}
Best Regards,
Joakim Zhang
> Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support
From: Neil Armstrong @ 2019-08-28 11:28 UTC (permalink / raw)
To: Robin Murphy, Tomeu Vizoso
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux IOMMU, David Airlie, Will Deacon, open list, dri-devel,
Steven Price, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Clément Péron,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <dc3872a4-8cd9-462b-9f73-0d69a810d985@arm.com>
Hi Robyn,
On 31/05/2019 15:47, Robin Murphy wrote:
> On 31/05/2019 13:04, Tomeu Vizoso wrote:
>> On Wed, 29 May 2019 at 19:38, Robin Murphy <robin.murphy@arm.com> wrote:
>>>
>>> On 29/05/2019 16:09, Tomeu Vizoso wrote:
>>>> On Tue, 21 May 2019 at 18:11, Clément Péron <peron.clem@gmail.com> wrote:
>>>>>
>>>> [snip]
>>>>> [ 345.204813] panfrost 1800000.gpu: mmu irq status=1
>>>>> [ 345.209617] panfrost 1800000.gpu: Unhandled Page fault in AS0 at VA
>>>>> 0x0000000002400400
>>>>
>>>> From what I can see here, 0x0000000002400400 points to the first byte
>>>> of the first submitted job descriptor.
>>>>
>>>> So mapping buffers for the GPU doesn't seem to be working at all on
>>>> 64-bit T-760.
>>>>
>>>> Steven, Robin, do you have any idea of why this could be?
>>>
>>> I tried rolling back to the old panfrost/nondrm shim, and it works fine
>>> with kbase, and I also found that T-820 falls over in the exact same
>>> manner, so the fact that it seemed to be common to the smaller 33-bit
>>> designs rather than anything to do with the other
>>> job_descriptor_size/v4/v5 complication turned out to be telling.
>>
>> Is this complication something you can explain? I don't know what v4
>> and v5 are meant here.
>
> I was alluding to BASE_HW_FEATURE_V4, which I believe refers to the Midgard architecture version - the older versions implemented by T6xx and T720 seem to be collectively treated as "v4", while T760 and T8xx would effectively be "v5".
>
>>> [ as an aside, are 64-bit jobs actually known not to work on v4 GPUs, or
>>> is it just that nobody's yet observed a 64-bit blob driving one? ]
>>
>> I'm looking right now at getting Panfrost working on T720 with 64-bit
>> descriptors, with the ultimate goal of making Panfrost
>> 64-bit-descriptor only so we can have a single build of Mesa in
>> distros.
>
> Cool, I'll keep an eye out, and hope that it might be enough for T620 on Juno, too :)
>
>>> Long story short, it appears that 'Mali LPAE' is also lacking the start
>>> level notion of VMSA, and expects a full 4-level table even for <40 bits
>>> when level 0 effectively redundant. Thus walking the 3-level table that
>>> io-pgtable comes back with ends up going wildly wrong. The hack below
>>> seems to do the job for me; if Clément can confirm (on T-720 you'll
>>> still need the userspace hack to force 32-bit jobs as well) then I think
>>> I'll cook up a proper refactoring of the allocator to put things right.
>>
>> Mmaps seem to work with this patch, thanks.
>>
>> The main complication I'm facing right now seems to be that the SFBD
>> descriptor on T720 seems to be different from the one we already had
>> (tested on T6xx?).
>
> OK - with the 32-bit hack pointed to up-thread, a quick kmscube test gave me the impression that T720 works fine, but on closer inspection some parts of glmark2 do seem to go a bit wonky (although I suspect at least some of it is just down to the FPGA setup being both very slow and lacking in memory bandwidth), and the "nv12-1img" mode of kmscube turns out to render in some delightfully wrong colours.
>
> I'll try to get a 'proper' version of the io-pgtable patch posted soon.
I'm trying to collect all the fixes needed to make T820 work again, and
I was wondering if you finally have a proper patch for this and "cfg->ias > 48"
hack ? Or one I can test ?
Thanks,
Neil
>
> Thanks,
> Robin.
>
>>
>> Cheers,
>>
>> Tomeu
>>
>>> Robin.
>>>
>>>
>>> ----->8-----
>>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>>> index 546968d8a349..f29da6e8dc08 100644
>>> --- a/drivers/iommu/io-pgtable-arm.c
>>> +++ b/drivers/iommu/io-pgtable-arm.c
>>> @@ -1023,12 +1023,14 @@ arm_mali_lpae_alloc_pgtable(struct
>>> io_pgtable_cfg *cfg, void *cookie)
>>> iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
>>> if (iop) {
>>> u64 mair, ttbr;
>>> + struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(&iop->ops);
>>>
>>> + data->levels = 4;
>>> /* Copy values as union fields overlap */
>>> mair = cfg->arm_lpae_s1_cfg.mair[0];
>>> ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V8 2/3] Documentation: admin-guide: perf: add i.MX8 ddr pmu user doc
From: Joakim Zhang @ 2019-08-28 11:32 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland@arm.com, Frank Li, robin.murphy@arm.com,
dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828100440.melcuvu6hz5mrm3h@willie-the-truck>
> -----Original Message-----
> From: Will Deacon <will@kernel.org>
> Sent: 2019年8月28日 18:05
> To: Joakim Zhang <qiangqing.zhang@nxp.com>
> Cc: mark.rutland@arm.com; robin.murphy@arm.com; Frank Li
> <frank.li@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH V8 2/3] Documentation: admin-guide: perf: add i.MX8 ddr
> pmu user doc
>
> On Wed, Aug 28, 2019 at 03:05:39AM +0000, Joakim Zhang wrote:
> > Add i.MX8 ddr pmu user doc.
> >
> > ChangeLog:
> > V1 -> V4:
> > * new add in V4.
> > V4 -> V5:
> > * no change.
> > V5 -> V6:
> > * change the event name
> > V6 -> V7:
> > * no change.
> > V7 -> V8:
> > * improve the doc, add more details.
> >
> > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > ---
> > Documentation/admin-guide/perf/imx-ddr.rst | 51
> > ++++++++++++++++++++++
> > 1 file changed, 51 insertions(+)
> > create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
> >
> > diff --git a/Documentation/admin-guide/perf/imx-ddr.rst
> > b/Documentation/admin-guide/perf/imx-ddr.rst
> > new file mode 100644
> > index 000000000000..438de3be667b
> > --- /dev/null
> > +++ b/Documentation/admin-guide/perf/imx-ddr.rst
> > @@ -0,0 +1,51 @@
> > +=====================================================
> > +Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
> > +=====================================================
> > +
> > +There are no performance counters inside the DRAM controller, so
> > +performance signals are brought out to the edge of the controller
> > +where a set of 4 x 32 bit counters is implemented. This is controlled
> > +by the Performance log on parameter
>
> I don't understand what you mean by "Performance log on parameter".
[Joakim] From IC RM, it means Performance log on parameter field(event id)on counters control register. I will improve it.
> > +which causes a large number of PERF signals to be generated.
> > +
> > +Selection of the value for each counter is done via the config
> > +registiers. There
>
> registers
[Joakim] Will Fix it.
> > +is one register for each counter. Counter 0 is special in that it
> > +always counts “time” and when expired causes a lock on itself and the
> > +other counters and an interrupt ie enable of counter 0 is a global function.
>
> by "causes a lock on itself and the other counters" do you mean that Counter
> 0 counts down and, when it hits 0, all the counters stop counting?
[Joakim] Yes, as it commented in ddr_perf_irq_handler():
/*
* When the cycle counter overflows, all counters are stopped,
* and an IRQ is raised. If any other counter overflows, it
* continues counting, and no IRQ is raised.
*
* Cycles occur at least 4 times as often as other events, so we
* can update all events on a cycle counter overflow and not
* lose events.
*/
Best Regards,
Joakim Zhang
> Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support
From: Robin Murphy @ 2019-08-28 11:49 UTC (permalink / raw)
To: Neil Armstrong, Tomeu Vizoso
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux IOMMU, David Airlie, Will Deacon, open list, dri-devel,
Steven Price, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Clément Péron,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <92e9b697-ea0d-9b13-5512-b0a16a39df20@baylibre.com>
Hi Neil,
On 28/08/2019 12:28, Neil Armstrong wrote:
> Hi Robin,
>
> On 31/05/2019 15:47, Robin Murphy wrote:
>> On 31/05/2019 13:04, Tomeu Vizoso wrote:
>>> On Wed, 29 May 2019 at 19:38, Robin Murphy <robin.murphy@arm.com> wrote:
>>>>
>>>> On 29/05/2019 16:09, Tomeu Vizoso wrote:
>>>>> On Tue, 21 May 2019 at 18:11, Clément Péron <peron.clem@gmail.com> wrote:
>>>>>>
>>>>> [snip]
>>>>>> [ 345.204813] panfrost 1800000.gpu: mmu irq status=1
>>>>>> [ 345.209617] panfrost 1800000.gpu: Unhandled Page fault in AS0 at VA
>>>>>> 0x0000000002400400
>>>>>
>>>>> From what I can see here, 0x0000000002400400 points to the first byte
>>>>> of the first submitted job descriptor.
>>>>>
>>>>> So mapping buffers for the GPU doesn't seem to be working at all on
>>>>> 64-bit T-760.
>>>>>
>>>>> Steven, Robin, do you have any idea of why this could be?
>>>>
>>>> I tried rolling back to the old panfrost/nondrm shim, and it works fine
>>>> with kbase, and I also found that T-820 falls over in the exact same
>>>> manner, so the fact that it seemed to be common to the smaller 33-bit
>>>> designs rather than anything to do with the other
>>>> job_descriptor_size/v4/v5 complication turned out to be telling.
>>>
>>> Is this complication something you can explain? I don't know what v4
>>> and v5 are meant here.
>>
>> I was alluding to BASE_HW_FEATURE_V4, which I believe refers to the Midgard architecture version - the older versions implemented by T6xx and T720 seem to be collectively treated as "v4", while T760 and T8xx would effectively be "v5".
>>
>>>> [ as an aside, are 64-bit jobs actually known not to work on v4 GPUs, or
>>>> is it just that nobody's yet observed a 64-bit blob driving one? ]
>>>
>>> I'm looking right now at getting Panfrost working on T720 with 64-bit
>>> descriptors, with the ultimate goal of making Panfrost
>>> 64-bit-descriptor only so we can have a single build of Mesa in
>>> distros.
>>
>> Cool, I'll keep an eye out, and hope that it might be enough for T620 on Juno, too :)
>>
>>>> Long story short, it appears that 'Mali LPAE' is also lacking the start
>>>> level notion of VMSA, and expects a full 4-level table even for <40 bits
>>>> when level 0 effectively redundant. Thus walking the 3-level table that
>>>> io-pgtable comes back with ends up going wildly wrong. The hack below
>>>> seems to do the job for me; if Clément can confirm (on T-720 you'll
>>>> still need the userspace hack to force 32-bit jobs as well) then I think
>>>> I'll cook up a proper refactoring of the allocator to put things right.
>>>
>>> Mmaps seem to work with this patch, thanks.
>>>
>>> The main complication I'm facing right now seems to be that the SFBD
>>> descriptor on T720 seems to be different from the one we already had
>>> (tested on T6xx?).
>>
>> OK - with the 32-bit hack pointed to up-thread, a quick kmscube test gave me the impression that T720 works fine, but on closer inspection some parts of glmark2 do seem to go a bit wonky (although I suspect at least some of it is just down to the FPGA setup being both very slow and lacking in memory bandwidth), and the "nv12-1img" mode of kmscube turns out to render in some delightfully wrong colours.
>>
>> I'll try to get a 'proper' version of the io-pgtable patch posted soon.
>
> I'm trying to collect all the fixes needed to make T820 work again, and
> I was wondering if you finally have a proper patch for this and "cfg->ias > 48"
> hack ? Or one I can test ?
I do have a handful of io-pgtable patches written up and ready to go,
I'm just treading carefully and waiting for the internal approval box to
be ticked before I share anything :(
Robin.
>
> Thanks,
> Neil
>
>>
>> Thanks,
>> Robin.
>>
>>>
>>> Cheers,
>>>
>>> Tomeu
>>>
>>>> Robin.
>>>>
>>>>
>>>> ----->8-----
>>>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>>>> index 546968d8a349..f29da6e8dc08 100644
>>>> --- a/drivers/iommu/io-pgtable-arm.c
>>>> +++ b/drivers/iommu/io-pgtable-arm.c
>>>> @@ -1023,12 +1023,14 @@ arm_mali_lpae_alloc_pgtable(struct
>>>> io_pgtable_cfg *cfg, void *cookie)
>>>> iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
>>>> if (iop) {
>>>> u64 mair, ttbr;
>>>> + struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(&iop->ops);
>>>>
>>>> + data->levels = 4;
>>>> /* Copy values as union fields overlap */
>>>> mair = cfg->arm_lpae_s1_cfg.mair[0];
>>>> ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
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 v6 0/6] Allwinner H6 Mali GPU support
From: Neil Armstrong @ 2019-08-28 11:51 UTC (permalink / raw)
To: Robin Murphy, Tomeu Vizoso
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux IOMMU, David Airlie, Will Deacon, open list, dri-devel,
Steven Price, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Clément Péron,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <8433455c-3b74-c176-49a1-388b3f085e9e@arm.com>
On 28/08/2019 13:49, Robin Murphy wrote:
> Hi Neil,
>
> On 28/08/2019 12:28, Neil Armstrong wrote:
>> Hi Robin,
>>
[...]
>>>
>>> OK - with the 32-bit hack pointed to up-thread, a quick kmscube test gave me the impression that T720 works fine, but on closer inspection some parts of glmark2 do seem to go a bit wonky (although I suspect at least some of it is just down to the FPGA setup being both very slow and lacking in memory bandwidth), and the "nv12-1img" mode of kmscube turns out to render in some delightfully wrong colours.
>>>
>>> I'll try to get a 'proper' version of the io-pgtable patch posted soon.
>>
>> I'm trying to collect all the fixes needed to make T820 work again, and
>> I was wondering if you finally have a proper patch for this and "cfg->ias > 48"
>> hack ? Or one I can test ?
>
> I do have a handful of io-pgtable patches written up and ready to go, I'm just treading carefully and waiting for the internal approval box to be ticked before I share anything :(
Great !
No problem, it can totally wait until approval,
Thanks,
Neil
>
> Robin.
>
>>
>> Thanks,
>> Neil
>>
>>>
>>> Thanks,
>>> Robin.
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Tomeu
>>>>
>>>>> Robin.
>>>>>
>>>>>
>>>>> ----->8-----
>>>>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>>>>> index 546968d8a349..f29da6e8dc08 100644
>>>>> --- a/drivers/iommu/io-pgtable-arm.c
>>>>> +++ b/drivers/iommu/io-pgtable-arm.c
>>>>> @@ -1023,12 +1023,14 @@ arm_mali_lpae_alloc_pgtable(struct
>>>>> io_pgtable_cfg *cfg, void *cookie)
>>>>> iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
>>>>> if (iop) {
>>>>> u64 mair, ttbr;
>>>>> + struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(&iop->ops);
>>>>>
>>>>> + data->levels = 4;
>>>>> /* Copy values as union fields overlap */
>>>>> mair = cfg->arm_lpae_s1_cfg.mair[0];
>>>>> ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
>>>>>
>>>>> _______________________________________________
>>>>> dri-devel mailing list
>>>>> dri-devel@lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/5] arm64: atomics: avoid out-of-line ll/sc atomics
From: Andrew Murray @ 2019-08-28 11:53 UTC (permalink / raw)
To: Mark Rutland
Cc: Peter Zijlstra, Catalin Marinas, Boqun Feng, Will Deacon,
Ard.Biesheuvel, linux-arm-kernel
In-Reply-To: <20190822170155.GE33080@lakrids.cambridge.arm.com>
On Thu, Aug 22, 2019 at 06:01:55PM +0100, Mark Rutland wrote:
> On Mon, Aug 12, 2019 at 03:36:23PM +0100, Andrew Murray wrote:
> > When building for LSE atomics (CONFIG_ARM64_LSE_ATOMICS), if the hardware
> > or toolchain doesn't support it the existing code will fallback to ll/sc
> > atomics. It achieves this by branching from inline assembly to a function
> > that is built with specical compile flags. Further this results in the
> > clobbering of registers even when the fallback isn't used increasing
> > register pressure.
> >
> > Let's improve this by providing inline implementations of both LSE and
> > ll/sc and use a static key to select between them. This allows for the
> > compiler to generate better atomics code.
> >
> > To improve icache performance for the LL/SC fallback atomics, we put them
> > in their own subsection.
> >
> > Please note that as atomic_arch.h is included indirectly by kernel.h
> > (via bitops.h), we cannot depend on features provided later in the kernel.h
> > file. This prevents us from placing the system_uses_lse_atomics function
> > in cpu_feature.h due to its dependencies.
> >
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
>
> [...]
>
> > diff --git a/arch/arm64/include/asm/atomic_arch.h b/arch/arm64/include/asm/atomic_arch.h
> > new file mode 100644
> > index 000000000000..255a284321c6
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/atomic_arch.h
> > @@ -0,0 +1,154 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Selection between LSE and LL/SC atomics.
> > + *
> > + * Copyright (C) 2018 ARM Ltd.
> > + * Author: Andrew Murray <andrew.murray@arm.com>
> > + */
> > +
> > +#ifndef __ASM_ATOMIC_ARCH_H
> > +#define __ASM_ATOMIC_ARCH_H
> > +
> > +#include <asm/atomic_lse.h>
> > +#include <asm/atomic_ll_sc.h>
> > +
> > +#include <linux/jump_label.h>
> > +#include <asm/cpucaps.h>
>
> I'm guessing that we have to include the <asm/atomic_*> headers first
> due to the include dependencies. If that's the case, could we please
> have a comment here to that effect?
>
> Minor nit, but could we also order those two alphabetically, please?
>
> The general style is to have headers alphabetically, with (for reasons
> unknown) the <linux/*> headers before the <asm/*> headers.
There doesn't appear to be any valid reason for ordering the includes
in the way I have done, so I'll change it to the
linux-followed-by-asm-alphabetical way.
>
> [...]
>
> > +#if IS_ENABLED(CONFIG_ARM64_LSE_ATOMICS) && IS_ENABLED(CONFIG_AS_LSE)
> > +#define __LL_SC_FALLBACK(asm_ops) \
> > +" b 3f\n" \
> > +" .subsection 1\n" \
> > +"3:\n" \
> > +asm_ops "\n" \
> > +" b 4f\n" \
> > +" .previous\n" \
> > +"4:\n"
> > +#else
> > +#define __LL_SC_FALLBACK(asm_ops) asm_ops
> > #endif
>
> Can we instead make the ll/sc functions with the cold attribute (wrapped
> by <linux/compiler.h> as __cold)?
>
> IIUC that should have a similar effect, and might allow GCC to do better
> (e.g. merging compatible instances of the ll/sc code in the same cold
> subsection).
>
> https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Common-Function-Attributes.html#index-cold-function-attribute
Thanks for suggesting this, I hadn't considered this previously. However
the cold attribute only seems to have an effect when the function it is
applied to isn't inline. I think we want to keep both LSE and fallback
functions as inline.
At present the fallback functions are inlined, due to the use of 'unlikely'
they end up at the end of the function they are called from. Within this
inline'd function we take unconditional branches to/from the actual LL/SC
implementation, as we are using subsections the LL/SC implementations are
grouped together at the end of the each compilation unit. As we are using
unconditional branches, each call to an atomics function results in the LL/SC
implementation being duplicated (just like any other inline function, except
the code is elsewhere). We get some locality benefits from the use of
subsection but that is per-compilation unit (so you'll get clusters of them
across the vmlinux).
This approach gives us bloat, we can mitigate this by not using inline
functions, and further by optimising for size. We can put all the fallback
atomics in a single section to benefit from vmlinux-wide code locality -
however to benefit from all this we must use functions calls and their
associated overhead.
Thanks,
Andrew Murray
>
> Otherwise, this is looking much nicer!
>
> Thanks,
> Mark.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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 6/7] soc: renesas: r8a77980-sysc: Fix power request conflicts
From: Geert Uytterhoeven @ 2019-08-28 11:36 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-renesas-soc, Simon Horman, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Describe the location and contents of the SYSCEXTMASK register on R-Car
V3H, to prevent conflicts between internal and external power requests.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- No changes.
---
drivers/soc/renesas/r8a77980-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77980-sysc.c b/drivers/soc/renesas/r8a77980-sysc.c
index a8dbe55e8ba82d7e..e3b5ee1b3091dee1 100644
--- a/drivers/soc/renesas/r8a77980-sysc.c
+++ b/drivers/soc/renesas/r8a77980-sysc.c
@@ -6,6 +6,7 @@
* Copyright (C) 2018 Cogent Embedded, Inc.
*/
+#include <linux/bits.h>
#include <linux/bug.h>
#include <linux/kernel.h>
@@ -49,4 +50,6 @@ static const struct rcar_sysc_area r8a77980_areas[] __initconst = {
const struct rcar_sysc_info r8a77980_sysc_info __initconst = {
.areas = r8a77980_areas,
.num_areas = ARRAY_SIZE(r8a77980_areas),
+ .extmask_offs = 0x138,
+ .extmask_val = BIT(0),
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 7/7] soc: renesas: r8a77990-sysc: Fix power request conflicts
From: Geert Uytterhoeven @ 2019-08-28 11:36 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-renesas-soc, Simon Horman, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Describe the location and contents of the SYSCEXTMASK register on R-Car
E3, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham <dien.pham.ry@renesas.com>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- No changes.
---
drivers/soc/renesas/r8a77990-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77990-sysc.c b/drivers/soc/renesas/r8a77990-sysc.c
index 664b244eb1dd9d95..1d2432020b7a15d2 100644
--- a/drivers/soc/renesas/r8a77990-sysc.c
+++ b/drivers/soc/renesas/r8a77990-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2018 Renesas Electronics Corp.
*/
+#include <linux/bits.h>
#include <linux/bug.h>
#include <linux/kernel.h>
#include <linux/sys_soc.h>
@@ -50,4 +51,6 @@ const struct rcar_sysc_info r8a77990_sysc_info __initconst = {
.init = r8a77990_sysc_init,
.areas = r8a77990_areas,
.num_areas = ARRAY_SIZE(r8a77990_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/7] soc: renesas: r8a77965-sysc: Fix power request conflicts
From: Geert Uytterhoeven @ 2019-08-28 11:36 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-renesas-soc, Simon Horman, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Describe the location and contents of the SYSCEXTMASK register on R-Car
M3-N, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham <dien.pham.ry@renesas.com>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- No changes.
---
drivers/soc/renesas/r8a77965-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77965-sysc.c b/drivers/soc/renesas/r8a77965-sysc.c
index e0533beb50fd7063..b5d8230d4bbc1b87 100644
--- a/drivers/soc/renesas/r8a77965-sysc.c
+++ b/drivers/soc/renesas/r8a77965-sysc.c
@@ -7,6 +7,7 @@
* Copyright (C) 2016 Glider bvba
*/
+#include <linux/bits.h>
#include <linux/bug.h>
#include <linux/kernel.h>
@@ -33,4 +34,6 @@ static const struct rcar_sysc_area r8a77965_areas[] __initconst = {
const struct rcar_sysc_info r8a77965_sysc_info __initconst = {
.areas = r8a77965_areas,
.num_areas = ARRAY_SIZE(r8a77965_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/7] soc: renesas: rcar-gen3-sysc: Fix power request conflicts
From: Geert Uytterhoeven @ 2019-08-28 11:36 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-renesas-soc, Simon Horman, Geert Uytterhoeven,
linux-arm-kernel
Hi all,
Recent R-Car Gen3 SoCs added an External Request Mask Register to the
System Controller (SYSC). This register allows to mask external power
requests for CPU or 3DG domains, to prevent conflicts between powering
off CPU cores or the 3D Graphics Engine, and changing the state of
another power domain through SYSC, which could lead to CPG state machine
lock-ups.
This patch series starts making use of this register. Note that the
register is optional, and that its location and contents are
SoC-specific.
This was inspired by a patch in the BSP by Dien Pham
<dien.pham.ry@renesas.com>.
Note that the issue fixed cannot happen in the upstream kernel, as
upstream has no support for graphics acceleration yet. SoCs lacking the
External Request Mask Register may need a different mitigation in the
future.
Changes compared to v1[1]:
- Improve description of cover letter and first patch.
Changes compared to RFC[2]:
- Rebased.
This has been boot-tested on R-Car H3 ES1.0, H3 ES2.0, M3-W ES1.0, M3-N,
V3M, and E3 (only the last 3 have this register!), and regression-tested
on R-Car Gen2.
This has not been tested on R-Car H3 ES3.0, M3-W ES2.0, and V3H.
For your convenience, this series is available in the
topic/rcar3-sysc-extmask-v2 branch of my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
Thanks for your comments!
[1] Not posted, but included in yesterday's renesas-drivers-2019-08-27-v5.3-rc6
[2] "[RFC PATCH 0/7] soc: renesas: rcar-gen3-sysc: Fix power request conflicts"
(https://lore.kernel.org/linux-renesas-soc/20181205155028.14335-1-geert+renesas@glider.be/)
Geert Uytterhoeven (7):
soc: renesas: rcar-sysc: Prepare for fixing power request conflicts
soc: renesas: r8a7795-sysc: Fix power request conflicts
soc: renesas: r8a7796-sysc: Fix power request conflicts
soc: renesas: r8a77965-sysc: Fix power request conflicts
soc: renesas: r8a77970-sysc: Fix power request conflicts
soc: renesas: r8a77980-sysc: Fix power request conflicts
soc: renesas: r8a77990-sysc: Fix power request conflicts
drivers/soc/renesas/r8a7795-sysc.c | 32 ++++++++++++++++++++++++-----
drivers/soc/renesas/r8a7796-sysc.c | 22 +++++++++++++++++++-
drivers/soc/renesas/r8a77965-sysc.c | 3 +++
drivers/soc/renesas/r8a77970-sysc.c | 3 +++
drivers/soc/renesas/r8a77980-sysc.c | 3 +++
drivers/soc/renesas/r8a77990-sysc.c | 3 +++
drivers/soc/renesas/rcar-sysc.c | 16 +++++++++++++++
drivers/soc/renesas/rcar-sysc.h | 7 +++++--
8 files changed, 81 insertions(+), 8 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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 3/7] soc: renesas: r8a7796-sysc: Fix power request conflicts
From: Geert Uytterhoeven @ 2019-08-28 11:36 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-renesas-soc, Simon Horman, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Describe the location and contents of the SYSCEXTMASK register on R-Car
M3-W, to prevent conflicts between internal and external power requests.
This register does not exist on R-Car M3-W ES1.x.
Based on a patch in the BSP by Dien Pham <dien.pham.ry@renesas.com>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- No changes.
---
drivers/soc/renesas/r8a7796-sysc.c | 22 +++++++++++++++++++++-
drivers/soc/renesas/rcar-sysc.h | 2 +-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/renesas/r8a7796-sysc.c b/drivers/soc/renesas/r8a7796-sysc.c
index 1b06f868b6e81c79..a4eaa8d1f5d0f49d 100644
--- a/drivers/soc/renesas/r8a7796-sysc.c
+++ b/drivers/soc/renesas/r8a7796-sysc.c
@@ -5,8 +5,10 @@
* Copyright (C) 2016 Glider bvba
*/
+#include <linux/bits.h>
#include <linux/bug.h>
#include <linux/kernel.h>
+#include <linux/sys_soc.h>
#include <dt-bindings/power/r8a7796-sysc.h>
@@ -39,7 +41,25 @@ static const struct rcar_sysc_area r8a7796_areas[] __initconst = {
{ "a3ir", 0x180, 0, R8A7796_PD_A3IR, R8A7796_PD_ALWAYS_ON },
};
-const struct rcar_sysc_info r8a7796_sysc_info __initconst = {
+
+/* Fixups for R-Car M3-W ES1.x revision */
+static const struct soc_device_attribute r8a7796es1[] __initconst = {
+ { .soc_id = "r8a7796", .revision = "ES1.*" },
+ { /* sentinel */ }
+};
+
+static int __init r8a7796_sysc_init(void)
+{
+ if (soc_device_match(r8a7796es1))
+ r8a7796_sysc_info.extmask_val = 0;
+
+ return 0;
+}
+
+struct rcar_sysc_info r8a7796_sysc_info __initdata = {
+ .init = r8a7796_sysc_init,
.areas = r8a7796_areas,
.num_areas = ARRAY_SIZE(r8a7796_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 499797a9e18c2f10..64c2a0fa7945d80b 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -60,7 +60,7 @@ extern const struct rcar_sysc_info r8a7791_sysc_info;
extern const struct rcar_sysc_info r8a7792_sysc_info;
extern const struct rcar_sysc_info r8a7794_sysc_info;
extern struct rcar_sysc_info r8a7795_sysc_info;
-extern const struct rcar_sysc_info r8a7796_sysc_info;
+extern struct rcar_sysc_info r8a7796_sysc_info;
extern const struct rcar_sysc_info r8a77965_sysc_info;
extern const struct rcar_sysc_info r8a77970_sysc_info;
extern const struct rcar_sysc_info r8a77980_sysc_info;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/7] soc: renesas: r8a77970-sysc: Fix power request conflicts
From: Geert Uytterhoeven @ 2019-08-28 11:36 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-renesas-soc, Simon Horman, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Describe the location and contents of the SYSCEXTMASK register on R-Car
V3M, to prevent conflicts between internal and external power requests.
Based on a patch in the BSP by Dien Pham <dien.pham.ry@renesas.com>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- No changes.
---
drivers/soc/renesas/r8a77970-sysc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/soc/renesas/r8a77970-sysc.c b/drivers/soc/renesas/r8a77970-sysc.c
index 280c48b80f240424..b3033e3f0fd0b0ff 100644
--- a/drivers/soc/renesas/r8a77970-sysc.c
+++ b/drivers/soc/renesas/r8a77970-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2017 Cogent Embedded Inc.
*/
+#include <linux/bits.h>
#include <linux/bug.h>
#include <linux/kernel.h>
@@ -32,4 +33,6 @@ static const struct rcar_sysc_area r8a77970_areas[] __initconst = {
const struct rcar_sysc_info r8a77970_sysc_info __initconst = {
.areas = r8a77970_areas,
.num_areas = ARRAY_SIZE(r8a77970_areas),
+ .extmask_offs = 0x1b0,
+ .extmask_val = BIT(0),
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/7] soc: renesas: rcar-sysc: Prepare for fixing power request conflicts
From: Geert Uytterhoeven @ 2019-08-28 11:36 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-renesas-soc, Simon Horman, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Recent R-Car Gen3 SoCs added an External Request Mask Register to the
System Controller (SYSC). This register allows to mask external power
requests for CPU or 3DG domains, to prevent conflicts between powering
off CPU cores or the 3D Graphics Engine, and changing the state of
another power domain through SYSC, which could lead to CPG state machine
lock-ups.
Add support for making use of this register. Take into account that the
register is optional, and that its location and contents are
SoC-specific.
Note that the issue fixed by this cannot happen in the upstream kernel,
as upstream has no support for graphics acceleration yet. SoCs lacking
the External Request Mask Register may need a different mitigation in
the future.
Inspired by a patch in the BSP by Dien Pham <dien.pham.ry@renesas.com>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- Improve patch description.
---
drivers/soc/renesas/rcar-sysc.c | 16 ++++++++++++++++
drivers/soc/renesas/rcar-sysc.h | 3 +++
2 files changed, 19 insertions(+)
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index 59b5e6b102722a6d..176de145f4230fbd 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -63,6 +63,7 @@ struct rcar_sysc_ch {
static void __iomem *rcar_sysc_base;
static DEFINE_SPINLOCK(rcar_sysc_lock); /* SMP CPUs + I/O devices */
+static u32 rcar_sysc_extmask_offs, rcar_sysc_extmask_val;
static int rcar_sysc_pwr_on_off(const struct rcar_sysc_ch *sysc_ch, bool on)
{
@@ -105,6 +106,14 @@ static int rcar_sysc_power(const struct rcar_sysc_ch *sysc_ch, bool on)
spin_lock_irqsave(&rcar_sysc_lock, flags);
+ /*
+ * Mask external power requests for CPU or 3DG domains
+ */
+ if (rcar_sysc_extmask_val) {
+ iowrite32(rcar_sysc_extmask_val,
+ rcar_sysc_base + rcar_sysc_extmask_offs);
+ }
+
/*
* The interrupt source needs to be enabled, but masked, to prevent the
* CPU from receiving it.
@@ -148,6 +157,9 @@ static int rcar_sysc_power(const struct rcar_sysc_ch *sysc_ch, bool on)
iowrite32(isr_mask, rcar_sysc_base + SYSCISCR);
out:
+ if (rcar_sysc_extmask_val)
+ iowrite32(0, rcar_sysc_base + rcar_sysc_extmask_offs);
+
spin_unlock_irqrestore(&rcar_sysc_lock, flags);
pr_debug("sysc power %s domain %d: %08x -> %d\n", on ? "on" : "off",
@@ -360,6 +372,10 @@ static int __init rcar_sysc_pd_init(void)
rcar_sysc_base = base;
+ /* Optional External Request Mask Register */
+ rcar_sysc_extmask_offs = info->extmask_offs;
+ rcar_sysc_extmask_val = info->extmask_val;
+
domains = kzalloc(sizeof(*domains), GFP_KERNEL);
if (!domains) {
error = -ENOMEM;
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 485520a5b295c13e..21ee3ff8620bbafe 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -44,6 +44,9 @@ struct rcar_sysc_info {
int (*init)(void); /* Optional */
const struct rcar_sysc_area *areas;
unsigned int num_areas;
+ /* Optional External Request Mask Register */
+ u32 extmask_offs; /* SYSCEXTMASK register offset */
+ u32 extmask_val; /* SYSCEXTMASK register mask value */
};
extern const struct rcar_sysc_info r8a7743_sysc_info;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/7] soc: renesas: r8a7795-sysc: Fix power request conflicts
From: Geert Uytterhoeven @ 2019-08-28 11:36 UTC (permalink / raw)
To: Magnus Damm
Cc: linux-renesas-soc, Simon Horman, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190828113618.6672-1-geert+renesas@glider.be>
Describe the location and contents of the SYSCEXTMASK register on R-Car
H3, to prevent conflicts between internal and external power requests.
This register does not exist on R-Car H3 ES1.x and ES2.x.
Based on a patch in the BSP by Dien Pham <dien.pham.ry@renesas.com>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
v2:
- No changes.
---
drivers/soc/renesas/r8a7795-sysc.c | 32 +++++++++++++++++++++++++-----
drivers/soc/renesas/rcar-sysc.h | 2 +-
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/renesas/r8a7795-sysc.c b/drivers/soc/renesas/r8a7795-sysc.c
index cda27a67de9876af..7e15cd09c4eb4780 100644
--- a/drivers/soc/renesas/r8a7795-sysc.c
+++ b/drivers/soc/renesas/r8a7795-sysc.c
@@ -5,6 +5,7 @@
* Copyright (C) 2016-2017 Glider bvba
*/
+#include <linux/bits.h>
#include <linux/bug.h>
#include <linux/kernel.h>
#include <linux/sys_soc.h>
@@ -51,25 +52,46 @@ static struct rcar_sysc_area r8a7795_areas[] __initdata = {
/*
- * Fixups for R-Car H3 revisions after ES1.x
+ * Fixups for R-Car H3 revisions
*/
-static const struct soc_device_attribute r8a7795es1[] __initconst = {
- { .soc_id = "r8a7795", .revision = "ES1.*" },
+#define HAS_A2VC0 BIT(0) /* Power domain A2VC0 is present */
+#define NO_EXTMASK BIT(1) /* Missing SYSCEXTMASK register */
+
+static const struct soc_device_attribute r8a7795_quirks_match[] __initconst = {
+ {
+ .soc_id = "r8a7795", .revision = "ES1.*",
+ .data = (void *)(HAS_A2VC0 | NO_EXTMASK),
+ }, {
+ .soc_id = "r8a7795", .revision = "ES2.*",
+ .data = (void *)(NO_EXTMASK),
+ },
{ /* sentinel */ }
};
static int __init r8a7795_sysc_init(void)
{
- if (!soc_device_match(r8a7795es1))
+ const struct soc_device_attribute *attr;
+ u32 quirks = 0;
+
+ attr = soc_device_match(r8a7795_quirks_match);
+ if (attr)
+ quirks = (uintptr_t)attr->data;
+
+ if (!(quirks & HAS_A2VC0))
rcar_sysc_nullify(r8a7795_areas, ARRAY_SIZE(r8a7795_areas),
R8A7795_PD_A2VC0);
+ if (quirks & NO_EXTMASK)
+ r8a7795_sysc_info.extmask_val = 0;
+
return 0;
}
-const struct rcar_sysc_info r8a7795_sysc_info __initconst = {
+struct rcar_sysc_info r8a7795_sysc_info __initdata = {
.init = r8a7795_sysc_init,
.areas = r8a7795_areas,
.num_areas = ARRAY_SIZE(r8a7795_areas),
+ .extmask_offs = 0x2f8,
+ .extmask_val = BIT(0),
};
diff --git a/drivers/soc/renesas/rcar-sysc.h b/drivers/soc/renesas/rcar-sysc.h
index 21ee3ff8620bbafe..499797a9e18c2f10 100644
--- a/drivers/soc/renesas/rcar-sysc.h
+++ b/drivers/soc/renesas/rcar-sysc.h
@@ -59,7 +59,7 @@ extern const struct rcar_sysc_info r8a7790_sysc_info;
extern const struct rcar_sysc_info r8a7791_sysc_info;
extern const struct rcar_sysc_info r8a7792_sysc_info;
extern const struct rcar_sysc_info r8a7794_sysc_info;
-extern const struct rcar_sysc_info r8a7795_sysc_info;
+extern struct rcar_sysc_info r8a7795_sysc_info;
extern const struct rcar_sysc_info r8a7796_sysc_info;
extern const struct rcar_sysc_info r8a77965_sysc_info;
extern const struct rcar_sysc_info r8a77970_sysc_info;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V9 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-28 12:07 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
writes with an ARID or AWID matching filter setting. Granularity is at
subsystem level. Implementation does not allow filtring between masters
within a subsystem. Filter is defined with 2 configuration parameters.
--AXI_ID defines AxID matching value
--AXI_MASKING defines which bits of AxID are meaningful for the matching
0:corresponding bit is masked
1: corresponding bit is not masked, i.e. used to do 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
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/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
it will be reverted in driver automatically. so that the user can just specify
axi_id to monitor a specific id, rather than having to specify axi_mask.
e.g.
perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
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().
V5 -> V6:
* change the event name: axi-id-read->axid-read;
axi-id-write->axid-write
* add another helper: ddr_perf_filters_compatible()
* drop the dev_dbg()
V6 -> V7:
* revert AXI_MASKING at driver.
V7 -> V8:
* separate axi_id to axi_mask and axi_id these two fileds.
V8 -> V9:
* only program DPCR1 for filtered events.
---
drivers/perf/fsl_imx8_ddr_perf.c | 74 +++++++++++++++++++++++++++++++-
1 file changed, 72 insertions(+), 2 deletions(-)
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index 0e3310dbb145..ce7345745b42 100644
--- a/drivers/perf/fsl_imx8_ddr_perf.c
+++ b/drivers/perf/fsl_imx8_ddr_perf.c
@@ -35,6 +35,8 @@
#define EVENT_CYCLES_COUNTER 0
#define NUM_COUNTERS 4
+#define AXI_MASKING_REVERT 0xffff0000 /* AXI_MASKING(MSB 16bits) + AXI_ID(LSB 16bits) */
+
#define to_ddr_pmu(p) container_of(p, struct ddr_pmu, pmu)
#define DDR_PERF_DEV_NAME "imx8_ddr"
@@ -42,9 +44,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 */ }
};
MODULE_DEVICE_TABLE(of, imx_ddr_pmu_dt_ids);
@@ -58,6 +73,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;
};
@@ -129,6 +145,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(axid-read, 0x41),
+ IMX8_DDR_PMU_EVENT_ATTR(axid-write, 0x42),
NULL,
};
@@ -138,9 +156,13 @@ static struct attribute_group ddr_perf_events_attr_group = {
};
PMU_FORMAT_ATTR(event, "config:0-7");
+PMU_FORMAT_ATTR(axi_id, "config1:0-15");
+PMU_FORMAT_ATTR(axi_mask, "config1:16-31");
static struct attribute *ddr_perf_format_attrs[] = {
&format_attr_event.attr,
+ &format_attr_axi_id.attr,
+ &format_attr_axi_mask.attr,
NULL,
};
@@ -190,6 +212,26 @@ 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;
+}
+
+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);
@@ -216,6 +258,15 @@ 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) {
+ 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;
+ }
+ }
+
for_each_sibling_event(sibling, event->group_leader) {
if (sibling->pmu != event->pmu &&
!is_software_event(sibling))
@@ -288,6 +339,23 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
struct hw_perf_event *hwc = &event->hw;
int counter;
int cfg = event->attr.config;
+ int cfg1 = event->attr.config1;
+
+ if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
+ int i;
+
+ for (i = 1; i < NUM_COUNTERS; i++) {
+ if (pmu->events[i] &&
+ !ddr_perf_filters_compatible(event, pmu->events[i]))
+ return -EINVAL;
+ }
+
+ if (ddr_perf_is_filtered(event)) {
+ /* revert axi id masking(axi_mask) value */
+ cfg1 ^= AXI_MASKING_REVERT;
+ writel(cfg1, pmu->base + COUNTER_DPCR1);
+ }
+ }
counter = ddr_perf_alloc_counter(pmu, cfg);
if (counter < 0) {
@@ -473,6 +541,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 related
* [PATCH V9 2/3] Documentation: admin-guide: perf: add i.MX8 ddr pmu user doc
From: Joakim Zhang @ 2019-08-28 12:07 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190828120524.9038-1-qiangqing.zhang@nxp.com>
Add i.MX8 ddr pmu user doc.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
ChangeLog:
V1 -> V4:
* new add in V4.
V4 -> V5:
* no change.
V5 -> V6:
* change the event name
V6 -> V7:
* no change.
V7 -> V8:
* improve the doc, add more details.
V8 -> V9:
* improve the doc.
---
Documentation/admin-guide/perf/imx-ddr.rst | 52 ++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/admin-guide/perf/imx-ddr.rst
diff --git a/Documentation/admin-guide/perf/imx-ddr.rst b/Documentation/admin-guide/perf/imx-ddr.rst
new file mode 100644
index 000000000000..517a205abad6
--- /dev/null
+++ b/Documentation/admin-guide/perf/imx-ddr.rst
@@ -0,0 +1,52 @@
+=====================================================
+Freescale i.MX8 DDR Performance Monitoring Unit (PMU)
+=====================================================
+
+There are no performance counters inside the DRAM controller, so performance
+signals are brought out to the edge of the controller where a set of 4 x 32 bit
+counters is implemented. This is controlled by the CSV modes programed in counter
+control register which causes a large number of PERF signals to be generated.
+
+Selection of the value for each counter is done via the config registers. There
+is one register for each counter. Counter 0 is special in that it always counts
+“time” and when expired causes a lock on itself and the other counters and an
+interrupt is raised. If any other counter overflows, it continues counting, and
+no interrupt is raised.
+
+The "format" directory describes format of the config (event ID) and config1
+(AXI filtering) fields of the perf_event_attr structure, see /sys/bus/event_source/
+devices/imx8_ddr0/format/. The "events" directory describes the events types
+hardware supported that can be used with perf tool, see /sys/bus/event_source/
+devices/imx8_ddr0/events/.
+ e.g.::
+ perf stat -a -e imx8_ddr0/cycles/ cmd
+ perf stat -a -e imx8_ddr0/read/,imx8_ddr0/write/ cmd
+
+AXI filtering is only used by CSV modes 0x41 (axid-read) and 0x42 (axid-write)
+to count reading or writing matches filter setting. Filter setting is various
+from different DRAM controller implementations, which is distinguished by quirks
+in the driver.
+
+* With DDR_CAP_AXI_ID_FILTER quirk.
+ Filter is defined with two configuration parts:
+ --AXI_ID defines AxID matching value.
+ --AXI_MASKING defines which bits of AxID are meaningful for the matching.
+ 0:corresponding bit is masked.
+ 1: corresponding bit is not masked, i.e. used to do the matching.
+
+ AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
+ When non-masked bits are matching corresponding AXI_ID bits then counter is
+ incremented. Perf counter is incremented if
+ AxID && AXI_MASKING == AXI_ID && AXI_MASKING
+
+ This filter doesn't support filter different AXI ID for axid-read and axid-write
+ event at the same time as this filter is shared between counters.
+ e.g.::
+ perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
+ perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/ cmd
+
+ NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to mask), and
+ it will be reverted in driver automatically. so that the user can just specify
+ axi_id to monitor a specific id, rather than having to specify axi_mask.
+ e.g.::
+ perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will monitor ARID=0x12
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V9 3/3] MAINTAINERS: add imx8 ddr perf admin-guide maintainer information
From: Joakim Zhang @ 2019-08-28 12:07 UTC (permalink / raw)
To: mark.rutland@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
Joakim Zhang
In-Reply-To: <20190828120524.9038-1-qiangqing.zhang@nxp.com>
Add imx8 ddr perf admin-guide maintainer information.
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
ChangeLog:
V1 -> V5:
* new add in V5.
V5 -> V6:
* no change.
V6 -> V7:
* no change.
V7 -> V8:
* no change.
V8 -> V9:
* no change.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e60f5c361969..2ba378e806c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6462,6 +6462,7 @@ M: Frank Li <Frank.li@nxp.com>
L: linux-arm-kernel@lists.infradead.org
S: Maintained
F: drivers/perf/fsl_imx8_ddr_perf.c
+F: Documentation/admin-guide/perf/imx-ddr.rst
F: Documentation/devicetree/bindings/perf/fsl-imx-ddr.txt
FREESCALE IMX LPI2C DRIVER
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 01/10] KVM: arm64: Document PV-time interface
From: Steven Price @ 2019-08-28 12:09 UTC (permalink / raw)
To: Christoffer Dall
Cc: kvm, linux-doc, Marc Zyngier, linux-kernel, Russell King,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190827085706.GB6541@e113682-lin.lund.arm.com>
On 27/08/2019 09:57, Christoffer Dall wrote:
> On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
>> Introduce a paravirtualization interface for KVM/arm64 based on the
>> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>>
>> This only adds the details about "Stolen Time" as the details of "Live
>> Physical Time" have not been fully agreed.
>>
>> User space can specify a reserved area of memory for the guest and
>> inform KVM to populate the memory with information on time that the host
>> kernel has stolen from the guest.
>>
>> A hypercall interface is provided for the guest to interrogate the
>> hypervisor's support for this interface and the location of the shared
>> memory structures.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
>> 1 file changed, 100 insertions(+)
>> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
>>
>> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
>> new file mode 100644
>> index 000000000000..1ceb118694e7
>> --- /dev/null
>> +++ b/Documentation/virt/kvm/arm/pvtime.txt
>> @@ -0,0 +1,100 @@
>> +Paravirtualized time support for arm64
>> +======================================
>> +
>> +Arm specification DEN0057/A defined a standard for paravirtualised time
>> +support for AArch64 guests:
>> +
>> +https://developer.arm.com/docs/den0057/a
>> +
>> +KVM/arm64 implements the stolen time part of this specification by providing
>> +some hypervisor service calls to support a paravirtualized guest obtaining a
>> +view of the amount of time stolen from its execution.
>> +
>> +Two new SMCCC compatible hypercalls are defined:
>> +
>> +PV_FEATURES 0xC5000020
>> +PV_TIME_ST 0xC5000022
>> +
>> +These are only available in the SMC64/HVC64 calling convention as
>> +paravirtualized time is not available to 32 bit Arm guests. The existence of
>> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
>> +mechanism before calling it.
>> +
>> +PV_FEATURES
>> + Function ID: (uint32) : 0xC5000020
>> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
>> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
>> + PV-time feature is supported by the hypervisor.
>> +
>> +PV_TIME_ST
>> + Function ID: (uint32) : 0xC5000022
>> + Return value: (int64) : IPA of the stolen time data structure for this
>> + (V)CPU. On failure:
>> + NOT_SUPPORTED (-1)
>> +
>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
>> +with inner and outer write back caching attributes, in the inner shareable
>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
>> +meaningfully filled by the hypervisor (see structure below).
>> +
>> +PV_TIME_ST returns the structure for the calling VCPU.
>> +
>> +Stolen Time
>> +-----------
>> +
>> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
>> +
>> + Field | Byte Length | Byte Offset | Description
>> + ----------- | ----------- | ----------- | --------------------------
>> + Revision | 4 | 0 | Must be 0 for version 0.1
>> + Attributes | 4 | 4 | Must be 0
>> + Stolen time | 8 | 8 | Stolen time in unsigned
>> + | | | nanoseconds indicating how
>> + | | | much time this VCPU thread
>> + | | | was involuntarily not
>> + | | | running on a physical CPU.
>> +
>> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
>> +will be present within a reserved region of the normal memory given to the
>> +guest. The guest should not attempt to write into this memory. There is a
>> +structure per VCPU of the guest.
>> +
>> +User space interface
>> +====================
>> +
>> +User space can request that KVM provide the paravirtualized time interface to
>> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
>> +
>> + struct kvm_create_device pvtime_device = {
>> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
>> + .attr = 0,
>> + .flags = 0,
>> + };
>> +
>> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
>> +
>> +Creation of the device should be done after creating the vCPUs of the virtual
>> +machine.
>> +
>> +The IPA of the structures must be given to KVM. This is the base address
>> +of an array of stolen time structures (one for each VCPU). The base address
>> +must be page aligned. The size must be at least 64 * number of VCPUs and be a
>> +multiple of PAGE_SIZE.
>> +
>> +The memory for these structures should be added to the guest in the usual
>> +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
>> +
>> +For example:
>> +
>> + struct kvm_dev_arm_st_region region = {
>> + .gpa = <IPA of guest base address>,
>> + .size = <size in bytes>
>> + };
>
> This feel fragile; how are you handling userspace creating VCPUs after
> setting this up,
In this case as long as the structures all fit within the region created
VCPUs can be created/destroyed at will. If the VCPU index is too high
then the kernel will bail out in kvm_update_stolen_time() so the
structure will not be written. I consider this case as user space
messing up, so beyond protecting the host from the mess, user space gets
to keep the pieces.
> the GPA overlapping guest memory, etc.
Again, the (host) kernel is protected against this, but clearly this
will end badly for the guest.
> Is the
> philosophy here that the VMM can mess up the VM if it wants, but that
> this should never lead attacks on the host (we better hope not) and so
> we don't care?
Yes. For things like GPA overlapping guest memory it's not really the
host's position to work out what is "guest memory". It's quite possible
that user space could decide to place the stolen time structures right
in the middle of guest memory - it's just up to user space to inform the
guest what memory is usable. Obviously the expectation is that the
shared structures would be positioned "out of the way" in GPA space in
any normal arrangement.
> It seems to me setting the IPA per vcpu throught the VCPU device would
> avoid a lot of these issues. See
> Documentation/virt/kvm/devices/vcpu.txt.
That is certainly a possibility, I'm not really sure what the benefit is
though? It would still lead to corner cases:
* What if only some VCPUs had stolen time setup on them?
* What if multiple VCPUs pointed to the same location?
* The structures can still overlap with guest memory
It's also more work to setup in user space with the only "benefit" being
that user space could choose to organise the structures however it sees
fit (e.g. no need for them to be contiguous in memory). But I'm not sure
I see a use case for that flexibility.
Perhaps there's some benefit I'm not seeing?
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm/arm64: defconfig: Update configs to use the new CROS_EC options
From: Arnd Bergmann @ 2019-08-28 12:09 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Gwendal Grignou, Collabora kernel ML, Geert Uytterhoeven,
Tony Lindgren, Catalin Marinas, Linus Walleij, Bjorn Andersson,
Thierry Reding, Miquel Raynal, Guenter Roeck, Leonard Crestez,
Will Deacon, Marek Szyprowski, Maxime Ripard,
moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Anson Huang,
Lee Jones, Daniel Lezcano, Russell King, Krzysztof Kozlowski,
Jonathan Hunter, Marcin Juszkiewicz, Chanwoo Choi, Kukjin Kim,
Jagan Teki, Alexandre Torgue, Robert Jarzmik, SoC Team,
open list:TEGRA ARCHITECTURE SUPPORT, Simon Horman,
Fabrice Gasnier, Benson Leung, Linux ARM,
Linux Kernel Mailing List, Yannick Fertr?, Dinh Nguyen,
Sudeep Holla, Olof Johansson, Shawn Guo, Daniel Mack
In-Reply-To: <2db6cde1-9e7f-8b1c-f2e4-80bdd2478d28@collabora.com>
On Wed, Aug 28, 2019 at 12:10 PM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
> On 27/8/19 18:12, Arnd Bergmann wrote:
> > On Tue, Aug 27, 2019 at 6:08 PM Bjorn Andersson
> > <bjorn.andersson@linaro.org> wrote:
> >>
> >> On Tue 27 Aug 08:48 PDT 2019, Enric Balletbo i Serra wrote:
> >>
> >>> Recently we refactored the CrOS EC drivers moving part of the code from
> >>> the MFD subsystem to the platform chrome subsystem. During this change
> >>> we needed to rename some config options, so, update the defconfigs
> >>> accordingly.
> >>>
> >>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> >>> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
> >>> Tested-by: Gwendal Grignou <gwendal@chromium.org>
> >>
> >> Can we make the entries in the generic arm64 defconfig modules?
> >
> > Good idea.
> >
> > Actually I would prefer to have all of them as modules for consistency,
> > if at all possible.
> >
>
> It is very common boot Chromebooks from an USB device, the EC needs to be
> built-in in order to boot from these devices, otherwise you should use an
> initramfs. I'd like to avoid forcing people to build an initramfs just to boot
> from these devices if possible, in fact, my usual workflow is without initramfs,
> and knowing that with the default defconfig just should boot helps a lot sometimes.
>
> Note that, it's not the case for EC subdevices, these are already build as modules.
Ok, fair enough, let's leave it built-in then.
> BTW, Lee asked if this patch should be squashed with the patches that really
> renames the config options to help bisect ability, I don't have a hard opinion
> as I don't usually run the config option between bisection steps, so please let
> me know what do you prefer and I'll respin the patches ASAP if that's the case.
I'm not usually worried about bisection in defconfig changes, since like you
say most commonly one would not run 'make defconfig' betweens the
bisection steps.
If we really care about it, we could keep a symbol like this
in drivers/platform/chrome/Kconfig for one release:
config CONFIG_MFD_CROS_EC
tristate "Enable ChromeOS Embedded Controller"
select CROS_EC
select CHROME_PLATFORMS
select CONFIG_MFD_CROS_EC_DEV
help
This is a transitional Kconfig option and will be removed
after everyone enables the parts individually.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/2] ARM: dts: exynos: Add support ARM architected timers on Exynos5
From: Marek Szyprowski @ 2019-08-28 12:10 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: Chanwoo Choi, Bartlomiej Zolnierkiewicz, Marc Zyngier,
Krzysztof Kozlowski, Marek Szyprowski
In-Reply-To: <20190828121005.29368-1-m.szyprowski@samsung.com>
All CortexA7/A15 based Exynos5 SoCs have ARM architected timers, so enable
support for them directly in the base dtsi. None of the known firmware
properly configures CNTFRQ arch timer register, so force clock frequency
to 24MHz, which is the only configuration supported by the remaining
clock drivers so far.
Stock firmware for Peach Pit and Pi Chromebooks also doesn't reset
properly other arch timer registers, so add respective properties
indicating that. Other Exynos5-based boards behaves correctly in this area,
what finally allows to enable support for KVM-based virtualization.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 ++++
arch/arm/boot/dts/exynos54xx.dtsi | 9 +++++++++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
3 files changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index f78db6809cca..77e08a4c7300 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -1064,6 +1064,10 @@
status = "okay";
};
+&timer {
+ arm,cpu-registers-not-fw-configured;
+};
+
&tmu_cpu0 {
vtmu-supply = <&ldo10_reg>;
};
diff --git a/arch/arm/boot/dts/exynos54xx.dtsi b/arch/arm/boot/dts/exynos54xx.dtsi
index 9c3b63b7cac6..02d34957cd83 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -45,6 +45,15 @@
status = "disabled";
};
+ timer: timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+ clock-frequency = <24000000>;
+ };
+
soc: soc {
sysram@2020000 {
compatible = "mmio-sram";
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index e0f470fe54c8..5e8cec736444 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -1033,6 +1033,10 @@
status = "okay";
};
+&timer {
+ arm,cpu-registers-not-fw-configured;
+};
+
&tmu_cpu0 {
vtmu-supply = <&ldo10_reg>;
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/2] ARM: exynos: Enable support for ARM architected timers
From: Marek Szyprowski @ 2019-08-28 12:10 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: Chanwoo Choi, Bartlomiej Zolnierkiewicz, Marc Zyngier,
Krzysztof Kozlowski, Marek Szyprowski
In-Reply-To: <20190828121005.29368-1-m.szyprowski@samsung.com>
ARM architected timer can be used together with Exynos MultiCore Timer
driver, so enable support for it. Support for ARM architected timers is
essential for enabling proper KVM support.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/mach-exynos/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index f83786640f94..9dab1f50a02f 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -19,6 +19,7 @@ menuconfig ARCH_EXYNOS
select EXYNOS_SROM
select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
select GPIOLIB
+ select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5 && VIRTUALIZATION
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/2] Exynos SoCs: enable support for ARM Architected Timers
From: Marek Szyprowski @ 2019-08-28 12:10 UTC (permalink / raw)
To: linux-samsung-soc, linux-arm-kernel
Cc: Chanwoo Choi, Bartlomiej Zolnierkiewicz, Marc Zyngier,
Krzysztof Kozlowski, Marek Szyprowski
In-Reply-To: <CGME20190828121011eucas1p1ff9b23536aaa79643e5fca10c02db9a0@eucas1p1.samsung.com>
Dear All,
ARM Architected Timers are present in all CortexA7/A15 based Samsung
Exynos SoCs. So far they were not enabled, because there were some issues
related to their initialization. Samsung Exynos SoCs used custom timer
hardware - Exynos MultiCore Timer. It turned out that enabling MCT it is
also needed to get ARM Architected Timers working, because they both
share some common hardware blocks (global system counter).
This patchset enables support for ARM Architected Timer driver together
with a standard Exynos MultiCore Timer driver, which is kept as a default
timer source on ARM 32bit platforms. Support for ARM architected timers
is essential for enabling proper KVM support on those platforms.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v3:
- checked the status of arch timer registers on all Exynos5 SoCs,
dropped 'not-fw-configured' property on most of them as requested
by Marc Zyngier
- dropped enabling arch timers on Exynos3250, as there is no benefit from
that (none of the Exynos3250-based board boots in HYP mode)
v2: https://www.spinics.net/lists/arm-kernel/msg751017.html
- dropped MCT patches (merged to v5.1)
- dropped timer priority change patch (merged to v5.3)
v1: https://www.spinics.net/lists/arm-kernel/msg751018.html
- initial version, covers some MCT patches previously sent as a timer
rework for Exynos5433
Patch summary:
Marek Szyprowski (2):
ARM: dts: exynos: Add support ARM architected timers on Exynos5
ARM: exynos: Enable support for ARM architected timers
arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 ++++
arch/arm/boot/dts/exynos54xx.dtsi | 9 +++++++++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
arch/arm/mach-exynos/Kconfig | 1 +
4 files changed, 18 insertions(+)
--
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 3/8] coresight: etm4x: Add missing API to set EL match on address filters
From: Mike Leach @ 2019-08-28 12:10 UTC (permalink / raw)
To: Leo Yan; +Cc: Coresight ML, linux-arm-kernel, Mathieu Poirier
In-Reply-To: <20190828025313.GC26133@leoy-ThinkPad-X240s>
Hi Leo,
On Wed, 28 Aug 2019 at 03:53, Leo Yan <leo.yan@linaro.org> wrote:
>
> On Mon, Aug 19, 2019 at 09:57:15PM +0100, Mike Leach wrote:
> > TRCACATRn registers have match bits for secure and non-secure exception
> > levels which are not accessible by the sysfs API.
> > This adds a new sysfs parameter to enable this - addr_exlevel_s_ns.
> >
> > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > ---
> > .../coresight/coresight-etm4x-sysfs.c | 39 +++++++++++++++++++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > index fa1d6a938f6c..7eab5d7d0b62 100644
> > --- a/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > +++ b/drivers/hwtracing/coresight/coresight-etm4x-sysfs.c
> > @@ -1233,6 +1233,44 @@ static ssize_t addr_context_store(struct device *dev,
> > }
> > static DEVICE_ATTR_RW(addr_context);
> >
> > +static ssize_t addr_exlevel_s_ns_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->addr_idx;
> > + val = BMVAL(config->addr_acc[idx], 14, 8);
> > + spin_unlock(&drvdata->spinlock);
> > + return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> > +}
> > +
> > +static ssize_t addr_exlevel_s_ns_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t size)
> > +{
> > + u8 idx;
> > + unsigned long val;
> > + struct etmv4_drvdata *drvdata = dev_get_drvdata(dev->parent);
> > + struct etmv4_config *config = &drvdata->config;
> > +
> > + if (kstrtoul(buf, 16, &val))
> > + return -EINVAL;
> > +
> > + spin_lock(&drvdata->spinlock);
> > + idx = config->addr_idx;
> > + /* clear Exlevel_ns & Exlevel_s bits[14:12, 11:8] */
> > + config->addr_acc[idx] &= ~(GENMASK(14, 8));
> > + config->addr_acc[idx] |= (val << 8);
>
> I think it needs to check if 'val' is out of bound, which only can have
> value which is less than 7 bits (finally set for bit 8 to bit 14).
>
Agreed.
> Just curious, if the CPU runs in non-secure mode (e.g. NS-EL1 in
> kernel mode), does it have permission to access EXLEVEL_S field? I
> don't see the spec give info for this.
>
This field can be accessed in NS mode - the permissions for tracing
secure state are given in the authentication signals - this register
only controls matching in particular states.
If there is no permission to trace secure state, then the EXLEVEL_S
field will have no effect as trace will automatically be disabled
should the PE transit to secure state.
Thanks
Mike
> Thanks,
> Leo Yan
>
> > + spin_unlock(&drvdata->spinlock);
> > + return size;
> > +}
> > +static DEVICE_ATTR_RW(addr_exlevel_s_ns);
> > +
> > static ssize_t seq_idx_show(struct device *dev,
> > struct device_attribute *attr,
> > char *buf)
> > @@ -2038,6 +2076,7 @@ static struct attribute *coresight_etmv4_attrs[] = {
> > &dev_attr_addr_stop.attr,
> > &dev_attr_addr_ctxtype.attr,
> > &dev_attr_addr_context.attr,
> > + &dev_attr_addr_exlevel_s_ns.attr,
> > &dev_attr_seq_idx.attr,
> > &dev_attr_seq_state.attr,
> > &dev_attr_seq_event.attr,
> > --
> > 2.17.1
> >
> > _______________________________________________
> > CoreSight mailing list
> > CoreSight@lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/coresight
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
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-28 12:23 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: <CAK7LNAQ_nQcBt=xH1-h+=co85mTxFgbe+_46Gu4LaNsDSm+kYA@mail.gmail.com>
On Wed, Aug 28, 2019 at 7:53 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Hi Christoph,
>
> On Tue, Aug 27, 2019 at 8:55 PM Christoph Hellwig <hch@lst.de> wrote:
> >
> > On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> > > Yes, this makes my driver working again
> > > when CONFIG_DMA_CMA=y.
> > >
> > >
> > > If I apply the following, my driver gets back working
> > > irrespective of CONFIG_DMA_CMA.
> >
> > That sounds a lot like the device simply isn't 64-bit DMA capable, and
> > previously always got CMA allocations under the limit it actually
> > supported. I suggest that you submit this quirk to the mmc maintainers.
>
>
> I tested v5.2 and my MMC host controller works with
> dma_address that exceeds 32-bit physical address.
>
> So, I believe my MMC device is 64-bit DMA capable.
>
> I am still looking into the code
> to find out what was changed.
I retract this comment.
Prior to bd2e75633c8012fc8a7431c82fda66237133bf7e,
the descriptor table for ADMA is placed within the
32-bit phys address range, not exceeds the 32-bit limit.
Probably, my device is not 64-bit capable.
I will talk to the hardware engineer,
and check the hardware spec just in case.
Thanks.
--
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
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