* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Lorenzo Pieralisi @ 2016-11-10 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3136fae-144c-5949-3933-671b783671c8@arm.com>
On Wed, Nov 09, 2016 at 02:40:08PM +0000, Robin Murphy wrote:
[...]
> > +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops)
> > +{
> > + struct iommu_fwentry *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> > +
> > + if (WARN_ON(!iommu))
> > + return;
> > +
> > + if (is_of_node(fwnode))
>
> Nit: this check is actually redundant, since to_of_node() already does
> the right thing and of_node_get() is NULL-safe - iommu_fwspec_init()
> already works that way. On the other hand, though, it is perhaps more
> intuitive to see it explicitly, and since to_of_node() is inline it
> ought to result in the same object code (I've not checked, though).
I can easily fold this change in the final code and I think we
should keep this consistent so I am happy to change my code and
make the is_of_node() check implicit.
> Either way:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Thank you !
Lorenzo
> > + of_node_get(to_of_node(fwnode));
> > +
> > + INIT_LIST_HEAD(&iommu->list);
> > + iommu->fwnode = fwnode;
> > + iommu->ops = ops;
> > + spin_lock(&iommu_fwentry_lock);
> > + list_add_tail(&iommu->list, &iommu_fwentry_list);
> > + spin_unlock(&iommu_fwentry_lock);
> > +}
> > +
> > +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> > +{
> > + struct iommu_fwentry *node;
> > + const struct iommu_ops *ops = NULL;
> > +
> > + spin_lock(&iommu_fwentry_lock);
> > + list_for_each_entry(node, &iommu_fwentry_list, list)
> > + if (node->fwnode == fwnode) {
> > + ops = node->ops;
> > + break;
> > + }
> > + spin_unlock(&iommu_fwentry_lock);
> > + return ops;
> > +}
> > +
> > int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> > const struct iommu_ops *ops)
> > {
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > index 5b82862..0f57ddc 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -96,45 +96,6 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> > }
> > EXPORT_SYMBOL_GPL(of_get_dma_window);
> >
> > -struct of_iommu_node {
> > - struct list_head list;
> > - struct device_node *np;
> > - const struct iommu_ops *ops;
> > -};
> > -static LIST_HEAD(of_iommu_list);
> > -static DEFINE_SPINLOCK(of_iommu_lock);
> > -
> > -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops)
> > -{
> > - struct of_iommu_node *iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
> > -
> > - if (WARN_ON(!iommu))
> > - return;
> > -
> > - of_node_get(np);
> > - INIT_LIST_HEAD(&iommu->list);
> > - iommu->np = np;
> > - iommu->ops = ops;
> > - spin_lock(&of_iommu_lock);
> > - list_add_tail(&iommu->list, &of_iommu_list);
> > - spin_unlock(&of_iommu_lock);
> > -}
> > -
> > -const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> > -{
> > - struct of_iommu_node *node;
> > - const struct iommu_ops *ops = NULL;
> > -
> > - spin_lock(&of_iommu_lock);
> > - list_for_each_entry(node, &of_iommu_list, list)
> > - if (node->np == np) {
> > - ops = node->ops;
> > - break;
> > - }
> > - spin_unlock(&of_iommu_lock);
> > - return ops;
> > -}
> > -
> > static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> > {
> > struct of_phandle_args *iommu_spec = data;
> > diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> > index 436dc21..15d5478 100644
> > --- a/include/linux/iommu.h
> > +++ b/include/linux/iommu.h
> > @@ -351,6 +351,9 @@ int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
> > const struct iommu_ops *ops);
> > void iommu_fwspec_free(struct device *dev);
> > int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> > +void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops);
> > +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode);
> >
> > #else /* CONFIG_IOMMU_API */
> >
> > @@ -580,6 +583,17 @@ static inline int iommu_fwspec_add_ids(struct device *dev, u32 *ids,
> > return -ENODEV;
> > }
> >
> > +static inline void fwnode_iommu_set_ops(struct fwnode_handle *fwnode,
> > + const struct iommu_ops *ops)
> > +{
> > +}
> > +
> > +static inline
> > +const struct iommu_ops *fwnode_iommu_get_ops(struct fwnode_handle *fwnode)
> > +{
> > + return NULL;
> > +}
> > +
> > #endif /* CONFIG_IOMMU_API */
> >
> > #endif /* __LINUX_IOMMU_H */
> > diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> > index e80b9c7..7681007 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -31,8 +31,16 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
> >
> > #endif /* CONFIG_OF_IOMMU */
> >
> > -void of_iommu_set_ops(struct device_node *np, const struct iommu_ops *ops);
> > -const struct iommu_ops *of_iommu_get_ops(struct device_node *np);
> > +static inline void of_iommu_set_ops(struct device_node *np,
> > + const struct iommu_ops *ops)
> > +{
> > + fwnode_iommu_set_ops(&np->fwnode, ops);
> > +}
> > +
> > +static inline const struct iommu_ops *of_iommu_get_ops(struct device_node *np)
> > +{
> > + return fwnode_iommu_get_ops(&np->fwnode);
> > +}
> >
> > extern struct of_device_id __iommu_of_table;
> >
> >
>
^ permalink raw reply
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Charles Keepax @ 2016-11-10 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f53d533d-163f-31f3-4efb-0e39d201589d@samsung.com>
On Tue, Nov 08, 2016 at 04:53:40PM +0100, Sylwester Nawrocki wrote:
> On 11/08/2016 03:55 PM, Charles Keepax wrote:
> >>> diff --git a/arch/arm/mach-s3c64xx/pl080.c b/arch/arm/mach-s3c64xx/pl080.c
> >>> > > index 89c5a62..8c88680 100644
> >>> > > --- a/arch/arm/mach-s3c64xx/pl080.c
> >>> > > +++ b/arch/arm/mach-s3c64xx/pl080.c
> >> > <snip>
> >>> > > @@ -134,6 +153,8 @@ struct pl08x_platform_data s3c64xx_dma0_plat_data = {
> >>> > > .put_xfer_signal = pl08x_put_xfer_signal,
> >>> > > .slave_channels = s3c64xx_dma0_info,
> >>> > > .num_slave_channels = ARRAY_SIZE(s3c64xx_dma0_info),
> >>> > > + .slave_map = s3c64xx_dma0_slave_map,
> >>> > > + .slavecnt = ARRAY_SIZE(s3c64xx_dma0_slave_map),
> >>> > > };
> >> >
> >> > Here we add a .slavecnt but the pl08x_platform_data structure doesn't
> >> > contain that field. I can't see it on the branch you linked in
> >> > the cover letter either, is it added by a patch on another branch
> >> > I am missing?
> >> >
> > Ah I think I see it should be .slave_map_len here.
>
> Yeah, sorry, I fixed it after getting report from the kbuild test
> but have forgotten to push changes to the git tree.
>
> I pushed now to branch for-v4.10/dma/pl080-s3c64xx-v2 with this
> issue fixed and added initialization of the filer function.
Apologies for the delay got somewhat swamped with internal stuff
yesterday. Yeah using that branch it looks good to me, the SPI and
I2S are both working fine. I can download code to the wm0010
which should be a good work out of the SPI and play audio
correctly so the I2S should be fine. So for the series:
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
I do still need to revert these two patches to get the I2S to
work properly:
commit d70e861a3154833467023123e218e9b1ba558809
ASoC: samsung: Remove SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag
commit acde50a7bf1fd6ae0baa4402f0a02c4b1bd4c990
ASoC: dmaengine_pcm: Make FLAG_NO_RESIDUE internal
But that is clearly an unrelated issue, which I haven't found
time to look into yet as we don't use this platform that often
these days.
Thanks,
Charles
^ permalink raw reply
* [PATCH 1/2] iommu/mediatek: Convert M4Uv2 to iommu_fwspec
From: Joerg Roedel @ 2016-11-10 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0205bf6404b16bdebe8039bfc65570a2a6f9f960.1476704508.git.robin.murphy@arm.com>
On Mon, Oct 17, 2016 at 12:49:20PM +0100, Robin Murphy wrote:
> Our per-device data consists of the M4U instance and firmware-provided
> list of LARB IDs, which is a perfect fit for the generic iommu_fwspec
> machinery. Use that directly as a simpler alternative to the custom
> archdata code.
>
> CC: Yong Wu <yong.wu@mediatek.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>
> These are fairly mechanical cleanups, so I'm pretty confident, but it
> still bears mentioning that they're only compile-tested as I don't have
> the relevant hardware.
>
> Robin.
>
> drivers/iommu/mtk_iommu.c | 75 ++++++++++++-----------------------------------
> 1 file changed, 18 insertions(+), 57 deletions(-)
Applied both, thanks Robin.
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Ulf Hansson @ 2016-11-10 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWox5ksj1xhJ6_n0wNA9j6veX0AzAE0V9Gs26Kvw5C_sw@mail.gmail.com>
On 10 November 2016 at 10:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Ulf,
>
> On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>>> >> > And Samsung.
>>> >> > Shall I create the immutable branch now?
>>> >>
>>> >> Arnd: are you happy with the new patches and changes?
>>> >
>>> > I still had some comments for patch 7, but that shouldn't stop
>>> > you from creating a branch for the first three so everyone can
>>> > build on top of that.
>>>
>>> Thanks!
>>>
>>> What about patch [4/7]?
>>> Haven't you received it? Your address was in the To-line for all 7 patches.
>>
>> Ok, I see it now, looks good. That should be included as well then.
>
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
>
> In the mean time, Ulf has applied the first two patches to mmc/next, on top
> of lots of MMC work :-(
No worries! :-)
>
> Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
> but also for Samsung and Renesas, would it still be possible to replace these
> two commits
>
> 8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
> 6fa350172b098f0f base: soc: Check for NULL SoC device attributes
>
> by a merge of soc-device-match-tag1?
Yes, I will take care of it during the day.
Kind regards
Uffe
^ permalink raw reply
* [PATCH v7 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-11-10 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0j09fsp4Y66v2UANOGnW4FNO7PWxpZY=Pgw=bUccEL_eA@mail.gmail.com>
Hi Rafael,
On Thu, Nov 10, 2016 at 12:36:12AM +0100, Rafael J. Wysocki wrote:
> Hi Lorenzo,
>
> On Wed, Nov 9, 2016 at 3:19 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > This patch series is v7 of a previous posting:
> >
> > https://lkml.org/lkml/2016/10/18/506
>
> I don't see anything objectionable in this series.
Thank you very much !
> Please let me know which patches in particular to look at in detail.
Apart from patch 1, patch 7 (and patch 16 that adds on top of it)
requires an ack from an ACPI core perspective. acpi_dma_configure()
should not affect x86/ia64 systems at all so those patches should
not really be controversial (patch 16 adds an IORT hook into
acpi_dma_configure() that is a nop by design on anything other than
ARM64), please let me know if they are ok.
Thank you again for your time,
Lorenzo
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWox5ksj1xhJ6_n0wNA9j6veX0AzAE0V9Gs26Kvw5C_sw@mail.gmail.com>
On Thu, Nov 10, 2016 at 10:22 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
Tested by kbuild test robot:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
soc-device-match
da65a1589dacc7ec44ea0557a14d70a39d991f32 base: soc: Provide a
dummy implementation of soc_device_match()
elapsed time: 101m
configs tested: 85
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 3/3] ARM: gr8: evb: Add i2s codec
From: Maxime Ripard @ 2016-11-10 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v6557B5dooERbKc709Hbrzb3vP8eoSj3nh6rKek7UwrgEQ@mail.gmail.com>
1;4600;0c
On Tue, Nov 08, 2016 at 03:57:48PM +0800, Chen-Yu Tsai wrote:
> On Tue, Nov 8, 2016 at 3:44 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Mon, Nov 07, 2016 at 10:11:45PM +0800, Chen-Yu Tsai wrote:
> >> On Mon, Nov 7, 2016 at 9:08 PM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > The GR8-EVB comes with a wm8978 codec connected to the i2s bus.
> >> >
> >> > Add a card in order to have it working
> >> >
> >> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >> > ---
> >> > arch/arm/boot/dts/ntc-gr8-evb.dts | 14 ++++++++++++++
> >> > 1 file changed, 14 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/arch/arm/boot/dts/ntc-gr8-evb.dts b/arch/arm/boot/dts/ntc-gr8-evb.dts
> >> > index 12b4317a4383..5291e425caf9 100644
> >> > --- a/arch/arm/boot/dts/ntc-gr8-evb.dts
> >> > +++ b/arch/arm/boot/dts/ntc-gr8-evb.dts
> >> > @@ -76,6 +76,20 @@
> >> > default-brightness-level = <8>;
> >> > };
> >> >
> >> > + i2s {
> >>
> >> "sound" might be a better node name? The I2S controllers are also
> >> named "i2s".
> >
> > I know, but we also had the codec and SPDIF on this board, so sound
> > was too generic to be meaningful I guess. I don't really care about
> > the name though, if you have any suggestion...
>
> Well people seem to use "sound" for the sound card nodes...
>
> What about "sound-analog" for this one, and "sound-spdif" for the
> SPDIF simple card? Or "analog-sound" and "spdif-sound" if that looks
> better.
I fixed it and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/e93f3889/attachment.sig>
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-10 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110111506.02842cbd@free-electrons.com>
Hi Thomas,
On jeu., nov. 10 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
[...]
>> > A good example of why I'm worried is the sa-sram case:
>> >
>> > + crypto_sram0: sa-sram0 at 0 {
>> > compatible = "mmio-sram";
>> > reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>> >
>> > + crypto_sram1: sa-sram1 at 0 {
>> > compatible = "mmio-sram";
>> > reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
>> >
>> > The node names should be just "sram" without a number. Indeed for UARTs
>> > for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
>> > uart1 at ABC. But then, if you do that, with your scheme, you end up with
>> > both nodes named sa-sram at 0.
>> >
>> > Which clearly shows that the way you set this unit-address is not
>> > correct: those two devices are mapped at completely different
>> > locations, but you end up with an identical unit address.
>> >
>> > I have no idea what is the rule for setting the unit address in this
>> > case, but I'm pretty sure the rule you've chosen is not good.
>>
>> I don't know if there is an existing rules for this case. But I see your
>> concern. What I propose then is to expose the memory windows ID by
>> adding the target and the attributes like this:
>>
>> crypto_sram0: sa-sram at 09_09_0 {
>> compatible = "mmio-sram";
>> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>>
>>
>> crypto_sram1: sa-sram at 09_05_0 {
>> compatible = "mmio-sram";
>> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
>
> I have no idea if 09_05_0 is considered a valid unit address. Indeed
> the _ character in an address looks a bit weird.
>
> I guess we need guidance from the DT binding maintainers on this, since
> it's really a matter of interpreting what "unit address" means in
> relation to the value of the "reg" property.
So I looked for in the reference: Power_ePAPR_APPROVED_v1.0, and in
paragraph "2.2.1.1 Node Name Requirements" we have:
"The unit-address component of the name is specific to the bus type on
which the node sits. It consists of one or more ASCII characters from
the set of characters in Table 2-1. The fundamental requirement is that
at any level of the device tree the unit-address be unique in order to
differentiate nodes with the same name at the same level in the
tree. The binding for a particular bus may specify additional, more
specific requirements for the format of a unit-address."
In Table 2-1 we have the following characters:
0-9
a-z
A-z
,
.
_
+
-
So the underscore is valid. And by adding information about the memory
windows we match the fundamental requirement :"at any level of the
device tree the unit-address be unique".
Gregory
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-10 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110012249.ed56ik6kdffoikym@rob-hp-laptop>
On 10/11/16 01:22, Rob Herring wrote:
> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>> This patch adds specific compatible to support legacy SCPI protocol.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index d1882c4540d0..ebd03fc93135 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>>
>> Required properties:
>>
>> -- compatible : should be "arm,scpi"
>> +- compatible : should be
>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or above
>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>
> I'd prefer that we explicitly enumerate the old versions. Are there
> many?
>
I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.
I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Ard Biesheuvel @ 2016-11-10 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109224955.GO14322@bhelgaas-glaptop.roam.corp.google.com>
On 10 November 2016 at 06:49, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Nov 09, 2016 at 08:29:23PM +0000, Ard Biesheuvel wrote:
>> Hi Bjorn,
>>
>> On 9 November 2016 at 20:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Wed, Nov 09, 2016 at 02:25:56PM -0500, Christopher Covington wrote:
>> >> Hi Bjorn,
>> >>
>> [...]
>> >>
>> >> We're working to add the PNP0C02 resource to future firmware, but it's
>> >> not in the current firmware. Are dmesg and /proc/iomem from the
>> >> current firmware interesting or should we wait for the update to file?
>> >
>> > Note that the ECAM space is not the only thing that should be
>> > described via these PNP0C02 devices. *All* non-enumerable resources
>> > should be described by the _CRS method of some ACPI device. Here's a
>> > sample from my laptop:
>> >
>> > PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
>> > system 00:01: [io 0x1800-0x189f] could not be reserved
>> > system 00:01: [io 0x0800-0x087f] has been reserved
>> > system 00:01: [io 0x0880-0x08ff] has been reserved
>> > system 00:01: [io 0x0900-0x097f] has been reserved
>> > system 00:01: [io 0x0980-0x09ff] has been reserved
>> > system 00:01: [io 0x0a00-0x0a7f] has been reserved
>> > system 00:01: [io 0x0a80-0x0aff] has been reserved
>> > system 00:01: [io 0x0b00-0x0b7f] has been reserved
>> > system 00:01: [io 0x0b80-0x0bff] has been reserved
>> > system 00:01: [io 0x15e0-0x15ef] has been reserved
>> > system 00:01: [io 0x1600-0x167f] has been reserved
>> > system 00:01: [io 0x1640-0x165f] has been reserved
>> > system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
>> > system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
>> > system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
>> > system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
>> > system 00:01: [mem 0xfeb00000-0xfebfffff] has been reserved
>> > system 00:01: [mem 0xfed20000-0xfed3ffff] has been reserved
>> > system 00:01: [mem 0xfed90000-0xfed93fff] has been reserved
>> > system 00:01: [mem 0xf7fe0000-0xf7ffffff] has been reserved
>> > system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
>> >
>> > Do you have firmware in the field that may not get updated? If so,
>> > I'd like to see the whole solution for that firmware, including the
>> > MCFG quirk (which tells the PCI core where the ECAM region is) and
>> > whatever PNP0C02 quirk you figure out to actually reserve the region.
>> >
>> > I proposed a PNP0C02 quirk to Duc along these lines of the below. I
>> > don't actually know if it's feasible, but it didn't look as bad as I
>> > expected, so I'd kind of like somebody to try it out. I think you
>> > would have to call this via a DMI hook (do you have DMI on arm64?),
>> > maybe from pnp_init() or similar.
>>
>> We do have SMBIOS/DMI on arm64, but we have been successful so far not
>> to rely on it for quirks, and we'd very much like to keep it that way.
>>
>> Since this ACPI _CRS method has nothing to do with SMBIOS/DMI, surely
>> there is a better way to wire up the reservation code to the
>> information exposed by ACPI?
>
> I'm open to other ways, feel free to propose one :)
>
> If you do a quirk, you need some way to identify the machine/firmware
> combination, because you don't want to apply the quirk on every
> machine. You're trying to work around a firmware issue, so you
> probably want something tied to the firmware version. On x86, that's
> typically done with DMI.
>
I think I misunderstood the purpose of the example: that should only
be necessary if the _CRS methods are missing from the firmware, right?
If we update the firmware to cover all non-enumerable resources by
such a method, we shouldn't need any such quirks at all IIUC
^ permalink raw reply
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3693445.TSdZGaiT9S@wuerfel>
Hi Arnd,
Thanks for your comments!
On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> v2:
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>
> I think I'd rather have seen the family names left in there, but it's
> not important, so up to you.
They're not useful for matching, as family names may change anytime, and don't
always say much about the hardware capabilities.
E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
SuperH.
At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>
> I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> binding for these, among other things.
I understand you've received them in the mean time?
> It does seem wrong to have a device node for a specific register though.
> Shouldn't the node be for the block of registers that these are inside
> of?
On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
we further don't touch at all.
On R-Car Gen2, it's not documented, but does exist.
BTW, see why I'd prefer not to have it in DT at all, and go for KISS in code
we can change at any time? To avoid mistakes we have to keep on supporting
forever.
>> - Don't register the SoC bus if the chip ID register is missing,
>
> Why? My objection was to hardcoding the register, not to registering
> the device? I think I'd rather see the device registered with an
> empty revision string.
If there's no chip ID register, there's no reason to use soc_device_match(),
as we can always look at a compatible value. All SoCs listed in this driver
have a chip ID register.
if you want me to register the soc_bus for those SoCs regardless, I want to
re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
registers ;-)
>> +#define CCCR 0xe600101c /* Common Chip Code Register */
>> +#define PRR 0xff000044 /* Product Register */
>> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
>> +
>> +static const struct of_device_id renesas_socs[] __initconst = {
>> +#ifdef CONFIG_ARCH_R8A73A4
>> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
>> +#endif
>> +#ifdef CONFIG_ARCH_R8A7740
>> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
>> +#endif
>
> My preference here would be to list the register address only for
> SoCs that are known to need them, while also having .dtb files that
> don't have the nodes.
Even if drivers don't have to handle differences, there's been a long
outstanding request to print SoC revision information during bootup
(E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
>> +static int __init renesas_soc_init(void)
>> +{
>> + struct soc_device_attribute *soc_dev_attr;
>> + const struct of_device_id *match;
>> + void __iomem *chipid = NULL;
>> + struct soc_device *soc_dev;
>> + struct device_node *np;
>> + unsigned int product;
>> +
>> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + of_node_put(np);
>> +
>> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> + if (!np)
>> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> + if (np) {
>> + chipid = of_iomap(np, 0);
>> + of_node_put(np);
>> + } else if (match->data) {
>> + chipid = ioremap((uintptr_t)match->data, 4);
>> + }
>> + if (!chipid)
>>
>
> Here, I'd turn the order around and look for the DT nodes of the
> devices first. Only if they are not found, look at the compatible
> string of the root node. No need to search for a node though,
> you know which one it is when you look for a compatible =
> "renesas,r8a73a4".
"renesas,r8a73a4" is the root node, not the device, so it does not have the
"reg" property for reading the chip ID?
There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
Hence I always need to look at the root nodes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Thomas Petazzoni @ 2016-11-10 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wpgbekwg.fsf@free-electrons.com>
Hello,
On Thu, 10 Nov 2016 10:36:47 +0100, Gregory CLEMENT wrote:
> >> - bootrom {
> >> + bootrom at 0 {
> >> compatible = "marvell,bootrom";
> >> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
> >
> > I am still not sure whether this "0" unit address is correct compared
> > to the reg property being passed.
>
> I chose to use the adress register inside the window memory.
Which I think is bogus, as my example below highlighted.
> > A good example of why I'm worried is the sa-sram case:
> >
> > + crypto_sram0: sa-sram0 at 0 {
> > compatible = "mmio-sram";
> > reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
> >
> > + crypto_sram1: sa-sram1 at 0 {
> > compatible = "mmio-sram";
> > reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
> >
> > The node names should be just "sram" without a number. Indeed for UARTs
> > for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
> > uart1 at ABC. But then, if you do that, with your scheme, you end up with
> > both nodes named sa-sram at 0.
> >
> > Which clearly shows that the way you set this unit-address is not
> > correct: those two devices are mapped at completely different
> > locations, but you end up with an identical unit address.
> >
> > I have no idea what is the rule for setting the unit address in this
> > case, but I'm pretty sure the rule you've chosen is not good.
>
> I don't know if there is an existing rules for this case. But I see your
> concern. What I propose then is to expose the memory windows ID by
> adding the target and the attributes like this:
>
> crypto_sram0: sa-sram at 09_09_0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>
>
> crypto_sram1: sa-sram at 09_05_0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
I have no idea if 09_05_0 is considered a valid unit address. Indeed
the _ character in an address looks a bit weird.
I guess we need guidance from the DT binding maintainers on this, since
it's really a matter of interpreting what "unit address" means in
relation to the value of the "reg" property.
Rob, Mark?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM
From: Nathan Rossi @ 2016-11-10 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+aJhH11ty3xWQ5-CLCrPA5xH-dr_nVb8JCKZEvgJcm6Ha3xaA@mail.gmail.com>
On 10 November 2016 at 19:33, Nathan Rossi <nathan@nathanrossi.com> wrote:
> On 10 November 2016 at 18:41, Michal Simek <monstr@monstr.eu> wrote:
>> + Nathan
>>
>> 2016-10-31 17:26 GMT+01:00 Kyle Roeschley <kyle.roeschley@ni.com>:
>>>
>>> On Zynq, we haven't been reserving the correct amount of DMA-incapable
>>> RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
>>> the first 512k). In older kernels, this was masked by the
>>> memblock_reserve call in arm_memblock_init(). Now, reserve the correct
>>> amount excplicitly rather than relying on swapper_pg_dir, which is an
>>> address and not a size anyway.
>>>
>>> Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
>>> kernel")
>>>
>>> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
>
> Tested-by: Nathan Rossi <nathan@nathanrossi.com>
>
> For reference this causes problems with DEBUG_RODATA (which changed to
Sorry typo -> s/causes/caused/, as in "... this [incorrect reserving
of the lower 512K] caused ...".
Regards,
Nathan
> default yes for CPU_V7 in v4.6) due to padding memory between
> .head.text and .text, allowing memory below 0x80000 to be available
> for allocation as non-reserved memory.
>
> Regards,
> Nathan
>
>>> ---
>>> Found when migrating from 4.1 to 4.6.
>>>
>>> arch/arm/mach-zynq/common.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
>>> index 6cefdb8..75885bc 100644
>>> --- a/arch/arm/mach-zynq/common.c
>>> +++ b/arch/arm/mach-zynq/common.c
>>> @@ -59,7 +59,7 @@ void __iomem *zynq_scu_base;
>>> static void __init zynq_memory_init(void)
>>> {
>>> if (!__pa(PAGE_OFFSET))
>>> - memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
>>> + memblock_reserve(__pa(PAGE_OFFSET), 0x80000);
>>> }
>>>
>>> static struct platform_device zynq_cpuidle_device = {
>>> --
>>> 2.9.3
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>>
>> --
>> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
>> w: www.monstr.eu p: +42-0-721842854
>> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
>> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
>> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-10 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110092221.0219490b@free-electrons.com>
Hi Thomas,
On jeu., nov. 10 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Thu, 10 Nov 2016 01:09:50 +0100, Gregory CLEMENT wrote:
>
>> - bootrom {
>> + bootrom at 0 {
>> compatible = "marvell,bootrom";
>> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
>
> I am still not sure whether this "0" unit address is correct compared
> to the reg property being passed.
I chose to use the adress register inside the window memory.
>
> A good example of why I'm worried is the sa-sram case:
>
> + crypto_sram0: sa-sram0 at 0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>
> + crypto_sram1: sa-sram1 at 0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
>
> The node names should be just "sram" without a number. Indeed for UARTs
> for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
> uart1 at ABC. But then, if you do that, with your scheme, you end up with
> both nodes named sa-sram at 0.
>
> Which clearly shows that the way you set this unit-address is not
> correct: those two devices are mapped at completely different
> locations, but you end up with an identical unit address.
>
> I have no idea what is the rule for setting the unit address in this
> case, but I'm pretty sure the rule you've chosen is not good.
I don't know if there is an existing rules for this case. But I see your
concern. What I propose then is to expose the memory windows ID by
adding the target and the attributes like this:
crypto_sram0: sa-sram at 09_09_0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
crypto_sram1: sa-sram at 09_05_0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM
From: Nathan Rossi @ 2016-11-10 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d+8kBYQwcUUcL1Z71Geij4EU3pjcv29=r8ndqSLW8iZDw@mail.gmail.com>
On 10 November 2016 at 18:41, Michal Simek <monstr@monstr.eu> wrote:
> + Nathan
>
> 2016-10-31 17:26 GMT+01:00 Kyle Roeschley <kyle.roeschley@ni.com>:
>>
>> On Zynq, we haven't been reserving the correct amount of DMA-incapable
>> RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
>> the first 512k). In older kernels, this was masked by the
>> memblock_reserve call in arm_memblock_init(). Now, reserve the correct
>> amount excplicitly rather than relying on swapper_pg_dir, which is an
>> address and not a size anyway.
>>
>> Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
>> kernel")
>>
>> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
Tested-by: Nathan Rossi <nathan@nathanrossi.com>
For reference this causes problems with DEBUG_RODATA (which changed to
default yes for CPU_V7 in v4.6) due to padding memory between
.head.text and .text, allowing memory below 0x80000 to be available
for allocation as non-reserved memory.
Regards,
Nathan
>> ---
>> Found when migrating from 4.1 to 4.6.
>>
>> arch/arm/mach-zynq/common.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
>> index 6cefdb8..75885bc 100644
>> --- a/arch/arm/mach-zynq/common.c
>> +++ b/arch/arm/mach-zynq/common.c
>> @@ -59,7 +59,7 @@ void __iomem *zynq_scu_base;
>> static void __init zynq_memory_init(void)
>> {
>> if (!__pa(PAGE_OFFSET))
>> - memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
>> + memblock_reserve(__pa(PAGE_OFFSET), 0x80000);
>> }
>>
>> static struct platform_device zynq_cpuidle_device = {
>> --
>> 2.9.3
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
> Maintainer of Linux kernel - Xilinx Zynq ARM architecture
> Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [v16, 0/7] Fix eSDHC host version register bug
From: Geert Uytterhoeven @ 2016-11-10 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrcAN_pqgtGaUanfB2zh97zGcL23m5VDtJ3g==NJeRrfA@mail.gmail.com>
Hi Ulf,
On Wed, Nov 9, 2016 at 7:27 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 9 November 2016 at 04:14, Yangbo Lu <yangbo.lu@nxp.com> wrote:
>> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
>> eSDHC controller. To match the SoC version and revision, 15 previous version
>> patchsets had tried many methods but all of them were rejected by reviewers.
>> Such as
>> - dts compatible method
>> - syscon method
>> - ifdef PPC method
>> - GUTS driver getting SVR method
>> Anrd suggested a soc_device_match method in v10, and this is the only available
>> method left now. This v11 patchset introduces the soc_device_match interface in
>> soc driver.
>>
>> The first four patches of Yangbo are to add the GUTS driver. This is used to
>> register a soc device which contain soc version and revision information.
>> The other three patches introduce the soc_device_match method in soc driver
>> and apply it on esdhc driver to fix this bug.
>>
>> ---
>> Changes for v15:
>> - Dropped patch 'dt: bindings: update Freescale DCFG compatible'
>> since the work had been done by below patch on ShawnGuo's linux tree.
>> 'dt-bindings: fsl: add LS1043A/LS1046A/LS2080A compatible for SCFG
>> and DCFG'
>> - Fixed error code issue in guts driver
>> Changes for v16:
>> - Dropped patch 'powerpc/fsl: move mpc85xx.h to include/linux/fsl'
>> - Added a bug-fix patch from Geert
>> ---
>>
>> Arnd Bergmann (1):
>> base: soc: introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (1):
>> base: soc: Check for NULL SoC device attributes
> Thanks, applied on my mmc tree for next!
Oops, the above two commits (plus two more enhancements) are also a dependency
for Samsung and Renesas. Hence the plan was to use an immutable branch for
that...
Ulf, would it still be possible to replace these two commits in mmc/next:
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of the immutable branch I've just created?
Cfr, the other thread "[PATCH v2 0/7] soc: renesas: Identify SoC and register
with the SoC bus".
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6723536.97ljqcB8tS@wuerfel>
Hi Ulf,
On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> >> > And Samsung.
>> >> > Shall I create the immutable branch now?
>> >>
>> >> Arnd: are you happy with the new patches and changes?
>> >
>> > I still had some comments for patch 7, but that shouldn't stop
>> > you from creating a branch for the first three so everyone can
>> > build on top of that.
>>
>> Thanks!
>>
>> What about patch [4/7]?
>> Haven't you received it? Your address was in the To-line for all 7 patches.
>
> Ok, I see it now, looks good. That should be included as well then.
Thanks, I've created the branch/tag :
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
branch soc-device-match
signed tag soc-device-match-tag1
In the mean time, Ulf has applied the first two patches to mmc/next, on top
of lots of MMC work :-(
Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
but also for Samsung and Renesas, would it still be possible to replace these
two commits
8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
6fa350172b098f0f base: soc: Check for NULL SoC device attributes
by a merge of soc-device-match-tag1?
You can find more info in the full thread at
https://www.spinics.net/lists/devicetree/msg148558.html
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: Heiko Stübner @ 2016-11-10 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9eeb3d84-f850-4b76-ce6a-67cc92d6de3b@rock-chips.com>
Am Donnerstag, 10. November 2016, 10:54:49 schrieb wlf:
> Hi Doug,
>
> ? 2016?11?10? 04:54, Doug Anderson ??:
> > Hi,
> >
> > On Mon, Nov 7, 2016 at 5:00 AM, William Wu <wulf@rock-chips.com> wrote:
> >> We found that the system crashed due to 480MHz output clock of
> >> USB2 PHY was unstable after clock had been enabled by gpu module.
> >>
> >> Theoretically, 1 millisecond is a critical value for 480MHz
> >> output clock stable time, so we try to change the delay time
> >> to 1.2 millisecond to avoid this issue.
> >>
> >> Signed-off-by: William Wu <wulf@rock-chips.com>
> >> ---
> >>
> >> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c
> >> b/drivers/phy/phy-rockchip-inno-usb2.c index ecfd7d1..8f2d2b6 100644
> >> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> >> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> >> @@ -267,7 +267,7 @@ static int rockchip_usb2phy_clk480m_enable(struct
> >> clk_hw *hw)>>
> >> return ret;
> >>
> >> /* waitting for the clk become stable */
> >>
> >> - mdelay(1);
> >> + udelay(1200);
> >
> > Several people who have seen this patch have expressed concern that a
> > 1.2 ms delay is pretty long for something that's supposed to be
> > "atomic" like a clk_enable(). Consider that someone might call
> > clk_enable() while interrupts are disabled and that a 1.2 ms interrupt
> > latency is not so great.
> >
> > It seems like this clock should be moved to be enabled in "prepare"
> > and the "enable" should be a no-op. This is a functionality change,
> > but I don't think there are any real users for this clock at the
> > moment so it should be fine.
> >
> > (of course, the 1 ms latency that existed before this patch was still
> > pretty bad, but ...)
>
> Thanks a lot for your suggestion.
> I agree with you. clk_enable() will call spin_lock_irqsave() to disable
> interrupt, and we add
> more than 1ms in clk_enable may cause big latency.
>
> And according to clk_prepare() description:
> In a simple case, clk_prepare can be used instead of clk_enable to
> ungate a clk if the
> operation may sleep. One example is a clk which is accessed over I2c.
>
> So maybe we can remove the clock to clk_prepare.
>
> Hi Heiko, Frank,
> What do you think of it?
moving to clk_prepare sounds sensible. That way you can switch from delay to
sleep functions as well.
Heiko
^ permalink raw reply
* [PATCH] regulator: gpio: properly check return value of of_get_named_gpio
From: Jisheng Zhang @ 2016-11-10 9:21 UTC (permalink / raw)
To: linux-arm-kernel
The function of_get_named_gpio() could return -ENOENT, -EPROBE_DEFER
-EINVAL and so on. Currently, for the optional property "enable-gpio",
we only check -EPROBE_DEFER, this is not enough since there may be
misconfigured "enable-gpio" in the DTB, of_get_named_gpio() will return
-EINVAL in this case, we should return immediately here. And for the
optional property "gpios", we didn't check the return value, the driver
will continue to the point where gpio_request_array() is called, it
doesn't make sense to continue if we got -EPROBE_DEFER or -EINVAL here.
This patch tries to address these two issues by properly checking the
return value of of_get_named_gpio.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
---
drivers/regulator/gpio-regulator.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c
index 83e89e5..0fce06a 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -162,8 +162,8 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np,
of_property_read_u32(np, "startup-delay-us", &config->startup_delay);
config->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0);
- if (config->enable_gpio == -EPROBE_DEFER)
- return ERR_PTR(-EPROBE_DEFER);
+ if (config->enable_gpio < 0 && config->enable_gpio != -ENOENT)
+ return ERR_PTR(config->enable_gpio);
/* Fetch GPIOs. - optional property*/
ret = of_gpio_count(np);
@@ -190,8 +190,11 @@ of_get_gpio_regulator_config(struct device *dev, struct device_node *np,
for (i = 0; i < config->nr_gpios; i++) {
gpio = of_get_named_gpio(np, "gpios", i);
- if (gpio < 0)
+ if (gpio < 0) {
+ if (gpio != -ENOENT)
+ return ERR_PTR(gpio);
break;
+ }
config->gpios[i].gpio = gpio;
if (proplen > 0) {
of_property_read_u32_index(np, "gpios-states",
--
2.10.2
^ permalink raw reply related
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-10 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5824165A.4040303@hisilicon.com>
On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote:
> On 2016/11/10 5:34, Arnd Bergmann wrote:
> > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
> >>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> >>>> + /*
> >>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
> >>> indirectIO.
> >>>> + * It will separate indirectIO range from pci host bridge to
> >>>> + * avoid the possible PIO conflict.
> >>>> + * Set the indirectIO range directly here.
> >>>> + */
> >>>> + lpcdev->io_ops.start = 0;
> >>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> >>>> + lpcdev->io_ops.devpara = lpcdev;
> >>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
> >>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
> >>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> >>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> >>>
> >>> I have to look at patch 2 in more detail again, after missing a few
> >>> review
> >>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> >>> range here, and would hope that we can just go through the same
> >>> assignment of logical port ranges that we have for PCI buses,
> >>> decoupling
> >>> the bus addresses from the linux-internal ones.
> >>
> >> The point here is that we want to avoid any conflict/overlap between
> >> the LPC I/O space and the PCI I/O space. With the assignment above
> >> we make sure that LPC never interfere with PCI I/O space.
> >
> > But we already abstract the PCI I/O space using dynamic registration.
> > There is no need to hardcode the logical address for ISA, though
> > I think we can hardcode the bus address to start at zero here.
>
> Do you means that we can pick up the maximal I/O address from all children's
> device resources??
The driver should not look at the resources of its children, just
register a range of addresses dynamically, as I suggested in an
earlier review.
Your current version has
if (arm64_extio_ops->pfout) \
arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
addr, value, sizeof(type)); \
Instead, just subtract the start of the range from the logical
port number to transform it back into a bus-local port number:
if (arm64_extio_ops->pfout) \
arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
addr - arm64_extio_ops->start, value, sizeof(type)); \
We know that the ISA/LPC bus can only have up to 65536 ports,
so you can register all of those, or possibly limit it further to
1024 or 4096 ports, whichever matches the bus implementation.
Arnd
^ permalink raw reply
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Marc Zyngier @ 2016-11-10 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478721480-24852-1-git-send-email-wei@redhat.com>
Hi Wei,
On 09/11/16 19:57, Wei Huang wrote:
> This patch moves ARMv8-related perf event definitions from perf_event.c
> to asm/perf_event.h; so KVM code can use them directly. This also help
> remove a duplicated definition of SW_INCR in perf_event.h.
>
> Signed-off-by: Wei Huang <wei@redhat.com>
> ---
> arch/arm64/include/asm/perf_event.h | 161 +++++++++++++++++++++++++++++++++++-
> arch/arm64/kernel/perf_event.c | 161 ------------------------------------
> 2 files changed, 160 insertions(+), 162 deletions(-)
>
> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
> index 2065f46..6c7b18b 100644
> --- a/arch/arm64/include/asm/perf_event.h
> +++ b/arch/arm64/include/asm/perf_event.h
> @@ -46,7 +46,166 @@
> #define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
> #define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
>
> -#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
> +/*
> + * ARMv8 PMUv3 Performance Events handling code.
> + * Common event types.
> + */
> +
> +/* Required events. */
> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
In my initial review, I asked for the "required" events to be moved to a
shared location. What's the rational for moving absolutely everything?
KVM only needs to know about ARMV8_PMUV3_PERFCTR_SW_INCR and
ARMV8_PMUV3_PERFCTR_CPU_CYCLES, so I thought that moving the above six
events (and maybe the following two) would be enough.
Also, you've now broken the build by dropping
ARMV8_PMU_EVTYPE_EVENT_SW_INCR without amending it use in the KVM PMU
code (see the kbuild report).
> +
> +/* At least one of the following is required. */
> +#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
> +#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
> +
> +/* Common architectural events. */
> +#define ARMV8_PMUV3_PERFCTR_LD_RETIRED 0x06
> +#define ARMV8_PMUV3_PERFCTR_ST_RETIRED 0x07
> +#define ARMV8_PMUV3_PERFCTR_EXC_TAKEN 0x09
> +#define ARMV8_PMUV3_PERFCTR_EXC_RETURN 0x0A
> +#define ARMV8_PMUV3_PERFCTR_CID_WRITE_RETIRED 0x0B
> +#define ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED 0x0C
> +#define ARMV8_PMUV3_PERFCTR_BR_IMMED_RETIRED 0x0D
> +#define ARMV8_PMUV3_PERFCTR_BR_RETURN_RETIRED 0x0E
> +#define ARMV8_PMUV3_PERFCTR_UNALIGNED_LDST_RETIRED 0x0F
> +#define ARMV8_PMUV3_PERFCTR_TTBR_WRITE_RETIRED 0x1C
> +#define ARMV8_PMUV3_PERFCTR_CHAIN 0x1E
> +#define ARMV8_PMUV3_PERFCTR_BR_RETIRED 0x21
> +
> +/* Common microarchitectural events. */
> +#define ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL 0x01
> +#define ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL 0x02
> +#define ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL 0x05
> +#define ARMV8_PMUV3_PERFCTR_MEM_ACCESS 0x13
> +#define ARMV8_PMUV3_PERFCTR_L1I_CACHE 0x14
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_WB 0x15
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE 0x16
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL 0x17
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_WB 0x18
> +#define ARMV8_PMUV3_PERFCTR_BUS_ACCESS 0x19
> +#define ARMV8_PMUV3_PERFCTR_MEMORY_ERROR 0x1A
> +#define ARMV8_PMUV3_PERFCTR_BUS_CYCLES 0x1D
> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_ALLOCATE 0x1F
> +#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_ALLOCATE 0x20
> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED_RETIRED 0x22
> +#define ARMV8_PMUV3_PERFCTR_STALL_FRONTEND 0x23
> +#define ARMV8_PMUV3_PERFCTR_STALL_BACKEND 0x24
> +#define ARMV8_PMUV3_PERFCTR_L1D_TLB 0x25
> +#define ARMV8_PMUV3_PERFCTR_L1I_TLB 0x26
> +#define ARMV8_PMUV3_PERFCTR_L2I_CACHE 0x27
> +#define ARMV8_PMUV3_PERFCTR_L2I_CACHE_REFILL 0x28
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_ALLOCATE 0x29
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_REFILL 0x2A
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE 0x2B
> +#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_WB 0x2C
> +#define ARMV8_PMUV3_PERFCTR_L2D_TLB_REFILL 0x2D
> +#define ARMV8_PMUV3_PERFCTR_L2I_TLB_REFILL 0x2E
> +#define ARMV8_PMUV3_PERFCTR_L2D_TLB 0x2F
> +#define ARMV8_PMUV3_PERFCTR_L2I_TLB 0x30
> +
> +/* ARMv8 recommended implementation defined event types */
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_RD 0x40
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WR 0x41
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_RD 0x42
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x43
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_INNER 0x44
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_OUTER 0x45
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_VICTIM 0x46
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_CLEAN 0x47
> +#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_INVAL 0x48
> +
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x4C
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x4D
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x4E
> +#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x4F
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_RD 0x50
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WR 0x51
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_RD 0x52
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_WR 0x53
> +
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_VICTIM 0x56
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_CLEAN 0x57
> +#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_INVAL 0x58
> +
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_RD 0x5C
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_WR 0x5D
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_RD 0x5E
> +#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_WR 0x5F
> +
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x60
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x61
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_SHARED 0x62
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NOT_SHARED 0x63
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NORMAL 0x64
> +#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_PERIPH 0x65
> +
> +#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_RD 0x66
> +#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_WR 0x67
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LD_SPEC 0x68
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_ST_SPEC 0x69
> +#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LDST_SPEC 0x6A
> +
> +#define ARMV8_IMPDEF_PERFCTR_LDREX_SPEC 0x6C
> +#define ARMV8_IMPDEF_PERFCTR_STREX_PASS_SPEC 0x6D
> +#define ARMV8_IMPDEF_PERFCTR_STREX_FAIL_SPEC 0x6E
> +#define ARMV8_IMPDEF_PERFCTR_STREX_SPEC 0x6F
> +#define ARMV8_IMPDEF_PERFCTR_LD_SPEC 0x70
> +#define ARMV8_IMPDEF_PERFCTR_ST_SPEC 0x71
> +#define ARMV8_IMPDEF_PERFCTR_LDST_SPEC 0x72
> +#define ARMV8_IMPDEF_PERFCTR_DP_SPEC 0x73
> +#define ARMV8_IMPDEF_PERFCTR_ASE_SPEC 0x74
> +#define ARMV8_IMPDEF_PERFCTR_VFP_SPEC 0x75
> +#define ARMV8_IMPDEF_PERFCTR_PC_WRITE_SPEC 0x76
> +#define ARMV8_IMPDEF_PERFCTR_CRYPTO_SPEC 0x77
> +#define ARMV8_IMPDEF_PERFCTR_BR_IMMED_SPEC 0x78
> +#define ARMV8_IMPDEF_PERFCTR_BR_RETURN_SPEC 0x79
> +#define ARMV8_IMPDEF_PERFCTR_BR_INDIRECT_SPEC 0x7A
> +
> +#define ARMV8_IMPDEF_PERFCTR_ISB_SPEC 0x7C
> +#define ARMV8_IMPDEF_PERFCTR_DSB_SPEC 0x7D
> +#define ARMV8_IMPDEF_PERFCTR_DMB_SPEC 0x7E
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_UNDEF 0x81
> +#define ARMV8_IMPDEF_PERFCTR_EXC_SVC 0x82
> +#define ARMV8_IMPDEF_PERFCTR_EXC_PABORT 0x83
> +#define ARMV8_IMPDEF_PERFCTR_EXC_DABORT 0x84
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_IRQ 0x86
> +#define ARMV8_IMPDEF_PERFCTR_EXC_FIQ 0x87
> +#define ARMV8_IMPDEF_PERFCTR_EXC_SMC 0x88
> +
> +#define ARMV8_IMPDEF_PERFCTR_EXC_HVC 0x8A
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_PABORT 0x8B
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_DABORT 0x8C
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_OTHER 0x8D
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_IRQ 0x8E
> +#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_FIQ 0x8F
> +#define ARMV8_IMPDEF_PERFCTR_RC_LD_SPEC 0x90
> +#define ARMV8_IMPDEF_PERFCTR_RC_ST_SPEC 0x91
> +
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_RD 0xA0
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WR 0xA1
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_RD 0xA2
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_WR 0xA3
> +
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_VICTIM 0xA6
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_CLEAN 0xA7
> +#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_INVAL 0xA8
> +
> +/* ARMv8 Cortex-A53 specific event types. */
> +#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> +
> +/* ARMv8 Cavium ThunderX specific event types. */
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_MISS_ST 0xE9
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_ACCESS 0xEA
> +#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_MISS 0xEB
> +#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_ACCESS 0xEC
> +#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_MISS 0xED
>
> /*
> * Event filters for PMUv3
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index a9310a6..108ba40 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -29,167 +29,6 @@
> #include <linux/perf/arm_pmu.h>
> #include <linux/platform_device.h>
>
> -/*
> - * ARMv8 PMUv3 Performance Events handling code.
> - * Common event types.
> - */
> -
> -/* Required events. */
> -#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
> -#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
> -#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
> -#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
> -
> -/* At least one of the following is required. */
> -#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
> -#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
> -
> -/* Common architectural events. */
> -#define ARMV8_PMUV3_PERFCTR_LD_RETIRED 0x06
> -#define ARMV8_PMUV3_PERFCTR_ST_RETIRED 0x07
> -#define ARMV8_PMUV3_PERFCTR_EXC_TAKEN 0x09
> -#define ARMV8_PMUV3_PERFCTR_EXC_RETURN 0x0A
> -#define ARMV8_PMUV3_PERFCTR_CID_WRITE_RETIRED 0x0B
> -#define ARMV8_PMUV3_PERFCTR_PC_WRITE_RETIRED 0x0C
> -#define ARMV8_PMUV3_PERFCTR_BR_IMMED_RETIRED 0x0D
> -#define ARMV8_PMUV3_PERFCTR_BR_RETURN_RETIRED 0x0E
> -#define ARMV8_PMUV3_PERFCTR_UNALIGNED_LDST_RETIRED 0x0F
> -#define ARMV8_PMUV3_PERFCTR_TTBR_WRITE_RETIRED 0x1C
> -#define ARMV8_PMUV3_PERFCTR_CHAIN 0x1E
> -#define ARMV8_PMUV3_PERFCTR_BR_RETIRED 0x21
> -
> -/* Common microarchitectural events. */
> -#define ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL 0x01
> -#define ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL 0x02
> -#define ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL 0x05
> -#define ARMV8_PMUV3_PERFCTR_MEM_ACCESS 0x13
> -#define ARMV8_PMUV3_PERFCTR_L1I_CACHE 0x14
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_WB 0x15
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE 0x16
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL 0x17
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_WB 0x18
> -#define ARMV8_PMUV3_PERFCTR_BUS_ACCESS 0x19
> -#define ARMV8_PMUV3_PERFCTR_MEMORY_ERROR 0x1A
> -#define ARMV8_PMUV3_PERFCTR_BUS_CYCLES 0x1D
> -#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_ALLOCATE 0x1F
> -#define ARMV8_PMUV3_PERFCTR_L2D_CACHE_ALLOCATE 0x20
> -#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED_RETIRED 0x22
> -#define ARMV8_PMUV3_PERFCTR_STALL_FRONTEND 0x23
> -#define ARMV8_PMUV3_PERFCTR_STALL_BACKEND 0x24
> -#define ARMV8_PMUV3_PERFCTR_L1D_TLB 0x25
> -#define ARMV8_PMUV3_PERFCTR_L1I_TLB 0x26
> -#define ARMV8_PMUV3_PERFCTR_L2I_CACHE 0x27
> -#define ARMV8_PMUV3_PERFCTR_L2I_CACHE_REFILL 0x28
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_ALLOCATE 0x29
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_REFILL 0x2A
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE 0x2B
> -#define ARMV8_PMUV3_PERFCTR_L3D_CACHE_WB 0x2C
> -#define ARMV8_PMUV3_PERFCTR_L2D_TLB_REFILL 0x2D
> -#define ARMV8_PMUV3_PERFCTR_L2I_TLB_REFILL 0x2E
> -#define ARMV8_PMUV3_PERFCTR_L2D_TLB 0x2F
> -#define ARMV8_PMUV3_PERFCTR_L2I_TLB 0x30
> -
> -/* ARMv8 recommended implementation defined event types */
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_RD 0x40
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WR 0x41
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_RD 0x42
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_WR 0x43
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_INNER 0x44
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_REFILL_OUTER 0x45
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_VICTIM 0x46
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_WB_CLEAN 0x47
> -#define ARMV8_IMPDEF_PERFCTR_L1D_CACHE_INVAL 0x48
> -
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_RD 0x4C
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_REFILL_WR 0x4D
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_RD 0x4E
> -#define ARMV8_IMPDEF_PERFCTR_L1D_TLB_WR 0x4F
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_RD 0x50
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WR 0x51
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_RD 0x52
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_REFILL_WR 0x53
> -
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_VICTIM 0x56
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_WB_CLEAN 0x57
> -#define ARMV8_IMPDEF_PERFCTR_L2D_CACHE_INVAL 0x58
> -
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_RD 0x5C
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_REFILL_WR 0x5D
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_RD 0x5E
> -#define ARMV8_IMPDEF_PERFCTR_L2D_TLB_WR 0x5F
> -
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_RD 0x60
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_WR 0x61
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_SHARED 0x62
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NOT_SHARED 0x63
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_NORMAL 0x64
> -#define ARMV8_IMPDEF_PERFCTR_BUS_ACCESS_PERIPH 0x65
> -
> -#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_RD 0x66
> -#define ARMV8_IMPDEF_PERFCTR_MEM_ACCESS_WR 0x67
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LD_SPEC 0x68
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_ST_SPEC 0x69
> -#define ARMV8_IMPDEF_PERFCTR_UNALIGNED_LDST_SPEC 0x6A
> -
> -#define ARMV8_IMPDEF_PERFCTR_LDREX_SPEC 0x6C
> -#define ARMV8_IMPDEF_PERFCTR_STREX_PASS_SPEC 0x6D
> -#define ARMV8_IMPDEF_PERFCTR_STREX_FAIL_SPEC 0x6E
> -#define ARMV8_IMPDEF_PERFCTR_STREX_SPEC 0x6F
> -#define ARMV8_IMPDEF_PERFCTR_LD_SPEC 0x70
> -#define ARMV8_IMPDEF_PERFCTR_ST_SPEC 0x71
> -#define ARMV8_IMPDEF_PERFCTR_LDST_SPEC 0x72
> -#define ARMV8_IMPDEF_PERFCTR_DP_SPEC 0x73
> -#define ARMV8_IMPDEF_PERFCTR_ASE_SPEC 0x74
> -#define ARMV8_IMPDEF_PERFCTR_VFP_SPEC 0x75
> -#define ARMV8_IMPDEF_PERFCTR_PC_WRITE_SPEC 0x76
> -#define ARMV8_IMPDEF_PERFCTR_CRYPTO_SPEC 0x77
> -#define ARMV8_IMPDEF_PERFCTR_BR_IMMED_SPEC 0x78
> -#define ARMV8_IMPDEF_PERFCTR_BR_RETURN_SPEC 0x79
> -#define ARMV8_IMPDEF_PERFCTR_BR_INDIRECT_SPEC 0x7A
> -
> -#define ARMV8_IMPDEF_PERFCTR_ISB_SPEC 0x7C
> -#define ARMV8_IMPDEF_PERFCTR_DSB_SPEC 0x7D
> -#define ARMV8_IMPDEF_PERFCTR_DMB_SPEC 0x7E
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_UNDEF 0x81
> -#define ARMV8_IMPDEF_PERFCTR_EXC_SVC 0x82
> -#define ARMV8_IMPDEF_PERFCTR_EXC_PABORT 0x83
> -#define ARMV8_IMPDEF_PERFCTR_EXC_DABORT 0x84
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_IRQ 0x86
> -#define ARMV8_IMPDEF_PERFCTR_EXC_FIQ 0x87
> -#define ARMV8_IMPDEF_PERFCTR_EXC_SMC 0x88
> -
> -#define ARMV8_IMPDEF_PERFCTR_EXC_HVC 0x8A
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_PABORT 0x8B
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_DABORT 0x8C
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_OTHER 0x8D
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_IRQ 0x8E
> -#define ARMV8_IMPDEF_PERFCTR_EXC_TRAP_FIQ 0x8F
> -#define ARMV8_IMPDEF_PERFCTR_RC_LD_SPEC 0x90
> -#define ARMV8_IMPDEF_PERFCTR_RC_ST_SPEC 0x91
> -
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_RD 0xA0
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WR 0xA1
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_RD 0xA2
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_REFILL_WR 0xA3
> -
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_VICTIM 0xA6
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_WB_CLEAN 0xA7
> -#define ARMV8_IMPDEF_PERFCTR_L3D_CACHE_INVAL 0xA8
> -
> -/* ARMv8 Cortex-A53 specific event types. */
> -#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> -
> -/* ARMv8 Cavium ThunderX specific event types. */
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_MISS_ST 0xE9
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_ACCESS 0xEA
> -#define ARMV8_THUNDER_PERFCTR_L1D_CACHE_PREF_MISS 0xEB
> -#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_ACCESS 0xEC
> -#define ARMV8_THUNDER_PERFCTR_L1I_CACHE_PREF_MISS 0xED
> -
> /* PMUv3 HW events mapping. */
>
> /*
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [GIT PULL] STi DT update for v4.10 round 2
From: Patrice Chotard @ 2016-11-10 9:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, Olof
PLease consider this second round of STi dts update for v4.10 :
The following changes since commit 97a0b97f9e8197429eee5f87ce14373f73dbd9d3:
ARM: dts: stih410-clocks: Add PROC_STFE as a critical clock (2016-10-20 16:20:26 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-dt-for-4.10-round2
for you to fetch changes up to 64783ea7de0bff3de77cfdff1ed76428c288faac:
ARM: dts: STiHxxx-b2120: change sound card name (2016-11-10 09:52:49 +0100)
----------------------------------------------------------------
STi dts update:
Change sound card name for B2120
Enable sound card for B2260
Remove stih415-clks.h
Identify critical clocks for STiH407
Fix typo in stih407-pinctrl.dtsi
----------------------------------------------------------------
Arnaud Pouliquen (2):
ARM: dts: STiH410-B2260: enable sound card
ARM: dts: STiHxxx-b2120: change sound card name
Geert Uytterhoeven (1):
ARM: dts: STiH407: DT fix s/interrupts-names/interrupt-names/
Patrice Chotard (1):
ARM: dts: remove stih415-clks.h
Peter Griffin (1):
ARM: dts: stih407-clocks: Identify critical clocks
arch/arm/boot/dts/stih407-clock.dtsi | 10 ++++++++++
arch/arm/boot/dts/stih407-pinctrl.dtsi | 2 +-
arch/arm/boot/dts/stih410-b2260.dts | 22 ++++++++++++++++++++++
arch/arm/boot/dts/stihxxx-b2120.dtsi | 2 +-
include/dt-bindings/clock/stih415-clks.h | 16 ----------------
5 files changed, 34 insertions(+), 18 deletions(-)
delete mode 100644 include/dt-bindings/clock/stih415-clks.h
^ permalink raw reply
* [GIT PULL] STi defconfig updates for v4.10 round 2
From: Patrice Chotard @ 2016-11-10 9:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider the second round of multi_v7_defconfig updates for v4.10 :
The following changes since commit 620c52f4db4d47e1f33c64e641392fe575d5397f:
ARM: multi_v7_defconfig: Remove stih41x phy Kconfig symbol. (2016-10-20 17:05:08 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git sti-defconfig-for-4.10-round2
for you to fetch changes up to 57dae748959d0abae2b382ccee68621a82f827c8:
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol (2016-10-21 17:05:54 +0200)
----------------------------------------------------------------
Remove STiH415/416 specific IPs
As STiH415/416 have been removed from kernel, remove IPs only
found on these socs, remove ST_THERMAL_SYSCFG.
----------------------------------------------------------------
Patrice Chotard (1):
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol
arch/arm/configs/multi_v7_defconfig | 1 -
1 file changed, 1 deletion(-)
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Hans de Goede @ 2016-11-10 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28234714-3994-6747-9cf8-1ff0b3257f7a@gmail.com>
Hi,
On 09-11-16 21:45, Jacek Anaszewski wrote:
> Hi Tony,
>
> On 11/09/2016 08:23 PM, Tony Lindgren wrote:
>> Hi,
>>
>> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
>> the sysfs brightness attr for changes.") breaks runtime PM for me.
>>
>> On my omap dm3730 based test system, idle power consumption is over 70
>> times higher now with this patch! It goes from about 6mW for the core
>> system to over 440mW during idle meaning there's some busy timer now
>> active.
>>
>> Reverting this patch fixes the issue. Any ideas?
>
> Thanks for the report. This is probably caused by sysfs_notify_dirent().
> I'm afraid that we can't keep this feature in the current shape.
> Hans, I'm dropping the patch. We probably will have to delegate this
> call to a workqueue task. Think about use cases when the LED is blinked
> with high frequency e.g. from ledtrig-disk.c.
sysfs_notify_dirent() already uses a workqueue, here is the actual
implementation of it (from fs/kernfs/file.c) :
void kernfs_notify(struct kernfs_node *kn)
{
static DECLARE_WORK(kernfs_notify_work, kernfs_notify_workfn);
unsigned long flags;
if (WARN_ON(kernfs_type(kn) != KERNFS_FILE))
return;
spin_lock_irqsave(&kernfs_notify_lock, flags);
if (!kn->attr.notify_next) {
kernfs_get(kn);
kn->attr.notify_next = kernfs_notify_list;
kernfs_notify_list = kn;
schedule_work(&kernfs_notify_work);
}
spin_unlock_irqrestore(&kernfs_notify_lock, flags);
}
So using a workqueue is not going to help. Note that I already
feared this, which is why my initial implementation only called
sysfs_notify_dirent() for user initiated changes and not for
triggers / blinking.
I think we may need to reconsider what getting the brightness
sysfs atrribute actually returns. Currently when a LED is
blinking it will return 0 resp. the actual brightness depending
on when in the blink cycle the user reads the brightness
sysfs atrribute.
So a user can do "echo 128 > brightness && cat brightness" and
get out 0, or 128, depending purely on timing.
This seems to contradict what Documentation/ABI/testing/sysfs-class-led
has to say:
What: /sys/class/leds/<led>/brightness
Date: March 2006
KernelVersion: 2.6.17
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Set the brightness of the LED. Most LEDs don't
have hardware brightness support, so will just be turned on for
non-zero brightness settings. The value is between 0 and
/sys/class/leds/<led>/max_brightness.
Writing 0 to this file clears active trigger.
Writing non-zero to this file while trigger is active changes the
top brightness trigger is going to use.
Even though it only talks about writing, the logical thing would be for
reading to be the exact opposite of writing, so we would get:
Reading from this file while a trigger is active returns the
top brightness trigger is going to use.
The current docs say not about (sw) blinking, but that should be treated just
like a trigger IMHO.
If we can get consensus on what the read behavior for the brightness attribute
should be, then I think that a better poll() behavior will automatically follow
from that.
Regards,
Hans
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: add nand controller nodes
From: Steffen Trumtrar @ 2016-11-10 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7127bcd-ec0e-cb47-592d-06f404857d50@kernel.org>
On Wed, Nov 09, 2016 at 12:48:21PM -0600, Dinh Nguyen wrote:
>
>
> On 11/09/2016 01:35 AM, Steffen Trumtrar wrote:
> > Add the denali nand controller to the socfpga dtsi.
> >
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > ---
> > arch/arm/boot/dts/socfpga.dtsi | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> > index 9f48141270b8..6b0c23ca5e88 100644
> > --- a/arch/arm/boot/dts/socfpga.dtsi
> > +++ b/arch/arm/boot/dts/socfpga.dtsi
> > @@ -700,6 +700,19 @@
> > status = "disabled";
> > };
> >
> > + nand0: nand at ff900000 {
> > + #address-cells = <0x1>;
> > + #size-cells = <0x1>;
> > + compatible = "denali,denali-nand-dt";
> > + reg = <0xff900000 0x100000>,
> > + <0xffb80000 0x10000>;
> > + reg-names = "nand_data", "denali_reg";
> > + interrupts = <0x0 0x90 0x4>;
> > + dma-mask = <0xffffffff>;
> > + clocks = <&nand_clk>;
> > + status = "disabled";
> > + };
> > +
> > ocram: sram at ffff0000 {
> > compatible = "mmio-sram";
> > reg = <0xffff0000 0x10000>;
> >
>
> Since there's only 1 NAND node, do we need to call the node "nand0"? No
> need to resend a patch, I can change it locally if we agree that the
> node should be just:
>
> nand: nand at ff900000
>
Okay with me. Go ahead.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox