* Re: [UNVERIFIED SENDER] Re: [PATCH 0/9] arm64: Stolen time support
From: Steven Price @ 2019-08-16 10:23 UTC (permalink / raw)
To: Alexander Graf, Marc Zyngier
Cc: kvm, linux-doc, Catalin Marinas, linux-kernel, Russell King,
Paolo Bonzini, Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <bda4e0f7-e5f4-32af-e998-00b6240b5260@amazon.com>
On 14/08/2019 15:52, Alexander Graf wrote:
>
>
> On 14.08.19 16:19, Marc Zyngier wrote:
>> On Wed, 14 Aug 2019 14:02:25 +0100,
>> Alexander Graf <graf@amazon.com> wrote:
>>>
>>>
>>>
>>> On 05.08.19 15:06, Steven Price wrote:
>>>> On 03/08/2019 19:05, Marc Zyngier wrote:
>>>>> On Fri, 2 Aug 2019 15:50:08 +0100
>>>>> Steven Price <steven.price@arm.com> wrote:
>>>>>
>>>>> Hi Steven,
>>>>>
>>>>>> This series add support for paravirtualized time for arm64 guests and
>>>>>> KVM hosts following the specification in Arm's document DEN 0057A:
>>>>>>
>>>>>> https://developer.arm.com/docs/den0057/a
>>>>>>
>>>>>> It implements support for stolen time, allowing the guest to
>>>>>> identify time when it is forcibly not executing.
>>>>>>
>>>>>> It doesn't implement support for Live Physical Time (LPT) as there
>>>>>> are
>>>>>> some concerns about the overheads and approach in the above
>>>>>> specification, and I expect an updated version of the
>>>>>> specification to
>>>>>> be released soon with just the stolen time parts.
>>>>>
>>>>> Thanks for posting this.
>>>>>
>>>>> My current concern with this series is around the fact that we
>>>>> allocate
>>>>> memory from the kernel on behalf of the guest. It is the first example
>>>>> of such thing in the ARM port, and I can't really say I'm fond of it.
>>>>>
>>>>> x86 seems to get away with it by having the memory allocated from
>>>>> userspace, why I tend to like more. Yes, put_user is more
>>>>> expensive than a straight store, but this isn't done too often either.
>>>>>
>>>>> What is the rational for your current approach?
>>>>
>>>> As I see it there are 3 approaches that can be taken here:
>>>>
>>>> 1. Hypervisor allocates memory and adds it to the virtual machine. This
>>>> means that everything to do with the 'device' is encapsulated behind
>>>> the
>>>> KVM_CREATE_DEVICE / KVM_[GS]ET_DEVICE_ATTR ioctls. But since we want
>>>> the
>>>> stolen time structure to be fast it cannot be a trapping region and has
>>>> to be backed by real memory - in this case allocated by the host
>>>> kernel.
>>>>
>>>> 2. Host user space allocates memory. Similar to above, but this time
>>>> user space needs to manage the memory region as well as the usual
>>>> KVM_CREATE_DEVICE dance. I've no objection to this, but it means
>>>> kvmtool/QEMU needs to be much more aware of what is going on (e.g. how
>>>> to size the memory region).
>>>
>>> You ideally want to get the host overhead for a VM to as little as you
>>> can. I'm not terribly fond of the idea of reserving a full page just
>>> because we're too afraid of having the guest donate memory.
>>
>> Well, reduce the amount of memory you give to the guest by one page,
>> and allocate that page to the stolen time device. Problem solved!
>>
>> Seriously, if you're worried about the allocation of a single page,
>> you should first look at how many holes we have in the vcpu structure,
>> for example (even better, with the 8.4 NV patches applied). Just
>> fixing that would give you that page back *per vcpu*.
>
> I'm worried about additional memory slots, about fragmenting the
> cachable guest memory regions, about avoidable HV taxes.
>
> I think we need to distinguish here between the KVM implementation and
> the hypervisor/guest interface. Just because in KVM we can save overhead
> today doesn't mean that the HV interface should be built around the
> assumption that "memory is free".
The HV interface just requires that the host provides some memory for
the structures to live in. The memory can be adjacent (or even within)
the normal memory of the guest. The only requirement is that the guest
isn't told to use this memory for normal allocations (i.e. it should
either be explicitly reserved or just not contained within the normal
memory block).
>>
>>>> 3. Guest kernel "donates" the memory to the hypervisor for the
>>>> structure. As far as I'm aware this is what x86 does. The problems I
>>>> see
>>>> this approach are:
>>>>
>>>> a) kexec becomes much more tricky - there needs to be a disabling
>>>> mechanism for the guest to stop the hypervisor scribbling on memory
>>>> before starting the new kernel.
>>>
>>> I wouldn't call "quiesce a device" much more tricky. We have to do
>>> that for other devices as well today.
>>
>> And since there is no standard way of doing it, we keep inventing
>> weird and wonderful ways of doing so -- cue the terrible GICv3 LPI
>> situation, and all the various hacks to keep existing IOMMU mappings
>> around across firmware/kernel handovers as well as kexec.
>
> Well, the good news here is that we don't have to keep it around ;).
>
>>
>>>
>>>> b) If there is more than one entity that is interested in the
>>>> information (e.g. firmware and kernel) then this requires some form of
>>>> arbitration in the guest because the hypervisor doesn't want to have to
>>>> track an arbitrary number of regions to update.
>>>
>>> Why would FW care?
>>
>> Exactly. It doesn't care. Not caring means it doesn't know about the
>> page the guest has allocated for stolen time, and starts using it for
>> its own purposes. Hello, memory corruption. Same thing goes if you
>> reboot into a non stolen time aware kernel.
>
> If you reboot, you go via the vcpu reset path which clears the map, no?
> Same goes for FW entry. If you enter firmware that does not set up the
> map, you never see it.
Doing this per-vcpu implies you are probably going to have to allocate
an entire page per vcpu. Because it's entirely possible for a guest to
reset an individual vcpu. Or at the least there's some messy reference
counting going on here.
Having a region of memory provided by the host means the structures can
be packed and there's nothing to be done in the reset path.
>>
>>>
>>>> c) Performance can suffer if the host kernel doesn't have a suitably
>>>> aligned/sized area to use. As you say - put_user() is more expensive.
>>>
>>> Just define the interface to always require natural alignment when
>>> donating a memory location?
>>>
>>>> The structure is updated on every return to the VM.
>>>
>>> If you really do suffer from put_user(), there are alternatives. You
>>> could just map the page on the registration hcall and then leave it
>>> pinned until the vcpu gets destroyed again.
>>
>> put_user() should be cheap enough. It is one of the things we tend to
>> optimise anyway. And yes, worse case, we pin the page.
>>
>>>
>>>> Of course x86 does prove the third approach can work, but I'm not sure
>>>> which is actually better. Avoid the kexec cancellation requirements was
>>>> the main driver of the current approach. Although many of the
>>>
>>> I really don't understand the problem with kexec cancellation. Worst
>>> case, let guest FW set it up for you and propagate only the address
>>> down via ACPI/DT. That way you can mark the respective memory as
>>> reserved too.
>>
>> We already went down that road with the LPI hack. I'm not going there
>> again if we can avoid it. And it turn out that we can. Just allocate
>> the stolen time page as a separate memblock, give it to KVM for that
>> purpose.
>>
>> Your suggestion of letting the guest firmware set something up only
>> works if whatever you're booting after that understands it. If it
>> doesn't, you're screwed.
>
> Why? For UEFI, mark the region as reserved in the memory map. For DT,
> just mark it straight on reserved.
>
> That said, I'm not advocating for doing it in the FW. I think this can
> be solved really easily with a simple guest driver to enable and a vcpu
> reset hook to disable the map.
>
>>
>>> But even with a Linux only mechanism, just take a look at
>>> arch/x86/kernel/kvmclock.c. All they do to remove the map is to hook
>>> into machine_crash_shutdown() and machine_shutdown().
>>
>> I'm not going to take something that is Linux specific. It has to work
>> for all guests, at all times, whether they know about the hypervisor
>> service or not.
>
> If they don't know about the HV service, they don't register the writer,
> so they don't see corruption.
>
> If they know about the HV service and they don't support kexec, they
> don't have to worry because a vcpu reset should also clear the map.
>
> If they do support kexec, they already have a mechanism to quiesce devices.
>
> So I don't understand how this is Linux specific? The question was Linux
> specific, so I answered with precedence to show that disabling on kexec
> is not all that hard :).
My concern is more around a something like Jailhouse as a
guest-hypervisor. There Linux gives up CPUs to run another OS. This
hand-off of a CPU is much easier if there's just a structure in memory
somewhere which doesn't move.
The kexec case like you say can be handled as a device to quiesce.
I don't think either scheme is unworkable, but I do think getting the
host to provide the memory is easier for both guest and host. Marc had a
good point that getting user space to allocate the memory is probably
preferable to getting the host kernel to do so, so I'm reworking the
code to do that.
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 02/10] PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode
From: Andrew Murray @ 2019-08-16 10:20 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, arnd@arndb.de,
gregkh@linuxfoundation.org, jingoohan1@gmail.com, Z.q. Hou,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, Leo Li, M.h. Lian,
robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, bhelgaas@google.com, kishon@ti.com,
shawnguo@kernel.org, Mingkai Hu
In-Reply-To: <AM5PR04MB329973845D6396624AFDE547F5AF0@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Fri, Aug 16, 2019 at 02:58:31AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年8月15日 19:54
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: jingoohan1@gmail.com; gustavo.pimentel@synopsys.com;
> > bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org;
> > 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
> > Subject: Re: [PATCH 02/10] PCI: designware-ep: Add the doorbell mode of
> > MSI-X in EP mode
> >
> > On Thu, Aug 15, 2019 at 04:37:08PM +0800, Xiaowei Bao wrote:
> > > Add the doorbell mode of MSI-X in EP mode.
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-designware-ep.c | 14 ++++++++++++++
> > > drivers/pci/controller/dwc/pcie-designware.h | 14 ++++++++++++++
> > > 2 files changed, 28 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > index 75e2955..e3a7cdf 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > @@ -454,6 +454,20 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep
> > *ep, u8 func_no,
> > > return 0;
> > > }
> > >
> > > +int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8
> > func_no,
> > > + u16 interrupt_num)
> > > +{
> > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + u32 msg_data;
> > > +
> > > + msg_data = (func_no << PCIE_MSIX_DOORBELL_PF_SHIFT) |
> > > + (interrupt_num - 1);
> > > +
> > > + dw_pcie_writel_dbi(pci, PCIE_MSIX_DOORBELL, msg_data);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > u16 interrupt_num)
> >
> > Have I understood correctly that the hardware provides an alternative
> > mechanism that allows for raising MSI-X interrupts without the bother of
> > reading the capabilities registers?
> Yes, the hardware provide two way to MSI-X, please check the page 492 of
> DWC_pcie_dm_registers_4.30 Menu.
> MSIX_DOORBELL_OFF on page 492 0x948 Description: MSI-X Doorbell Register....>
Thanks for the reference.
> >
> > If so is there any good reason to keep dw_pcie_ep_raise_msix_irq? (And thus
> > use it in dw_plat_pcie_ep_raise_irq also)?
> I am not sure, but I think the dw_pcie_ep_raise_msix_irq function is not correct,
> because I think we can't get the MSIX table from the address ep->phys_base + tbl_addr,
> but I also don't know where I can get the correct MSIX table.
Well it looks like this function is used by snps,dw-pcie-ep and snps,dw-pcie,
perhaps the doorbell mode isn't available on that hardware.
> >
> >
> > > {
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > index 2b291e8..cd903e9 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > @@ -88,6 +88,11 @@
> > > #define PCIE_MISC_CONTROL_1_OFF 0x8BC
> > > #define PCIE_DBI_RO_WR_EN BIT(0)
> > >
> > > +#define PCIE_MSIX_DOORBELL 0x948
> > > +#define PCIE_MSIX_DOORBELL_PF_SHIFT 24
> > > +#define PCIE_MSIX_DOORBELL_VF_SHIFT 16
> > > +#define PCIE_MSIX_DOORBELL_VF_ACTIVE BIT(15)
> >
> > The _VF defines are not used, I'd suggest removing them.
> In fact, I will add the SRIOV support in this file, the SRIOV feature have verified
> In my board, but I need wait the EP framework SRIOV patch merge,
> so I defined these two macros.
I'd suggest adding the VF macros along with the SRIOV feature.
Thanks,
Andrew Murray
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > +
> > > /*
> > > * iATU Unroll-specific register definitions
> > > * From 4.80 core version the address translation will be made by
> > > unroll @@ -399,6 +404,8 @@ int dw_pcie_ep_raise_msi_irq(struct
> > dw_pcie_ep *ep, u8 func_no,
> > > u8 interrupt_num);
> > > int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > u16 interrupt_num);
> > > +int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8
> > func_no,
> > > + u16 interrupt_num);
> > > void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
> > > #else static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep) @@
> > > -431,6 +438,13 @@ static inline int dw_pcie_ep_raise_msix_irq(struct
> > dw_pcie_ep *ep, u8 func_no,
> > > return 0;
> > > }
> > >
> > > +static inline int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep
> > *ep,
> > > + u8 func_no,
> > > + u16 interrupt_num)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
> > > pci_barno bar) { }
> > > --
> > > 2.9.5
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=02%
> > 7C0
> > >
> > 1%7Cxiaowei.bao%40nxp.com%7C8489493003bb48a0139d08d721773972%
> > 7C686ea1d
> > >
> > 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637014668369499298&sd
> > ata=dyrXB
> > >
> > avljJBFUSNXW7K%2FRoXvwfWTE%2FoU2KMd1bZkJow%3D&reserved=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 v2 2/2] iommu/arm-smmu-v3: add nr_ats_masters for quickly check
From: Leizhen (ThunderTown) @ 2019-08-16 10:12 UTC (permalink / raw)
To: Will Deacon
Cc: Jean-Philippe Brucker, Jean-Philippe Brucker, Joerg Roedel,
John Garry, linux-kernel, iommu, Robin Murphy, linux-arm-kernel
In-Reply-To: <20190815152313.apa2d5rzhqa34l7l@willie-the-truck>
On 2019/8/15 23:23, Will Deacon wrote:
> On Thu, Aug 15, 2019 at 01:44:39PM +0800, Zhen Lei wrote:
>> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a
>> smmu domain does not contain any ats master, the operations of
>> arm_smmu_atc_inv_to_cmd() and lock protection in arm_smmu_atc_inv_domain()
>> are always executed. This will impact performance, especially in
>> multi-core and stress scenarios. For my FIO test scenario, about 8%
>> performance reduced.
>>
>> In fact, we can use a struct member to record how many ats masters that
>> the smmu contains. And check that without traverse the list and check all
>> masters one by one in the lock protection.
>>
>> Fixes: 9ce27afc0830 ("iommu/arm-smmu-v3: Add support for PCI ATS")
>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 29056d9bb12aa01..154334d3310c9b8 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -631,6 +631,7 @@ struct arm_smmu_domain {
>>
>> struct io_pgtable_ops *pgtbl_ops;
>> bool non_strict;
>> + int nr_ats_masters;
>>
>> enum arm_smmu_domain_stage stage;
>> union {
>> @@ -1531,7 +1532,16 @@ static int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain,
>> struct arm_smmu_cmdq_ent cmd;
>> struct arm_smmu_master *master;
>>
>> - if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS))
>> + /*
>> + * The protectiom of spinlock(&iommu_domain->devices_lock) is omitted.
>> + * Because for a given master, its map/unmap operations should only be
>> + * happened after it has been attached and before it has been detached.
>> + * So that, if at least one master need to be atc invalidated, the
>> + * value of smmu_domain->nr_ats_masters can not be zero.
>> + *
>> + * This can alleviate performance loss in multi-core scenarios.
>> + */
>
> I find this reasoning pretty dubious, since I think you're assuming that
> an endpoint cannot issue speculative ATS translation requests once its
> ATS capability is enabled. That said, I think it also means we should enable
> ATS in the STE *before* enabling it in the endpoint -- the current logic
> looks like it's the wrong way round to me (including in detach()).
>
> Anyway, these speculative translations could race with a concurrent unmap()
> call and end up with the ATC containing translations for unmapped pages,
> which I think we should try to avoid.
>
> Did the RCU approach not work out? You could use an rwlock instead as a
> temporary bodge if the performance doesn't hurt too much.
OK, I will try rwlock first, this does not change the original code logic.
>
> Alternatively... maybe we could change the attach flow to do something
> like:
>
> enable_ats_in_ste(master);
> enable_ats_at_pcie_endpoint(master);
> spin_lock(devices_lock)
> add_to_device_list(master);
> nr_ats_masters++;
> spin_unlock(devices_lock);
> invalidate_atc(master);
>
> in which case, the concurrent unmapper will be doing something like:
>
> issue_tlbi();
> smp_mb();
> if (READ_ONCE(nr_ats_masters)) {
> ...
> }
>
> and I *think* that means that either the unmapper will see the
> nr_ats_masters update and perform the invalidation, or they'll miss
> the update but the attach will invalidate the ATC /after/ the TLBI
> in the command queue.
>
> Also, John's idea of converting this stuff over to my command batching
> mechanism should help a lot if we can defer this to sync time using the
> gather structure. Maybe an rwlock would be alright for that. Dunno.
>
> 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 4/4] arm64: dts: imx8mm: Enable cpu-idle driver
From: Anson Huang @ 2019-08-16 10:08 UTC (permalink / raw)
To: Daniel Lezcano, robh+dt@kernel.org, mark.rutland@arm.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, tglx@linutronix.de,
Leonard Crestez, Daniel Baluta, Jacky Bai, Jun Li,
l.stach@pengutronix.de, Abel Vesa, ccaione@baylibre.com,
andrew.smirnov@gmail.com, angus@akkea.ca, agx@sigxcpu.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <e62d26b9-8c9b-644f-d2b3-485586e07e35@linaro.org>
Hi, Daniel/Shawn
> On 16/08/2019 02:38, Anson Huang wrote:
> > Enable i.MX8MM cpu-idle using generic ARM cpu-idle driver, 2 states
> > are supported, details as below:
> >
> > root@imx8mmevk:~# cat
> /sys/devices/system/cpu/cpu0/cpuidle/state0/name
> > WFI
> > root@imx8mmevk:~# cat
> > /sys/devices/system/cpu/cpu0/cpuidle/state0/usage
> > 3973
> > root@imx8mmevk:~# cat
> /sys/devices/system/cpu/cpu0/cpuidle/state1/name
> > cpu-pd-wait
> > root@imx8mmevk:~# cat
> > /sys/devices/system/cpu/cpu0/cpuidle/state1/usage
> > 6647
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>
> Hi Anson,
>
> I've applied the patches 1-3 but this one does not apply.
Thanks.
>
> You can either respin it against tip/timers/core and take it through Shawn's
> tree. If the later, you can add my Acked-by.
Hi, Shawn
Can you take this patch and add below Acked-by? It should can be applied to your tree directly.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Thanks,
Anson
_______________________________________________
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 4/4] arm64: dts: imx8mm: Enable cpu-idle driver
From: Daniel Lezcano @ 2019-08-16 9:59 UTC (permalink / raw)
To: Anson Huang, robh+dt, mark.rutland, shawnguo, s.hauer, kernel,
festevam, tglx, leonard.crestez, daniel.baluta, ping.bai, jun.li,
l.stach, abel.vesa, ccaione, andrew.smirnov, angus, agx,
devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
In-Reply-To: <1565915925-21009-4-git-send-email-Anson.Huang@nxp.com>
On 16/08/2019 02:38, Anson Huang wrote:
> Enable i.MX8MM cpu-idle using generic ARM cpu-idle driver, 2 states
> are supported, details as below:
>
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/name
> WFI
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/usage
> 3973
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state1/name
> cpu-pd-wait
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state1/usage
> 6647
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Hi Anson,
I've applied the patches 1-3 but this one does not apply.
You can either respin it against tip/timers/core and take it through
Shawn's tree. If the later, you can add my Acked-by.
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Jernej Škrabec @ 2019-08-16 9:50 UTC (permalink / raw)
To: linux-sunxi, peron.clem
Cc: Mark Rutland, devicetree, linux-kernel, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, clabbe.montjoie, linux-arm-kernel
In-Reply-To: <CAJiuCcfASQriPLMuwuDCn9bU=_8q4jL+KkPo8NmMrrYpOqy2qA@mail.gmail.com>
Dne sreda, 14. avgust 2019 ob 15:28:53 CEST je Clément Péron napisal(a):
> Hi,
>
> On Wed, 14 Aug 2019 at 15:20, Corentin Labbe <clabbe.montjoie@gmail.com>
wrote:
> > On Mon, Aug 12, 2019 at 12:56:56PM +0200, Jernej Škrabec wrote:
> > > Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe
napisal(a):
> > > > This patch adds the evaluation variant of the model A of the PineH64.
> > > > The model A has the same size of the pine64 and has a PCIE slot.
> > > >
> > > > The only devicetree difference with current pineH64, is the PHY
> > > > regulator.
> > >
> > > I have Model A board which also needs ddc-en-gpios property for HDMI
> > > connector in order for HDMI to work correctly. Otherwise it will just
> > > use 1024x768 resolution. Can you confirm that?
>
> Schematics Rev A:
> http://files.pine64.org/doc/Pine%20H64/Pine%20H64%20Ver1.1-20180104.pdf
>
> Rev B:
> http://files.pine64.org/doc/Pine%20H64/PINE-H6-model-B-20181212-schematic.pd
> f
>
> There is a DDC_EN on REV A not on REV B
>
> Regards,
> Clément
>
> > > Best regards,
> > > Jernej
> >
> > Sorry I didnt use at all video stuff (like HDMI), so I cannot answer now.
> >
> > Could you send me a patch against my future v2 and I could test
> > with/without.
I don't have access to my Model A board currently, but this should suffice:
&connector {
ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
};
Best regards,
Jernej
> >
> > Regards
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscribe@googlegroups.com. To view this discussion on the
> > web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20190814132001.GC24324%40Re
> > d.
_______________________________________________
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 02/18] dt-bindings: thermal: add binding document for h6 thermal controller
From: Maxime Ripard @ 2019-08-16 9:47 UTC (permalink / raw)
To: Frank Lee
Cc: Mark Rutland, devicetree, Linux PM, Greg Kroah-Hartman,
Daniel Lezcano, Linux Kernel Mailing List, Eduardo Valentin,
Chen-Yu Tsai, Rob Herring, Jonathan.Cameron,
Mauro Carvalho Chehab, rui.zhang, David Miller, Linux ARM
In-Reply-To: <CAEExFWswLiFknVpBEKF9c5yoFvvA4np-ivWYkQLcteYoM8qjfg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3885 bytes --]
On Tue, Aug 13, 2019 at 07:40:44AM +0800, Frank Lee wrote:
> On Mon, Aug 12, 2019 at 4:56 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Sat, Aug 10, 2019 at 05:28:13AM +0000, Yangtao Li wrote:
> > > This patch adds binding document for allwinner h6 thermal controller.
> > >
> > > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > > ---
> > > .../bindings/thermal/sun8i-thermal.yaml | 79 +++++++++++++++++++
> > > 1 file changed, 79 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml b/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> > > new file mode 100644
> > > index 000000000000..e0973199ba3c
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
> >
> > We've used so far for the schemas the first compatible to introduce
> > that controller as the filename, we should be consistent here. In that
> > case that would be allwinner,sun8i-a23-ths.yaml
> >
> > > @@ -0,0 +1,79 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/thermal/sun8i-thermal.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Allwinner SUN8I Thermal Controller Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Yangtao Li <tiny.windzz@gmail.com>
> > > +
> > > +description: |-
> > > + This describes the device tree binding for the Allwinner thermal
> > > + controller which measures the on-SoC temperatures.
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - allwinner,sun50i-h6-ths
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + resets:
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + maxItems: 1
> > > +
> > > + clock-names:
> > > + const: bus
> > > +
> > > + "#thermal-sensor-cells":
> > > + const: 1
> > > +
> > > + nvmem-cells:
> >
> > You need a maxItems here too
> >
> > > + description: ths calibrate data
> >
> > What about something like this:
> >
> > Calibration data for the thermal sensor
> >
> > > +
> > > + nvmem-cell-names:
> > > + const: calib
> >
> > I'm not sure we need a abbreviation here, calibration would be more
> > explicit
> >
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - reset
> > > + - clocks
> > > + - clock-names
> > > + - interrupts
> > > + - "#thermal-sensor-cells"
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + ths: ths@5070400 {
> > > + compatible = "allwinner,sun50i-h6-ths";
> > > + reg = <0x05070400 0x100>;
> > > + clocks = <&ccu CLK_BUS_THS>;
> > > + clock-names = "bus";
> > > + resets = <&ccu RST_BUS_THS>;
> > > + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
> >
> > Those examples won't compile.
>
> Emmm, I have some questions about this.
> I added this information and it can be compiled.
With your patch applied,
$ ARCH=arm DT_SCHEMA_FILES=Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml make -j4 dt_binding_check
CHKDT Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml
DTC Documentation/devicetree/bindings/thermal/sun8i-thermal.example.dt.yaml
Error: Documentation/devicetree/bindings/thermal/sun8i-thermal.example.dts:20.28-29 syntax error
FATAL ERROR: Unable to parse input tree
make[2]: *** [scripts/Makefile.lib:299: Documentation/devicetree/bindings/thermal/sun8i-thermal.example.dt.yaml] Error 1
make[1]: *** [/home/max/Work/src/linux/Makefile:1286: dt_binding_check] Error 2
make: *** [/home/max/Work/src/linux/Makefile:179: sub-make] Error 2
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/10] PCI: designware-ep: Add multiple PFs support for DWC
From: Andrew Murray @ 2019-08-16 9:44 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, gregkh@linuxfoundation.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, devicetree@vger.kernel.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM5PR04MB3299396885AC4B54B9E8D0AEF5AF0@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Fri, Aug 16, 2019 at 02:55:41AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年8月15日 19:32
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: jingoohan1@gmail.com; gustavo.pimentel@synopsys.com;
> > bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> > lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org;
> > 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
> > Subject: Re: [PATCH 01/10] PCI: designware-ep: Add multiple PFs support for
> > DWC
> >
> > On Thu, Aug 15, 2019 at 04:37:07PM +0800, Xiaowei Bao wrote:
> > > Add multiple PFs support for DWC, different PF have different config
> > > space, we use pf-offset property which get from the DTS to access the
> > > different pF config space.
> >
> > Thanks for the patch. I haven't seen a cover letter for this series, is there one
> > missing?
> Maybe I miss, I will add you to review next time, thanks a lot for your comments.
> >
> >
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-designware-ep.c | 97
> > +++++++++++++---------
> > > drivers/pci/controller/dwc/pcie-designware.c | 105
> > ++++++++++++++++++++++--
> > > drivers/pci/controller/dwc/pcie-designware.h | 10 ++-
> > > include/linux/pci-epc.h | 1 +
> > > 4 files changed, 164 insertions(+), 49 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > index 2bf5a35..75e2955 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > @@ -19,12 +19,14 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > > pci_epc_linkup(epc);
> > > }
> > >
> > > -static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
> > bar,
> > > - int flags)
> > > +static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
> > > + enum pci_barno bar, int flags)
> > > {
> > > u32 reg;
> > > + struct pci_epc *epc = pci->ep.epc;
> > > + u32 pf_base = func_no * epc->pf_offset;
> > >
> > > - reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> > > + reg = pf_base + PCI_BASE_ADDRESS_0 + (4 * bar);
> >
> > I think I'd rather see this arithmetic (and the one for determining pf_base)
> > inside a macro or inline header function. This would make this code more
> > readable and reduce the chances of an error by avoiding duplication of code.
> >
> > For example look at cdns_pcie_ep_fn_writeb and
> > ROCKCHIP_PCIE_EP_FUNC_BASE for examples of other EP drivers that do
> > this.
> Agree, this looks fine, thanks a lot for your comments, I will use this way to access
> the registers in next version patch.
> >
> >
> > > dw_pcie_dbi_ro_wr_en(pci);
> > > dw_pcie_writel_dbi2(pci, reg, 0x0);
> > > dw_pcie_writel_dbi(pci, reg, 0x0);
> > > @@ -37,7 +39,12 @@ static void __dw_pcie_ep_reset_bar(struct dw_pcie
> > > *pci, enum pci_barno bar,
> > >
> > > void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar) {
> > > - __dw_pcie_ep_reset_bar(pci, bar, 0);
> > > + u8 func_no, funcs;
> > > +
> > > + funcs = pci->ep.epc->max_functions;
> > > +
> > > + for (func_no = 0; func_no < funcs; func_no++)
> > > + __dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
> > > }
> > >
> > > static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie *pci, u8 cap_ptr,
> > > @@ -78,28 +85,29 @@ static int dw_pcie_ep_write_header(struct pci_epc
> > > *epc, u8 func_no, {
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + u32 pf_base = func_no * epc->pf_offset;
> > >
> > > dw_pcie_dbi_ro_wr_en(pci);
> > > - dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
> > > - dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
> > > - dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
> > > - dw_pcie_writeb_dbi(pci, PCI_CLASS_PROG, hdr->progif_code);
> > > - dw_pcie_writew_dbi(pci, PCI_CLASS_DEVICE,
> > > + dw_pcie_writew_dbi(pci, pf_base + PCI_VENDOR_ID, hdr->vendorid);
> > > + dw_pcie_writew_dbi(pci, pf_base + PCI_DEVICE_ID, hdr->deviceid);
> > > + dw_pcie_writeb_dbi(pci, pf_base + PCI_REVISION_ID, hdr->revid);
> > > + dw_pcie_writeb_dbi(pci, pf_base + PCI_CLASS_PROG, hdr->progif_code);
> > > + dw_pcie_writew_dbi(pci, pf_base + PCI_CLASS_DEVICE,
> > > hdr->subclass_code | hdr->baseclass_code << 8);
> > > - dw_pcie_writeb_dbi(pci, PCI_CACHE_LINE_SIZE,
> > > + dw_pcie_writeb_dbi(pci, pf_base + PCI_CACHE_LINE_SIZE,
> > > hdr->cache_line_size);
> > > - dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_VENDOR_ID,
> > > + dw_pcie_writew_dbi(pci, pf_base + PCI_SUBSYSTEM_VENDOR_ID,
> > > hdr->subsys_vendor_id);
> > > - dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
> > > - dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
> > > + dw_pcie_writew_dbi(pci, pf_base + PCI_SUBSYSTEM_ID,
> > hdr->subsys_id);
> > > + dw_pcie_writeb_dbi(pci, pf_base + PCI_INTERRUPT_PIN,
> > > hdr->interrupt_pin);
> > > dw_pcie_dbi_ro_wr_dis(pci);
> > >
> > > return 0;
> > > }
> > >
> > > -static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum
> > pci_barno bar,
> > > - dma_addr_t cpu_addr,
> > > +static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> > > + enum pci_barno bar, dma_addr_t cpu_addr,
> > > enum dw_pcie_as_type as_type)
> > > {
> > > int ret;
> > > @@ -112,7 +120,7 @@ static int dw_pcie_ep_inbound_atu(struct
> > dw_pcie_ep *ep, enum pci_barno bar,
> > > return -EINVAL;
> > > }
> > >
> > > - ret = dw_pcie_prog_inbound_atu(pci, free_win, bar, cpu_addr,
> > > + ret = dw_pcie_prog_inbound_atu(pci, func_no, free_win, bar,
> > > +cpu_addr,
> > > as_type);
> > > if (ret < 0) {
> > > dev_err(pci->dev, "Failed to program IB window\n"); @@ -125,7
> > > +133,8 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep,
> > enum pci_barno bar,
> > > return 0;
> > > }
> > >
> > > -static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, phys_addr_t
> > > phys_addr,
> > > +static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> > > + phys_addr_t phys_addr,
> > > u64 pci_addr, size_t size)
> > > {
> > > u32 free_win;
> > > @@ -137,8 +146,8 @@ static int dw_pcie_ep_outbound_atu(struct
> > dw_pcie_ep *ep, phys_addr_t phys_addr,
> > > return -EINVAL;
> > > }
> > >
> > > - dw_pcie_prog_outbound_atu(pci, free_win, PCIE_ATU_TYPE_MEM,
> > > - phys_addr, pci_addr, size);
> > > + dw_pcie_prog_ep_outbound_atu(pci, func_no, free_win,
> > PCIE_ATU_TYPE_MEM,
> > > + phys_addr, pci_addr, size);
> > >
> > > set_bit(free_win, ep->ob_window_map);
> > > ep->outbound_addr[free_win] = phys_addr; @@ -154,7 +163,7 @@
> > static
> > > void dw_pcie_ep_clear_bar(struct pci_epc *epc, u8 func_no,
> > > enum pci_barno bar = epf_bar->barno;
> > > u32 atu_index = ep->bar_to_atu[bar];
> > >
> > > - __dw_pcie_ep_reset_bar(pci, bar, epf_bar->flags);
> > > + __dw_pcie_ep_reset_bar(pci, func_no, bar, epf_bar->flags);
> > >
> > > dw_pcie_disable_atu(pci, atu_index, DW_PCIE_REGION_INBOUND);
> > > clear_bit(atu_index, ep->ib_window_map); @@ -170,14 +179,16 @@
> > > static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no,
> > > size_t size = epf_bar->size;
> > > int flags = epf_bar->flags;
> > > enum dw_pcie_as_type as_type;
> > > - u32 reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> > > + u32 pf_base = func_no * epc->pf_offset;
> > > + u32 reg = PCI_BASE_ADDRESS_0 + (4 * bar) + pf_base;
> > >
> > > if (!(flags & PCI_BASE_ADDRESS_SPACE))
> > > as_type = DW_PCIE_AS_MEM;
> > > else
> > > as_type = DW_PCIE_AS_IO;
> > >
> > > - ret = dw_pcie_ep_inbound_atu(ep, bar, epf_bar->phys_addr, as_type);
> > > + ret = dw_pcie_ep_inbound_atu(ep, func_no, bar,
> > > + epf_bar->phys_addr, as_type);
> > > if (ret)
> > > return ret;
> > >
> > > @@ -235,7 +246,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc
> > *epc, u8 func_no,
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > >
> > > - ret = dw_pcie_ep_outbound_atu(ep, addr, pci_addr, size);
> > > + ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
> > > if (ret) {
> > > dev_err(pci->dev, "Failed to enable address\n");
> > > return ret;
> > > @@ -248,12 +259,13 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> > > *epc, u8 func_no) {
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + u32 pf_base = func_no * epc->pf_offset;
> > > u32 val, reg;
> > >
> > > if (!ep->msi_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + pf_base + PCI_MSI_FLAGS;
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > if (!(val & PCI_MSI_FLAGS_ENABLE))
> > > return -EINVAL;
> > > @@ -267,12 +279,13 @@ static int dw_pcie_ep_set_msi(struct pci_epc
> > > *epc, u8 func_no, u8 interrupts) {
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + u32 pf_base = func_no * epc->pf_offset;
> > > u32 val, reg;
> > >
> > > if (!ep->msi_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + pf_base + PCI_MSI_FLAGS;
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > val &= ~PCI_MSI_FLAGS_QMASK;
> > > val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK; @@ -287,12 +300,13
> > > @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no) {
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + u32 pf_base = func_no * epc->pf_offset;
> > > u32 val, reg;
> > >
> > > if (!ep->msix_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > > + reg = ep->msix_cap + pf_base + PCI_MSIX_FLAGS;
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > if (!(val & PCI_MSIX_FLAGS_ENABLE))
> > > return -EINVAL;
> > > @@ -306,12 +320,13 @@ static int dw_pcie_ep_set_msix(struct pci_epc
> > > *epc, u8 func_no, u16 interrupts) {
> > > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + u32 pf_base = func_no * epc->pf_offset;
> > > u32 val, reg;
> > >
> > > if (!ep->msix_cap)
> > > return -EINVAL;
> > >
> > > - reg = ep->msix_cap + PCI_MSIX_FLAGS;
> > > + reg = ep->msix_cap + pf_base + PCI_MSIX_FLAGS;
> > > val = dw_pcie_readw_dbi(pci, reg);
> > > val &= ~PCI_MSIX_FLAGS_QSIZE;
> > > val |= interrupts;
> > > @@ -400,6 +415,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep
> > *ep, u8 func_no,
> > > unsigned int aligned_offset;
> > > u16 msg_ctrl, msg_data;
> > > u32 msg_addr_lower, msg_addr_upper, reg;
> > > + u32 pf_base = func_no * epc->pf_offset;
> > > u64 msg_addr;
> > > bool has_upper;
> > > int ret;
> > > @@ -408,19 +424,19 @@ int dw_pcie_ep_raise_msi_irq(struct
> > dw_pcie_ep *ep, u8 func_no,
> > > return -EINVAL;
> > >
> > > /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> > > - reg = ep->msi_cap + PCI_MSI_FLAGS;
> > > + reg = ep->msi_cap + pf_base + PCI_MSI_FLAGS;
> > > msg_ctrl = dw_pcie_readw_dbi(pci, reg);
> > > has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > > - reg = ep->msi_cap + PCI_MSI_ADDRESS_LO;
> > > + reg = ep->msi_cap + pf_base + PCI_MSI_ADDRESS_LO;
> > > msg_addr_lower = dw_pcie_readl_dbi(pci, reg);
> > > if (has_upper) {
> > > - reg = ep->msi_cap + PCI_MSI_ADDRESS_HI;
> > > + reg = ep->msi_cap + pf_base + PCI_MSI_ADDRESS_HI;
> > > msg_addr_upper = dw_pcie_readl_dbi(pci, reg);
> > > - reg = ep->msi_cap + PCI_MSI_DATA_64;
> > > + reg = ep->msi_cap + pf_base + PCI_MSI_DATA_64;
> > > msg_data = dw_pcie_readw_dbi(pci, reg);
> > > } else {
> > > msg_addr_upper = 0;
> > > - reg = ep->msi_cap + PCI_MSI_DATA_32;
> > > + reg = ep->msi_cap + pf_base + PCI_MSI_DATA_32;
> > > msg_data = dw_pcie_readw_dbi(pci, reg);
> > > }
> > > aligned_offset = msg_addr_lower & (epc->mem->page_size - 1); @@
> > > -439,7 +455,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> > > u8 func_no, }
> > >
> > > int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > - u16 interrupt_num)
> > > + u16 interrupt_num)
> > > {
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > struct pci_epc *epc = ep->epc;
> > > @@ -447,16 +463,17 @@ int dw_pcie_ep_raise_msix_irq(struct
> > dw_pcie_ep *ep, u8 func_no,
> > > u32 bar_addr_upper, bar_addr_lower;
> > > u32 msg_addr_upper, msg_addr_lower;
> > > u32 reg, msg_data, vec_ctrl;
> > > + u32 pf_base = func_no * epc->pf_offset;
> > > u64 tbl_addr, msg_addr, reg_u64;
> > > void __iomem *msix_tbl;
> > > int ret;
> > >
> > > - reg = ep->msix_cap + PCI_MSIX_TABLE;
> > > + reg = ep->msix_cap + pf_base + PCI_MSIX_TABLE;
> > > tbl_offset = dw_pcie_readl_dbi(pci, reg);
> > > bir = (tbl_offset & PCI_MSIX_TABLE_BIR);
> > > tbl_offset &= PCI_MSIX_TABLE_OFFSET;
> > >
> > > - reg = PCI_BASE_ADDRESS_0 + (4 * bir);
> > > + reg = PCI_BASE_ADDRESS_0 + pf_base + (4 * bir);
> > > bar_addr_upper = 0;
> > > bar_addr_lower = dw_pcie_readl_dbi(pci, reg);
> > > reg_u64 = (bar_addr_lower & PCI_BASE_ADDRESS_MEM_TYPE_MASK);
> > @@
> > > -592,13 +609,17 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > > ep->epc = epc;
> > > epc_set_drvdata(epc, ep);
> > >
> > > - if (ep->ops->ep_init)
> > > - ep->ops->ep_init(ep);
> > > -
> > > ret = of_property_read_u8(np, "max-functions", &epc->max_functions);
> > > if (ret < 0)
> > > epc->max_functions = 1;
> > >
> > > + ret = of_property_read_u32(np, "pf-offset", &epc->pf_offset);
> > > + if (ret < 0)
> > > + epc->pf_offset = 0;
> >
> > Bad things will likely happen if max_functions > 1 and pf-offset isn't set.
> > I think the driver should bail in this situation. It would be very easy for
> > someone to misconfigure this.
> Yes, you are right, but if the max-functions have defined in DTS, require the pf-offset
> must define in DTS, I am not sure the correct value of pf-offsetfor other platforms,
> so I think the max-functions and pf-offset should not have the dependence.
Yes you're correct. I hadn't really thought about this beyond layerscape. It's
also possible that other hardware could support multiple PFs without relying on
an offset and perhaps employ some other mechanism to access different
functions. So whilst this property can be optional for the majority of dwc
controllers - it must be set and cannot be zero for layerscape.
Perhaps inside ls_pcie_ep_init, you can set max_functions to 1 if pf_offset is
0 and print a WARN to explain why? (Or ls_pcie_ep_init returns failure and
dw_pcie_ep_init checks it and bails).
The assumption is being made here that future dw controllers may also use
pf_offset (is this likely?) - otherwise why is this in pcie-designware-ep.c and
not pci-layerscape-ep.c and why is this value not just hard-coded for lp?
> even though I didn't define pf-offset when I defined max-functions, the pf-offset is 0,
> the DWC ep driver can continue run the progress of INIT but not return, of course,
> thus the PF1 will not work, I don't know which way is better.
> >
> >
> > > +
> > > + if (ep->ops->ep_init)
> > > + ep->ops->ep_init(ep);
> > > +
> > > ret = __pci_epc_mem_init(epc, ep->phys_base, ep->addr_size,
> > > ep->page_size);
> > > if (ret < 0) {
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > index 7d25102..c99cee4 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > @@ -158,6 +158,43 @@ static void dw_pcie_writel_ob_unroll(struct
> > dw_pcie *pci, u32 index, u32 reg,
> > > dw_pcie_writel_atu(pci, offset + reg, val); }
> > >
> > > +static void dw_pcie_prog_ep_outbound_atu_unroll(struct dw_pcie *pci, u8
> > func_no,
> > > + int index, int type,
> > > + u64 cpu_addr, u64 pci_addr,
> > > + u32 size)
> > > +{
> > > + u32 retries, val;
> > > +
> > > + dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_BASE,
> > > + lower_32_bits(cpu_addr));
> > > + dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_BASE,
> > > + upper_32_bits(cpu_addr));
> > > + dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LIMIT,
> > > + lower_32_bits(cpu_addr + size - 1));
> > > + dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_LOWER_TARGET,
> > > + lower_32_bits(pci_addr));
> > > + dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_UPPER_TARGET,
> > > + upper_32_bits(pci_addr));
> > > + dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > > + type | PCIE_ATU_FUNC_NUM(func_no));
> >
> > With the exception of this line, the rest of this function is identical to
> > dw_pcie_prog_outbound_atu_unroll.
> Yes, I can integrate the same code, but I think we'd better use the different outbound
> window set function between RC and EP, because the RC don't need the func_num parameter.
> >
> > > + dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> > > + PCIE_ATU_ENABLE);
> > > +
> > > + /*
> > > + * Make sure ATU enable takes effect before any subsequent config
> > > + * and I/O accesses.
> > > + */
> > > + for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
> > > + val = dw_pcie_readl_ob_unroll(pci, index,
> > > + PCIE_ATU_UNR_REGION_CTRL2);
> > > + if (val & PCIE_ATU_ENABLE)
> > > + return;
> > > +
> > > + mdelay(LINK_WAIT_IATU);
> > > + }
> > > + dev_err(pci->dev, "Outbound iATU is not being enabled\n"); }
> > > +
> > > static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int
> > index,
> > > int type, u64 cpu_addr,
> > > u64 pci_addr, u32 size)
> > > @@ -194,6 +231,51 @@ static void
> > dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index,
> > > dev_err(pci->dev, "Outbound iATU is not being enabled\n"); }
> > >
> > > +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> > index,
> > > + int type, u64 cpu_addr, u64 pci_addr,
> > > + u32 size)
> > > +{
> > > + u32 retries, val;
> > > +
> > > + if (pci->ops->cpu_addr_fixup)
> > > + cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
> > > +
> > > + if (pci->iatu_unroll_enabled) {
> > > + dw_pcie_prog_ep_outbound_atu_unroll(pci, func_no, index, type,
> > > + cpu_addr, pci_addr, size);
> > > + return;
> > > + }
> > > +
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
> > > + PCIE_ATU_REGION_OUTBOUND | index);
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_BASE,
> > > + lower_32_bits(cpu_addr));
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_BASE,
> > > + upper_32_bits(cpu_addr));
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_LIMIT,
> > > + lower_32_bits(cpu_addr + size - 1));
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_LOWER_TARGET,
> > > + lower_32_bits(pci_addr));
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_UPPER_TARGET,
> > > + upper_32_bits(pci_addr));
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type |
> > > + PCIE_ATU_FUNC_NUM(func_no));
> >
> > The same here, this is identical to dw_pcie_prog_outbound_atu with the
> > exception of this line.
> >
> > Is there a way you can avoid all of this duplicated code?
> As above, I can integrate the same code, but I keep to think the different outbound
> Window set function should be used between RC and EP.
Or, is it possible to keep and use the existing functions, but use them
differently, e.g:
@@ -137,8 +146,8 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, phys_addr_t phys_addr,
return -EINVAL;
}
- dw_pcie_prog_outbound_atu(pci, free_win, PCIE_ATU_TYPE_MEM,
- phys_addr, pci_addr, size);
+ dw_pcie_prog_outbound_atu(pci, free_win, PCIE_ATU_TYPE_MEM_FUNC(func_no),
+ phys_addr, pci_addr, size);
set_bit(free_win, ep->ob_window_map);
ep->outbound_addr[free_win] = phys_addr;
Supported with:
#define PCIE_ATU_TYPE_MEM 0x0
#define PCIE_ATU_TYPE_MEM_FUNC(func_no) (PCIE_ATU_TYPE_MEM | PCIE_ATU_FUNC_NUM(func_no))
This is just a suggestion, but I'm keen to avoid code duplication.
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE);
> > > +
> > > + /*
> > > + * Make sure ATU enable takes effect before any subsequent config
> > > + * and I/O accesses.
> > > + */
> > > + for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
> > > + val = dw_pcie_readl_dbi(pci, PCIE_ATU_CR2);
> > > + if (val & PCIE_ATU_ENABLE)
> > > + return;
> > > +
> > > + mdelay(LINK_WAIT_IATU);
> > > + }
> > > + dev_err(pci->dev, "Outbound iATU is not being enabled\n"); }
> > > +
> > > void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> > > u64 cpu_addr, u64 pci_addr, u32 size) { @@ -252,8
> > +334,8
> > > @@ static void dw_pcie_writel_ib_unroll(struct dw_pcie *pci, u32 index,
> > u32 reg,
> > > dw_pcie_writel_atu(pci, offset + reg, val); }
> > >
> > > -static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index,
> > > - int bar, u64 cpu_addr,
> > > +static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, u8
> > func_no,
> > > + int index, int bar, u64 cpu_addr,
> > > enum dw_pcie_as_type as_type) {
> > > int type;
> > > @@ -275,8 +357,10 @@ static int dw_pcie_prog_inbound_atu_unroll(struct
> > dw_pcie *pci, int index,
> > > return -EINVAL;
> > > }
> > >
> > > - dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > type);
> > > + dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL1,
> > type |
> > > + PCIE_ATU_FUNC_NUM(func_no));
> > > dw_pcie_writel_ib_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2,
> > > + PCIE_ATU_FUNC_NUM_MATCH_EN |
> > > PCIE_ATU_ENABLE |
> > > PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
> > >
> > > @@ -297,14 +381,15 @@ static int
> > dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index,
> > > return -EBUSY;
> > > }
> > >
> > > -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> > > - u64 cpu_addr, enum dw_pcie_as_type as_type)
> > > +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > > + int bar, u64 cpu_addr,
> > > + enum dw_pcie_as_type as_type)
> > > {
> > > int type;
> > > u32 retries, val;
> > >
> > > if (pci->iatu_unroll_enabled)
> > > - return dw_pcie_prog_inbound_atu_unroll(pci, index, bar,
> > > + return dw_pcie_prog_inbound_atu_unroll(pci, func_no, index, bar,
> > > cpu_addr, as_type);
> > >
> > > dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT,
> > PCIE_ATU_REGION_INBOUND |
> > > @@ -323,9 +408,11 @@ int dw_pcie_prog_inbound_atu(struct dw_pcie
> > *pci, int index, int bar,
> > > return -EINVAL;
> > > }
> > >
> > > - dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type);
> > > - dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE
> > > - | PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_CR1, type |
> > > + PCIE_ATU_FUNC_NUM(func_no));
> > > + dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, PCIE_ATU_ENABLE |
> > > + PCIE_ATU_FUNC_NUM_MATCH_EN |
> > > + PCIE_ATU_BAR_MODE_ENABLE | (bar << 8));
> > >
> > > /*
> > > * Make sure ATU enable takes effect before any subsequent config
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > index ffed084..2b291e8 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > @@ -71,9 +71,11 @@
> > > #define PCIE_ATU_TYPE_IO 0x2
> > > #define PCIE_ATU_TYPE_CFG0 0x4
> > > #define PCIE_ATU_TYPE_CFG1 0x5
> > > +#define PCIE_ATU_FUNC_NUM(pf) (pf << 20)
> > > #define PCIE_ATU_CR2 0x908
> > > #define PCIE_ATU_ENABLE BIT(31)
> > > #define PCIE_ATU_BAR_MODE_ENABLE BIT(30)
> > > +#define PCIE_ATU_FUNC_NUM_MATCH_EN BIT(19)
> > > #define PCIE_ATU_LOWER_BASE 0x90C
> > > #define PCIE_ATU_UPPER_BASE 0x910
> > > #define PCIE_ATU_LIMIT 0x914
> > > @@ -265,8 +267,12 @@ int dw_pcie_wait_for_link(struct dw_pcie *pci);
> > > void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> > > int type, u64 cpu_addr, u64 pci_addr,
> > > u32 size);
> > > -int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int bar,
> > > - u64 cpu_addr, enum dw_pcie_as_type as_type);
> > > +void dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int
> > index,
> > > + int type, u64 cpu_addr, u64 pci_addr,
> > > + u32 size);
> > > +int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > > + int bar, u64 cpu_addr,
> > > + enum dw_pcie_as_type as_type);
> > > void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
> > > enum dw_pcie_region_type type);
> > > void dw_pcie_setup(struct dw_pcie *pci); diff --git
> > > a/include/linux/pci-epc.h b/include/linux/pci-epc.h index
> > > f641bad..fc2feee 100644
> > > --- a/include/linux/pci-epc.h
> > > +++ b/include/linux/pci-epc.h
> > > @@ -96,6 +96,7 @@ struct pci_epc {
> > > const struct pci_epc_ops *ops;
> > > struct pci_epc_mem *mem;
> > > u8 max_functions;
> > > + u32 pf_offset;
Also pf_offset is an implementation detail needed only by the driver to
calculate where the PF is - it doesn't seem right that we share this with the
EP controller framework (whereas max_functions is used as a bounds check
for func_no in the framework calls).
I'd suggest that pf_offset is moved to a dwc structure, perhaps dw_pcie_ep?
Thanks,
Andrew Murray
> > > struct config_group *group;
> > > /* spinlock to protect against concurrent access of EP controller */
> > > spinlock_t lock;
> > > --
> > > 2.9.5
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > > .infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=02%
> > 7C0
> > >
> > 1%7Cxiaowei.bao%40nxp.com%7C0e39168f6f144db6840308d721742040%7
> > C686ea1d
> > >
> > 3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637014654998524452&sd
> > ata=bP7eh
> > > cjlGXCMVFE2b4f12Q6fGV7lQ%2F5i9qIi9FoPlbI%3D&reserved=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/3] pwm: atmel: document known weaknesses of both hardware and software
From: Uwe Kleine-König @ 2019-08-16 9:37 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding
Cc: linux-pwm, Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
In-Reply-To: <20190815214133.11134-1-uwe@kleine-koenig.org>
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
drivers/pwm/pwm-atmel.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 42fe7bc043a8..1ddb93db9627 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -7,6 +7,16 @@
*
* Reference manual for "atmel,at91sam9rl-pwm":
* http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
+ *
+ * Limitations:
+ * - Periods start with the inactive level.
+ * - Hardware has to be stopped in general to update settings.
+ *
+ * Software bugs/possible improvements:
+ * - When atmel_pwm_apply() is called with state->enabled=false a change in
+ * state->polarity isn't honored.
+ * - Instead of sleeping to wait for a completed period, the interrupt
+ * functionality could be used.
*/
#include <linux/clk.h>
--
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] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Corentin Labbe @ 2019-08-16 9:35 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, wens,
robh+dt, linux-arm-kernel
In-Reply-To: <20190814133322.dawzv3ityakxtqs4@flea>
On Wed, Aug 14, 2019 at 03:33:22PM +0200, Maxime Ripard wrote:
> On Wed, Aug 14, 2019 at 03:17:41PM +0200, Corentin Labbe wrote:
> > On Mon, Aug 12, 2019 at 11:40:00AM +0200, Maxime Ripard wrote:
> > > On Thu, Aug 08, 2019 at 10:42:53AM +0200, Corentin Labbe wrote:
> > > > This patch adds the evaluation variant of the model A of the PineH64.
> > > > The model A has the same size of the pine64 and has a PCIE slot.
> > > >
> > > > The only devicetree difference with current pineH64, is the PHY
> > > > regulator.
> > > >
> > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > ---
> > > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > > > .../sun50i-h6-pine-h64-modelA-eval.dts | 26 +++++++++++++++++++
> > > > 2 files changed, 27 insertions(+)
> > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > >
> > > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > > > index f6db0611cb85..9a02166cbf72 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > > > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > > > @@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > > > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-modelA-eval.dtb
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > new file mode 100644
> > > > index 000000000000..d8ff02747efe
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > @@ -0,0 +1,26 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > > +/*
> > > > + * Copyright (C) 2019 Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > + */
> > > > +
> > > > +#include "sun50i-h6-pine-h64.dts"
> > > > +
> > > > +/ {
> > > > + model = "Pine H64 model A evaluation board";
> > > > + compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> > > > +
> > > > + reg_gmac_3v3: gmac-3v3 {
> > > > + compatible = "regulator-fixed";
> > > > + regulator-name = "vcc-gmac-3v3";
> > > > + regulator-min-microvolt = <3300000>;
> > > > + regulator-max-microvolt = <3300000>;
> > > > + startup-delay-us = <100000>;
> > > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;
> > > > + enable-active-high;
> > > > + };
> > > > +
> > > > +};
> > > > +
> > > > +&emac {
> > > > + phy-supply = <®_gmac_3v3>;
> > > > +};
> > >
> > > I might be missing some context here, but I'm pretty sure that the
> > > initial intent of the pine h64 DTS was to support the model A all
> > > along.
> > >
> >
> > The regulator changed between modelA and B.
> > See this old patchset (supporting modelA) https://patchwork.kernel.org/patch/10539149/ for example.
>
> I'm not sure what your point is, but mine is that everything about the
> model A should be in sun50i-h6-pine-h64.dts.
>
model A and B are different enough for distinct dtb, (see sub-thread on HDMI difference for an other difference than PHY regulator)
And clearly, the current dtb is for model B.
So do you mean that we need to create a new dtb for model B ? (and hack the current back to model A ?)
Regards
_______________________________________________
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] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Wei Xu @ 2019-08-16 9:05 UTC (permalink / raw)
To: xuwei5, linux-gpio, linux-kernel, linux-arm-kernel, linus.walleij,
rjw, lenb, mika.westerberg, andy.shevchenko
Cc: salil.mehta, jinying, tangkunshan, john.garry, linuxarm,
shameerali.kolothum.thodi, huangdaode, jonathan.cameron, liguozhu,
zhangyi.ac, shiju.jose
Invoke acpi_gpiochip_request_interrupts after the acpi data has been
attached to the pl061 acpi node to register interruption.
Otherwise it will be failed to register interruption for the ACPI case.
Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
after gpiochip_add_irqchip but at that time the acpi data has not been
attached yet.
Tested with below steps on QEMU v4.1.0-rc3 and Linux kernel v5.3-rc4,
and found pl061 interruption is missed in the /proc/interrupts:
1.
qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu cortex-a57 \
-m 1G,maxmem=4G,slots=4 \
-kernel Image -initrd rootfs.cpio.gz \
-net none -nographic \
-bios QEMU_EFI.fd \
-append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"
2. cat /proc/interrupts in the guest console:
estuary:/$ cat /proc/interrupts
CPU0
2: 3228 GICv3 27 Level arch_timer
4: 15 GICv3 33 Level uart-pl011
42: 0 GICv3 23 Level arm-pmu
IPI0: 0 Rescheduling interrupts
IPI1: 0 Function call interrupts
IPI2: 0 CPU stop interrupts
IPI3: 0 CPU stop (for crash dump) interrupts
IPI4: 0 Timer broadcast interrupts
IPI5: 0 IRQ work interrupts
IPI6: 0 CPU wake-up interrupts
Err: 0
But on QEMU v3.0.0 and Linux kernel v5.2.0-rc7, pl061 interruption is
there as below:
estuary:/$ cat /proc/interrupts
CPU0
2: 2648 GICv3 27 Level arch_timer
4: 12 GICv3 33 Level uart-pl011
42: 0 GICv3 23 Level arm-pmu
43: 0 ARMH0061:00 3 Edge ACPI:Event
IPI0: 0 Rescheduling interrupts
IPI1: 0 Function call interrupts
IPI2: 0 CPU stop interrupts
IPI3: 0 CPU stop (for crash dump) interrupts
IPI4: 0 Timer broadcast interrupts
IPI5: 0 IRQ work interrupts
IPI6: 0 CPU wake-up interrupts
Err: 0
And the whole dmesg log on Linux kernel v5.2.0-rc7 is as below:
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
[ 0.000000] Linux version 5.2.0-rc7 (joyx@Turing-Arch-b) (gcc version 4.9.1 20140505 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.05 - Linaro GCC 4.9-2014.05)) #61 SMP PREEMPT Fri Aug 16 11:54:31 CST 2019
[ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options '')
[ 0.000000] printk: bootconsole [pl11] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: EFI v2.70 by EDK II
[ 0.000000] efi: SMBIOS 3.0=0x7f8e0000 MEMATTR=0x7d60f018 ACPI 2.0=0x7c270000 MEMRESERVE=0x7c503018
[ 0.000000] cma: Reserved 32 MiB at 0x000000007a000000
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x000000007C270000 000024 (v02 BOCHS )
[ 0.000000] ACPI: XSDT 0x000000007C260000 000054 (v01 BOCHS BXPCFACP 00000001 01000013)
[ 0.000000] ACPI: FACP 0x000000007C220000 00010C (v05 BOCHS BXPCFACP 00000001 BXPC 00000001)
[ 0.000000] ACPI: DSDT 0x000000007C230000 00482C (v02 BOCHS BXPCDSDT 00000001 BXPC 00000001)
[ 0.000000] ACPI: APIC 0x000000007C210000 0000A0 (v03 BOCHS BXPCAPIC 00000001 BXPC 00000001)
[ 0.000000] ACPI: GTDT 0x000000007C200000 000060 (v02 BOCHS BXPCGTDT 00000001 BXPC 00000001)v
[ 0.000000] ACPI: MCFG 0x000000007C1F0000 00003C (v01 BOCHS BXPCMCFG 00000001 BXPC 00000001)
[ 0.000000] ACPI: SPCR 0x000000007C1E0000 000050 (v02 BOCHS BXPCSPCR 00000001 BXPC 00000001)
[ 0.000000] ACPI: SRAT 0x000000007C1D0000 00006A (v03 BOCHS BXPCSRAT 00000001 BXPC 00000001)
[ 0.000000] ACPI: SPCR: console: pl011,mmio,0x9000000,9600
[ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x40000000-0x7fffffff]
[ 0.000000] NUMA: NODE_DATA [mem 0x7fdfb840-0x7fdfcfff]
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000040000000-0x000000007fffffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000040000000-0x000000007c27ffff]
[ 0.000000] node 0: [mem 0x000000007c280000-0x000000007c4fffff]
[ 0.000000] node 0: [mem 0x000000007c500000-0x000000007f7dffff]
[ 0.000000] node 0: [mem 0x000000007f7e0000-0x000000007f86ffff]
[ 0.000000] node 0: [mem 0x000000007f870000-0x000000007f87ffff]
[ 0.000000] node 0: [mem 0x000000007f880000-0x000000007f99ffff]
[ 0.000000] node 0: [mem 0x000000007f9a0000-0x000000007fffffff]
[ 0.000000] Zeroed struct page in unavailable ranges: 416 pages
[ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
[ 0.000000] On node 0 totalpages: 262144
[ 0.000000] DMA32 zone: 4096 pages used for memmap
[ 0.000000] DMA32 zone: 0 pages reserved
[ 0.000000] DMA32 zone: 262144 pages, LIFO batch:63
[ 0.000000] psci: probing for conduit method from ACPI.
[ 0.000000] psci: PSCIv0.2 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: Trusted OS migration not required
[ 0.000000] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x0 -> Node 0
[ 0.000000] percpu: Embedded 23 pages/cpu s56768 r8192 d29248 u94208
[ 0.000000] pcpu-alloc: s56768 r8192 d29248 u94208 alloc=23*4096
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Detected PIPT I-cache on CPU0
[ 0.000000] CPU features: detected: ARM erratum 832075
[ 0.000000] CPU features: detected: GIC system register CPU interface
[ 0.000000] CPU features: detected: ARM erratum 834220
[ 0.000000] CPU features: detected: EL2 vector hardening
[ 0.000000] ARM_SMCCC_ARCH_WORKAROUND_1 missing from firmware
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 258048
[ 0.000000] Policy zone: DMA32
[ 0.000000] Kernel command line: console=ttyAMA0 acpi=force earlycon=pl011,0x9000000 initrd=initrd
[ 0.000000] Memory: 848128K/1048576K available (11132K kernel code, 1766K rwdata, 5924K rodata, 1344K init, 447K bss, 167680K reserved, 32768K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] GICv3: Distributor has no Range Selector support
[ 0.000000] GICv3: no VLPI support, no direct LPI support
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x00000000080a0000
[ 0.000000] random: get_random_bytes called from start_kernel+0x2b4/0x470 with crng_init=0
[ 0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
[ 0.000092] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
[ 0.007507] Console: colour dummy device 80x25
[ 0.009048] ACPI: Core revision 20190509
[ 0.013315] Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
[ 0.014388] pid_max: default: 32768 minimum: 301
[ 0.015596] LSM: Security Framework initializing
[ 0.125480] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[ 0.126961] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[ 0.127543] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.127927] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.139974] *** VALIDATE proc ***
[ 0.144385] *** VALIDATE cgroup1 ***
[ 0.144602] *** VALIDATE cgroup2 ***
[ 0.156728] ACPI PPTT: No PPTT table found, CPU and cache topology may be inaccurate
[ 0.185506] ASID allocator initialised with 32768 entries
[ 0.193054] rcu: Hierarchical SRCU implementation.
[ 0.204036] Remapping and enabling EFI services.
[ 0.213563] smp: Bringing up secondary CPUs ...
[ 0.213898] smp: Brought up 1 node, 1 CPU
[ 0.214131] SMP: Total of 1 processors activated.
[ 0.214418] CPU features: detected: 32-bit EL0 Support
[ 0.214766] CPU features: detected: CRC32 instructions
[ 0.223253] CPU: All CPU(s) started at EL1
[ 0.223634] alternatives: patching kernel code
[ 0.244639] devtmpfs: initialized
[ 0.256434] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.257056] futex hash table entries: 256 (order: 2, 16384 bytes)
[ 0.263282] pinctrl core: initialized pinctrl subsystem
[ 0.276553] SMBIOS 3.0.0 present.
[ 0.276921] DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[ 0.284007] NET: Registered protocol family 16
[ 0.286721] audit: initializing netlink subsys (disabled)
[ 0.291045] audit: type=2000 audit(0.268:1): state=initialized audit_enabled=0 res=1
[ 0.295580] cpuidle: using governor menu
[ 0.297330] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[ 0.304834] DMA: preallocated 256 KiB pool for atomic allocations
[ 0.308014] ACPI: bus type PCI registered
[ 0.308308] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.310517] Serial: AMBA PL011 UART driver
[ 0.354362] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[ 0.354735] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[ 0.355104] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[ 0.355445] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[ 0.382352] cryptd: max_cpu_qlen set to 1000
[ 0.408375] ACPI: Added _OSI(Module Device)
[ 0.408641] ACPI: Added _OSI(Processor Device)
[ 0.408873] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.409122] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.409476] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.410058] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 0.410334] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 0.491373] ACPI: 1 ACPI AML tables successfully acquired and loaded
[ 0.506610] ACPI: Interpreter enabled
[ 0.506855] ACPI: Using GIC for interrupt routing
[ 0.507529] ACPI: MCFG table detected, 1 entries
[ 0.562419] ARMH0011:00: ttyAMA0 at MMIO 0x9000000 (irq = 4, base_baud = 0) is a SBSA
[ 0.635348] printk: console [ttyAMA0] enabled
[ 0.671533] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.672857] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[ 0.680379] acpi PNP0A08:00: _OSC: platform does not support [LTR]
[ 0.683111] acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability]
[ 0.688777] acpi PNP0A08:00: ECAM area [mem 0x4010000000-0x401fffffff] reserved by PNP0C02:00
[ 0.689904] acpi PNP0A08:00: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
[ 0.691879] Remapped I/O 0x000000003eff0000 to [io 0x0000-0xffff window]
[ 0.695715] PCI host bridge to bus 0000:00
[ 0.696261] pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
[ 0.697055] pci_bus 0000:00: root bus resource [io 0x0000-0xffff window]
[ 0.697735] pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
[ 0.698606] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.700266] pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
[ 0.706988] ACPI: PCI Interrupt Link [GSI0] (IRQs *35)
[ 0.707965] ACPI: PCI Interrupt Link [GSI1] (IRQs *36)
[ 0.708661] ACPI: PCI Interrupt Link [GSI2] (IRQs *37)
[ 0.709336] ACPI: PCI Interrupt Link [GSI3] (IRQs *38)
[ 0.721505] vgaarb: loaded
[ 0.723261] SCSI subsystem initialized
[ 0.725065] libata version 3.00 loaded.
[ 0.726270] ACPI: bus type USB registered
[ 0.727346] usbcore: registered new interface driver usbfs
[ 0.728223] usbcore: registered new interface driver hub
[ 0.729326] usbcore: registered new device driver usb
[ 0.732056] pps_core: LinuxPPS API ver. 1 registered
[ 0.732580] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.733803] PTP clock support registered
[ 0.734781] EDAC MC: Ver: 3.0.0
[ 0.739155] Registered efivars operations
[ 0.752186] FPGA manager framework
[ 0.753453] Advanced Linux Sound Architecture Driver Initialized.
[ 0.767808] clocksource: Switched to clocksource arch_sys_counter
[ 0.769435] VFS: Disk quotas dquot_6.6.0
[ 0.770090] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.772939] *** VALIDATE hugetlbfs ***
[ 0.775509] pnp: PnP ACPI init
[ 0.779262] system 00:00: [mem 0x4010000000-0x401fffffff window] could not be reserved
[ 0.780474] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.780648] pnp: PnP ACPI: found 1 devices
[ 0.814296] NET: Registered protocol family 2
[ 0.820604] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes)
[ 0.821551] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.822567] TCP bind hash table entries: 8192 (order: 5, 131072 bytes)
[ 0.823490] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.826650] UDP hash table entries: 512 (order: 2, 16384 bytes)
[ 0.827508] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[ 0.829971] NET: Registered protocol family 1
[ 0.846727] RPC: Registered named UNIX socket transport module.
[ 0.847379] RPC: Registered udp transport module.
[ 0.848334] RPC: Registered tcp transport module.
[ 0.848818] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.849786] PCI: CLS 0 bytes, default 64
[ 0.853671] Unpacking initramfs...
[ 6.993882] Freeing initrd memory: 123392K
[ 6.996833] hw perfevents: enabled with armv8_pmuv3_0 PMU driver, 1 counters available
[ 6.997772] kvm [1]: HYP mode not available
[ 7.699500] Initialise system trusted keyrings
[ 7.701698] workingset: timestamp_bits=44 max_order=18 bucket_order=0
[ 7.734096] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 7.742467] NFS: Registering the id_resolver key type
[ 7.743404] Key type id_resolver registered
[ 7.744455] Key type id_legacy registered
[ 7.745321] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 7.747602] 9p: Installing v9fs 9p2000 file system support
[ 7.778884] Key type asymmetric registered
[ 7.779383] Asymmetric key parser 'x509' registered
[ 7.780548] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
[ 7.781375] io scheduler mq-deadline registered
[ 7.781899] io scheduler kyber registered
[ 7.809878] pl061_gpio ARMH0061:00: PL061 GPIO chip @0x0000000009030000 registered
[ 7.820983] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[ 7.822495] ACPI: Power Button [PWRB]
[ 7.829682] EINJ: EINJ table not found.
[ 7.893411] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 7.902202] SuperH (H)SCI(F) driver initialized
[ 7.904102] msm_serial: driver initialized
[ 7.908209] cacheinfo: Unable to detect cache hierarchy for CPU 0
[ 7.940712] loop: module loaded
[ 7.957364] libphy: Fixed MDIO Bus: probed
[ 7.959166] tun: Universal TUN/TAP device driver, 1.6
[ 7.962432] thunder_xcv, ver 1.0
[ 7.962986] thunder_bgx, ver 1.0
[ 7.963542] nicpf, ver 1.0
[ 7.965950] hclge is initializing
[ 7.966402] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[ 7.967095] hns3: Copyright (c) 2017 Huawei Corporation.
[ 7.968228] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[ 7.968792] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 7.969591] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[ 7.970258] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 7.971023] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[ 7.971977] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[ 7.973720] sky2: driver version 1.30
[ 7.976724] VFIO - User Level meta-driver version: 0.3
[ 7.988959] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 7.989976] ehci-pci: EHCI PCI platform driver
[ 7.991065] ehci-platform: EHCI generic platform driver
[ 7.992716] ehci-orion: EHCI orion driver
[ 7.993799] ehci-exynos: EHCI EXYNOS driver
[ 7.994893] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 7.995615] ohci-pci: OHCI PCI platform driver
[ 7.996497] ohci-platform: OHCI generic platform driver
[ 7.997352] ohci-exynos: OHCI EXYNOS driver
[ 7.999395] usbcore: registered new interface driver usb-storage
[ 8.013108] rtc-efi rtc-efi: registered as rtc0
[ 8.016099] i2c /dev entries driver
[ 8.031422] sdhci: Secure Digital Host Controller Interface driver
[ 8.032163] sdhci: Copyright(c) Pierre Ossman
[ 8.034139] Synopsys Designware Multimedia Card Interface Driver
[ 8.037333] sdhci-pltfm: SDHCI platform and OF driver helper
[ 8.042220] ledtrig-cpu: registered to indicate activity on CPUs
[ 8.049014] usbcore: registered new interface driver usbhid
[ 8.049565] usbhid: USB HID core driver
[ 8.062947] NET: Registered protocol family 17
[ 8.065201] 9pnet: Installing 9P2000 support
[ 8.065961] Key type dns_resolver registered
[ 8.069421] registered taskstats version 1
[ 8.069864] Loading compiled-in X.509 certificates
[ 8.075662] rtc-efi rtc-efi: setting system clock to 2019-08-16T07:48:26 UTC (1565941706)
[ 8.079525] ALSA device list:
[ 8.080167] No soundcards found.
[ 8.478229] Freeing unused kernel memory: 1344K
[ 8.480677] Run /init as init process
[ 9.767007] random: sshd: uninitialized urandom read (32 bytes read)
estuary:/$
Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
v1- > v2:
* rebased on https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
* attached the log based on QEMU v3.0.0 and Linux kernel v5.2.0-rc7
---
drivers/gpio/gpio-pl061.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 722ce5c..e1a434e 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -8,6 +8,7 @@
*
* Data sheet: ARM DDI 0190B, September 2000
*/
+#include <linux/acpi.h>
#include <linux/spinlock.h>
#include <linux/errno.h>
#include <linux/init.h>
@@ -24,6 +25,9 @@
#include <linux/pinctrl/consumer.h>
#include <linux/pm.h>
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
+
#define GPIODIR 0x400
#define GPIOIS 0x404
#define GPIOIBE 0x408
@@ -345,6 +349,9 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
if (ret)
return ret;
+ if (has_acpi_companion(dev))
+ acpi_gpiochip_request_interrupts(&pl061->gc);
+
amba_set_drvdata(adev, pl061);
dev_info(dev, "PL061 GPIO chip registered\n");
--
2.8.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] arm64: allwinner: h6: add I2C nodes
From: Bhushan Shah @ 2019-08-16 8:43 UTC (permalink / raw)
To: Icenowy Zheng, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Gregory CLEMENT, Wolfram Sang, Bhushan Shah,
linux-i2c, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816084309.27440-1-bshah@kde.org>
Add device-tree nodes for i2c0 to i2c2, and also add relevant pinctrl
nodes.
Suggested-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Bhushan Shah <bshah@kde.org>
---
Changes in v3:
- fix compatible for the i2c
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 60 +++++++++++++++++++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index db71807255ef..5dc174715311 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -332,6 +332,21 @@
function = "hdmi";
};
+ i2c0_pins: i2c0-pins {
+ pins = "PD25", "PD26";
+ function = "i2c0";
+ };
+
+ i2c1_pins: i2c1-pins {
+ pins = "PH5", "PH6";
+ function = "i2c1";
+ };
+
+ i2c2_pins: i2c2-pins {
+ pins = "PD23", "PD24";
+ function = "i2c2";
+ };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2", "PF3",
"PF4", "PF5";
@@ -467,6 +482,48 @@
status = "disabled";
};
+ i2c0: i2c@5002000 {
+ compatible = "allwinner,sun50i-h6-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002000 0x400>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@5002400 {
+ compatible = "allwinner,sun50i-h6-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002400 0x400>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@5002800 {
+ compatible = "allwinner,sun50i-h6-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002800 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C2>;
+ resets = <&ccu RST_BUS_I2C2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
emac: ethernet@5020000 {
compatible = "allwinner,sun50i-h6-emac",
"allwinner,sun50i-a64-emac";
@@ -798,7 +855,8 @@
};
r_i2c: i2c@7081400 {
- compatible = "allwinner,sun6i-a31-i2c";
+ compatible = "allwinner,sun50i-h6-i2c",
+ "allwinner,sun6i-a31-i2c";
reg = <0x07081400 0x400>;
interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&r_ccu CLK_R_APB2_I2C>;
--
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 1/2] dt-bindings: i2c: mv64xxx: Add compatible for the H6 i2c node.
From: Bhushan Shah @ 2019-08-16 8:43 UTC (permalink / raw)
To: Icenowy Zheng, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Gregory CLEMENT, Wolfram Sang, Bhushan Shah,
linux-i2c, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816084309.27440-1-bshah@kde.org>
Allwinner H6 have a mv64xxx i2c interface available to be used.
Signed-off-by: Bhushan Shah <bshah@kde.org>
---
Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
index 001f2b7abad0..c779000515d6 100644
--- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
@@ -26,6 +26,9 @@ properties:
- items:
- const: allwinner,sun50i-a64-i2c
- const: allwinner,sun6i-a31-i2c
+ - items:
+ - const: allwinner,sun50i-h6-i2c
+ - const: allwinner,sun6i-a31-i2c
- const: marvell,mv64xxx-i2c
- const: marvell,mv78230-i2c
--
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] Enable the I2C nodes for Allwinner H6 CPU
From: Bhushan Shah @ 2019-08-16 8:43 UTC (permalink / raw)
To: Icenowy Zheng, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Gregory CLEMENT, Wolfram Sang, Bhushan Shah,
linux-i2c, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20190816064710.18280-1-bshah@kde.org>
This patch series adds device-tree nodes for i2c nodes in the H6 dtsi,
and enables it for the Pine H64.
Changes in v2:
- Add the SoC specific compatible string instead of re-using a31 one.
- Don't enable the i2c0 node in PineH64 by default
Changes in v3:
- Fix compatible for i2c in sun50i-h6.dtsi
- drop changes in the PineH64 dts completely
Bhushan Shah (2):
dt-bindings: i2c: mv64xxx: Add compatible for the H6 i2c node.
arm64: allwinner: h6: add I2C nodes
.../bindings/i2c/marvell,mv64xxx-i2c.yaml | 3 +
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 60 ++++++++++++++++++-
2 files changed, 62 insertions(+), 1 deletion(-)
--
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] gpio: pl061: Fix the issue failed to register the ACPI interruption
From: Wei Xu @ 2019-08-16 8:41 UTC (permalink / raw)
To: Linus Walleij
Cc: Salil Mehta, jinying, Tangkunshan, John Garry,
linux-kernel@vger.kernel.org, Shameerali Kolothum Thodi, Linuxarm,
open list:GPIO SUBSYSTEM, huangdaode, Jonathan Cameron,
Liguozhu (Kenneth), Zhangyi ac,
linux-arm-kernel@lists.infradead.org, Shiju Jose
In-Reply-To: <CACRpkdbi21mV5quTmur6egb6FJMFrD-Lg1EUKtk+HejyWjzmUA@mail.gmail.com>
Hi Linus,
On 2019/8/14 17:04, Linus Walleij wrote:
> Hi Wei,
>
> thanks for your patch!
>
> This doesn't apply for my "devel" branch, can you rebase
> on this:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
>
> We have moved some ACPI headers around recently.
Thanks to review!
I just sent out the v2 based on that.
> On Mon, Aug 12, 2019 at 1:28 PM Wei Xu <xuwei5@hisilicon.com> wrote:
>
>> Invoke acpi_gpiochip_request_interrupts after the acpi data has been
>> attached to the pl061 acpi node to register interruption.
> Makes sense.
>
>> Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
> I doubt this is a regression since I haven't seen anyone use this
> gpiochip with ACPI before.
>
> Please rename the patch "gpio: pl061: Add ACPI support" unless
> you can convince me it worked without changes before.
In the v2, I attached the log on QEMU v3.0.0 and Linux kernel v5.2.0-rc7
and
the pl061 driver can register ACPI interruption.
Based on that, I did not rename the patch but I am OK to rename it if
you have
any doubt.
> Please include some ACPI people on review of this. From
> MAINTAINERS:
> ACPI
> M: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> M: Len Brown <lenb@kernel.org>
> L: linux-acpi@vger.kernel.org
>
> I would also include Andy Shevchenko and Mika Westerberg for
> the GPIO aspects.
Copied to all of them in the v2.
Thanks!
Best Regards,
Wei
> Thanks!
> Linus Walleij
>
> .
>
_______________________________________________
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 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Aaro Koskinen @ 2019-08-16 8:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartlomiej Zolnierkiewicz, Tony Lindgren, Greg Kroah-Hartman,
Linus Walleij, Linux Kernel Mailing List, Dominik Brodowski,
Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <CAK8P3a3k_HOGqzMGjtc+7NSaK0Bsa_vxxRFLzY8aP6ev4wa9iA@mail.gmail.com>
Hi,
On Wed, Aug 14, 2019 at 12:36:40PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 14, 2019 at 9:49 AM Tony Lindgren <tony@atomide.com> wrote:
> > * Arnd Bergmann <arnd@arndb.de> [190813 19:34]:
> > > -#define OMAP1_IO_OFFSET 0x01000000 /* Virtual IO
> > > = 0xfefb0000 */
> > > +#define OMAP1_IO_OFFSET 0x00fb0000 /* Virtual IO
> > > = 0xff000000 */
> > > #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET)
> >
> > Oh OK yeah sounds like that's the issue.
> >
> > > There may be additional locations that hardcode the virtual address.
> >
> > Those should be in mach-omap1/io.c, and I recall innovator had some
> > hardcoded fpga address that should also be checked.
>
> I see four boards with hardcoded I/O addresses, but they are all below
> the PCI I/O virtual address range, and are not affected by that change.
>
> For the innovator FPGA access, this was ok, it uses the correct address
> in the OMAP1_IO_OFFSET range.
I tried testing this on OSK board. If I boot with earlyprintk disabled,
it boots OK and everything works (also CF card) with your playground
commit 5723b6686943.
However with earlyprintk it seems to hang as soon as kernel tries to print
something. So something goes wrong with early DEBUG_LL mapping code when
CONFIG_DEBUG_UART_VIRT=0xff000000 is used?
A.
_______________________________________________
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/3] arm64: allwinner: h6: add I2C nodes
From: Bhushan Shah @ 2019-08-16 8:23 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Wolfram Sang, Gregory CLEMENT,
Bhushan Shah, linux-kernel, Chen-Yu Tsai, Rob Herring, linux-i2c,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190816075031.zw4bjunn4hfoaq3e@flea>
[-- Attachment #1.1: Type: text/plain, Size: 1969 bytes --]
On Fri, Aug 16, 2019 at 09:50:31AM +0200, Maxime Ripard wrote:
> On Fri, Aug 16, 2019 at 12:17:09PM +0530, Bhushan Shah wrote:
> > Add device-tree nodes for i2c0 to i2c2, and also add relevant pinctrl
> > nodes.
> >
> > Suggested-by: Icenowy Zheng <icenowy@aosc.io>
> > Signed-off-by: Bhushan Shah <bshah@kde.org>
> > ---
> > Changes in v2:
> > - Add the SoC specific compatible string instead of re-using a31 one.
> >
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56 +++++++++++++++++++-
> > 1 file changed, 55 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index bcecca17d61d..a1a329926540 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -329,6 +329,21 @@
> > function = "hdmi";
> > };
> >
> > + i2c0_pins: i2c0-pins {
> > + pins = "PD25", "PD26";
> > + function = "i2c0";
> > + };
> > +
> > + i2c1_pins: i2c1-pins {
> > + pins = "PH5", "PH6";
> > + function = "i2c1";
> > + };
> > +
> > + i2c2_pins: i2c2-pins {
> > + pins = "PD23", "PD24";
> > + function = "i2c2";
> > + };
> > +
> > mmc0_pins: mmc0-pins {
> > pins = "PF0", "PF1", "PF2", "PF3",
> > "PF4", "PF5";
> > @@ -464,6 +479,45 @@
> > status = "disabled";
> > };
> >
> > + i2c0: i2c@5002000 {
> > + compatible = "allwinner,sun50i-h6-i2c";
>
> This isn't going to work if you don't patch the driver to add the
> compatible. And this isn't what you described in the binding patch.
oops, I will correct this in next patch series. Sorry.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: allwinner: h6: add i2c0 node in PineH64
From: Bhushan Shah @ 2019-08-16 8:21 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Wolfram Sang, Gregory CLEMENT,
Bhushan Shah, linux-kernel, Chen-Yu Tsai, Rob Herring, linux-i2c,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190816075211.xaq54q2cdniwjpp3@flea>
[-- Attachment #1.1: Type: text/plain, Size: 632 bytes --]
On Fri, Aug 16, 2019 at 09:52:11AM +0200, Maxime Ripard wrote:
> > +/* This i2c interface is exposed on PI-2 BUS, Pin 3 (I2C_SDA) and 5 (I2C_SCL) */
> > +&i2c0 {
> > + status = "disabled";
> > +};
>
> This property is set to disabled in the DTSI already
I added this node here with disabled status due to comment from wens in
previous revision, main reason being that serves as reference/pointer to
people looking at how to enable i2c0.
I can remove it if you prefer.
--
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 2/4] media: stm32-dcmi: trace the supported fourcc/mbus_code
From: Sakari Ailus @ 2019-08-16 8:15 UTC (permalink / raw)
To: Hugues Fruchet
Cc: Yannick Fertre, Alexandre Torgue, Mickael GUENE, linux-kernel,
Philippe CORNU, Hans Verkuil, Benjamin Gaignard,
Mauro Carvalho Chehab, linux-stm32, linux-arm-kernel, linux-media
In-Reply-To: <1565790533-10043-3-git-send-email-hugues.fruchet@st.com>
Hi Hugues,
On Wed, Aug 14, 2019 at 03:48:51PM +0200, Hugues Fruchet wrote:
> Add a trace of the set of supported fourcc/mbus_code which
> intersect between DCMI and source sub-device.
>
> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
> ---
> drivers/media/platform/stm32/stm32-dcmi.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index b462f71..18acecf 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -1447,12 +1447,20 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
> /* Code supported, have we got this fourcc yet? */
> for (j = 0; j < num_fmts; j++)
> if (sd_fmts[j]->fourcc ==
> - dcmi_formats[i].fourcc)
> + dcmi_formats[i].fourcc) {
> /* Already available */
> + dev_dbg(dcmi->dev, "Skipping fourcc/code: %4.4s/0x%x\n",
> + (char *)&sd_fmts[j]->fourcc,
> + mbus_code.code);
> break;
> - if (j == num_fmts)
> + }
> + if (j == num_fmts) {
> /* New */
> sd_fmts[num_fmts++] = dcmi_formats + i;
> + dev_dbg(dcmi->dev, "Supported fourcc/code: %4.4s/0x%x\n",
Over 80 characters per line.
> + (char *)&sd_fmts[num_fmts - 1]->fourcc,
> + sd_fmts[num_fmts - 1]->mbus_code);
> + }
> }
> mbus_code.index++;
> }
--
Regards,
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: do_csum: implement accelerated scalar version
From: Shaokun Zhang @ 2019-08-16 8:15 UTC (permalink / raw)
To: Will Deacon
Cc: Ard Biesheuvel, netdev, ilias.apalodimas, huanglingyan (A),
Robin Murphy, linux-arm-kernel, steve.capper
In-Reply-To: <20190815164609.GI2015@fuggles.cambridge.arm.com>
Hi Will,
On 2019/8/16 0:46, Will Deacon wrote:
> On Thu, May 16, 2019 at 11:14:35AM +0800, Zhangshaokun wrote:
>> On 2019/5/15 17:47, Will Deacon wrote:
>>> On Mon, Apr 15, 2019 at 07:18:22PM +0100, Robin Murphy wrote:
>>>> On 12/04/2019 10:52, Will Deacon wrote:
>>>>> I'm waiting for Robin to come back with numbers for a C implementation.
>>>>>
>>>>> Robin -- did you get anywhere with that?
>>>>
>>>> Still not what I would call finished, but where I've got so far (besides an
>>>> increasingly elaborate test rig) is as below - it still wants some unrolling
>>>> in the middle to really fly (and actual testing on BE), but the worst-case
>>>> performance already equals or just beats this asm version on Cortex-A53 with
>>>> GCC 7 (by virtue of being alignment-insensitive and branchless except for
>>>> the loop). Unfortunately, the advantage of C code being instrumentable does
>>>> also come around to bite me...
>>>
>>> Is there any interest from anybody in spinning a proper patch out of this?
>>> Shaokun?
>>
>> HiSilicon's Kunpeng920(Hi1620) benefits from do_csum optimization, if Ard and
>> Robin are ok, Lingyan or I can try to do it.
>> Of course, if any guy posts the patch, we are happy to test it.
>> Any will be ok.
>
> I don't mind who posts it, but Robin is super busy with SMMU stuff at the
> moment so it probably makes more sense for you or Lingyan to do it.
Thanks for restarting this topic, I or Lingyan will do it soon.
Thanks,
Shaokun
>
> 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 v2 3/3] arm64: allwinner: h6: add i2c0 node in PineH64
From: Maxime Ripard @ 2019-08-16 7:52 UTC (permalink / raw)
To: Bhushan Shah
Cc: Mark Rutland, devicetree, Wolfram Sang, Gregory CLEMENT,
linux-kernel, Chen-Yu Tsai, Rob Herring, linux-i2c,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190816064710.18280-4-bshah@kde.org>
[-- Attachment #1.1: Type: text/plain, Size: 1116 bytes --]
65;5603;1c
On Fri, Aug 16, 2019 at 12:17:10PM +0530, Bhushan Shah wrote:
> i2c0 bus is exposed by PI-2 BUS in the PineH64, model B.
>
> Signed-off-by: Bhushan Shah <bshah@kde.org>
> ---
> Changes in v2:
> - Don't enable the i2c0 node in PineH64 by default
>
> arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> index 684d1daa3081..97d9b7c63fb3 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> @@ -160,6 +160,15 @@
> vcc-pg-supply = <®_aldo1>;
> };
>
> +/* This i2c interface is exposed on PI-2 BUS, Pin 3 (I2C_SDA) and 5 (I2C_SCL) */
> +&i2c0 {
> + status = "disabled";
> +};
This property is set to disabled in the DTSI already
> +&i2c0_pins {
> + bias-pull-up;
> +};
> +
And this should be in the same overlay than the one that sets status
to okay.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: allwinner: h6: add I2C nodes
From: Maxime Ripard @ 2019-08-16 7:50 UTC (permalink / raw)
To: Bhushan Shah
Cc: Mark Rutland, devicetree, Wolfram Sang, Gregory CLEMENT,
linux-kernel, Chen-Yu Tsai, Rob Herring, linux-i2c,
linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20190816064710.18280-3-bshah@kde.org>
[-- Attachment #1.1: Type: text/plain, Size: 1530 bytes --]
On Fri, Aug 16, 2019 at 12:17:09PM +0530, Bhushan Shah wrote:
> Add device-tree nodes for i2c0 to i2c2, and also add relevant pinctrl
> nodes.
>
> Suggested-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Bhushan Shah <bshah@kde.org>
> ---
> Changes in v2:
> - Add the SoC specific compatible string instead of re-using a31 one.
>
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56 +++++++++++++++++++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index bcecca17d61d..a1a329926540 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -329,6 +329,21 @@
> function = "hdmi";
> };
>
> + i2c0_pins: i2c0-pins {
> + pins = "PD25", "PD26";
> + function = "i2c0";
> + };
> +
> + i2c1_pins: i2c1-pins {
> + pins = "PH5", "PH6";
> + function = "i2c1";
> + };
> +
> + i2c2_pins: i2c2-pins {
> + pins = "PD23", "PD24";
> + function = "i2c2";
> + };
> +
> mmc0_pins: mmc0-pins {
> pins = "PF0", "PF1", "PF2", "PF3",
> "PF4", "PF5";
> @@ -464,6 +479,45 @@
> status = "disabled";
> };
>
> + i2c0: i2c@5002000 {
> + compatible = "allwinner,sun50i-h6-i2c";
This isn't going to work if you don't patch the driver to add the
compatible. And this isn't what you described in the binding patch.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/6] dma-mapping: remove arch_dma_mmap_pgprot
From: Geert Uytterhoeven @ 2019-08-16 7:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, linux-m68k, Will Deacon, linuxppc-dev,
Linux Kernel Mailing List, Linux IOMMU, Paul Burton,
Catalin Marinas, James Hogan, Russell King, linux-mips,
Guan Xuetao, Linux ARM, Robin Murphy
In-Reply-To: <20190816070754.15653-5-hch@lst.de>
On Fri, Aug 16, 2019 at 9:19 AM Christoph Hellwig <hch@lst.de> wrote:
> arch_dma_mmap_pgprot is used for two things:
>
> 1) to override the "normal" uncached page attributes for mapping
> memory coherent to devices that can't snoop the CPU caches
> 2) to provide the special DMA_ATTR_WRITE_COMBINE semantics on older
> arm systems
>
> Replace one with the pgprot_dmacoherent macro that is already provided
> by arm and much simpler to use, and lift the DMA_ATTR_WRITE_COMBINE
> handling to common code with an explicit arch opt-in.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> arch/m68k/Kconfig | 1 -
> arch/m68k/include/asm/pgtable_mm.h | 3 +++
> arch/m68k/kernel/dma.c | 3 +--
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Geert Uytterhoeven @ 2019-08-16 7:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Shawn Guo, Fabio Estevam, Linux-Arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, linux-m68k, Minas Harutyunyan, Bin Liu, Linux ARM,
Laurentiu Tudor, Geoff Levand, Greg Kroah-Hartman, USB list,
Linux Kernel Mailing List, Linux IOMMU, Pengutronix Kernel Team,
linuxppc-dev
In-Reply-To: <20190816062435.881-7-hch@lst.de>
Hi Christoph,
On Fri, Aug 16, 2019 at 8:30 AM Christoph Hellwig <hch@lst.de> wrote:
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_device so that we can initialize
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default, replacing similar functionality in m68k and
> powerpc. The arch_setup_pdev_archdata hooks is now unused and removed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/m68k/kernel/dma.c | 9 -------
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> arch/sh/boards/mach-ecovec24/setup.c | 2 --
> arch/sh/boards/mach-migor/setup.c | 1 -
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
given "[PATCH 0/2] Remove calls to empty arch_setup_pdev_archdata()"
https://lore.kernel.org/linux-renesas-soc/1526641611-2769-1-git-send-email-geert+renesas@glider.be/
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 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Christoph Hellwig @ 2019-08-16 7:07 UTC (permalink / raw)
To: iommu
Cc: Shawn Anastasio, Will Deacon, linux-m68k, Guan Xuetao,
linuxppc-dev, linux-kernel, Russell King, linux-mips, Paul Burton,
Geert Uytterhoeven, Catalin Marinas, James Hogan, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190816070754.15653-1-hch@lst.de>
Based on an email from Will Deacon.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm64/include/asm/pgtable.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 6700371227d1..6ff221d9a631 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -435,6 +435,14 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
#define pgprot_device(prot) \
__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
+/*
+ * DMA allocations for non-coherent devices use what the Arm architecture calls
+ * "Normal non-cacheable" memory, which permits speculation, unaligned accesses
+ * and merging of writes. This is different from "Strongly Ordered" memory
+ * which is intended for MMIO and thus forbids speculation, preserves access
+ * size, requires strict alignment and also forces write responses to come from
+ * the endpoint.
+ */
#define pgprot_dmacoherent(prot) \
__pgprot_modify(prot, PTE_ATTRINDX_MASK, \
PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
--
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
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