* [RFC] Configure i.MX6 RGMII pad group control registers from device tree
From: Michal Vokáč @ 2018-06-12 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f5a01de5-fc81-52c1-c2ea-edb77ecff076@ysoft.com>
On 11.6.2018 14:36, Michal Vok?? wrote:
> Ahoj,
>
> To configure individual pad's characteristics on i.MX6 SoC a
> fsl,pins = <PIN_FUNC_ID CONFIG> property can be used. Is there any convenient
> way to configure the pad group control registers?
>
> The issue is that some bits (DDR_SEL and ODT) in the individual RGMII pad
> control registers are read-only. To tweak those parameters (signal voltage and
> termination resistors) one need to write to the pad group control registers for
> the whole RGMII pad group. Namely IOMUXC_SW_PAD_CTL_GRP_DDR_TYPE_RGMII and
> IOMUXC_SW_PAD_CTL_GRP_RGMII_TERM. The group registers in general are not
> accessible from the list in arch/arm/boot/dts/imx6dl-pinfunc.h.
>
> I could not find any other way to change the group registers than hacking-in
> some lines into the imx6q_init_machine(void) function in
> arch/arm/mach-imx/mach-imx6q.c source. As I work towards upstreaming my board
> this should be done from my device tree or solved in some universal way.
>
> Any hints will be much appreciated.
> Michal
I figured out this is more "pinctrl-imx.c" than "device-tree" related
so I am kindly adding maintainers of that file in hope somebody will
shed some light to it.
I am diving deeper into the code and it seems there really is no generic
option to set the i.MX6 pad group control registers from device tree.
Or am I looking at the problem from a wrong angle?
How should we deal with boards that need to configure some pad
characteristics available only through the pad group control registers?
I also raised this question at the NXP community forum [1] and get quite
unsatisfying answer so far. I would love to find/implement a proper
and universal solution.
Thanks in advance for your time,
Michal
[1] https://community.nxp.com/thread/477464
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Punit Agrawal @ 2018-06-12 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611145330.GO13364@dhcp22.suse.cz>
Michal Hocko <mhocko@kernel.org> writes:
> On Mon 11-06-18 08:43:03, Bjorn Helgaas wrote:
>> On Mon, Jun 11, 2018 at 08:32:10PM +0800, Xie XiuQi wrote:
>> > Hi Michal,
>> >
>> > On 2018/6/11 16:52, Michal Hocko wrote:
>> > > On Mon 11-06-18 11:23:18, Xie XiuQi wrote:
>> > >> Hi Michal,
>> > >>
>> > >> On 2018/6/7 20:21, Michal Hocko wrote:
>> > >>> On Thu 07-06-18 19:55:53, Hanjun Guo wrote:
>> > >>>> On 2018/6/7 18:55, Michal Hocko wrote:
>> > >>> [...]
>> > >>>>> I am not sure I have the full context but pci_acpi_scan_root calls
>> > >>>>> kzalloc_node(sizeof(*info), GFP_KERNEL, node)
>> > >>>>> and that should fall back to whatever node that is online. Offline node
>> > >>>>> shouldn't keep any pages behind. So there must be something else going
>> > >>>>> on here and the patch is not the right way to handle it. What does
>> > >>>>> faddr2line __alloc_pages_nodemask+0xf0 tells on this kernel?
>> > >>>>
>> > >>>> The whole context is:
>> > >>>>
>> > >>>> The system is booted with a NUMA node has no memory attaching to it
>> > >>>> (memory-less NUMA node), also with NR_CPUS less than CPUs presented
>> > >>>> in MADT, so CPUs on this memory-less node are not brought up, and
>> > >>>> this NUMA node will not be online (but SRAT presents this NUMA node);
>> > >>>>
>> > >>>> Devices attaching to this NUMA node such as PCI host bridge still
>> > >>>> return the valid NUMA node via _PXM, but actually that valid NUMA node
>> > >>>> is not online which lead to this issue.
>> > >>>
>> > >>> But we should have other numa nodes on the zonelists so the allocator
>> > >>> should fall back to other node. If the zonelist is not intiailized
>> > >>> properly, though, then this can indeed show up as a problem. Knowing
>> > >>> which exact place has blown up would help get a better picture...
>> > >>>
>> > >>
>> > >> I specific a non-exist node to allocate memory using kzalloc_node,
>> > >> and got this following error message.
>> > >>
>> > >> And I found out there is just a VM_WARN, but it does not prevent the memory
>> > >> allocation continue.
>> > >>
>> > >> This nid would be use to access NODE_DADA(nid), so if nid is invalid,
>> > >> it would cause oops here.
>> > >>
>> > >> 459 /*
>> > >> 460 * Allocate pages, preferring the node given as nid. The node must be valid and
>> > >> 461 * online. For more general interface, see alloc_pages_node().
>> > >> 462 */
>> > >> 463 static inline struct page *
>> > >> 464 __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
>> > >> 465 {
>> > >> 466 VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
>> > >> 467 VM_WARN_ON(!node_online(nid));
>> > >> 468
>> > >> 469 return __alloc_pages(gfp_mask, order, nid);
>> > >> 470 }
>> > >> 471
>> > >>
>> > >> (I wrote a ko, to allocate memory on a non-exist node using kzalloc_node().)
>> > >
>> > > OK, so this is an artificialy broken code, right. You shouldn't get a
>> > > non-existent node via standard APIs AFAICS. The original report was
>> > > about an existing node which is offline AFAIU. That would be a different
>> > > case. If I am missing something and there are legitimate users that try
>> > > to allocate from non-existing nodes then we should handle that in
>> > > node_zonelist.
>> >
>> > I think hanjun's comments may help to understood this question:
>> > - NUMA node will be built if CPUs and (or) memory are valid on this NUMA
>> > node;
>> >
>> > - But if we boot the system with memory-less node and also with
>> > CONFIG_NR_CPUS less than CPUs in SRAT, for example, 64 CPUs total with 4
>> > NUMA nodes, 16 CPUs on each NUMA node, if we boot with
>> > CONFIG_NR_CPUS=48, then we will not built numa node for node 3, but with
>> > devices on that numa node, alloc memory will be panic because NUMA node
>> > 3 is not a valid node.
>
> Hmm, but this is not a memory-less node. It sounds like a misconfigured
> kernel to me or the broken initialization. Each CPU should have a
> fallback numa node to be used.
>
>> > I triggered this BUG on arm64 platform, and I found a similar bug has
>> > been fixed on x86 platform. So I sent a similar patch for this bug.
>> >
>> > Or, could we consider to fix it in the mm subsystem?
>>
>> The patch below (b755de8dfdfe) seems like totally the wrong direction.
>> I don't think we want every caller of kzalloc_node() to have check for
>> node_online().
>
> absolutely.
>
>> Why would memory on an off-line node even be in the allocation pool?
>> I wouldn't expect that memory to be put in the pool until the node
>> comes online and the memory is accessible, so this sounds like some
>> kind of setup issue.
>>
>> But I'm definitely not an mm person.
>
> Well, the standard way to handle memory less NUMA nodes is to simply
> fallback to the closest NUMA node. We even have an API for that
> (numa_mem_id).
CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end
up returning the original node in the fallback path.
Xie, does the below patch help? I can submit a proper patch if this
fixes the issue for you.
-- >8 --
Subject: [PATCH] arm64/numa: Enable memoryless numa nodes
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
---
arch/arm64/Kconfig | 4 ++++
arch/arm64/mm/numa.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index eb2cf4938f6d..5317e9aa93ab 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -756,6 +756,10 @@ config USE_PERCPU_NUMA_NODE_ID
def_bool y
depends on NUMA
+config HAVE_MEMORYLESS_NODES
+ def_bool y
+ depends on NUMA
+
config HAVE_SETUP_PER_CPU_AREA
def_bool y
depends on NUMA
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index dad128ba98bf..c699dcfe93de 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -73,6 +73,8 @@ EXPORT_SYMBOL(cpumask_of_node);
static void map_cpu_to_node(unsigned int cpu, int nid)
{
set_cpu_numa_node(cpu, nid);
+ set_numa_mem(local_memory_node(nid));
+
if (nid >= 0)
cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
}
--
2.17.0
^ permalink raw reply related
* [PATCH v3 0/5] PM / Domains: Add support for multi PM domains per device
From: Rafael J. Wysocki @ 2018-06-12 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531105959.14843-1-ulf.hansson@linaro.org>
On Thursday, May 31, 2018 12:59:54 PM CEST Ulf Hansson wrote:
> Changes in v3:
> - Drop patch 1->4 as they have already been applied.
> - Collected tags, for tests and reviews.
> - Minor update to function descriptions in patch 4 (earlier 8) and 5
> (earlier9).
> - Note, because of the minor changes, no history is provided per patch.
>
> Changes in v2:
> - Addressed comments from Geert around DT doc.
> - Addressed comments from Jon around clarification of how to use this
> and changes to returned error codes.
> - Fixed build error in case CONFIG_PM was unset.
>
> There are devices that are partitioned across multiple PM domains. Currently
> these can't be supported well by the available PM infrastructures we have in
> the kernel. This series is an attempt to address this.
>
> One existing case where devices are partitioned across multiple PM domains, is
> the Nvida Tegra 124/210 X-USB subsystem. A while ago Jon Hunter (Nvidia) sent a
> series, trying to address these issues, however this is a new approach, while
> it re-uses the same concepts from DT point of view.
>
> The Tegra 124/210 X-USB subsystem contains of a host controller and a device
> controller. Each controller have its own independent PM domain, but are being
> partitioned across another shared PM domain for the USB super-speed logic.
>
> Currently to make the drivers work, either the related PM domains needs to stay
> powered on always or the PM domain topology needs to be in-correctly modelled
> through sub-domains. In both cases PM domains may be powered on while they
> don't need to be, so in the end this means - wasting power -.
>
> As stated above, this series intends to address these problem from a PM
> infrastructure point of view. More details are available in each changelog.
>
> Kind regards
> Ulf Hansson
>
> Ulf Hansson (5):
> PM / Domains: dt: Allow power-domain property to be a list of
> specifiers
> PM / Domains: Don't attach devices in genpd with multi PM domains
> PM / Domains: Split genpd_dev_pm_attach()
> PM / Domains: Add support for multi PM domains per device to genpd
> PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM
> domains
>
> .../bindings/power/power_domain.txt | 19 ++-
> drivers/base/power/common.c | 43 +++++-
> drivers/base/power/domain.c | 134 +++++++++++++++---
> include/linux/pm_domain.h | 15 ++
> 4 files changed, 183 insertions(+), 28 deletions(-)
>
>
Applied, thanks!
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: imx6q: check speed grades for i.MX6ULL
From: Rafael J. Wysocki @ 2018-06-12 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611053826.GC16091@dragon>
On Monday, June 11, 2018 7:38:27 AM CEST Shawn Guo wrote:
> On Tue, May 22, 2018 at 08:28:51AM +0200, S?bastien Szymanski wrote:
> > Check the max speed supported from the fuses for i.MX6ULL and update the
> > operating points table accordingly.
> >
> > Signed-off-by: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
Patch applied, thanks!
^ permalink raw reply
* [PATCH RESEND v4 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: gengdongjiu @ 2018-06-12 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af93e4b1-80d5-33be-d5ed-312c3ea1d715@arm.com>
On 2018/6/11 21:36, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 09/06/18 13:40, Marc Zyngier wrote:
>> On Fri, 08 Jun 2018 20:48:40 +0100, Dongjiu Geng wrote:
>>> For the migrating VMs, user space may need to know the exception
>>> state. For example, in the machine A, KVM make an SError pending,
>>> when migrate to B, KVM also needs to pend an SError.
>>>
>>> This new IOCTL exports user-invisible states related to SError.
>>> Together with appropriate user space changes, user space can get/set
>>> the SError exception state to do migrate/snapshot/suspend.
>
>>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>>> index 04b3256..df4faee 100644
>>> --- a/arch/arm64/include/uapi/asm/kvm.h
>>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>>> @@ -153,6 +154,18 @@ struct kvm_sync_regs {
>>> struct kvm_arch_memory_slot {
>>> };
>>>
>>> +/* for KVM_GET/SET_VCPU_EVENTS */
>>> +struct kvm_vcpu_events {
>>> + struct {
>>> + __u8 serror_pending;
>>> + __u8 serror_has_esr;
>>> + /* Align it to 8 bytes */
>>> + __u8 pad[6];
>>> + __u64 serror_esr;
>>> + } exception;
>>> + __u32 reserved[12];
>>> +};
>
>>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>>> index 56a0260..4426915 100644
>>> --- a/arch/arm64/kvm/guest.c
>>> +++ b/arch/arm64/kvm/guest.c
>
>>> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
>>> + struct kvm_vcpu_events *events)
>>> +{
>>> + bool serror_pending = events->exception.serror_pending;
>>> + bool has_esr = events->exception.serror_has_esr;
>>> +
>>> + if (serror_pending && has_esr) {
>>> + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
>>> + return -EINVAL;
>>> +
>>> + kvm_set_sei_esr(vcpu, events->exception.serror_esr);
>>> + } else if (serror_pending) {
>>> + kvm_inject_vabt(vcpu);
>>> + }
>>> +
>>> + return 0;
>>
>> There was an earlier request to check that all the padding is set to
>> zero. I still think this makes sense.
>
> I agree, not just the exception.padding[], but reserved[] too.
Ok, thanks for the reminder again.
>
>
> Thanks,
>
> James
>
> .
>
^ permalink raw reply
* [PATCH RESEND v4 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: gengdongjiu @ 2018-06-12 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45e94aae-ed9f-1fb7-f10e-d95c2f969ddd@arm.com>
Hi James,
thanks for the review.
On 2018/6/11 21:36, James Morse wrote:
> Hi Dongjiu Geng,
>
> Please only put 'RESEND' in the subject if the patch content is identical.
> This patch is not the same as v4.
Yes, it should
>
> On 08/06/18 20:48, Dongjiu Geng wrote:
>> For the migrating VMs, user space may need to know the exception
>> state. For example, in the machine A, KVM make an SError pending,
>> when migrate to B, KVM also needs to pend an SError.
>>
>> This new IOCTL exports user-invisible states related to SError.
>> Together with appropriate user space changes, user space can get/set
>> the SError exception state to do migrate/snapshot/suspend.
>
>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>> index fdac969..8896737 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -835,11 +835,13 @@ struct kvm_clock_data {
>>
>> Capability: KVM_CAP_VCPU_EVENTS
>> Extended by: KVM_CAP_INTR_SHADOW
>> -Architectures: x86
>> +Architectures: x86, arm, arm64
>> Type: vm ioctl
>
> Isn't this actually a per-vcpu ioctl? Can we fix the documentation?
I will modify the original documentation
>
>
>> Parameters: struct kvm_vcpu_event (out)
>> Returns: 0 on success, -1 on error
>>
>> +X86:
>> +
>> Gets currently pending exceptions, interrupts, and NMIs as well as related
>> states of the vcpu.
>>
>> @@ -881,15 +883,32 @@ Only two fields are defined in the flags field:
>> - KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
>> smi contains a valid state.
>>
>> +ARM, ARM64:
>> +
>> +Gets currently pending SError exceptions as well as related states of the vcpu.
>> +
>> +struct kvm_vcpu_events {
>> + struct {
>> + __u8 serror_pending;
>> + __u8 serror_has_esr;
>> + /* Align it to 8 bytes */
>> + __u8 pad[6];
>> + __u64 serror_esr;
>> + } exception;
>> + __u32 reserved[12];
>> +};
>> +
>> 4.32 KVM_SET_VCPU_EVENTS
>>
>> -Capability: KVM_CAP_VCPU_EVENTS
>> +Capebility: KVM_CAP_VCPU_EVENTS
>
> (please fix this)
Ok, will fix this
>
>
>> Extended by: KVM_CAP_INTR_SHADOW
>> -Architectures: x86
>> +Architectures: x86, arm, arm64
>> Type: vm ioctl
>
> (this is also a vcpu ioctl)
will fix
>
>
>> Parameters: struct kvm_vcpu_event (in)
>> Returns: 0 on success, -1 on error
>>
>> +X86:
>> +
>> Set pending exceptions, interrupts, and NMIs as well as related states of the
>> vcpu.
>>
>> @@ -910,6 +929,12 @@ shall be written into the VCPU.
>>
>> KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
>>
>> +ARM, ARM64:
>> +
>> +Set pending SError exceptions as well as related states of the vcpu.
>
> There are some deliberate choices here I think we should document:
> | This API can't be used to clear a pending SError.
>
> If there already was an SError pending, this API just overwrites it with the new
> one. The architecture has some rules about merging multiple SError. (details in
> 2.5.3 Multiple SError interrupts of [0])
>
> I don't think KVM needs to enforce these, as they are implementation-defined if
> one of the ESR is implementation-defined... the part that matters is reporting
> the 'most severe' RAS ESR if there are multiple pending. As only user-space ever
> sets these, let's make it user-spaces problem to do.
>
> I think we should recommend user-space always reads the pending values and
> applies its merging-multiple-SError logic. (I assume your Qemu patches do this).
I will check whether QEMU can be possible to do such things, anyway this patch
not need to do such merging.
> Something like:
> | User-space should first use KVM_GET_VCPU_EVENTS in case KVM has made an SError
> | pending as part of its device emulation. When both values are architected RAS
> | SError ESR values, the new ESR should reflect the combined effect of both
> | errors.>
>
>> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
>> index caae484..c3e6975 100644
>> --- a/arch/arm/include/uapi/asm/kvm.h
>> +++ b/arch/arm/include/uapi/asm/kvm.h
>> @@ -124,6 +124,18 @@ struct kvm_sync_regs {
>> struct kvm_arch_memory_slot {
>> };
>>
>> +/* for KVM_GET/SET_VCPU_EVENTS */
>> +struct kvm_vcpu_events {
>> + struct {
>> + __u8 serror_pending;
>> + __u8 serror_has_esr;
>> + /* Align it to 8 bytes */
>> + __u8 pad[6];
>> + __u64 serror_esr;
>> + } exception;
>> + __u32 reserved[12];
>> +};
>> +
>
> You haven't defined __KVM_HAVE_VCPU_EVENTS for 32bit, so presumably this struct
> will never be used. Why is it here?
if not add it for 32 bits. the 32 arm platform will build Fail, whether you have good
idea to avoid this Failure if not add this struct for the 32 bit?
> (I agree if we ever provide it on 32bit, the struct layout should be the same.
> Is this only here to force that to happen?)
>
> [...]
>
>
>> +int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
>> + struct kvm_vcpu_events *events)
>> +{
>> + bool serror_pending = events->exception.serror_pending;
>> + bool has_esr = events->exception.serror_has_esr;
>> +
>> + if (serror_pending && has_esr) {
>> + if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
>> + return -EINVAL;
>> +
>> + kvm_set_sei_esr(vcpu, events->exception.serror_esr);
>
> kvm_set_sei_esr() will silently discard the top 40 bits of serror_esr, (which is
> correct, we shouldn't copy them into hardware without know what they do).
>
> Could we please force user-space to zero these bits, we can advertise extra CAPs
> if new features turn up in that space, instead of user-space passing <something>
> and relying on the kernel to remove it.
yes, I can zero these bits in the user-space and not depend on kernel to remove it.
>
> (Background: VSESR is a 64bit register that holds the value to go in a 32bit
> register. I suspect the top-half could get re-used for control values or
> something we don't want to give user-space)
do you mean when user-space get the VSESR value through KVM_GET_VCPU_EVENTS it only return the low-half 32 bits?
>
>
>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
>> index d8e7165..a55e91d 100644
>> --- a/arch/arm64/kvm/inject_fault.c
>> +++ b/arch/arm64/kvm/inject_fault.c
>> @@ -164,9 +164,9 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
>> inject_undef64(vcpu);
>> }
>>
>> -static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
>> +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 esr)
>> {
>> - vcpu_set_vsesr(vcpu, esr);
>> + vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
>> *vcpu_hcr(vcpu) |= HCR_VSE;
>> }
>>
>
>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>> index a4c1b76..79ecba9 100644
>> --- a/virt/kvm/arm/arm.c
>> +++ b/virt/kvm/arm/arm.c
>> @@ -1107,6 +1107,25 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>
>> + case KVM_SET_VCPU_EVENTS: {
>> + struct kvm_vcpu_events events;
>> +
>> + if (copy_from_user(&events, argp, sizeof(events)))
>> + return -EFAULT;
>> +
>> + return kvm_arm_vcpu_set_events(vcpu, &events);
>> + }
>
> Please check the padding[] and reserved[] are zero, otherwise we can't re-use these.
Ok, thanks
>
>
> Thanks,
>
> James
>
> [0]
> https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf
>
> .
>
^ permalink raw reply
* [RFC V2 3/3] perf: qcom: Add Falkor CPU PMU IMPLEMENTATION DEFINED event support
From: Mark Rutland @ 2018-06-12 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528379808-27970-4-git-send-email-agustinv@codeaurora.org>
Hi,
On Thu, Jun 07, 2018 at 09:56:48AM -0400, Agustin Vega-Frias wrote:
> Selection of these events can be envisioned as indexing them from
> a 3D matrix:
> - the first index selects a Region Event Selection Register (PMRESRx_EL0)
> - the second index selects a group from which only one event at a time
> can be selected
> - the third index selects the event
>
> The event is encoded into perf_event_attr.config as 0xPRCCG, where:
> P [config:16 ] = prefix (flag that indicates a matrix-based event)
> R [config:12-15] = register (specifies the PMRESRx_EL0 instance)
> G [config:0-3 ] = group (specifies the event group)
> CC [config:4-11 ] = code (specifies the event)
>
> Events with the P flag set to zero are treated as common PMUv3 events
> and are directly programmed into PMXEVTYPERx_EL0.
>
> The first two indexes are set combining the RESR and group number with
> a base number and writing it into the architected PMXEVTYPER_EL0 register.
> The third index is set by writing the code into the bits corresponding
> with the group into the appropriate IMPLEMENTATION DEFINED PMRESRx_EL0
> register.
When are the IMP DEF registers accessible at EL0? Are those goverend by
the same controls as the architected registers?
[...]
> +/*
> + * Qualcomm Technologies CPU PMU IMPLEMENTATION DEFINED extensions support
> + *
> + * Current extensions supported:
> + *
> + * - Matrix-based microarchitectural events support
> + *
> + * Selection of these events can be envisioned as indexing them from
> + * a 3D matrix:
> + * - the first index selects a Region Event Selection Register (PMRESRx_EL0)
> + * - the second index selects a group from which only one event at a time
> + * can be selected
> + * - the third index selects the event
> + *
> + * The event is encoded into perf_event_attr.config as 0xPRCCG, where:
> + * P [config:16 ] = prefix (flag that indicates a matrix-based event)
> + * R [config:12-15] = register (specifies the PMRESRx_EL0 instance)
> + * G [config:0-3 ] = group (specifies the event group)
> + * CC [config:4-11 ] = code (specifies the event)
> + *
> + * Events with the P flag set to zero are treated as common PMUv3 events
> + * and are directly programmed into PMXEVTYPERx_EL0.
When PMUv3 is given a raw event code, the config fields should be the
PMU event number, and this conflicts with RESERVED encodings.
I'd rather we used a separate field for the QC extension events. e.g.
turn config1 into a flags field, and move the P flag there.
We *should* add code to sanity check those fields are zero in the PMUv3
driver, even though it's a potential ABI break to start now.
> + *
> + * The first two indexes are set combining the RESR and group number with
> + * a base number and writing it into the architected PMXEVTYPER_EL0 register.
> + * The third index is set by writing the code into the bits corresponding
> + * with the group into the appropriate IMPLEMENTATION DEFINED PMRESRx_EL0
> + * register.
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/perf/arm_pmu.h>
You'll also need:
#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/perf_event.h>
#include <linux/printk.h>
#include <linux/types.h>
#include <asm/barrier.h>
#include <asm/sysreg.h>
> +
> +#define pmresr0_el0 sys_reg(3, 5, 11, 3, 0)
> +#define pmresr1_el0 sys_reg(3, 5, 11, 3, 2)
> +#define pmresr2_el0 sys_reg(3, 5, 11, 3, 4)
> +#define pmxevcntcr_el0 sys_reg(3, 5, 11, 0, 3)
> +
> +#define QC_EVT_PFX_SHIFT 16
> +#define QC_EVT_REG_SHIFT 12
> +#define QC_EVT_CODE_SHIFT 4
> +#define QC_EVT_GRP_SHIFT 0
> +#define QC_EVT_PFX_MASK GENMASK(QC_EVT_PFX_SHIFT, QC_EVT_PFX_SHIFT)
> +#define QC_EVT_REG_MASK GENMASK(QC_EVT_REG_SHIFT + 3, QC_EVT_REG_SHIFT)
> +#define QC_EVT_CODE_MASK GENMASK(QC_EVT_CODE_SHIFT + 7, QC_EVT_CODE_SHIFT)
> +#define QC_EVT_GRP_MASK GENMASK(QC_EVT_GRP_SHIFT + 3, QC_EVT_GRP_SHIFT)
> +#define QC_EVT_PRG_MASK (QC_EVT_PFX_MASK | QC_EVT_REG_MASK | QC_EVT_GRP_MASK)
> +#define QC_EVT_PRG(event) ((event) & QC_EVT_PRG_MASK)
> +#define QC_EVT_REG(event) (((event) & QC_EVT_REG_MASK) >> QC_EVT_REG_SHIFT)
> +#define QC_EVT_CODE(event) (((event) & QC_EVT_CODE_MASK) >> QC_EVT_CODE_SHIFT)
> +#define QC_EVT_GROUP(event) (((event) & QC_EVT_GRP_MASK) >> QC_EVT_GRP_SHIFT)
> +
> +#define QC_MAX_GROUP 7
> +#define QC_MAX_RESR 2
> +#define QC_BITS_PER_GROUP 8
> +#define QC_RESR_ENABLE BIT_ULL(63)
> +#define QC_RESR_EVT_BASE 0xd8
> +
> +static struct arm_pmu *def_ops;
> +
> +static inline void falkor_write_pmresr(u64 reg, u64 val)
> +{
> + if (reg == 0)
> + write_sysreg_s(val, pmresr0_el0);
> + else if (reg == 1)
> + write_sysreg_s(val, pmresr1_el0);
> + else
> + write_sysreg_s(val, pmresr2_el0);
> +}
> +
> +static inline u64 falkor_read_pmresr(u64 reg)
> +{
> + return (reg == 0 ? read_sysreg_s(pmresr0_el0) :
> + reg == 1 ? read_sysreg_s(pmresr1_el0) :
> + read_sysreg_s(pmresr2_el0));
> +}
Please use switch statements for both of these.
> +
> +static void falkor_set_resr(u64 reg, u64 group, u64 code)
> +{
> + u64 shift = group * QC_BITS_PER_GROUP;
> + u64 mask = GENMASK(shift + QC_BITS_PER_GROUP - 1, shift);
> + u64 val;
> +
> + val = falkor_read_pmresr(reg) & ~mask;
> + val |= (code << shift);
> + val |= QC_RESR_ENABLE;
> + falkor_write_pmresr(reg, val);
> +}
> +
> +static void falkor_clear_resr(u64 reg, u64 group)
> +{
> + u32 shift = group * QC_BITS_PER_GROUP;
> + u64 mask = GENMASK(shift + QC_BITS_PER_GROUP - 1, shift);
> + u64 val = falkor_read_pmresr(reg) & ~mask;
> +
> + falkor_write_pmresr(reg, val == QC_RESR_ENABLE ? 0 : val);
> +}
> +
> +/*
> + * Check if e1 and e2 conflict with each other
> + *
> + * e1 is a matrix-based microarchitectural event we are checking against e2.
> + * A conflict exists if the events use the same reg, group, and a different
> + * code. Events with the same code are allowed because they could be using
> + * different filters (e.g. one to count user space and the other to count
> + * kernel space events).
> + */
What problem occurs when there's a conflict?
Does the filter matter at all? When happens if I open two identical
events, both counting the same reg, group, and code, with the same
filter?
> +static inline int events_conflict(struct perf_event *e1, struct perf_event *e2)
> +{
> + if ((e1 != e2) &&
> + (e1->pmu == e2->pmu) &&
> + (QC_EVT_PRG(e1->attr.config) == QC_EVT_PRG(e2->attr.config)) &&
> + (QC_EVT_CODE(e1->attr.config) != QC_EVT_CODE(e2->attr.config))) {
> + pr_debug_ratelimited(
> + "Group exclusion: conflicting events %llx %llx\n",
> + e1->attr.config,
> + e2->attr.config);
> + return 1;
> + }
> + return 0;
> +}
This would be easier to read as a series of tests:
static inline bool events_conflict(struct perf_event *new,
struct perf_event *other)
{
/* own group leader */
if (new == other)
return false;
/* software events can't conflict */
if (is_sw_event(other))
return false;
/* No conflict if using different reg or group */
if (QC_EVT_PRG(new->attr.config) != QC_EVT_PRG(other->attr.config))
return false;
/* Same reg and group is fine so long as code matches */
if (QC_EVT_CODE(new->attr.config) == QC_EVT_PRG(other->attr.config)
return false;
pr_debug_ratelimited("Group exclusion: conflicting events %llx %llx\n",
new->attr.config, other->attr.config);
return true;
}
> +
> +/*
> + * Check if the given event is valid for the PMU and if so return the value
> + * that can be used in PMXEVTYPER_EL0 to select the event
> + */
> +static int falkor_map_event(struct perf_event *event)
> +{
> + u64 reg = QC_EVT_REG(event->attr.config);
> + u64 group = QC_EVT_GROUP(event->attr.config);
> + struct perf_event *leader;
> + struct perf_event *sibling;
> +
> + if (!(event->attr.config & QC_EVT_PFX_MASK))
> + /* Common PMUv3 event, forward to the original op */
> + return def_ops->map_event(event);
The QC event codes should only be used when either:
* event->attr.type is PERF_TYPE_RAW, or:
* event->pmu.type is this PMU's dynamic type
... otherwise this will accept events meant for other PMUs, and/or
override conflicting events in other type namespaces (e.g.
PERF_EVENT_TYPE_HW, PERF_EVENT_TYPE_CACHE).
> +
> + /* Is it a valid matrix event? */
> + if ((group > QC_MAX_GROUP) || (reg > QC_MAX_RESR))
> + return -ENOENT;
> +
> + /* If part of an event group, check if the event can be put in it */
> +
> + leader = event->group_leader;
> + if (events_conflict(event, leader))
> + return -ENOENT;
> +
> + for_each_sibling_event(sibling, leader)
> + if (events_conflict(event, sibling))
> + return -ENOENT;
> +
> + return QC_RESR_EVT_BASE + reg*8 + group;
Nit: spacing around binary operators please.
> +}
> +
> +/*
> + * Find a slot for the event on the current CPU
> + */
> +static int falkor_get_event_idx(struct pmu_hw_events *cpuc, struct perf_event *event)
> +{
> + int idx;
> +
> + if (!!(event->attr.config & QC_EVT_PFX_MASK))
The '!!' isn't required.
> + /* Matrix event, check for conflicts with existing events */
> + for_each_set_bit(idx, cpuc->used_mask, ARMPMU_MAX_HWEVENTS)
> + if (cpuc->events[idx] &&
> + events_conflict(event, cpuc->events[idx]))
> + return -ENOENT;
> +
> + /* Let the original op handle the rest */
> + idx = def_ops->get_event_idx(cpuc, event);
Same comments as for falkor_map_event().
> +
> + /*
> + * This is called for actually allocating the events, but also with
> + * a dummy pmu_hw_events when validating groups, for that case we
> + * need to ensure that cpuc->events[idx] is NULL so we don't use
> + * an uninitialized pointer. Conflicts for matrix events in groups
> + * are checked during event mapping anyway (see falkor_event_map).
> + */
> + cpuc->events[idx] = NULL;
> +
> + return idx;
> +}
> +
> +/*
> + * Reset the PMU
> + */
> +static void falkor_reset(void *info)
> +{
> + struct arm_pmu *pmu = (struct arm_pmu *)info;
> + u32 i, ctrs = pmu->num_events;
> +
> + /* PMRESRx_EL0 regs are unknown at reset, except for the EN field */
> + for (i = 0; i <= QC_MAX_RESR; i++)
> + falkor_write_pmresr(i, 0);
> +
> + /* PMXEVCNTCRx_EL0 regs are unknown at reset */
> + for (i = 0; i <= ctrs; i++) {
> + write_sysreg(i, pmselr_el0);
> + isb();
> + write_sysreg_s(0, pmxevcntcr_el0);
> + }
> +
> + /* Let the original op handle the rest */
> + def_ops->reset(info);
> +}
> +
> +/*
> + * Enable the given event
> + */
> +static void falkor_enable(struct perf_event *event)
> +{
> + if (!!(event->attr.config & QC_EVT_PFX_MASK)) {
The '!!' isn't required.
> + /* Matrix event, program the appropriate PMRESRx_EL0 */
> + struct arm_pmu *pmu = to_arm_pmu(event->pmu);
> + struct pmu_hw_events *events = this_cpu_ptr(pmu->hw_events);
> + u64 reg = QC_EVT_REG(event->attr.config);
> + u64 code = QC_EVT_CODE(event->attr.config);
> + u64 group = QC_EVT_GROUP(event->attr.config);
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(&events->pmu_lock, flags);
> + falkor_set_resr(reg, group, code);
> + raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
Why is the spinlock required?
AFACIT this should only ever be called in contexts where IRQs are
disabled already.
> + }
> +
> + /* Let the original op handle the rest */
> + def_ops->enable(event);
> +}
> +
> +/*
> + * Disable the given event
> + */
> +static void falkor_disable(struct perf_event *event)
> +{
> + /* Use the original op to disable the counter and interrupt */
> + def_ops->enable(event);
> +
> + if (!!(event->attr.config & QC_EVT_PFX_MASK)) {
> + /* Matrix event, de-program the appropriate PMRESRx_EL0 */
> + struct arm_pmu *pmu = to_arm_pmu(event->pmu);
> + struct pmu_hw_events *events = this_cpu_ptr(pmu->hw_events);
> + u64 reg = QC_EVT_REG(event->attr.config);
> + u64 group = QC_EVT_GROUP(event->attr.config);
> + unsigned long flags;
> +
> + raw_spin_lock_irqsave(&events->pmu_lock, flags);
> + falkor_clear_resr(reg, group);
> + raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
> + }
> +}
Same comments as with falkor_enable().
> +
> +PMU_FORMAT_ATTR(event, "config:0-15");
> +PMU_FORMAT_ATTR(prefix, "config:16");
> +PMU_FORMAT_ATTR(reg, "config:12-15");
> +PMU_FORMAT_ATTR(code, "config:4-11");
> +PMU_FORMAT_ATTR(group, "config:0-3");
What sort of events are available? Do you plan to add anything to the
userspace event database in tools/perf/pmu-events/ ?
> +
> +static struct attribute *falkor_pmu_formats[] = {
> + &format_attr_event.attr,
> + &format_attr_prefix.attr,
> + &format_attr_reg.attr,
> + &format_attr_code.attr,
> + &format_attr_group.attr,
> + NULL,
> +};
> +
> +static struct attribute_group falkor_pmu_format_attr_group = {
> + .name = "format",
> + .attrs = falkor_pmu_formats,
> +};
> +
> +static int qcom_falkor_pmu_init(struct arm_pmu *pmu, struct device *dev)
> +{
> + /* Save base arm_pmu so we can invoke its ops when appropriate */
> + def_ops = devm_kmemdup(dev, pmu, sizeof(*def_ops), GFP_KERNEL);
> + if (!def_ops) {
> + pr_warn("Failed to allocate arm_pmu for QCOM extensions");
> + return -ENODEV;
> + }
> +
> + pmu->name = "qcom_pmuv3";
All the other CPU PMUs on an ARM ACPI system will have an index suffix,
e.g. "armv8_pmuv3_0". I can see why we might want to change the name to
indicate the QC extensions, but I think we should keep the existing
pattern, with a '_0' suffix here.
> +
> + /* Override the necessary ops */
> + pmu->map_event = falkor_map_event;
> + pmu->get_event_idx = falkor_get_event_idx;
> + pmu->reset = falkor_reset;
> + pmu->enable = falkor_enable;
> + pmu->disable = falkor_disable;
I'm somewhat concerned by hooking into the existing PMU code at this
level, but I don't currently have a better suggestion.
Thanks,
Mark.
> +
> + /* Override the necessary attributes */
> + pmu->pmu.attr_groups[ARMPMU_ATTR_GROUP_FORMATS] =
> + &falkor_pmu_format_attr_group;
> +
> + return 1;
> +}
> +
> +ACPI_DECLARE_PMU_VARIANT(qcom_falkor, "QCOM8150", qcom_falkor_pmu_init);
> --
> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
>
^ permalink raw reply
* [PATCH] drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()'
From: Neil Armstrong @ 2018-06-12 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611165335.24542-1-christophe.jaillet@wanadoo.fr>
On 11/06/2018 18:53, Christophe JAILLET wrote:
> If 'platform_get_resource_byname()' fails, we should release some resources
> before leaving, as already done in the other error handling path of the
> function.
>
> Fixes: acaa3f13b8dd ("drm/meson: Fix potential NULL dereference in meson_drv_bind_master()")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/gpu/drm/meson/meson_drv.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c
> index 32b1a6cdecfc..d3443125e661 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -197,8 +197,10 @@ static int meson_drv_bind_master(struct device *dev, bool has_components)
> priv->io_base = regs;
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hhi");
> - if (!res)
> - return -EINVAL;
> + if (!res) {
> + ret = -EINVAL;
> + goto free_drm;
> + }
> /* Simply ioremap since it may be a shared register zone */
> regs = devm_ioremap(dev, res->start, resource_size(res));
> if (!regs) {
> @@ -215,8 +217,10 @@ static int meson_drv_bind_master(struct device *dev, bool has_components)
> }
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dmc");
> - if (!res)
> - return -EINVAL;
> + if (!res) {
> + ret = -EINVAL;
> + goto free_drm;
> + }
> /* Simply ioremap since it may be a shared register zone */
> regs = devm_ioremap(dev, res->start, resource_size(res));
> if (!regs) {
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
I'll push it when rc1 is tagged.
Neil
^ permalink raw reply
* [PATCH v7 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Rafael J. Wysocki @ 2018-06-12 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <daba73df-037c-2583-3a08-f3f27c4129d1@pengutronix.de>
On Tuesday, June 12, 2018 2:42:12 PM CEST Oleksij Rempel wrote:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --Sj2PRcQlY7eZybdA0sq9wWzJEO8fKS924
> Content-Type: multipart/mixed; boundary="d6BZYFRi4L3iCmOh3nm6wjii3dWC9QFDg";
> protected-headers="v1"
> From: Oleksij Rempel <o.rempel@pengutronix.de>
> To: Shawn Guo <shawnguo@kernel.org>, Mark Brown <broonie@kernel.org>,
> "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> Cc: kernel at pengutronix.de, devicetree at vger.kernel.org,
> linux-arm-kernel at lists.infradead.org, linux-clk at vger.kernel.org,
> linux-kernel at vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
> Liam Girdwood <lgirdwood@gmail.com>,
> Leonard Crestez <leonard.crestez@nxp.com>, Rob Herring <robh+dt@kernel.org>,
> Mark Rutland <mark.rutland@arm.com>,
> Michael Turquette <mturquette@baylibre.com>,
> Stephen Boyd <sboyd@codeaurora.org>, Fabio Estevam <fabio.estevam@nxp.com>,
> Russell King <linux@armlinux.org.uk>
> Message-ID: <daba73df-037c-2583-3a08-f3f27c4129d1@pengutronix.de>
> Subject: Re: [PATCH v7 3/6] kernel/reboot.c: export pm_power_off_prepare
> References: <20180517055014.6607-1-o.rempel@pengutronix.de>
> <20180517055014.6607-4-o.rempel@pengutronix.de>
> In-Reply-To: <20180517055014.6607-4-o.rempel@pengutronix.de>
>
> --d6BZYFRi4L3iCmOh3nm6wjii3dWC9QFDg
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> Hi Rafael,
>
> Last version of this patch was send at 17.05.2018. No other comment was
> provided and this patch is a blocker for other patches in this serie.
> Can you please give some feedback on it.
I would have done that had I not missed the patch.
Which probably wouldn't have happened had you CCed it to linux-pm.
Anyway, I have no particular problems with exporting pm_power_off_prepare via
EXPORT_SYMBOL_GPL().
>
> On 17.05.2018 07:50, Oleksij Rempel wrote:
> > Export pm_power_off_prepare. It is needed to implement power off on
> > Freescale/NXP iMX6 based boards with external power management
> > integrated circuit (PMIC).
> >=20
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > kernel/reboot.c | 1 +
> > 1 file changed, 1 insertion(+)
> >=20
> > diff --git a/kernel/reboot.c b/kernel/reboot.c
> > index e4ced883d8de..83810d726f3e 100644
> > --- a/kernel/reboot.c
> > +++ b/kernel/reboot.c
> > @@ -49,6 +49,7 @@ int reboot_force;
> > */
> > =20
> > void (*pm_power_off_prepare)(void);
> > +EXPORT_SYMBOL_GPL(pm_power_off_prepare);
> > =20
> > /**
> > * emergency_restart - reboot the system
> >=20
>
>
> --d6BZYFRi4L3iCmOh3nm6wjii3dWC9QFDg--
>
> --Sj2PRcQlY7eZybdA0sq9wWzJEO8fKS924
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
>
>
> --Sj2PRcQlY7eZybdA0sq9wWzJEO8fKS924--
>
^ permalink raw reply
* [v3, 00/10] Support DPAA PTP clock and timestamping
From: Madalin-cristian Bucur @ 2018-06-12 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607092050.46128-1-yangbo.lu@nxp.com>
> -----Original Message-----
> From: Yangbo Lu [mailto:yangbo.lu at nxp.com]
> Sent: Thursday, June 7, 2018 12:21 PM
> To: netdev at vger.kernel.org; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Richard Cochran <richardcochran@gmail.com>;
> Rob Herring <robh+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>;
> David S . Miller <davem@davemloft.net>
> Cc: devicetree at vger.kernel.org; linuxppc-dev at lists.ozlabs.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Y.b. Lu
> <yangbo.lu@nxp.com>
> Subject: [v3, 00/10] Support DPAA PTP clock and timestamping
>
> This patchset is to support DPAA FMAN PTP clock and HW timestamping.
> It had been verified on both ARM platform and PPC platform.
> - The patch #1 to patch #5 are to support DPAA FMAN 1588 timer in
> ptp_qoriq driver.
> - The patch #6 to patch #10 are to add HW timestamping support in
> DPAA ethernet driver.
>
> Yangbo Lu (10):
> fsl/fman: share the event interrupt
> ptp: support DPAA FMan 1588 timer in ptp_qoriq
> dt-binding: ptp_qoriq: add DPAA FMan support
> powerpc/mpc85xx: move ptp timer out of fman in dts
> arm64: dts: fsl: move ptp timer out of fman
> fsl/fman: add set_tstamp interface
> fsl/fman_port: support getting timestamp
> fsl/fman: define frame description command UPD
> dpaa_eth: add support for hardware timestamping
> dpaa_eth: add the get_ts_info interface for ethtool
>
> Documentation/devicetree/bindings/net/fsl-fman.txt | 25 +-----
> .../devicetree/bindings/ptp/ptp-qoriq.txt | 15 +++-
> arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi | 14 ++-
> arch/powerpc/boot/dts/fsl/qoriq-fman-0.dtsi | 14 ++-
> arch/powerpc/boot/dts/fsl/qoriq-fman-1.dtsi | 14 ++-
> arch/powerpc/boot/dts/fsl/qoriq-fman3-0.dtsi | 14 ++-
> arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi | 14 ++-
> arch/powerpc/boot/dts/fsl/qoriq-fman3l-0.dtsi | 14 ++-
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 88
> ++++++++++++++++-
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.h | 3 +
> drivers/net/ethernet/freescale/dpaa/dpaa_ethtool.c | 39 ++++++++
> drivers/net/ethernet/freescale/fman/fman.c | 3 +-
> drivers/net/ethernet/freescale/fman/fman.h | 1 +
> drivers/net/ethernet/freescale/fman/fman_dtsec.c | 27 +++++
> drivers/net/ethernet/freescale/fman/fman_dtsec.h | 1 +
> drivers/net/ethernet/freescale/fman/fman_memac.c | 5 +
> drivers/net/ethernet/freescale/fman/fman_memac.h | 1 +
> drivers/net/ethernet/freescale/fman/fman_port.c | 12 +++
> drivers/net/ethernet/freescale/fman/fman_port.h | 2 +
> drivers/net/ethernet/freescale/fman/fman_tgec.c | 21 ++++
> drivers/net/ethernet/freescale/fman/fman_tgec.h | 1 +
> drivers/net/ethernet/freescale/fman/mac.c | 3 +
> drivers/net/ethernet/freescale/fman/mac.h | 1 +
> drivers/ptp/Kconfig | 2 +-
> drivers/ptp/ptp_qoriq.c | 104 ++++++++++++-------
> include/linux/fsl/ptp_qoriq.h | 38 ++++++--
> 26 files changed, 361 insertions(+), 115 deletions(-)
Acked-by: Madalin Bucur <madalin.bucur@nxp.com>
^ permalink raw reply
* [PATCH v4 6/6] dt-bindings: media: rcar-vin: Clarify optional props
From: Jacopo Mondi @ 2018-06-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528813566-17927-1-git-send-email-jacopo+renesas@jmondi.org>
Add a note to the R-Car VIN interface bindings to clarify that all
properties listed as generic properties in video-interfaces.txt can
be included in port at 0 endpoint, but if not explicitly listed in the
interface bindings documentation, they do not modify it behaviour.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
Documentation/devicetree/bindings/media/rcar_vin.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 8130849..03544c7 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -55,6 +55,12 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
instances that are connected to external pins should have port 0.
- Optional properties for endpoint nodes of port at 0:
+
+ All properties described in [1] and which apply to the selected
+ media bus type could be optionally listed here to better describe
+ the current hardware configuration, but only the following ones do
+ actually modify the VIN interface behaviour:
+
- hsync-active: see [1] for description. Default is active high.
- vsync-active: see [1] for description. Default is active high.
- data-enable-active: polarity of CLKENB signal, see [1] for
--
2.7.4
^ permalink raw reply related
* [PATCH v4 5/6] media: rcar-vin: Handle data-enable polarity
From: Jacopo Mondi @ 2018-06-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528813566-17927-1-git-send-email-jacopo+renesas@jmondi.org>
Handle data-enable signal polarity. If the polarity is not specifically
requested to be active low, use the active high default.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/media/platform/rcar-vin/rcar-dma.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c b/drivers/media/platform/rcar-vin/rcar-dma.c
index d2b7002..9145b56 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -123,6 +123,7 @@
/* Video n Data Mode Register 2 bits */
#define VNDMR2_VPS (1 << 30)
#define VNDMR2_HPS (1 << 29)
+#define VNDMR2_CES (1 << 28)
#define VNDMR2_FTEV (1 << 17)
#define VNDMR2_VLV(n) ((n & 0xf) << 12)
@@ -698,6 +699,10 @@ static int rvin_setup(struct rvin_dev *vin)
/* Vsync Signal Polarity Select */
if (!(vin->parallel->mbus_flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_VPS;
+
+ /* Data Enable Polarity Select */
+ if (vin->parallel->mbus_flags & V4L2_MBUS_DATA_ENABLE_LOW)
+ dmr2 |= VNDMR2_CES;
}
/*
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/6] dt-bindings: media: rcar-vin: Add 'data-enable-active'
From: Jacopo Mondi @ 2018-06-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528813566-17927-1-git-send-email-jacopo+renesas@jmondi.org>
Describe optional endpoint property 'data-enable-active' for R-Car VIN.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se
---
Documentation/devicetree/bindings/media/rcar_vin.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 87f93ec..8130849 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -57,6 +57,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
- Optional properties for endpoint nodes of port@0:
- hsync-active: see [1] for description. Default is active high.
- vsync-active: see [1] for description. Default is active high.
+ - data-enable-active: polarity of CLKENB signal, see [1] for
+ description. Default is active high.
If both HSYNC and VSYNC polarities are not specified, embedded
synchronization is selected.
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/6] media: v4l2-fwnode: parse 'data-enable-active' prop
From: Jacopo Mondi @ 2018-06-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528813566-17927-1-git-send-email-jacopo+renesas@jmondi.org>
Parse the newly defined 'data-enable-active' property in parallel endpoint
parsing function.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/media/v4l2-core/v4l2-fwnode.c | 4 ++++
include/media/v4l2-mediabus.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c
index 3f77aa3..6105191 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -154,6 +154,10 @@ static void v4l2_fwnode_endpoint_parse_parallel_bus(
flags |= v ? V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH :
V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW;
+ if (!fwnode_property_read_u32(fwnode, "data-enable-active", &v))
+ flags |= v ? V4L2_MBUS_DATA_ENABLE_HIGH :
+ V4L2_MBUS_DATA_ENABLE_LOW;
+
bus->flags = flags;
}
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 4d8626c..4bbb5f3 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -45,6 +45,8 @@
/* Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively. */
#define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH BIT(12)
#define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW BIT(13)
+#define V4L2_MBUS_DATA_ENABLE_HIGH BIT(14)
+#define V4L2_MBUS_DATA_ENABLE_LOW BIT(15)
/* Serial flags */
/* How many lanes the client can use */
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/6] dt-bindings: media: Document data-enable-active property
From: Jacopo Mondi @ 2018-06-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528813566-17927-1-git-send-email-jacopo+renesas@jmondi.org>
Add 'data-enable-active' property to endpoint node properties list.
The property allows to specify the polarity of the data-enable signal, which
when in active state determinates when data lines have to sampled for valid
pixel data.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 258b8df..9839d26 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -109,6 +109,8 @@ Optional endpoint properties
Note, that if HSYNC and VSYNC polarities are not specified, embedded
synchronization may be required, where supported.
- data-active: similar to HSYNC and VSYNC, specifies data line polarity.
+- data-enable-active: similar to HSYNC and VSYNC, specifies the data enable
+ signal polarity.
- field-even-active: field signal level during the even field data transmission.
- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
signal.
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties
From: Jacopo Mondi @ 2018-06-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528813566-17927-1-git-send-email-jacopo+renesas@jmondi.org>
Describe the optional endpoint properties for endpoint nodes of port at 0
and port at 1 of the R-Car VIN driver device tree bindings documentation.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/media/rcar_vin.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index a19517e1..87f93ec 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -53,6 +53,14 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
from external SoC pins described in video-interfaces.txt[1].
Describing more then one endpoint in port 0 is invalid. Only VIN
instances that are connected to external pins should have port 0.
+
+ - Optional properties for endpoint nodes of port at 0:
+ - hsync-active: see [1] for description. Default is active high.
+ - vsync-active: see [1] for description. Default is active high.
+
+ If both HSYNC and VSYNC polarities are not specified, embedded
+ synchronization is selected.
+
- port 1 - sub-nodes describing one or more endpoints connected to
the VIN from local SoC CSI-2 receivers. The endpoint numbers must
use the following schema.
@@ -62,6 +70,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
- Endpoint 2 - sub-node describing the endpoint connected to CSI40
- Endpoint 3 - sub-node describing the endpoint connected to CSI41
+ Endpoint nodes of port at 1 do not support any optional endpoint property.
+
Device node example for Gen2 platforms
--------------------------------------
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/6] media: rcar-vin: Brush endpoint properties
From: Jacopo Mondi @ 2018-06-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
4th round for the VIN endpoint brushing series.
Slightly enlarged the linux-media receiver list, as this new version
introduces a common property in 'video-interfaces.txt'.
Compared to v3 I have dropped the last controversial parts:
- The custom 'renesas,hsync-as-de' property has been dropped: do not handle
CHS bit for the moment.
- Do not remove properties not parsed by the driver and not listed in the
interface bindings from Gen2 boards. As this lead to a long discussion, I
have now proposed a patch to clearly state that properties not listed in the
interface bindings can be optionally specified, but they don't affect the
interface behaviour. To avoid more discussions this patch may be dropped
and things will stay the way they are now.
For the common 'data-enable-active' property, I guess with Rob's ack we should
be fine there and I hope the rest of the series won't slow down its acceptance.
Thanks
j
Jacopo Mondi (6):
dt-bindings: media: rcar-vin: Describe optional ep properties
dt-bindings: media: Document data-enable-active property
media: v4l2-fwnode: parse 'data-enable-active' prop
dt-bindings: media: rcar-vin: Add 'data-enable-active'
media: rcar-vin: Handle data-enable polarity
dt-bindings: media: rcar-vin: Clarify optional props
Documentation/devicetree/bindings/media/rcar_vin.txt | 18 ++++++++++++++++++
.../devicetree/bindings/media/video-interfaces.txt | 2 ++
drivers/media/platform/rcar-vin/rcar-dma.c | 5 +++++
drivers/media/v4l2-core/v4l2-fwnode.c | 4 ++++
include/media/v4l2-mediabus.h | 2 ++
5 files changed, 31 insertions(+)
--
2.7.4
^ permalink raw reply
* [GIT PULL 2/4] ARM: Device-tree updates
From: Olof Johansson @ 2018-06-12 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1628804.nlB6U0QxHY@phil>
Hi,
On Tue, Jun 12, 2018 at 6:04 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> Am Dienstag, 12. Juni 2018, 03:04:34 CEST schrieb Linus Torvalds:
>> On Mon, Jun 11, 2018 at 5:02 PM Olof Johansson <olof@lixom.net> wrote:
>> >
>> > - Qualcomm:
>> > + SDM845, a.k.a Snapdragon 845, an 4+4-core Kryo 385/845
>> > (Cortex-A75/A55 derivative) SoC that's one of the current high-end
>> > mobile SoCs.
>> >
>> > It's great to see mainline support for it. So far, you
>> > can't do much with it, since a lot of peripherals are not yet in the
>> > DTs but driver support for USB, GPU and other pieces are starting to
>> > trickle in. This might end up being a well-supported SoC upstream if
>> > the momentum keeps up.
>>
>> Isn't the Qualcomm 845 also the SoC in some of the new WARM laptops?
>>
>> I asked one person that had an older one (ASUS NovaGo - Qualcomm 835),
>> and apparently you can actually disable secure boot on that thing and
>> boot from USB.
>>
>> In other words, it might _actually_ act like a normal laptop.
>>
>> I'd love to have something that is actually a real honest-to-goodness
>> ARM laptop finally. Are we getting at all close to that?
>
> I guess the Samsung Chromebook Plus (Rockchip RK3399-based [branded
> OP1 though]) also is somewhat close to that target - even with a nice
> high-res display and everything except the 32kb BootRom being replaceable.
>
> Of course Qualcomm-based devices have the Adreno/Freedreno bonus,
> but even in that area we're seeing some progress for Mali (Midgard)
> this year [0].
Yeah, I think the benefit of the Qualcomm platform is the graphics
situation upstream, and they also come with a (native) bootloader that
makes more sense for those not used to the embedded ways of booting.
Sigh, I really wish ARM would come to the table and start working with
upstream on their Mali drivers.
About 845; it looks like there's mostly announced products and none
are shipping yet, so most people with knowledge probably still need to
be tight-lipped about details. I do look forward to seeing some of
these products coming out and what people will do with them. The fact
that secure boot can be turned off on them through regular settings is
promising.
-Olof
^ permalink raw reply
* armada 37xx comphy driver DTS question
From: Marek Behún @ 2018-06-12 14:09 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I am writing a driver for the comphy found on armada 37xx, basing it a
little on the driver from linux-marvell.
There are 3 phy lanes on armada 37xx. In the functional specification
these there are 3 memory areas for those (usb3_gbe1, pcie_gbe0 and
sata_usb3), and one memory area called "South Bridge PHY Configuration
Registers".
In linux-marvell they have written it so that in DTS, this is
configured this way:
comphy {
compatible = "...";
reg = <PHY_CONF regs>,
<pcie_gbe0 regs>,
<usb3_gbe1 regs>,
<sata indirect access regs>;
...
};
Then when other node is referencing a phy, it has to do it this way:
phys = <&comphy LANE_ID TYPE>;
for example
phys = <&comphy 1 COMPHY_PCIE0>;
I was wondering whether to do this the same way in my driver.
Rather I am inclined to create a separate node for each phy, and a
syscon node for PHY_CONF regs, ie:
pcie_gbe0_comphy {
compatible = "...";
reg = <pcie_gbe0 regs>;
marvell,comphy_conf = <&...>;
};
usb3_gbe1_comphy {
compatible = "...";
reg = <usb3_gbe1 regs>;
marvell,comphy_conf = <&...>;
};
What is your opinion?
Thanks.
Marek Behun
^ permalink raw reply
* [PATCH v4 02/26] arm64: cpufeature: Add cpufeature for IRQ priority masking
From: Julien Thierry @ 2018-06-12 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <acf4b44f-d5c7-c31a-7f47-cfbe1049eadc@arm.com>
On 25/05/18 11:48, Julien Thierry wrote:
>
>
> On 25/05/18 11:41, Suzuki K Poulose wrote:
>> On 25/05/18 11:39, Julien Thierry wrote:
>>>
>>>
>>> On 25/05/18 11:36, Suzuki K Poulose wrote:
>>>> On 25/05/18 11:17, Julien Thierry wrote:
>>>>>
>>>>>
>>>>> On 25/05/18 11:04, Suzuki K Poulose wrote:
>>>>>> On 25/05/18 10:49, Julien Thierry wrote:
>>>>>>> Add a cpufeature indicating whether a cpu supports masking
>>>>>>> interrupts
>>>>>>> by priority.
>>>>>>
>>>>>> How is this different from the SYSREG_GIC_CPUIF cap ? Is it just
>>>>>> the description ?
>>>>>
>>>>> More or less.
>>>>>
>>>>> It is just to have an easier condition in the rest of the series.
>>>>> Basically the PRIO masking feature is enabled if we have a GICv3
>>>>> CPUIF working *and* the option was selected at build time. Before
>>>>> this meant that I was checking for the GIC_CPUIF cap inside #ifdefs
>>>>> (and putting alternatives depending on that inside #ifdefs as well).
>>>>>
>>>>> Having this as a separate feature feels easier to manage in the
>>>>> code. It also makes it clearer at boot time that the kernel will be
>>>>> using irq priorities (although I admit it was not the initial
>>>>> intention):
>>>>>
>>>>> [??? 0.000000] CPU features: detected: IRQ priority masking
>>>>>
>>>>>
>>>>> But yes that new feature will be detected only if SYSREG_GIC_CPUIF
>>>>> gets detected as well.
>>>>
>>>> Well, you could always wrap the check like :
>>>>
>>>> static inline bool system_has_irq_priority_masking(void)
>>>> {
>>>> ?????return (IS_ENABLED(CONFIG_YOUR_CONFIG) &&
>>>> cpus_have_const_cap(HWCAP_SYSREG_GIC_CPUIF));
>>>> }
>>>>
>>>> and use it everywhere.
>>>>
>>>
>>> Yes, but I can't use that in the asm parts that use alternatives and
>>> would need to surround them in #ifdef... :\
>>
>> I thought there is _ALTERNATIVE_CFG() to base the alternative depend
>> on a CONFIG_xxx ?
>> Doesn't that solve the problem ?
>
> Right, I didn't see that one. It should work yes.
>
> I'll try that when working on the next version.
I've been trying to use this now, but I can't figure out how.
The _ALTERNATIVE_CFG does not seem to work in assembly code (despite
having its own definition for __ASSEMBLY__), and the alternative_insn
does not seem to be suited for instructions that take operands (or more
than one operand)
If I am mistaken, can you provide an example of how to use this in
assembly with instructions having more than 1 operand?
Cheers,
--
Julien Thierry
^ permalink raw reply
* [PATCH] ARM: dts: imx51-zii-rdu1: add rave-sp subdevices
From: Fabio Estevam @ 2018-06-12 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611052608.GB16091@dragon>
Hi Shawn,
On Mon, Jun 11, 2018 at 2:26 AM, Shawn Guo <shawnguo@kernel.org> wrote:
>> diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
>> index 0c99ac04ad08..98cc107098e0 100644
>> --- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
>> +++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
>> @@ -581,6 +581,14 @@
>> watchdog {
>> compatible = "zii,rave-sp-watchdog";
>> };
>> +
>> + backlight {
>> + compatible = "zii,rave-sp-backlight";
>> + };
>> +
>> + pwrbutton {
>> + compatible = "zii,rave-sp-pwrbutton";
>> + };
>
> Where are these compatibles documented?
Currently they are documented in linux-next at:
Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
Documentation/devicetree/bindings/leds/backlight/zii,rave-sp-backlight.txt
Documentation/devicetree/bindings/input/zii,rave-sp-pwrbutton.txt
They should land in 4.18-rc1.
^ permalink raw reply
* [PATCH v3] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
From: Lukasz Majewski @ 2018-06-12 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509153428.1440-1-lukma@denx.de>
This commit provides support for HSC and DDC boards from
Kieback&Peter GmbH vendor.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes for v3:
- Add Reviewed-by tag
- The &fec label moved to proper position
- Newline between property list and child node
- Remove not needed blank line
- Change name from underscore to hypen in the 'led' and 'button' node names
- Change the 'gpio_expanderX' name to 'gpio-expander'
Changes for v2:
- Remove not needed #address-cells and #size-cells in
the gpio_buttons node to pass make W=1
- Rename button@{12} to button_{kalt|pwr} nodes to pass make W=1
- Include #include <dt-bindings/input/input.h> to use KEY_F6|F7 directly
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx53-kp-ddc.dts | 146 ++++++++++++++++++++++++++++
arch/arm/boot/dts/imx53-kp-hsc.dts | 52 ++++++++++
arch/arm/boot/dts/imx53-kp.dtsi | 189 +++++++++++++++++++++++++++++++++++++
4 files changed, 389 insertions(+)
create mode 100644 arch/arm/boot/dts/imx53-kp-ddc.dts
create mode 100644 arch/arm/boot/dts/imx53-kp-hsc.dts
create mode 100644 arch/arm/boot/dts/imx53-kp.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fbc04b0db781..00854a5b6ac4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -360,6 +360,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
dtb-$(CONFIG_SOC_IMX53) += \
imx53-ard.dtb \
imx53-cx9020.dtb \
+ imx53-kp-ddc.dtb \
+ imx53-kp-hsc.dtb \
imx53-m53evk.dtb \
imx53-mba53.dtb \
imx53-ppd.dtb \
diff --git a/arch/arm/boot/dts/imx53-kp-ddc.dts b/arch/arm/boot/dts/imx53-kp-ddc.dts
new file mode 100644
index 000000000000..0e7f071fd10e
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp-ddc.dts
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-kp.dtsi"
+
+/ {
+ model = "K+P imx53 DDC";
+ compatible = "kiebackpeter,imx53-ddc", "fsl,imx53";
+
+ backlight_lcd: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm2 0 50000>;
+ power-supply = <®_backlight>;
+ brightness-levels = <0 24 28 32 36
+ 40 44 48 52 56
+ 60 64 68 72 76
+ 80 84 88 92 96 100>;
+ default-brightness-level = <20>;
+ };
+
+ lcd_display: display {
+ compatible = "fsl,imx-parallel-display";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interface-pix-fmt = "rgb24";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_disp>;
+
+ port at 0 {
+ reg = <0>;
+
+ display1_in: endpoint {
+ remote-endpoint = <&ipu_di1_disp1>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ lcd_display_out: endpoint {
+ remote-endpoint = <&lcd_panel_in>;
+ };
+ };
+ };
+
+ lcd_panel: lcd-panel {
+ compatible = "koe,tx14d24vm1bpa";
+ backlight = <&backlight_lcd>;
+ power-supply = <®_3v3>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <&lcd_display_out>;
+ };
+ };
+ };
+
+ reg_backlight: regulator-backlight {
+ compatible = "regulator-fixed";
+ regulator-name = "backlight-supply";
+ regulator-min-microvolt = <15000000>;
+ regulator-max-microvolt = <15000000>;
+ regulator-always-on;
+ };
+};
+
+&fec {
+ status = "okay";
+};
+
+&i2c3 {
+ adc at 48 {
+ compatible = "ti,ads1015";
+ reg = <0x48>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel at 4 {
+ reg = <4>;
+ ti,gain = <2>;
+ ti,datarate = <4>;
+ };
+
+ channel at 6 {
+ reg = <6>;
+ ti,gain = <2>;
+ ti,datarate = <4>;
+ };
+ };
+
+ gpio-expander2 at 21 {
+ compatible = "nxp,pcf8574";
+ reg = <0x21>;
+ interrupts = <109>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+};
+
+&iomuxc {
+ imx53-kp-ddc {
+ pinctrl_disp: dispgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 0x4
+ MX53_PAD_EIM_DA10__IPU_DI1_PIN15 0x4
+ MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 0x4
+ MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 0x4
+ MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 0x4
+ MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 0x4
+ MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 0x4
+ MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 0x4
+ MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 0x4
+ MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 0x4
+ MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 0x4
+ MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 0x4
+ MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 0x4
+ MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 0x4
+ MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 0x4
+ MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 0x4
+ MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 0x4
+ MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 0x4
+ MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 0x4
+ MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 0x4
+ MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 0x4
+ MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 0x4
+ MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 0x4
+ MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 0x4
+ MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 0x4
+ MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 0x4
+ MX53_PAD_GPIO_1__PWM2_PWMO 0x4
+ >;
+ };
+ };
+};
+
+&ipu_di1_disp1 {
+ remote-endpoint = <&display1_in>;
+};
+
+&pmic {
+ fsl,mc13xxx-uses-touch;
+};
diff --git a/arch/arm/boot/dts/imx53-kp-hsc.dts b/arch/arm/boot/dts/imx53-kp-hsc.dts
new file mode 100644
index 000000000000..6e3d71baac0f
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp-hsc.dts
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-kp.dtsi"
+
+/ {
+ model = "K+P imx53 HSC";
+ compatible = "kiebackpeter,imx53-hsc", "fsl,imx53";
+};
+
+&fec {
+ status = "okay";
+
+ fixed-link { /* RMII fixed link to LAN9303 */
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+&i2c3 {
+ switch: switch at a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <400>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 { /* RMII fixed link to master */
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&fec>;
+ };
+
+ port at 1 { /* external port 1 */
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port at 2 { /* external port 2 */
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/imx53-kp.dtsi b/arch/arm/boot/dts/imx53-kp.dtsi
new file mode 100644
index 000000000000..8b25416a5303
--- /dev/null
+++ b/arch/arm/boot/dts/imx53-kp.dtsi
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lukma at denx.de
+ */
+
+/dts-v1/;
+#include "imx53-tqma53.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ buzzer {
+ compatible = "pwm-beeper";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_buzzer>;
+ pwms = <&pwm1 0 500000>;
+ };
+
+ gpio-buttons {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiobuttons>;
+
+ button-kalt {
+ label = "Kaltstart";
+ linux,code = <KEY_F6>;
+ gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ button-pwr {
+ label = "PowerFailInterrupt";
+ linux,code = <KEY_F7>;
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-bus {
+ label = "bus";
+ gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "off";
+ };
+
+ led-error {
+ label = "error";
+ gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "gpio";
+ default-state = "off";
+ };
+
+ led-flash {
+ label = "flash";
+ gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "okay";
+};
+
+&i2c3 {
+ status = "okay";
+
+ gpio-expander1 at 22 {
+ compatible = "nxp,pcf8574";
+ reg = <0x22>;
+ interrupts = <109>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ rtc at 51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_kp_common>;
+
+ imx53-kp-common {
+ pinctrl_buzzer: buzzergrp {
+ fsl,pins = <
+ MX53_PAD_SD1_DATA3__PWM1_PWMO 0x1e4
+ >;
+ };
+
+ pinctrl_gpiobuttons: gpiobuttonsgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_RW__GPIO2_26 0x1e4
+ MX53_PAD_EIM_D22__GPIO3_22 0x1e4
+ >;
+ };
+
+ pinctrl_kp_common: kpcommongrp {
+ fsl,pins = <
+ MX53_PAD_EIM_CS0__GPIO2_23 0x1e4
+ MX53_PAD_GPIO_19__GPIO4_5 0x1e4
+ MX53_PAD_PATA_DATA6__GPIO2_6 0x1e4
+ MX53_PAD_PATA_DATA7__GPIO2_7 0xe0
+ MX53_PAD_CSI0_DAT14__GPIO6_0 0x1e4
+ MX53_PAD_CSI0_DAT16__GPIO6_2 0x1e4
+ MX53_PAD_CSI0_DAT18__GPIO6_4 0x1e4
+ MX53_PAD_EIM_D17__GPIO3_17 0x1e4
+ MX53_PAD_EIM_D18__GPIO3_18 0x1e4
+ MX53_PAD_EIM_D21__GPIO3_21 0x1e4
+ MX53_PAD_EIM_D29__GPIO3_29 0x1e4
+ MX53_PAD_EIM_DA11__GPIO3_11 0x1e4
+ MX53_PAD_EIM_DA13__GPIO3_13 0x1e4
+ MX53_PAD_EIM_DA14__GPIO3_14 0x1e4
+ MX53_PAD_SD1_DATA0__GPIO1_16 0x1e4
+ MX53_PAD_SD1_CMD__GPIO1_18 0x1e4
+ MX53_PAD_SD1_CLK__GPIO1_20 0x1e4
+ >;
+ };
+
+ pinctrl_leds: ledgrp {
+ fsl,pins = <
+ MX53_PAD_EIM_EB2__GPIO2_30 0x1d4
+ MX53_PAD_EIM_D28__GPIO3_28 0x1d4
+ MX53_PAD_EIM_WAIT__GPIO5_0 0x1d4
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 0x1e4
+ MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 0x1e4
+ >;
+ };
+ };
+};
+
+&pinctrl_uart1 {
+ fsl,pins = <
+ MX53_PAD_EIM_D23__GPIO3_23 0x1e4
+ MX53_PAD_EIM_EB3__GPIO2_31 0x1e4
+ MX53_PAD_EIM_D24__GPIO3_24 0x1e4
+ MX53_PAD_EIM_D25__GPIO3_25 0x1e4
+ MX53_PAD_EIM_D19__GPIO3_19 0x1e4
+ MX53_PAD_EIM_D20__GPIO3_20 0x1e4
+ >;
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+&usbphy0 {
+ status = "disabled";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 6/8] dt-bindings: rcar-vin: Add 'hsync-as-de' custom prop
From: jacopo mondi @ 2018-06-12 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604121933.GG19674@bigcity.dyn.berto.se>
Hi Niklas,
On Mon, Jun 04, 2018 at 02:19:33PM +0200, Niklas S?derlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-29 17:05:57 +0200, Jacopo Mondi wrote:
> > Document the boolean custom property 'renesas,hsync-as-de' that indicates
> > that the HSYNC signal is internally used as data-enable, when the
> > CLKENB signal is not connected.
> >
> > As this is a VIN specificity create a custom property specific to the R-Car
> > VIN driver.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > v3:
> > - new patch
> > ---
> > Documentation/devicetree/bindings/media/rcar_vin.txt | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > index ff53226..024c109 100644
> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> > @@ -60,6 +60,9 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> > - vsync-active: see [1] for description. Default is active high.
> > - data-enable-active: polarity of CLKENB signal, see [1] for
> > description. Default is active high.
> > + - renesas,hsync-as-de: a boolean property to indicate that HSYNC signal
> > + is internally used as data-enable when the CLKENB signal is
> > + not available.
>
> I'm not sure I like this, is there really a need to add a custom
> property for this? The datasheet states that when the CLKENB pin is not
> connected the driver should enable 'Clock Enable Hsync Select (CHS)'.
> With the new generic property 'data-enable-active' which describes the
> polarity of the CLKENB pin we also gain the knowledge if the CLKENB pin
> is connected or not.
That was my first proposal, we discussed that in
Re: [PATCH 3/6] media: rcar-vin: Handle data-active property
Re: [PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active
Let's sum it up in this way:
Instead of having to deal again with the "what happens if there is no
data-enable-active and we're running on BT.656 where there is no HSYNC signal"[1]
I decided to go with a custom property.
>
> I propose we drop this custom property and instead let the driver check
> if the CLKENB polarity is described or not and use that to determine if
> CHS bit should be set or not. IMHO that is much simpler then having two
> properties describing the same pin.
>
It is my understanding that both Gen2 and Gen3 boards CVBS input are
BT.656 and none of them has CLKENB input. So 'data-enable-active' is
never there but in this case we should not set CHS. So the absence of
'data-enable-active' has different consequences if we're running on
parallel or BT.656 bus, and that feels confusing to me, so I decided
to make it an explicit property.
Also, as the interface manual describes the "use HSYNC in place of CLKENB"
when on parallel bus as a design choice, that should imo be documented.
Again, this is very minor stuff. I'll leave this out from next
version, maybe we can talk about this f2f next week.
Thanks
j
> >
> > If both HSYNC and VSYNC polarities are not specified, embedded
> > synchronization is selected.
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas S?derlund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180612/d1d7273b/attachment.sig>
^ permalink raw reply
* [PATCH 19/19] mmc: mmci: add stm32 sdmmc variant
From: Ludovic Barre @ 2018-06-12 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528809280-31116-1-git-send-email-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
This patch adds a stm32 sdmmc variant, rev 1.1.
Introduces a new Manufacturer id "0x53, ascii 'S' to define
new stm32 sdmmc familly with clean range of amba
revision/configurations bits (corresponding to sdmmc_ver
register with major/minor fields).
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index af27a0a..bed671d 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -267,6 +267,29 @@ static struct variant_data variant_stm32 = {
.mmci_dma = &dmaengine,
};
+static struct variant_data variant_stm32_sdmmc = {
+ .fifosize = 16 * 4,
+ .fifohalfsize = 8 * 4,
+ .f_max = 208000000,
+ .stm32_clkdiv = true,
+ .reset = true,
+ .cmdreg_cpsm_enable = MCI_CPSM_STM32_ENABLE,
+ .cmdreg_lrsp_crc = MCI_CPSM_STM32_LRSP_CRC,
+ .cmdreg_srsp_crc = MCI_CPSM_STM32_SRSP_CRC,
+ .cmdreg_srsp = MCI_CPSM_STM32_SRSP,
+ .cmdreg_stop = MCI_CPSM_STM32_CMDSTOP,
+ .data_cmd_enable = MCI_CPSM_STM32_CMDTRANS,
+ .irq_pio_mask = MCI_IRQ_PIO_STM32_MASK,
+ .datactrl_first = true,
+ .datalength_bits = 25,
+ .datactrl_blocksz = 14,
+ .mmci_dma = &sdmmc_idma,
+ .stm32_idmabsize_mask = GENMASK(12, 5),
+ .validate_data = sdmmc_idma_validate_data,
+ .set_clkreg = mmci_sdmmc_set_clkreg,
+ .set_pwrreg = mmci_sdmmc_set_pwrreg,
+};
+
static struct variant_data variant_qcom = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
@@ -1907,6 +1930,11 @@ static const struct amba_id mmci_ids[] = {
.mask = 0x00ffffff,
.data = &variant_stm32,
},
+ {
+ .id = 0x10153180,
+ .mask = 0xf0ffffff,
+ .data = &variant_stm32_sdmmc,
+ },
/* Qualcomm variants */
{
.id = 0x00051180,
--
2.7.4
^ permalink raw reply related
* [PATCH 18/19] mmc: mmci: add specific clk/pwr procedure for stm32 sdmmc
From: Ludovic Barre @ 2018-06-12 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528809280-31116-1-git-send-email-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
This patch adds specific clock and power ios for stm32 sdmmc variant.
power ios: stm32 dedicated procedure must be done to perform power
off/on procedures. To power off, the sdmmc must be reset and set
to power cycle state before to disabling vqmmc. This drives low
SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK to prevent the Card from
being supplied through the signal lines.
To power on, set the SDMMC in power-off SDMMC_D[7:0], SDMMC_CMD
and SDMMC_CK are driven high. Then we can set the SDMMC to
Power-on state.
clock ios: specific bits behavior:
-clock divider card_clk = mclk / (2 * clkdiv)
-ddr activation
-wide bus 1/4/8bits
-bus speed
-receive clock selection (in_ck/ck_in/fb_ck)
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 86aef4f..af27a0a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -50,6 +50,10 @@
static unsigned int fmax = 515633;
+static void mmci_sdmmc_set_pwrreg(struct mmci_host *host,
+ unsigned char power_mode, unsigned int pwr);
+static void mmci_sdmmc_set_clkreg(struct mmci_host *host, unsigned int desired);
+
static struct variant_data variant_arm = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
@@ -490,6 +494,114 @@ static void mmci_set_pwrreg(struct mmci_host *host, unsigned char power_mode,
mmci_write_pwrreg(host, pwr);
}
+static void mmci_sdmmc_set_clkreg(struct mmci_host *host, unsigned int desired)
+{
+ unsigned int clk = 0, ddr = 0;
+
+ if (host->mmc->ios.timing == MMC_TIMING_MMC_DDR52 ||
+ host->mmc->ios.timing == MMC_TIMING_UHS_DDR50)
+ ddr = MCI_STM32_CLK_DDR;
+
+ /*
+ * cclk = mclk / (2 * clkdiv)
+ * clkdiv 0 => bypass
+ * in ddr mode bypass is not possible
+ */
+ if (desired) {
+ if (desired >= host->mclk && !ddr) {
+ host->cclk = host->mclk;
+ } else {
+ clk = DIV_ROUND_UP(host->mclk, 2 * desired);
+ if (clk > MCI_STM32_CLK_CLKDIV_MSK)
+ clk = MCI_STM32_CLK_CLKDIV_MSK;
+ host->cclk = host->mclk / (2 * clk);
+ }
+ }
+
+ if (host->mmc->ios.bus_width == MMC_BUS_WIDTH_4)
+ clk |= MCI_STM32_CLK_WIDEBUS_4;
+ if (host->mmc->ios.bus_width == MMC_BUS_WIDTH_8)
+ clk |= MCI_STM32_CLK_WIDEBUS_8;
+
+ clk |= MCI_STM32_CLK_HWFCEN;
+ clk |= host->clk_reg_add;
+ clk |= ddr;
+
+ /*
+ * SDMMC_FBCK is selected when an external Delay Block is needed
+ * with SDR104.
+ */
+ if (host->mmc->ios.timing >= MMC_TIMING_UHS_SDR50) {
+ clk |= MCI_STM32_CLK_BUSSPEED;
+ if (host->mmc->ios.timing == MMC_TIMING_UHS_SDR104) {
+ clk &= ~MCI_STM32_CLK_SEL_MSK;
+ clk |= MCI_STM32_CLK_SELFBCK;
+ }
+ }
+
+ mmci_write_clkreg(host, clk);
+}
+
+static void mmci_sdmmc_set_pwrreg(struct mmci_host *host,
+ unsigned char power_mode, unsigned int pwr)
+{
+ struct mmc_host *mmc = host->mmc;
+
+ pwr |= host->pwr_reg_add;
+
+ switch (power_mode) {
+ case MMC_POWER_OFF:
+ if (!IS_ERR(mmc->supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
+
+ /* Only a reset could disable sdmmc */
+ reset_control_assert(host->rst);
+ udelay(2);
+ reset_control_deassert(host->rst);
+
+ /* default mask (probe) must be activated */
+ writel(MCI_IRQENABLE | host->variant->start_err,
+ host->base + MMCIMASK0);
+
+ /*
+ * Set the SDMMC in Power-cycle state before to disabling vqmmc.
+ * This will make that the SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK
+ * are driven low, to prevent the Card from being supplied
+ * through the signal lines.
+ */
+ mmci_write_pwrreg(host, MCI_STM32_PWR_CYC | pwr);
+
+ if (!IS_ERR(host->mmc->supply.vqmmc) && host->vqmmc_enabled) {
+ regulator_disable(host->mmc->supply.vqmmc);
+ host->vqmmc_enabled = false;
+ }
+ break;
+ case MMC_POWER_UP:
+ if (!IS_ERR(mmc->supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc->supply.vmmc,
+ mmc->ios.vdd);
+ break;
+ case MMC_POWER_ON:
+ if (!IS_ERR(host->mmc->supply.vqmmc) && !host->vqmmc_enabled) {
+ if (regulator_enable(host->mmc->supply.vqmmc) < 0)
+ dev_err(mmc_dev(host->mmc),
+ "failed to enable vqmmc regulator\n");
+ else
+ host->vqmmc_enabled = true;
+ }
+
+ /*
+ * After a power-cycle state, we must set the SDMMC in
+ * Power-off. The SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK are
+ * driven high. Then we can set the SDMMC to Power-on state
+ */
+ mmci_write_pwrreg(host, MCI_PWR_OFF | pwr);
+ mdelay(1);
+ mmci_write_pwrreg(host, MCI_PWR_ON | pwr);
+ break;
+ }
+}
+
static void
mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
--
2.7.4
^ 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