* [bpf-next V4 PATCH 09/14] thunderx: setup xdp_rxq_info
From: Jesper Dangaard Brouer @ 2018-01-03 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <151497504273.18176.10177133999720101758.stgit@firesoul>
This driver uses a bool scheme for "enable"/"disable" when setting up
different resources. Thus, the hook points for xdp_rxq_info is done
in the same function call nicvf_rcv_queue_config(). This is activated
through enable/disable via nicvf_config_data_transfer(), which is tied
into nicvf_stop()/nicvf_open().
Extending driver packet handler call-path nicvf_rcv_pkt_handler() with
a pointer to the given struct rcv_queue, in-order to access the
xdp_rxq_info data area (in nicvf_xdp_rx()).
V2: Driver have no proper error path for failed XDP RX-queue info reg,
as nicvf_rcv_queue_config is a void function.
Cc: linux-arm-kernel at lists.infradead.org
Cc: Sunil Goutham <sgoutham@cavium.com>
Cc: Robert Richter <rric@kernel.org>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 11 +++++++----
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 4 ++++
drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 2 ++
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 52b3a6044f85..21618d0d694f 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -521,7 +521,7 @@ static void nicvf_unmap_page(struct nicvf *nic, struct page *page, u64 dma_addr)
static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
struct cqe_rx_t *cqe_rx, struct snd_queue *sq,
- struct sk_buff **skb)
+ struct rcv_queue *rq, struct sk_buff **skb)
{
struct xdp_buff xdp;
struct page *page;
@@ -545,6 +545,7 @@ static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
xdp.data = (void *)cpu_addr;
xdp_set_data_meta_invalid(&xdp);
xdp.data_end = xdp.data + len;
+ xdp.rxq = &rq->xdp_rxq;
orig_data = xdp.data;
rcu_read_lock();
@@ -698,7 +699,8 @@ static inline void nicvf_set_rxhash(struct net_device *netdev,
static void nicvf_rcv_pkt_handler(struct net_device *netdev,
struct napi_struct *napi,
- struct cqe_rx_t *cqe_rx, struct snd_queue *sq)
+ struct cqe_rx_t *cqe_rx,
+ struct snd_queue *sq, struct rcv_queue *rq)
{
struct sk_buff *skb = NULL;
struct nicvf *nic = netdev_priv(netdev);
@@ -724,7 +726,7 @@ static void nicvf_rcv_pkt_handler(struct net_device *netdev,
/* For XDP, ignore pkts spanning multiple pages */
if (nic->xdp_prog && (cqe_rx->rb_cnt == 1)) {
/* Packet consumed by XDP */
- if (nicvf_xdp_rx(snic, nic->xdp_prog, cqe_rx, sq, &skb))
+ if (nicvf_xdp_rx(snic, nic->xdp_prog, cqe_rx, sq, rq, &skb))
return;
} else {
skb = nicvf_get_rcv_skb(snic, cqe_rx,
@@ -781,6 +783,7 @@ static int nicvf_cq_intr_handler(struct net_device *netdev, u8 cq_idx,
struct cqe_rx_t *cq_desc;
struct netdev_queue *txq;
struct snd_queue *sq = &qs->sq[cq_idx];
+ struct rcv_queue *rq = &qs->rq[cq_idx];
unsigned int tx_pkts = 0, tx_bytes = 0, txq_idx;
spin_lock_bh(&cq->lock);
@@ -811,7 +814,7 @@ static int nicvf_cq_intr_handler(struct net_device *netdev, u8 cq_idx,
switch (cq_desc->cqe_type) {
case CQE_TYPE_RX:
- nicvf_rcv_pkt_handler(netdev, napi, cq_desc, sq);
+ nicvf_rcv_pkt_handler(netdev, napi, cq_desc, sq, rq);
work_done++;
break;
case CQE_TYPE_SEND:
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index f38ea349aa00..14e62c6ac342 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -760,6 +760,7 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
if (!rq->enable) {
nicvf_reclaim_rcv_queue(nic, qs, qidx);
+ xdp_rxq_info_unreg(&rq->xdp_rxq);
return;
}
@@ -772,6 +773,9 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
/* all writes of RBDR data to be loaded into L2 Cache as well*/
rq->caching = 1;
+ /* Driver have no proper error path for failed XDP RX-queue info reg */
+ WARN_ON(xdp_rxq_info_reg(&rq->xdp_rxq, nic->netdev, qidx) < 0);
+
/* Send a mailbox msg to PF to config RQ */
mbx.rq.msg = NIC_MBOX_MSG_RQ_CFG;
mbx.rq.qs_num = qs->vnic_id;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
index 178ab6e8e3c5..7d1e4e2aaad0 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
@@ -12,6 +12,7 @@
#include <linux/netdevice.h>
#include <linux/iommu.h>
#include <linux/bpf.h>
+#include <net/xdp.h>
#include "q_struct.h"
#define MAX_QUEUE_SET 128
@@ -255,6 +256,7 @@ struct rcv_queue {
u8 start_qs_rbdr_idx; /* RBDR idx in the above QS */
u8 caching;
struct rx_tx_queue_stats stats;
+ struct xdp_rxq_info xdp_rxq;
} ____cacheline_aligned_in_smp;
struct cmp_queue {
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
From: Simon Horman @ 2018-01-03 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102093823.o6km656xdef7jnwf@verge.net.au>
On Tue, Jan 02, 2018 at 10:38:24AM +0100, Simon Horman wrote:
> Hi Vladimir,
>
> Happy New Year!
>
> On Fri, Dec 22, 2017 at 12:22:09PM +0200, Vladimir Zapolskiy wrote:
> > Hi Simon,
> >
> > On 12/22/2017 10:40 AM, Simon Horman wrote:
> > > On Fri, Dec 22, 2017 at 09:32:03AM +0100, Simon Horman wrote:
> > >> On Thu, Dec 21, 2017 at 05:18:58PM +0200, Vladimir Zapolskiy wrote:
> > >>> From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> > >>>
> > >>> The present change is a bug fix for AVB link iteratively up/down.
> > >>>
> > >>> Steps to reproduce:
> > >>> - start AVB TX stream (Using aplay via MSE),
> > >>> - disconnect+reconnect the eth cable,
> > >>> - after a reconnection the eth connection goes iteratively up/down
> > >>> without user interaction,
> > >>> - this may heal after some seconds or even stay for minutes.
> > >>>
> > >>> As the documentation specifies, the "renesas,no-ether-link" option
> > >>> should be used when a board does not provide a proper AVB_LINK signal.
> > >>> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> > >>> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
> > >>>
> > >>> Choosing to keep or remove the "renesas,no-ether-link" option will
> > >>> have impact on the code flow in the following ways:
> > >>> - keeping this option enabled may lead to unexpected behavior since
> > >>> the RX & TX are enabled/disabled directly from adjust_link function
> > >>> without any HW interrogation,
> > >>> - removing this option, the RX & TX will only be enabled/disabled after
> > >>> HW interrogation. The HW check is made through the LMON pin in PSR
> > >>> register which specifies AVB_LINK signal value (0 - at low level;
> > >>> 1 - at high level).
> > >>>
> > >>> In conclusion, the present change is also a safety improvement because
> > >>> it removes the "renesas,no-ether-link" option leading to a proper way
> > >>> of detecting the link state based on HW interrogation and not on
> > >>> software heuristic.
> > >>>
> > >>> Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
> > >>
> > >> The above shuffles the code around but does not introduce the problem
> > >> as far as I can see. Instead I think we should use:
> > >>
> > >> Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
> > >> Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
> > >>
> > >>> Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> > >>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> > >
> > > I have applied this a fix for v4.15 with the updated Fixes tags above.
> > >
> >
> > thank you, I was unsure if you expected to get changes which can be used
> > as a base without patch application conflicts (my done choice) or changes,
> > which originally intorduced the bug, but formally require slightly
> > different fixes due to code changes in the middle. If it would be needed,
> > hopefully linux-stable maintainers can resolve the trivial conflicts.
> >
> > Also you may find this information from the cover letter useful,
> > someone may want to check the relevant board schematics and send
> > similar fixes (if applicable after schematics review and testing):
> >
> > Note that DTS files for V3M Starter Kit, Draak and Eagle boards
> > contain the same property, the files are untouched due to unavailable
> > schematics to verify if the fix applies to these boards as well.
>
> Thanks. I took a quick look and my findings so far are:
>
> * Eagle: This approach seems applicable as AVB_LINK appears to be hooked up
> * V3M Starter Kit: This approach seems applicable as AVB0_LINK appears to be
> hooked up
> * Draak: I don't seem to be able to locate documentation at this time
I have now obtained Draak documentation. It seems that this approach is
applicable to that board too as AVB0_LINK appears to be hooked up.
> Are you interested in creating follow-up patches?
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Graeme Gregory @ 2018-01-03 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8_6y3dU81ZS4WWCfpRZkfjGo_+_K--e3go_3_xXwBErQ@mail.gmail.com>
On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> On 18 December 2017 at 10:17, Marcin Wojtas <mw@semihalf.com> wrote:
> > Hi,
> >
> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> > First three patches introduce fwnode helpers for obtaining PHY
> > information from nodes and also MDIO fwnode API for registering
> > the bus with its PHY/devices.
> >
> > Following patches update code of the mvmdio and mvpp2 drivers
> > to support ACPI tables handling. The latter is done in 4 steps,
> > as can be seen in the commits. For the details, please
> > refer to the commit messages.
> >
> > Drivers operation was tested on top of the net-next branch
> > with both DT and ACPI. Although for compatibility reasons
> > with older platforms, the mvmdio driver keeps using
> > of_ MDIO registering, new fwnode_ one proved to fully work
> > with DT as well (tested on MacchiatoBin board).
> >
> > mvpp2/mvmdio driver can work with the ACPI representation, as exposed
> > on a public branch:
> > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> > It was compiled together with the most recent Tianocore EDK2 revision.
> > Please refer to the firmware build instruction on MacchiatoBin board:
> > http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
> >
> > Above support configures 1G to use its PHY normally. 10G can work now
> > only with the link interrupt mode. Somehow reading of the
> > string property in fwnode_mdiobus_child_is_phy works only with
> > DT and cannot cope with 10G PHY nodes as in:
> > https://pastebin.com/3JnYpU0A
> >
> > Above root cause will be further checked. In the meantime I will
> > appreciate any comments or remarks for the kernel patches.
> >
>
> Hi Marcin,
>
> I have added linux-acpi and Graeme to cc. I think it makes sense to
> discuss the way you describe the device topology before looking at the
> patches in more detail.
>
> In particular, I would like to request feedback on the use of
> [redundant] 'reg' properties and the use of _DSD + compatible to
> describe PHYs. Usually, we try to avoid this, given that it is
> essentially a ACPI encapsulated DT dialect that is difficult to
> support in drivers unless they are based on DT to begin with. Also,
> non-standard _DSD properties require a vendor prefix, it is not
> freeform.
>
> For reference, the ACPI description is here (starting at line 175)
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/72d5ac23b20dd74d479daa5e40ba443264b31261/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl
>
So the representation of PHY's with _DSD was kind of formalised here
http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
This is already in use in the kernel, and that DSDT seems to be along the same
lines. So seems ok in that manner.
The "reg", 0 property seems a little odd, it would probably make more
sense to check for the lack of ranges passed in in ACPI manner _CRS.
Graeme
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180103/373e76fd/attachment.sig>
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2018-01-03 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103110048.GA21230@xora-haswell>
Hi Graeme,
2018-01-03 12:00 GMT+01:00 Graeme Gregory <graeme.gregory@linaro.org>:
> On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
>> On 18 December 2017 at 10:17, Marcin Wojtas <mw@semihalf.com> wrote:
>> > Hi,
>> >
>> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
>> > First three patches introduce fwnode helpers for obtaining PHY
>> > information from nodes and also MDIO fwnode API for registering
>> > the bus with its PHY/devices.
>> >
>> > Following patches update code of the mvmdio and mvpp2 drivers
>> > to support ACPI tables handling. The latter is done in 4 steps,
>> > as can be seen in the commits. For the details, please
>> > refer to the commit messages.
>> >
>> > Drivers operation was tested on top of the net-next branch
>> > with both DT and ACPI. Although for compatibility reasons
>> > with older platforms, the mvmdio driver keeps using
>> > of_ MDIO registering, new fwnode_ one proved to fully work
>> > with DT as well (tested on MacchiatoBin board).
>> >
>> > mvpp2/mvmdio driver can work with the ACPI representation, as exposed
>> > on a public branch:
>> > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
>> > It was compiled together with the most recent Tianocore EDK2 revision.
>> > Please refer to the firmware build instruction on MacchiatoBin board:
>> > http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>> >
>> > Above support configures 1G to use its PHY normally. 10G can work now
>> > only with the link interrupt mode. Somehow reading of the
>> > string property in fwnode_mdiobus_child_is_phy works only with
>> > DT and cannot cope with 10G PHY nodes as in:
>> > https://pastebin.com/3JnYpU0A
>> >
>> > Above root cause will be further checked. In the meantime I will
>> > appreciate any comments or remarks for the kernel patches.
>> >
>>
>> Hi Marcin,
>>
>> I have added linux-acpi and Graeme to cc. I think it makes sense to
>> discuss the way you describe the device topology before looking at the
>> patches in more detail.
>>
>> In particular, I would like to request feedback on the use of
>> [redundant] 'reg' properties and the use of _DSD + compatible to
>> describe PHYs. Usually, we try to avoid this, given that it is
>> essentially a ACPI encapsulated DT dialect that is difficult to
>> support in drivers unless they are based on DT to begin with. Also,
>> non-standard _DSD properties require a vendor prefix, it is not
>> freeform.
>>
>> For reference, the ACPI description is here (starting at line 175)
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/72d5ac23b20dd74d479daa5e40ba443264b31261/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl
>>
> So the representation of PHY's with _DSD was kind of formalised here
>
> http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
>
> This is already in use in the kernel, and that DSDT seems to be along the same
> lines. So seems ok in that manner.
>
> The "reg", 0 property seems a little odd, it would probably make more
> sense to check for the lack of ranges passed in in ACPI manner _CRS.
>
I already agreed with 'reg' being awkward in the later emails.
Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
Thanks,
Marcin
^ permalink raw reply
* [net-next: PATCH v2 5/5] net: mvpp2: enable ACPI support in the driver
From: graeme.gregory at linaro.org @ 2018-01-03 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171231192354.GB20455@lunn.ch>
On Sun, Dec 31, 2017 at 08:23:54PM +0100, Andrew Lunn wrote:
> > * Modify way of obtaining interrupts - with ACPI they are resources
> > bound to struct platform_device and it's not possible to obtain
> > them directly from the child node. Hence a formula is used, depending
> > on the port_id and number of possible CPUs.
>
> Hi Marcin
>
> I know nothing about ACPI. Is this limitation with respect to
> interrupts fundamental to ACPI, or just that nobody has implemented
> flexible interrupt support yet?
>
The infrastructure is there to traverse trees of children, but I don't
think there any helper functions.
Graeme
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180103/bf301cec/attachment-0001.sig>
^ permalink raw reply
* [PATCH V4 22/26] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
From: Bartlomiej Zolnierkiewicz @ 2018-01-03 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7099e2af-4704-4611-94c0-830483de4578@codeaurora.org>
On Tuesday, January 02, 2018 08:38:24 AM Sinan Kaya wrote:
> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > where a PCI device is present. This restricts the device drivers to be
> > reused for other domain numbers.
> >
> > Getting ready to remove pci_get_bus_and_slot() function in favor of
> > pci_get_domain_bus_and_slot().
> >
> > Find the domain number from pdev.
> >
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Any feedback here ? most of the remaining patches have the ACK except these.
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH V4 23/26] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
From: Bartlomiej Zolnierkiewicz @ 2018-01-03 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a6b51ff-42d5-29cc-167e-f4ed74d7ac36@codeaurora.org>
On Tuesday, January 02, 2018 08:38:03 AM Sinan Kaya wrote:
> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > where a PCI device is present. This restricts the device drivers to be
> > reused for other domain numbers.
> >
> > Getting ready to remove pci_get_bus_and_slot() function in favor of
> > pci_get_domain_bus_and_slot().
> >
> > struct nvidia_par has a pointer to struct pci_dev. Use the pci_dev
> > member to extract the domain information and pass it to
> > pci_get_domain_bus_and_slot() function.
> >
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Any feedback here ? most of the remaining patches have the ACK except these.
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH V4 24/26] video: fbdev: riva: deprecate pci_get_bus_and_slot()
From: Bartlomiej Zolnierkiewicz @ 2018-01-03 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04f4cf20-9b57-3eff-79b6-abfda1258174@codeaurora.org>
On Tuesday, January 02, 2018 08:37:32 AM Sinan Kaya wrote:
> On 12/19/2017 12:38 AM, Sinan Kaya wrote:
> > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > where a PCI device is present. This restricts the device drivers to be
> > reused for other domain numbers.
> >
> > Getting ready to remove pci_get_bus_and_slot() function in favor of
> > pci_get_domain_bus_and_slot().
> >
> > struct riva_par has a pointer to struct pci_dev. Use the pci_dev member
> > to extract the domain information.
> >
> > Change the function signature for CalcStateExt and RivaGetConfig to pass
> > in struct pci_dev in addition to RIVA_HW_INST so that code inside the
> > riva_hw.c can also calculate domain number and pass it to
> > pci_get_domain_bus_and_slot().
> >
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Any feedback here, most of the remaining patches have the ACK except these?
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [net-next: PATCH v2 5/5] net: mvpp2: enable ACPI support in the driver
From: Marcin Wojtas @ 2018-01-03 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103111611.GB21230@xora-haswell>
Graeme,
2018-01-03 12:16 GMT+01:00 <graeme.gregory@linaro.org>:
> On Sun, Dec 31, 2017 at 08:23:54PM +0100, Andrew Lunn wrote:
>> > * Modify way of obtaining interrupts - with ACPI they are resources
>> > bound to struct platform_device and it's not possible to obtain
>> > them directly from the child node. Hence a formula is used, depending
>> > on the port_id and number of possible CPUs.
>>
>> Hi Marcin
>>
>> I know nothing about ACPI. Is this limitation with respect to
>> interrupts fundamental to ACPI, or just that nobody has implemented
>> flexible interrupt support yet?
>>
> The infrastructure is there to traverse trees of children, but I don't
> think there any helper functions.
>
Thanks, so if I implement such, do you expect any formal issues that
prevent its acceptance?
Best regards,
Marcin
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
From: Ganapatrao Kulkarni @ 2018-01-03 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da5b60cf-2ede-720e-b957-4e88325a7810@arm.com>
On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
>> Hi Marc,
>>
>> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>>>> When an interrupt is moved across node collections on ThunderX2
>>>
>>> node collections?
>>
>> ok, i will rephrase it.
>> i was intended to say cross NUMA node collection/cpu affinity change.
>>
>>>
>>>> multi Socket platform, an interrupt stops routed to new collection
>>>> and results in loss of interrupts.
>>>>
>>>> Adding workaround to issue INV after MOVI for cross-node collection
>>>> move to flush out the cached entry.
>>>>
>>>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>>>> ---
>>>> Documentation/arm64/silicon-errata.txt | 1 +
>>>> arch/arm64/Kconfig | 11 +++++++++++
>>>> drivers/irqchip/irq-gic-v3-its.c | 24 ++++++++++++++++++++++++
>>>> 3 files changed, 36 insertions(+)
>>>>
>>>> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
>>>> index fc1c884..fb27cb5 100644
>>>> --- a/Documentation/arm64/silicon-errata.txt
>>>> +++ b/Documentation/arm64/silicon-errata.txt
>>>> @@ -63,6 +63,7 @@ stable kernels.
>>>> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
>>>> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
>>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
>>>> +| Cavium | ThunderX2 ITS | #174 | CAVIUM_ERRATUM_174 |
>>>> | Cavium | ThunderX2 SMMUv3| #74 | N/A |
>>>> | Cavium | ThunderX2 SMMUv3| #126 | N/A |
>>>> | | | | |
>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>>> index c9a7e9e..71a7e30 100644
>>>> --- a/arch/arm64/Kconfig
>>>> +++ b/arch/arm64/Kconfig
>>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>>>
>>>> If unsure, say Y.
>>>>
>>>> +config CAVIUM_ERRATUM_174
>>>> + bool "Cavium ThunderX2 erratum 174"
>>>> + depends on NUMA
>>>
>>> Why? This system will be affected no matter whether NUMA is selected or not.
>>
>> it does not makes sense to enable on non-NUMA/single socket platforms.
>> By default NUMA is enabled on ThunderX2 dual socket platforms.
>
> <quote>
> config ARCH_THUNDER2
> bool "Cavium ThunderX2 Server Processors"
> select GPIOLIB
> help
> This enables support for Cavium's ThunderX2 CN99XX family of
> server processors.
> </quote>
>
> Do you see any NUMA here? I can perfectly compile a kernel with both
> sockets, and not using NUMA. NUMA has to do with memory, and not interrupts.
ok, i will remote it.
>
>>
>>>
>>>> + default y
>>>> + help
>>>> + LPI stops routed to redistributors after inter node collection
>>>> + move in ITS. Enable workaround to invalidate ITS entry after
>>>> + inter-node collection move.
>>>
>>> That's a very terse description. Nobody knows what an LPI, a
>>> redistributor or a collection is. Please explain what the erratum is in
>>> layman's terms (Cavium ThunderX2 systems may loose interrupts on
>>> affinity change) so that people understand whether or not they are affected.
>>
>> ok, i will rephrase it in next version.
>>>
>>>> +
>>>> + If unsure, say Y.
>>>> +
>>>> config CAVIUM_ERRATUM_22375
>>>> bool "Cavium erratum 22375, 24313"
>>>> default y
>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>>> index 06f025f..d8b9c96 100644
>>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>>> @@ -46,6 +46,7 @@
>>>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
>>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
>>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
>>>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>>>>
>>>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>>>>
>>>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>>>> if (cpu != its_dev->event_map.col_map[id]) {
>>>> target_col = &its_dev->its->collections[cpu];
>>>> its_send_movi(its_dev, target_col, id);
>>>> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
>>>> + /* Issue INV for cross node collection move. */
>>>> + if (cpu_to_node(cpu) !=
>>>> + cpu_to_node(its_dev->event_map.col_map[id]))
>>>> + its_send_inv(its_dev, id);
>>>> + }
>>>
>>> What happens if an interrupt happens after the MOV, but before the INV?
>>
>> there can be drop, if interrupt happens before INV, however, it is
>> highly unlikely that we will hit the issue since MOVI and INV are
>> executed back to back. this workaround fixed issue seen on couple of
>> IOs.
>
> Really? So this doesn't fix anything, and the device may just wait
> forever for the CPU to service an LPI that was never delivered. I'm
> sorry, but that's not an acceptable workaround.
>
> I can see two solutions:
> 1) you inject an interrupt after the INV as you may have lost at least one
> 2) you restrict the affinity of LPIs to a single socket
>
> (1) will generate spurious interrupts, but will be safe. (2) will result
> in an unbalanced system. Pick your poison...
>
> You may be able to achieve something by disabling the LPI before
> performing the MOVI/INV sequence, and reenable it afterwards, but only
> you can tell if this could work with your HW.
thanks for the suggestion, i will try out disable/enable LPI.
the sequence would be,
Disable LPI in rdist of cpu1
MOVI from cpu1 to cpu2
INV
enable LPI in rdist of cpu1
>
> In any case, I won't take a workaround that leaves any chance of loosing
> an interrupt.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
thanks
Ganapat
^ permalink raw reply
* [PATCH] ARM: dts: imx6ul: remove unnecessary clocks for cpu-freq
From: Anson Huang @ 2018-01-03 11:22 UTC (permalink / raw)
To: linux-arm-kernel
Remove unnecessary clocks for cpu-freq driver to
avoid confusion.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx6ul.dtsi | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 86b3251..fb06a9a 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -86,15 +86,10 @@
<&clks IMX6UL_CA7_SECONDARY_SEL>,
<&clks IMX6UL_CLK_STEP>,
<&clks IMX6UL_CLK_PLL1_SW>,
- <&clks IMX6UL_CLK_PLL1_SYS>,
- <&clks IMX6UL_PLL1_BYPASS>,
- <&clks IMX6UL_CLK_PLL1>,
- <&clks IMX6UL_PLL1_BYPASS_SRC>,
- <&clks IMX6UL_CLK_OSC>;
+ <&clks IMX6UL_CLK_PLL1_SYS>;
clock-names = "arm", "pll2_bus", "pll2_pfd2_396m",
"secondary_sel", "step", "pll1_sw",
- "pll1_sys", "pll1_bypass", "pll1",
- "pll1_bypass_src", "osc";
+ "pll1_sys";
arm-supply = <®_arm>;
soc-supply = <®_soc>;
};
--
1.9.1
^ permalink raw reply related
* [net-next: PATCH v2 1/5] device property: Introduce fwnode_get_mac_address()
From: Rafael J. Wysocki @ 2018-01-03 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514721520-18964-2-git-send-email-mw@semihalf.com>
On Sunday, December 31, 2017 12:58:36 PM CET Marcin Wojtas wrote:
> Until now there were two almost identical functions for
> obtaining MAC address - of_get_mac_address() and, more generic,
> device_get_mac_address(). However it is not uncommon,
> that the network interface is represented as a child
> of the actual controller, hence it is not associated
> directly to any struct device, required by the latter
> routine.
>
> This commit allows for getting the MAC address for
> children nodes in the ACPI world by introducing a new function -
> fwnode_get_mac_address(). This commit also changes
> device_get_mac_address() routine to be its wrapper, in order
> to prevent unnecessary duplication.
>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
The changes look reasonable to me, so
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/base/property.c | 28 ++++++++++++++------
> include/linux/property.h | 2 ++
> 2 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 851b1b6..f261d1a 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -1153,11 +1153,11 @@ int device_get_phy_mode(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(device_get_phy_mode);
>
> -static void *device_get_mac_addr(struct device *dev,
> +static void *fwnode_get_mac_addr(struct fwnode_handle *fwnode,
> const char *name, char *addr,
> int alen)
> {
> - int ret = device_property_read_u8_array(dev, name, addr, alen);
> + int ret = fwnode_property_read_u8_array(fwnode, name, addr, alen);
>
> if (ret == 0 && alen == ETH_ALEN && is_valid_ether_addr(addr))
> return addr;
> @@ -1165,8 +1165,8 @@ static void *device_get_mac_addr(struct device *dev,
> }
>
> /**
> - * device_get_mac_address - Get the MAC for a given device
> - * @dev: Pointer to the device
> + * fwnode_get_mac_address - Get the MAC from the firmware node
> + * @fwnode: Pointer to the firmware node
> * @addr: Address of buffer to store the MAC in
> * @alen: Length of the buffer pointed to by addr, should be ETH_ALEN
> *
> @@ -1187,19 +1187,31 @@ static void *device_get_mac_addr(struct device *dev,
> * In this case, the real MAC is in 'local-mac-address', and 'mac-address'
> * exists but is all zeros.
> */
> -void *device_get_mac_address(struct device *dev, char *addr, int alen)
> +void *fwnode_get_mac_address(struct fwnode_handle *fwnode, char *addr, int alen)
> {
> char *res;
>
> - res = device_get_mac_addr(dev, "mac-address", addr, alen);
> + res = fwnode_get_mac_addr(fwnode, "mac-address", addr, alen);
> if (res)
> return res;
>
> - res = device_get_mac_addr(dev, "local-mac-address", addr, alen);
> + res = fwnode_get_mac_addr(fwnode, "local-mac-address", addr, alen);
> if (res)
> return res;
>
> - return device_get_mac_addr(dev, "address", addr, alen);
> + return fwnode_get_mac_addr(fwnode, "address", addr, alen);
> +}
> +EXPORT_SYMBOL(fwnode_get_mac_address);
> +
> +/**
> + * device_get_mac_address - Get the MAC for a given device
> + * @dev: Pointer to the device
> + * @addr: Address of buffer to store the MAC in
> + * @alen: Length of the buffer pointed to by addr, should be ETH_ALEN
> + */
> +void *device_get_mac_address(struct device *dev, char *addr, int alen)
> +{
> + return fwnode_get_mac_address(dev_fwnode(dev), addr, alen);
> }
> EXPORT_SYMBOL(device_get_mac_address);
>
> diff --git a/include/linux/property.h b/include/linux/property.h
> index f6189a3..35620e0 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -279,6 +279,8 @@ int device_get_phy_mode(struct device *dev);
>
> void *device_get_mac_address(struct device *dev, char *addr, int alen);
>
> +void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
> + char *addr, int alen);
> struct fwnode_handle *fwnode_graph_get_next_endpoint(
> const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
> struct fwnode_handle *
>
^ permalink raw reply
* [net-next: PATCH v2 2/5] device property: Introduce fwnode_get_phy_mode()
From: Rafael J. Wysocki @ 2018-01-03 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514721520-18964-3-git-send-email-mw@semihalf.com>
On Sunday, December 31, 2017 12:58:37 PM CET Marcin Wojtas wrote:
> Until now there were two almost identical functions for
> obtaining network PHY mode - of_get_phy_mode() and,
> more generic, device_get_phy_mode(). However it is not uncommon,
> that the network interface is represented as a child
> of the actual controller, hence it is not associated
> directly to any struct device, required by the latter
> routine.
>
> This commit allows for getting the PHY mode for
> children nodes in the ACPI world by introducing a new function -
> fwnode_get_phy_mode(). This commit also changes
> device_get_phy_mode() routine to be its wrapper, in order
> to prevent unnecessary duplication.
>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/base/property.c | 24 ++++++++++++++++----
> include/linux/property.h | 1 +
> 2 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index f261d1a..7c4a53d 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -1126,21 +1126,21 @@ enum dev_dma_attr device_get_dma_attr(struct device *dev)
> EXPORT_SYMBOL_GPL(device_get_dma_attr);
>
> /**
> - * device_get_phy_mode - Get phy mode for given device
> - * @dev: Pointer to the given device
> + * fwnode_get_phy_mode - Get phy mode for given firmware node
> + * @fwnode: Pointer to the given node
> *
> * The function gets phy interface string from property 'phy-mode' or
> * 'phy-connection-type', and return its index in phy_modes table, or errno in
> * error case.
> */
> -int device_get_phy_mode(struct device *dev)
> +int fwnode_get_phy_mode(struct fwnode_handle *fwnode)
> {
> const char *pm;
> int err, i;
>
> - err = device_property_read_string(dev, "phy-mode", &pm);
> + err = fwnode_property_read_string(fwnode, "phy-mode", &pm);
> if (err < 0)
> - err = device_property_read_string(dev,
> + err = fwnode_property_read_string(fwnode,
> "phy-connection-type", &pm);
> if (err < 0)
> return err;
> @@ -1151,6 +1151,20 @@ int device_get_phy_mode(struct device *dev)
>
> return -ENODEV;
> }
> +EXPORT_SYMBOL_GPL(fwnode_get_phy_mode);
> +
> +/**
> + * device_get_phy_mode - Get phy mode for given device
> + * @dev: Pointer to the given device
> + *
> + * The function gets phy interface string from property 'phy-mode' or
> + * 'phy-connection-type', and return its index in phy_modes table, or errno in
> + * error case.
> + */
> +int device_get_phy_mode(struct device *dev)
> +{
> + return fwnode_get_phy_mode(dev_fwnode(dev));
> +}
> EXPORT_SYMBOL_GPL(device_get_phy_mode);
>
> static void *fwnode_get_mac_addr(struct fwnode_handle *fwnode,
> diff --git a/include/linux/property.h b/include/linux/property.h
> index 35620e0..9b13332 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -279,6 +279,7 @@ int device_get_phy_mode(struct device *dev);
>
> void *device_get_mac_address(struct device *dev, char *addr, int alen);
>
> +int fwnode_get_phy_mode(struct fwnode_handle *fwnode);
> void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
> char *addr, int alen);
> struct fwnode_handle *fwnode_graph_get_next_endpoint(
>
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
From: Marc Zyngier @ 2018-01-03 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKTKpr79ynWSLLftu7i+GARx4hyQrokpa3xpVnvFkmQaS6JjAA@mail.gmail.com>
On 03/01/18 11:20, Ganapatrao Kulkarni wrote:
> On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
>>> Hi Marc,
>>>
>>> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>>>>> When an interrupt is moved across node collections on ThunderX2
>>>>
>>>> node collections?
>>>
>>> ok, i will rephrase it.
>>> i was intended to say cross NUMA node collection/cpu affinity change.
>>>
>>>>
>>>>> multi Socket platform, an interrupt stops routed to new collection
>>>>> and results in loss of interrupts.
>>>>>
>>>>> Adding workaround to issue INV after MOVI for cross-node collection
>>>>> move to flush out the cached entry.
>>>>>
>>>>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>>>>> ---
>>>>> Documentation/arm64/silicon-errata.txt | 1 +
>>>>> arch/arm64/Kconfig | 11 +++++++++++
>>>>> drivers/irqchip/irq-gic-v3-its.c | 24 ++++++++++++++++++++++++
>>>>> 3 files changed, 36 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
>>>>> index fc1c884..fb27cb5 100644
>>>>> --- a/Documentation/arm64/silicon-errata.txt
>>>>> +++ b/Documentation/arm64/silicon-errata.txt
>>>>> @@ -63,6 +63,7 @@ stable kernels.
>>>>> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
>>>>> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
>>>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
>>>>> +| Cavium | ThunderX2 ITS | #174 | CAVIUM_ERRATUM_174 |
>>>>> | Cavium | ThunderX2 SMMUv3| #74 | N/A |
>>>>> | Cavium | ThunderX2 SMMUv3| #126 | N/A |
>>>>> | | | | |
>>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>>>> index c9a7e9e..71a7e30 100644
>>>>> --- a/arch/arm64/Kconfig
>>>>> +++ b/arch/arm64/Kconfig
>>>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>>>>
>>>>> If unsure, say Y.
>>>>>
>>>>> +config CAVIUM_ERRATUM_174
>>>>> + bool "Cavium ThunderX2 erratum 174"
>>>>> + depends on NUMA
>>>>
>>>> Why? This system will be affected no matter whether NUMA is selected or not.
>>>
>>> it does not makes sense to enable on non-NUMA/single socket platforms.
>>> By default NUMA is enabled on ThunderX2 dual socket platforms.
>>
>> <quote>
>> config ARCH_THUNDER2
>> bool "Cavium ThunderX2 Server Processors"
>> select GPIOLIB
>> help
>> This enables support for Cavium's ThunderX2 CN99XX family of
>> server processors.
>> </quote>
>>
>> Do you see any NUMA here? I can perfectly compile a kernel with both
>> sockets, and not using NUMA. NUMA has to do with memory, and not interrupts.
>
> ok, i will remote it.
>>
>>>
>>>>
>>>>> + default y
>>>>> + help
>>>>> + LPI stops routed to redistributors after inter node collection
>>>>> + move in ITS. Enable workaround to invalidate ITS entry after
>>>>> + inter-node collection move.
>>>>
>>>> That's a very terse description. Nobody knows what an LPI, a
>>>> redistributor or a collection is. Please explain what the erratum is in
>>>> layman's terms (Cavium ThunderX2 systems may loose interrupts on
>>>> affinity change) so that people understand whether or not they are affected.
>>>
>>> ok, i will rephrase it in next version.
>>>>
>>>>> +
>>>>> + If unsure, say Y.
>>>>> +
>>>>> config CAVIUM_ERRATUM_22375
>>>>> bool "Cavium erratum 22375, 24313"
>>>>> default y
>>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>>>> index 06f025f..d8b9c96 100644
>>>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>>>> @@ -46,6 +46,7 @@
>>>>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
>>>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
>>>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
>>>>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>>>>>
>>>>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>>>>>
>>>>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>>>>> if (cpu != its_dev->event_map.col_map[id]) {
>>>>> target_col = &its_dev->its->collections[cpu];
>>>>> its_send_movi(its_dev, target_col, id);
>>>>> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
>>>>> + /* Issue INV for cross node collection move. */
>>>>> + if (cpu_to_node(cpu) !=
>>>>> + cpu_to_node(its_dev->event_map.col_map[id]))
>>>>> + its_send_inv(its_dev, id);
>>>>> + }
>>>>
>>>> What happens if an interrupt happens after the MOV, but before the INV?
>>>
>>> there can be drop, if interrupt happens before INV, however, it is
>>> highly unlikely that we will hit the issue since MOVI and INV are
>>> executed back to back. this workaround fixed issue seen on couple of
>>> IOs.
>>
>> Really? So this doesn't fix anything, and the device may just wait
>> forever for the CPU to service an LPI that was never delivered. I'm
>> sorry, but that's not an acceptable workaround.
>>
>> I can see two solutions:
>> 1) you inject an interrupt after the INV as you may have lost at least one
>> 2) you restrict the affinity of LPIs to a single socket
>>
>> (1) will generate spurious interrupts, but will be safe. (2) will result
>> in an unbalanced system. Pick your poison...
>>
>> You may be able to achieve something by disabling the LPI before
>> performing the MOVI/INV sequence, and reenable it afterwards, but only
>> you can tell if this could work with your HW.
>
> thanks for the suggestion, i will try out disable/enable LPI.
> the sequence would be,
> Disable LPI in rdist of cpu1
> MOVI from cpu1 to cpu2
> INV
> enable LPI in rdist of cpu1
You cannot disable LPIs at the redistributor level. For a start, this is
not allowed by the architecture. It would also result in all the other
LPIs to be lost. What you can do is to disable the single LPI you're
about to move:
its_mask_irq(d);
MOVI
its_unmask_irq(d);
This will result in an INV/MOVI/INV sequence. Hopefully your MOVI
implementation can move pending bits. But I don't know if that's enough,
given the description of the erratum. And the more I think of it, the
less I think it is a viable workaround.
I'm starting to believe that something similar to
ITS_FLAGS_WORKAROUND_CAVIUM_23144 is the way to go.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] nokia N9: Add support for magnetometer and touchscreen
From: Sebastian Reichel @ 2018-01-03 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103102553.GA28083@amd>
Hi,
On Wed, Jan 03, 2018 at 11:25:53AM +0100, Pavel Machek wrote:
> On Tue 2018-01-02 18:27:20, Sebastian Reichel wrote:
> > Hi,
> >
> > On Tue, Jan 02, 2018 at 02:17:22PM +0100, Pavel Machek wrote:
> > > This adds dts support for magnetometer and touchscreen on Nokia N9.
> >
> > I think it makes sense to have this splitted.
>
> Creating more work for everyone for little gain? Meh.
More work for everyone? Could you please read Documentation/process
and actually follow it? It has a section about patches containing a
single logical change and you add two completly unrelated devices to
the device tree.
Also I suggest, that you rework your git workflow if this makes
more work than writing two sentences.
> > > diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> > > index 39e35f8..57a6679 100644
> > > --- a/arch/arm/boot/dts/omap3-n9.dts
> > > +++ b/arch/arm/boot/dts/omap3-n9.dts
> > > @@ -36,6 +57,22 @@
> > > };
> > > };
> > > };
> > > +
> > > + touch at 4b {
> >
> > touchscreen@
>
> Ok.
>
> > > + compatible = "atmel,maxtouch";
> > > + reg = <0x4b>;
> > > + interrupt-parent = <&gpio2>;
> > > + interrupts = <29 2>; /* gpio_61, IRQF_TRIGGER_FALLING*/
> >
> > reset-gpios = <&gpio3 17 GPIO_ACTIVE_SOMETHING>;
> >
> > > + vdd-supply = <&vio>;
> > > + avdd-supply = <&vaux1>;
> >
> > Those two are not mentioned in the binding and not supported by the
> > driver as far as I can see?
>
> Driver will need to be fixed, AFAICT :-(.
Obviously. DTS is only updated when binding has been acknowledged,
though. To get this working ASAP you can add "always-enabled;" to
the regulator and remove it once the driver gained support for
enabling the regulators itself.
> > Touchscreen with the same settings is required for n950, so it
> > should be in the shared n950 + n9 file.
>
> In future, settings will be different for n9/n950: calibration matrix
> is different as panel is rotated in different way. Still it probably
> makes sense to share. Ok.
The differences can be specified in the specific files by doing
something like the following:
n9-n950.dtsi:
ts: touchscreen {
shared-properties;
};
n9.dts:
&ts {
only-for-n9;
};
n950.dts:
&ts {
only-for-n950;
};
> > > +&i2c3 {
> > > + ak8975 at 0f {
> > > + compatible = "asahi-kasei,ak8975";
> > > + reg = <0x0f>;
> > > + };
> > > };
> >
> > Looking at the N9 board file this is missing a rotation matrix. This
> > is supported by the binding:
> >
> > Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
>
> Do you have an idea how the rotation matrix should look like? I don't
> currently have an userland software that could calibrate and test the
> sensor, so I'd prefer to merge basic binding now and do calibration
> later.
Well you take the values from sysfs, multiply it with the rotation
matrix and check if the values look ok. No special userspace tools
required except mount (for sysfs), ls & cat.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180103/3cc73e3f/attachment.sig>
^ permalink raw reply
* [PATCH RESEND V2 1/1] cpufreq: imx6q: switch to Use clk_bulk_get to refine clk operations
From: Rafael J. Wysocki @ 2018-01-03 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514004832-373-1-git-send-email-aisheng.dong@nxp.com>
On Saturday, December 23, 2017 5:53:52 AM CET Dong Aisheng wrote:
> Use clk_bulk_get to ease the driver clocks handling.
>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Anson Huang <anson.huang@nxp.com>
> Cc: Leonard Crestez <leonard.crestez@nxp.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> Rebased on linux-pm.git/linux-next branch
> ---
> drivers/cpufreq/imx6q-cpufreq.c | 125 ++++++++++++++++++----------------------
> 1 file changed, 56 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
> index d9b2c2d..8bfb077 100644
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -25,15 +25,29 @@ static struct regulator *arm_reg;
> static struct regulator *pu_reg;
> static struct regulator *soc_reg;
>
> -static struct clk *arm_clk;
> -static struct clk *pll1_sys_clk;
> -static struct clk *pll1_sw_clk;
> -static struct clk *step_clk;
> -static struct clk *pll2_pfd2_396m_clk;
> -
> -/* clk used by i.MX6UL */
> -static struct clk *pll2_bus_clk;
> -static struct clk *secondary_sel_clk;
> +enum IMX6_CPUFREQ_CLKS {
> + ARM,
> + PLL1_SYS,
> + STEP,
> + PLL1_SW,
> + PLL2_PFD2_396M,
> + /* MX6UL requires two more clks */
> + PLL2_BUS,
> + SECONDARY_SEL,
> +};
> +#define IMX6Q_CPUFREQ_CLK_NUM 5
> +#define IMX6UL_CPUFREQ_CLK_NUM 7
> +
> +static int num_clks;
> +static struct clk_bulk_data clks[] = {
> + { .id = "arm" },
> + { .id = "pll1_sys" },
> + { .id = "step" },
> + { .id = "pll1_sw" },
> + { .id = "pll2_pfd2_396m" },
> + { .id = "pll2_bus" },
> + { .id = "secondary_sel" },
> +};
>
> static struct device *cpu_dev;
> static bool free_opp;
> @@ -53,7 +67,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
>
> new_freq = freq_table[index].frequency;
> freq_hz = new_freq * 1000;
> - old_freq = clk_get_rate(arm_clk) / 1000;
> + old_freq = clk_get_rate(clks[ARM].clk) / 1000;
>
> opp = dev_pm_opp_find_freq_ceil(cpu_dev, &freq_hz);
> if (IS_ERR(opp)) {
> @@ -112,29 +126,31 @@ static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
> * voltage of 528MHz, so lower the CPU frequency to one
> * half before changing CPU frequency.
> */
> - clk_set_rate(arm_clk, (old_freq >> 1) * 1000);
> - clk_set_parent(pll1_sw_clk, pll1_sys_clk);
> - if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk))
> - clk_set_parent(secondary_sel_clk, pll2_bus_clk);
> + clk_set_rate(clks[ARM].clk, (old_freq >> 1) * 1000);
> + clk_set_parent(clks[PLL1_SW].clk, clks[PLL1_SYS].clk);
> + if (freq_hz > clk_get_rate(clks[PLL2_PFD2_396M].clk))
> + clk_set_parent(clks[SECONDARY_SEL].clk,
> + clks[PLL2_BUS].clk);
> else
> - clk_set_parent(secondary_sel_clk, pll2_pfd2_396m_clk);
> - clk_set_parent(step_clk, secondary_sel_clk);
> - clk_set_parent(pll1_sw_clk, step_clk);
> + clk_set_parent(clks[SECONDARY_SEL].clk,
> + clks[PLL2_PFD2_396M].clk);
> + clk_set_parent(clks[STEP].clk, clks[SECONDARY_SEL].clk);
> + clk_set_parent(clks[PLL1_SW].clk, clks[STEP].clk);
> } else {
> - clk_set_parent(step_clk, pll2_pfd2_396m_clk);
> - clk_set_parent(pll1_sw_clk, step_clk);
> - if (freq_hz > clk_get_rate(pll2_pfd2_396m_clk)) {
> - clk_set_rate(pll1_sys_clk, new_freq * 1000);
> - clk_set_parent(pll1_sw_clk, pll1_sys_clk);
> + clk_set_parent(clks[STEP].clk, clks[PLL2_PFD2_396M].clk);
> + clk_set_parent(clks[PLL1_SW].clk, clks[STEP].clk);
> + if (freq_hz > clk_get_rate(clks[PLL2_PFD2_396M].clk)) {
> + clk_set_rate(clks[PLL1_SYS].clk, new_freq * 1000);
> + clk_set_parent(clks[PLL1_SW].clk, clks[PLL1_SYS].clk);
> } else {
> /* pll1_sys needs to be enabled for divider rate change to work. */
> pll1_sys_temp_enabled = true;
> - clk_prepare_enable(pll1_sys_clk);
> + clk_prepare_enable(clks[PLL1_SYS].clk);
> }
> }
>
> /* Ensure the arm clock divider is what we expect */
> - ret = clk_set_rate(arm_clk, new_freq * 1000);
> + ret = clk_set_rate(clks[ARM].clk, new_freq * 1000);
> if (ret) {
> dev_err(cpu_dev, "failed to set clock rate: %d\n", ret);
> regulator_set_voltage_tol(arm_reg, volt_old, 0);
> @@ -143,7 +159,7 @@ static int imx6q_set_target(struct cpufreq_policy *policy, unsigned int index)
>
> /* PLL1 is only needed until after ARM-PODF is set. */
> if (pll1_sys_temp_enabled)
> - clk_disable_unprepare(pll1_sys_clk);
> + clk_disable_unprepare(clks[PLL1_SYS].clk);
>
> /* scaling down? scale voltage after frequency */
> if (new_freq < old_freq) {
> @@ -174,7 +190,7 @@ static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
> {
> int ret;
>
> - policy->clk = arm_clk;
> + policy->clk = clks[ARM].clk;
> ret = cpufreq_generic_init(policy, freq_table, transition_latency);
> policy->suspend_freq = policy->max;
>
> @@ -266,28 +282,15 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
> return -ENOENT;
> }
>
> - arm_clk = clk_get(cpu_dev, "arm");
> - pll1_sys_clk = clk_get(cpu_dev, "pll1_sys");
> - pll1_sw_clk = clk_get(cpu_dev, "pll1_sw");
> - step_clk = clk_get(cpu_dev, "step");
> - pll2_pfd2_396m_clk = clk_get(cpu_dev, "pll2_pfd2_396m");
> - if (IS_ERR(arm_clk) || IS_ERR(pll1_sys_clk) || IS_ERR(pll1_sw_clk) ||
> - IS_ERR(step_clk) || IS_ERR(pll2_pfd2_396m_clk)) {
> - dev_err(cpu_dev, "failed to get clocks\n");
> - ret = -ENOENT;
> - goto put_clk;
> - }
> -
> if (of_machine_is_compatible("fsl,imx6ul") ||
> - of_machine_is_compatible("fsl,imx6ull")) {
> - pll2_bus_clk = clk_get(cpu_dev, "pll2_bus");
> - secondary_sel_clk = clk_get(cpu_dev, "secondary_sel");
> - if (IS_ERR(pll2_bus_clk) || IS_ERR(secondary_sel_clk)) {
> - dev_err(cpu_dev, "failed to get clocks specific to imx6ul\n");
> - ret = -ENOENT;
> - goto put_clk;
> - }
> - }
> + of_machine_is_compatible("fsl,imx6ull"))
> + num_clks = IMX6UL_CPUFREQ_CLK_NUM;
> + else
> + num_clks = IMX6Q_CPUFREQ_CLK_NUM;
> +
> + ret = clk_bulk_get(cpu_dev, num_clks, clks);
> + if (ret)
> + goto put_node;
>
> arm_reg = regulator_get(cpu_dev, "arm");
> pu_reg = regulator_get_optional(cpu_dev, "pu");
> @@ -424,22 +427,11 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
> regulator_put(pu_reg);
> if (!IS_ERR(soc_reg))
> regulator_put(soc_reg);
> -put_clk:
> - if (!IS_ERR(arm_clk))
> - clk_put(arm_clk);
> - if (!IS_ERR(pll1_sys_clk))
> - clk_put(pll1_sys_clk);
> - if (!IS_ERR(pll1_sw_clk))
> - clk_put(pll1_sw_clk);
> - if (!IS_ERR(step_clk))
> - clk_put(step_clk);
> - if (!IS_ERR(pll2_pfd2_396m_clk))
> - clk_put(pll2_pfd2_396m_clk);
> - if (!IS_ERR(pll2_bus_clk))
> - clk_put(pll2_bus_clk);
> - if (!IS_ERR(secondary_sel_clk))
> - clk_put(secondary_sel_clk);
> +
> + clk_bulk_put(num_clks, clks);
> +put_node:
> of_node_put(np);
> +
> return ret;
> }
>
> @@ -453,13 +445,8 @@ static int imx6q_cpufreq_remove(struct platform_device *pdev)
> if (!IS_ERR(pu_reg))
> regulator_put(pu_reg);
> regulator_put(soc_reg);
> - clk_put(arm_clk);
> - clk_put(pll1_sys_clk);
> - clk_put(pll1_sw_clk);
> - clk_put(step_clk);
> - clk_put(pll2_pfd2_396m_clk);
> - clk_put(pll2_bus_clk);
> - clk_put(secondary_sel_clk);
> +
> + clk_bulk_put(num_clks, clks);
>
> return 0;
> }
>
Applied, thanks!
^ permalink raw reply
* Applied "ASoC: mediatek: fix error handling in mt2701_afe_pcm_dev_probe()" to the asoc tree
From: Mark Brown @ 2018-01-03 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6081b70610c31f2c92ae1b83decb887a3f690f80.1514881870.git.ryder.lee@mediatek.com>
The patch
ASoC: mediatek: fix error handling in mt2701_afe_pcm_dev_probe()
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From dd6bb9b16f23f9b95b77713c45bd6182336c5b2e Mon Sep 17 00:00:00 2001
From: Ryder Lee <ryder.lee@mediatek.com>
Date: Tue, 2 Jan 2018 19:47:18 +0800
Subject: [PATCH] ASoC: mediatek: fix error handling in
mt2701_afe_pcm_dev_probe()
Fix unbalanced error handling path which will get incorrect counts
if probe failed. The .remove() should be adjusted accordingly.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Tested-by: Garlic Tseng <garlic.tseng@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 31 ++++++++++++++----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index 8fda182f849b..a7362d1cda1b 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -1590,12 +1590,16 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, afe);
- pm_runtime_enable(&pdev->dev);
- if (!pm_runtime_enabled(&pdev->dev))
- goto err_pm_disable;
- pm_runtime_get_sync(&pdev->dev);
- ret = snd_soc_register_platform(&pdev->dev, &mtk_afe_pcm_platform);
+ pm_runtime_enable(dev);
+ if (!pm_runtime_enabled(dev)) {
+ ret = mt2701_afe_runtime_resume(dev);
+ if (ret)
+ goto err_pm_disable;
+ }
+ pm_runtime_get_sync(dev);
+
+ ret = snd_soc_register_platform(dev, &mtk_afe_pcm_platform);
if (ret) {
dev_warn(dev, "err_platform\n");
goto err_platform;
@@ -1610,35 +1614,28 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
goto err_dai_component;
}
- mt2701_afe_runtime_resume(&pdev->dev);
-
return 0;
err_dai_component:
- snd_soc_unregister_component(&pdev->dev);
-
+ snd_soc_unregister_platform(dev);
err_platform:
- snd_soc_unregister_platform(&pdev->dev);
-
+ pm_runtime_put_sync(dev);
err_pm_disable:
- pm_runtime_disable(&pdev->dev);
+ pm_runtime_disable(dev);
return ret;
}
static int mt2701_afe_pcm_dev_remove(struct platform_device *pdev)
{
- struct mtk_base_afe *afe = platform_get_drvdata(pdev);
-
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
if (!pm_runtime_status_suspended(&pdev->dev))
mt2701_afe_runtime_suspend(&pdev->dev);
- pm_runtime_put_sync(&pdev->dev);
snd_soc_unregister_component(&pdev->dev);
snd_soc_unregister_platform(&pdev->dev);
- /* disable afe clock */
- mt2701_afe_disable_clock(afe);
+
return 0;
}
--
2.15.1
^ permalink raw reply related
* [PATCH v5 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622
From: Lorenzo Pieralisi @ 2018-01-03 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514961544.25872.49.camel@mhfsdcap03>
On Wed, Jan 03, 2018 at 02:39:04PM +0800, Honghui Zhang wrote:
> On Tue, 2018-01-02 at 10:56 +0000, Lorenzo Pieralisi wrote:
> > On Thu, Dec 28, 2017 at 09:39:12AM +0800, Honghui Zhang wrote:
> > > On Wed, 2017-12-27 at 12:45 -0600, Bjorn Helgaas wrote:
> > > > On Wed, Dec 27, 2017 at 08:59:54AM +0800, honghui.zhang at mediatek.com wrote:
> > > > > From: Honghui Zhang <honghui.zhang@mediatek.com>
> > > > >
>
> > > > > + /* Set up class code for MT7622 */
> > > > > + val = PCI_CLASS_BRIDGE_PCI << 16;
> > > > > + writel(val, port->base + PCIE_CONF_CLASS);
> > > >
> > > > 1) Your comments mention MT7622 specifically, but this code is run for
> > > > both mt2712-pcie and mt7622-pcie. If this code is safe and necessary
> > > > for both mt2712-pcie and mt7622-pcie, please remove the mention of
> > > > MT7622.
> > >
> > > Hmm, the code snippet added here will only be executed by MT7622, since
> > > MT2712 will not enter this "if (pcie->base) {" condition.
> > > Should the mention of MT7622 must be removed in this case?
> >
> > You should add an explicit way (eg of_device_is_compatible() match for
> > instance) to apply the quirk just on the platform that requires it.
> >
> > Checking for "if (pcie->base)" is really not the way to do it.
> >
>
> hi, Lorenzo,
> Thanks very much for your advise.
> Passing the compatible string or platform data into this function needed
> to add some new field in the struct mtk_pcie_port, then I guess both set
> it for MT2712 and MT7622 is an easy way, since re-setting those values
> for MT2712 is safe.
You have a pointer to the host bridge DT node through the
mtk_pcie_port.pcie->dev pointer, use it to carry out the compatible
match, you have to apply quirks only if needed - I do not want to
guess it.
Lorenzo
> > > > 2) The first comment mentions both "vendor ID and device ID" but you
> > > > don't write the device ID. Since this code applies to both
> > > > mt2712-pcie and mt7622-pcie, my guess is that you don't *want* to
> > > > write the device ID. If that's the case, please fix the comment.
> > > >
> > >
> > > My bad, I did not check the comments carefully.
> > > Thanks.
> > >
> > > > 3) If you only need to set the vendor ID, you're performing a 32-bit
> > > > write (writel()) to update a 16-bit value. Please use writew()
> > > > instead.
> > > >
> > >
> > > Ok, thanks, I guess I could use the following code snippet in the next
> > > version:
> > > val = readl(port->base + PCIE_CONF_VENDOR_ID)
> > > val &= ~GENMASK(15, 0);
> > > val |= PCI_VENDOR_ID_MEDIATEK;
> > > writel(val, port->base + PCIE_CONF_VENDOR_ID);
> >
> > Have you read Bjorn's comment ? Or there is a problem with using
> > a writew() ?
> >
>
> This control register is a 32bit register, I'm not sure whether the apb
> bus support write an 16bit value with 16bit but not 32bit address
> alignment. I prefer the more safety old way of writel.
>
> I need to do more test about the writew if the code elegant is more
> important.
>
> thanks.
>
> > Lorenzo
> >
> > > > 4) If you only need to set the vendor ID, please use a definition like
> > > > "PCIE_CONF_VENDOR_ID" instead of the ambiguous "PCIE_CONF_ID".
> > > >
> > > > 5) If you only need to set the vendor ID, please update the changelog
> > > > to mention "vendor ID" specifically instead of the ambiguous "IDs".
> > >
> > > > 6) Please add a space before the closing "*/" of the first comment.
> > > >
> > > > 7) PCI_CLASS_BRIDGE_PCI is for a PCI-to-PCI bridge, i.e., one that has
> > > > PCI on both the primary (upstream) side and the secondary (downstream)
> > > > side. That kind of bridge has a type 1 config header (see
> > > > PCI_HEADER_TYPE) and the PCI_PRIMARY_BUS and PCI_SECONDARY_BUS
> > > > registers tell us the bus number of the primary and secondary sides.
> > > >
> > > > I don't believe this device is a PCI-to-PCI bridge. I think it's a
> > > > *host* bridge that has some non-PCI interface on the upstream side and
> > > > should have a type 0 config header. If that's the case you should use
> > > > PCI_CLASS_BRIDGE_HOST instead.
> > > >
> > >
> > > Thanks very much for your help with the review, I will fix the other
> > > issue in the next version.
> > >
> > > > > }
> > > > >
> > > > > /* Assert all reset signals */
> > > > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > > > > index ab20dc5..2480b0e 100644
> > > > > --- a/include/linux/pci_ids.h
> > > > > +++ b/include/linux/pci_ids.h
> > > > > @@ -2113,6 +2113,8 @@
> > > > >
> > > > > #define PCI_VENDOR_ID_MYRICOM 0x14c1
> > > > >
> > > > > +#define PCI_VENDOR_ID_MEDIATEK 0x14c3
> > > > > +
> > > > > #define PCI_VENDOR_ID_TITAN 0x14D2
> > > > > #define PCI_DEVICE_ID_TITAN_010L 0x8001
> > > > > #define PCI_DEVICE_ID_TITAN_100L 0x8010
> > > > > --
> > > > > 2.6.4
> > > > >
> > >
> > >
>
>
^ permalink raw reply
* Applied "spi: sirf: account for const type of of_device_id.data" to the spi tree
From: Mark Brown @ 2018-01-03 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514899688-27844-4-git-send-email-Julia.Lawall@lip6.fr>
The patch
spi: sirf: account for const type of of_device_id.data
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9e327ce71f3894e7e6b57f5c15a0dfa5be79f44e Mon Sep 17 00:00:00 2001
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Tue, 2 Jan 2018 14:27:59 +0100
Subject: [PATCH] spi: sirf: account for const type of of_device_id.data
This driver creates various const structures that it stores in the
data field of an of_device_id array.
Adding const to the declaration of the location that receives the
const value from the data field ensures that the compiler will
continue to check that the value is not modified. Furthermore, the
const-discarding cast on the extraction from the data field is no
longer needed.
Done using Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-sirf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-sirf.c b/drivers/spi/spi-sirf.c
index bbb1a275f718..f009d76f96b1 100644
--- a/drivers/spi/spi-sirf.c
+++ b/drivers/spi/spi-sirf.c
@@ -1072,7 +1072,7 @@ static int spi_sirfsoc_probe(struct platform_device *pdev)
struct sirfsoc_spi *sspi;
struct spi_master *master;
struct resource *mem_res;
- struct sirf_spi_comp_data *spi_comp_data;
+ const struct sirf_spi_comp_data *spi_comp_data;
int irq;
int ret;
const struct of_device_id *match;
@@ -1092,7 +1092,7 @@ static int spi_sirfsoc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, master);
sspi = spi_master_get_devdata(master);
sspi->fifo_full_offset = ilog2(sspi->fifo_size);
- spi_comp_data = (struct sirf_spi_comp_data *)match->data;
+ spi_comp_data = match->data;
sspi->regs = spi_comp_data->regs;
sspi->type = spi_comp_data->type;
sspi->fifo_level_chk_mask = (sspi->fifo_size / 4) - 1;
--
2.15.1
^ permalink raw reply related
* [PATCH v4 0/6] clk: renesas: r8a779[56]: Add Z and Z2 clock support
From: Simon Horman @ 2018-01-03 12:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this patch-set adds Z and Z2 clock support.
These are dependencies for supporting CPUFreq. The remainder of that
work is being posted separately and can be found at:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git topic/rcar-gen3-cpufreq-v4
Based on v4.15-rc1
Changes since v3:
* Rebase
* Divide parent clock by 2 to give correct rate (again) * Take care not to overflow multiplication on 32 but platforms
* Use __ffs as FIELD_{GET,PREP} don't not work with non-constant masks
* Use correct mask in cpg_z_clk_recalc_rate()
Changes since v2:
* Rebase
* Address review of v2 as noted in patch changelogs
Takeshi Kihara (6):
clk: renesas: rcar-gen3: Add Z clock divider support
clk: renesas: rcar-gen3: Add Z2 clock divider support
clk: renesas: r8a7795: Add Z clock
clk: renesas: r8a7795: Add Z2 clock
clk: renesas: r8a7796: Add Z clock
clk: renesas: r8a7796: Add Z2 clock
drivers/clk/renesas/r8a7795-cpg-mssr.c | 2 +
drivers/clk/renesas/r8a7796-cpg-mssr.c | 2 +
drivers/clk/renesas/rcar-gen3-cpg.c | 143 +++++++++++++++++++++++++++++++++
drivers/clk/renesas/rcar-gen3-cpg.h | 2 +
4 files changed, 149 insertions(+)
Results of testing this on the Salvator-X r8a7796 are as follows:
On Boot
-------
Z clock is half of pll0 and corresponds to CPU frequency.
Z2 clock is half pll2. This is as expected.
root at Debian:~# cd /sys/devices/system/cpu/cpu0/cpufreq
root at Debian:/sys/devices/system/cpu/cpu0/cpufreq# grep -E -w "pll0|z" /sys/kernel/debug/clk/clk_summary; grep -E -w "pll2|z2" /sys/kernel/debug/clk/clk_summary; grep . *cur*
.pll0 0 0 2999999880 0 0
z 0 0 1499999940 0 0
.pll2 0 0 2399999904 0 0
z2 0 0 1199999952 0 0
cpuinfo_cur_freq:1499999
scaling_cur_freq:1500000
CPU Freq scaled to 1000000 and then 500000
------------------------------------------
Z clock corresponds to new CPU frequency.
Z2 clock, PLL0 and PLL2 are unchanged.
This is also as expected.
root at Debian:/sys/devices/system/cpu/cpu0/cpufreq# echo 1000000 > scaling_max_freq
root at Debian:/sys/devices/system/cpu/cpu0/cpufreq# grep -E -w "pll0|z" /sys/kernel/debug/clk/clk_summary; grep -E -w "pll2|z2" /sys/kernel/debug/clk/clk_summary; grep . *cur*
grep . *cur*lk_summary; grep -E -w "pll2|z2" /sys/kernel/debug/clk/clk_summary;
.pll0 0 0 2999999880 0 0
z 0 0 1031249959 0 0
.pll2 0 0 2399999904 0 0
z2 0 0 1199999952 0 0
cpuinfo_cur_freq:1031249
scaling_cur_freq:1000000
root at Debian:/sys/devices/system/cpu/cpu0/cpufreq# echo 500000 > scaling_max_freq
root at Debian:/sys/devices/system/cpu/cpu0/cpufreq# grep -E -w "pll0|z" /sys/kernel/debug/clk/clk_summary; grep -E -w "pll2|z2" /sys/kernel/debug/clk/clk_summary; grep . *cur*
.pll0 0 0 2999999880 0 0
z 0 0 468749981 0 0
.pll2 0 0 2399999904 0 0
z2 0 0 1199999952 0 0
cpuinfo_cur_freq:468749
scaling_cur_freq:500000
^ permalink raw reply
* [PATCH v4 1/6] clk: renesas: rcar-gen3: Add Z clock divider support
From: Simon Horman @ 2018-01-03 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103121840.29316-1-horms+renesas@verge.net.au>
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch adds Z clock divider support for R-Car Gen3 SoC.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v4 [Simon Horman]
* Rebase
* Divide parent clock by 2 to give correct rate (again)
* Take care not to overflow multiplication on 32 but platforms
v3 [Simon Horman]
* Use DIV_ROUND_CLOSEST_ULL instead of open-coding the same behaviour
using div_u64()
* Do not round rate to 100MHz in cpg_z_clk_recalc_rate
* Remove calculation for PLL post-divider, this is bogus.
Instead do not round to closest in cpg_z_clk_round_rate()
* Drop check for !prate in cpg_z_clk_round_rate
v1 [Simon Horman]
* Divide parent clock by 2 to give correct rate
* Use GENMASK, FIELD_{GET,PREP}
* Correct whitespace
* Arrange local variables in reverse Christmas tree order
v0 [Takeshi Kihara]
---
drivers/clk/renesas/rcar-gen3-cpg.c | 133 ++++++++++++++++++++++++++++++++++++
drivers/clk/renesas/rcar-gen3-cpg.h | 1 +
2 files changed, 134 insertions(+)
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c b/drivers/clk/renesas/rcar-gen3-cpg.c
index 0904886f5501..b85918fa62c6 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -13,6 +13,7 @@
*/
#include <linux/bug.h>
+#include <linux/bitfield.h>
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/device.h>
@@ -62,6 +63,134 @@ static void cpg_simple_notifier_register(struct raw_notifier_head *notifiers,
}
/*
+ * Z Clock
+ *
+ * Traits of this clock:
+ * prepare - clk_prepare only ensures that parents are prepared
+ * enable - clk_enable only ensures that parents are enabled
+ * rate - rate is adjustable. clk->rate = (parent->rate * mult / 32 ) / 2
+ * parent - fixed parent. No clk_set_parent support
+ */
+#define CPG_FRQCRB 0x00000004
+#define CPG_FRQCRB_KICK BIT(31)
+#define CPG_FRQCRC 0x000000e0
+#define CPG_FRQCRC_ZFC_MASK GENMASK(12, 8)
+
+struct cpg_z_clk {
+ struct clk_hw hw;
+ void __iomem *reg;
+ void __iomem *kick_reg;
+};
+
+#define to_z_clk(_hw) container_of(_hw, struct cpg_z_clk, hw)
+
+static unsigned long cpg_z_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct cpg_z_clk *zclk = to_z_clk(hw);
+ unsigned int mult;
+
+ mult = 32 - FIELD_GET(CPG_FRQCRC_ZFC_MASK, clk_readl(zclk->reg));
+
+ /* Factor of 2 is for fixed divider */
+ return DIV_ROUND_CLOSEST_ULL((u64)parent_rate * mult, 32 * 2);
+}
+
+static long cpg_z_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ /* Factor of 2 is for fixed divider */
+ unsigned long prate = *parent_rate / 2;
+ unsigned int mult;
+
+ mult = div_u64(rate * 32ULL, prate);
+ mult = clamp(mult, 1U, 32U);
+
+ return (u64)prate * mult / 32;
+}
+
+static int cpg_z_clk_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct cpg_z_clk *zclk = to_z_clk(hw);
+ unsigned int mult;
+ unsigned int i;
+ u32 val, kick;
+
+ /* Factor of 2 is for fixed divider */
+ mult = DIV_ROUND_CLOSEST_ULL(rate * 32ULL * 2, parent_rate);
+ mult = clamp(mult, 1U, 32U);
+
+ if (clk_readl(zclk->kick_reg) & CPG_FRQCRB_KICK)
+ return -EBUSY;
+
+ val = clk_readl(zclk->reg) & ~CPG_FRQCRC_ZFC_MASK;
+ val |= FIELD_PREP(CPG_FRQCRC_ZFC_MASK, 32 - mult);
+ clk_writel(val, zclk->reg);
+
+ /*
+ * Set KICK bit in FRQCRB to update hardware setting and wait for
+ * clock change completion.
+ */
+ kick = clk_readl(zclk->kick_reg);
+ kick |= CPG_FRQCRB_KICK;
+ clk_writel(kick, zclk->kick_reg);
+
+ /*
+ * Note: There is no HW information about the worst case latency.
+ *
+ * Using experimental measurements, it seems that no more than
+ * ~10 iterations are needed, independently of the CPU rate.
+ * Since this value might be dependent of external xtal rate, pll1
+ * rate or even the other emulation clocks rate, use 1000 as a
+ * "super" safe value.
+ */
+ for (i = 1000; i; i--) {
+ if (!(clk_readl(zclk->kick_reg) & CPG_FRQCRB_KICK))
+ return 0;
+
+ cpu_relax();
+ }
+
+ return -ETIMEDOUT;
+}
+
+static const struct clk_ops cpg_z_clk_ops = {
+ .recalc_rate = cpg_z_clk_recalc_rate,
+ .round_rate = cpg_z_clk_round_rate,
+ .set_rate = cpg_z_clk_set_rate,
+};
+
+static struct clk * __init cpg_z_clk_register(const char *name,
+ const char *parent_name,
+ void __iomem *reg)
+{
+ struct clk_init_data init;
+ struct cpg_z_clk *zclk;
+ struct clk *clk;
+
+ zclk = kzalloc(sizeof(*zclk), GFP_KERNEL);
+ if (!zclk)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = &cpg_z_clk_ops;
+ init.flags = 0;
+ init.parent_names = &parent_name;
+ init.num_parents = 1;
+
+ zclk->reg = reg + CPG_FRQCRC;
+ zclk->kick_reg = reg + CPG_FRQCRB;
+ zclk->hw.init = &init;
+
+ clk = clk_register(NULL, &zclk->hw);
+ if (IS_ERR(clk))
+ kfree(zclk);
+
+ return clk;
+}
+
+/*
* SDn Clock
*/
#define CPG_SD_STP_HCK BIT(9)
@@ -420,6 +549,10 @@ struct clk * __init rcar_gen3_cpg_clk_register(struct device *dev,
mult = 1;
break;
+ case CLK_TYPE_GEN3_Z:
+ return cpg_z_clk_register(core->name, __clk_get_name(parent),
+ base);
+
default:
return ERR_PTR(-EINVAL);
}
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.h b/drivers/clk/renesas/rcar-gen3-cpg.h
index 2e4284399f53..c73d4d6fdc85 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.h
+++ b/drivers/clk/renesas/rcar-gen3-cpg.h
@@ -21,6 +21,7 @@ enum rcar_gen3_clk_types {
CLK_TYPE_GEN3_SD,
CLK_TYPE_GEN3_R,
CLK_TYPE_GEN3_PE,
+ CLK_TYPE_GEN3_Z,
};
#define DEF_GEN3_SD(_name, _id, _parent, _offset) \
--
2.11.0
^ permalink raw reply related
* [PATCH v4 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support
From: Simon Horman @ 2018-01-03 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103121840.29316-1-horms+renesas@verge.net.au>
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch adds Z2 clock divider support for R-Car Gen3 SoC.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
v4 [Simon Horman]
* Rebase
* Use __ffs as FIELD_{GET,PREP} don't not work with non-constant masks
* Use correct mask in cpg_z_clk_recalc_rate()
v3 [Simon Horman]
* Consolidate Z and Z2 clock ops
* Allow setting of Z2 clock
v1 [Simon Horman]
* Provide __cpg_z_clk_recalc_rate() helper
* Use GENMASK
v0 [Takeshi Kihara]
---
drivers/clk/renesas/rcar-gen3-cpg.c | 22 ++++++++++++++++------
drivers/clk/renesas/rcar-gen3-cpg.h | 1 +
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.c b/drivers/clk/renesas/rcar-gen3-cpg.c
index b85918fa62c6..a7d68cefda9c 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.c
+++ b/drivers/clk/renesas/rcar-gen3-cpg.c
@@ -63,7 +63,7 @@ static void cpg_simple_notifier_register(struct raw_notifier_head *notifiers,
}
/*
- * Z Clock
+ * Z Clock & Z2 Clock
*
* Traits of this clock:
* prepare - clk_prepare only ensures that parents are prepared
@@ -75,11 +75,13 @@ static void cpg_simple_notifier_register(struct raw_notifier_head *notifiers,
#define CPG_FRQCRB_KICK BIT(31)
#define CPG_FRQCRC 0x000000e0
#define CPG_FRQCRC_ZFC_MASK GENMASK(12, 8)
+#define CPG_FRQCRC_Z2FC_MASK GENMASK(4, 0)
struct cpg_z_clk {
struct clk_hw hw;
void __iomem *reg;
void __iomem *kick_reg;
+ unsigned long mask;
};
#define to_z_clk(_hw) container_of(_hw, struct cpg_z_clk, hw)
@@ -89,8 +91,10 @@ static unsigned long cpg_z_clk_recalc_rate(struct clk_hw *hw,
{
struct cpg_z_clk *zclk = to_z_clk(hw);
unsigned int mult;
+ u32 val;
- mult = 32 - FIELD_GET(CPG_FRQCRC_ZFC_MASK, clk_readl(zclk->reg));
+ val = clk_readl(zclk->reg) & zclk->mask;
+ mult = 32 - (val >> (__ffs(zclk->mask) - 1));
/* Factor of 2 is for fixed divider */
return DIV_ROUND_CLOSEST_ULL((u64)parent_rate * mult, 32 * 2);
@@ -124,8 +128,8 @@ static int cpg_z_clk_set_rate(struct clk_hw *hw, unsigned long rate,
if (clk_readl(zclk->kick_reg) & CPG_FRQCRB_KICK)
return -EBUSY;
- val = clk_readl(zclk->reg) & ~CPG_FRQCRC_ZFC_MASK;
- val |= FIELD_PREP(CPG_FRQCRC_ZFC_MASK, 32 - mult);
+ val = clk_readl(zclk->reg) & ~zclk->mask;
+ val |= ((32 - mult) << (__ffs(zclk->mask) - 1)) & zclk->mask;
clk_writel(val, zclk->reg);
/*
@@ -163,7 +167,8 @@ static const struct clk_ops cpg_z_clk_ops = {
static struct clk * __init cpg_z_clk_register(const char *name,
const char *parent_name,
- void __iomem *reg)
+ void __iomem *reg,
+ unsigned long mask)
{
struct clk_init_data init;
struct cpg_z_clk *zclk;
@@ -182,6 +187,7 @@ static struct clk * __init cpg_z_clk_register(const char *name,
zclk->reg = reg + CPG_FRQCRC;
zclk->kick_reg = reg + CPG_FRQCRB;
zclk->hw.init = &init;
+ zclk->mask = mask;
clk = clk_register(NULL, &zclk->hw);
if (IS_ERR(clk))
@@ -551,7 +557,11 @@ struct clk * __init rcar_gen3_cpg_clk_register(struct device *dev,
case CLK_TYPE_GEN3_Z:
return cpg_z_clk_register(core->name, __clk_get_name(parent),
- base);
+ base, CPG_FRQCRC_ZFC_MASK);
+
+ case CLK_TYPE_GEN3_Z2:
+ return cpg_z_clk_register(core->name, __clk_get_name(parent),
+ base, CPG_FRQCRC_Z2FC_MASK);
default:
return ERR_PTR(-EINVAL);
diff --git a/drivers/clk/renesas/rcar-gen3-cpg.h b/drivers/clk/renesas/rcar-gen3-cpg.h
index c73d4d6fdc85..ea4f8fc3c4c9 100644
--- a/drivers/clk/renesas/rcar-gen3-cpg.h
+++ b/drivers/clk/renesas/rcar-gen3-cpg.h
@@ -22,6 +22,7 @@ enum rcar_gen3_clk_types {
CLK_TYPE_GEN3_R,
CLK_TYPE_GEN3_PE,
CLK_TYPE_GEN3_Z,
+ CLK_TYPE_GEN3_Z2,
};
#define DEF_GEN3_SD(_name, _id, _parent, _offset) \
--
2.11.0
^ permalink raw reply related
* [PATCH v4 3/6] clk: renesas: r8a7795: Add Z clock
From: Simon Horman @ 2018-01-03 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103121840.29316-1-horms+renesas@verge.net.au>
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch adds Z clock for R8A7795 SoC.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index b1d9f48eae9e..995a4c4fb01e 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -74,6 +74,7 @@ static struct cpg_core_clk r8a7795_core_clks[] __initdata = {
DEF_FIXED(".sdsrc", CLK_SDSRC, CLK_PLL1_DIV2, 2, 1),
/* Core Clock Outputs */
+ DEF_BASE("z", R8A7795_CLK_Z, CLK_TYPE_GEN3_Z, CLK_PLL0),
DEF_FIXED("ztr", R8A7795_CLK_ZTR, CLK_PLL1_DIV2, 6, 1),
DEF_FIXED("ztrd2", R8A7795_CLK_ZTRD2, CLK_PLL1_DIV2, 12, 1),
DEF_FIXED("zt", R8A7795_CLK_ZT, CLK_PLL1_DIV2, 4, 1),
--
2.11.0
^ permalink raw reply related
* [PATCH v4 4/6] clk: renesas: r8a7795: Add Z2 clock
From: Simon Horman @ 2018-01-03 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103121840.29316-1-horms+renesas@verge.net.au>
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch adds Z2 clock for r8a7795 SoC.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 995a4c4fb01e..775b0ceaa337 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -75,6 +75,7 @@ static struct cpg_core_clk r8a7795_core_clks[] __initdata = {
/* Core Clock Outputs */
DEF_BASE("z", R8A7795_CLK_Z, CLK_TYPE_GEN3_Z, CLK_PLL0),
+ DEF_BASE("z2", R8A7795_CLK_Z2, CLK_TYPE_GEN3_Z2, CLK_PLL2),
DEF_FIXED("ztr", R8A7795_CLK_ZTR, CLK_PLL1_DIV2, 6, 1),
DEF_FIXED("ztrd2", R8A7795_CLK_ZTRD2, CLK_PLL1_DIV2, 12, 1),
DEF_FIXED("zt", R8A7795_CLK_ZT, CLK_PLL1_DIV2, 4, 1),
--
2.11.0
^ permalink raw reply related
* [PATCH v4 5/6] clk: renesas: r8a7796: Add Z clock
From: Simon Horman @ 2018-01-03 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103121840.29316-1-horms+renesas@verge.net.au>
From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
This patch adds Z clock for R8A7796 SoC.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/clk/renesas/r8a7796-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c b/drivers/clk/renesas/r8a7796-cpg-mssr.c
index b3767472088a..82b444ac66c6 100644
--- a/drivers/clk/renesas/r8a7796-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -74,6 +74,7 @@ static const struct cpg_core_clk r8a7796_core_clks[] __initconst = {
DEF_FIXED(".sdsrc", CLK_SDSRC, CLK_PLL1_DIV2, 2, 1),
/* Core Clock Outputs */
+ DEF_BASE("z", R8A7796_CLK_Z, CLK_TYPE_GEN3_Z, CLK_PLL0),
DEF_FIXED("ztr", R8A7796_CLK_ZTR, CLK_PLL1_DIV2, 6, 1),
DEF_FIXED("ztrd2", R8A7796_CLK_ZTRD2, CLK_PLL1_DIV2, 12, 1),
DEF_FIXED("zt", R8A7796_CLK_ZT, CLK_PLL1_DIV2, 4, 1),
--
2.11.0
^ 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