* [PATCH 00/14] arm64: eBPF JIT compiler
From: Will Deacon @ 2014-07-21 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405708100-13604-1-git-send-email-zlim.lnx@gmail.com>
Hello,
On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
> This series implements eBPF JIT compiler for arm64.
> Please see [14/14] for change log.
>
> Patches [1-13/14] implement code generation functions.
> Patch [14/14] implements the actual eBPF JIT compiler.
>
> Many thanks to everyone who's reviewed the code from
> RFCv1->RFCv3, especially Alexei for BPF bits, and Will
> for ARM64 codegen bits :)
>
> BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits).
> Should I add a patch updating MAINTAINERS as Patch 15?
I don't think that's necessary at the moment, but if we start seeing an
influx of patches to arch/arm64/net, then that could make sense in the
future.
> This series requires a patch that exports a function
> from net/core (resulting from RFCv1 discussion). This patch
> has been merged into net-next @ 9f12fbe603f7
> ("net: filter: move load_pointer() into filter.h").
>
> This series applies against net-next and is tested working
> with lib/test_bpf on ARMv8 Foundation Model.
Looks like it works on my Juno board too, so:
Acked-by: Will Deacon <will.deacon@arm.com>
for the series.
It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
also means the dependency on -next isn't an issue). Perhaps you could repost
around -rc3?
Cheers,
Will
^ permalink raw reply
* [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
From: Laurent Pinchart @ 2014-07-21 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C95124.1010902@ti.com>
Hi Suman, Joerg and Tony,
On Friday 18 July 2014 11:53:56 Suman Anna wrote:
> On 07/18/2014 05:49 AM, Laurent Pinchart wrote:
> > Hello,
> >
> > The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is
> > has been ported to the DMA API, remove the unused virtual memory manager.
> >
> > The removal is split in three patches to ease upstream merge. The first
> > patch removes the omap-iovmm driver, the second patch removes setting of
> > now unused platform data fields from arch code, and the last patch cleans
> > up the platform data structure.
>
> Thanks for the revised series, it looks good. I have also tested the
> series on OMAP3, OMAP4 and OMAP5.
>
> For the changes in the entire series,
> Acked-by: Suman Anna <s-anna@ti.com>
Thank you.
> > I'd like to get at least the first patch merged in v3.17. To avoid
> > splitting the series across three kernel versions, it would be nice to
> > also merge at least the second patch for v3.17. If there's no risk of
> > conflict everything could be merged in one go through the ARM SoC tree.
> > Otherwise a stable branch with patch 1/3 will be needed to base the arch
> > change on.
> >
> > Joerg, Tony, how would you like to proceed ?
The v3.17 merge window is getting close, it's probably too late to merge patch
2/3. Joerg, could you please take 1/3 in your tree for v3.17 ? 2/3 and 3/3
would then get in v3.18. Tony, how would you like to proceed for those ?
> > Changes compared to v1:
> >
> > - Fix OMAP_IOMMU_DEBUG dependency on OMAP_IOMMU
> > - Remove omap_iommu da_start and da_end fields
> > - Added patches 2/3 and 3/3
> >
> > Laurent Pinchart (3):
> > iommu/omap: Remove virtual memory manager
> > ARM: omap: Don't set iommu pdata da_start and da_end fields
> > iommu/omap: Remove platform data da_start and da_end fields
> >
> > arch/arm/mach-omap2/omap-iommu.c | 2 -
> > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4 -
> > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 4 -
> > drivers/iommu/Kconfig | 10 +-
> > drivers/iommu/Makefile | 1 -
> > drivers/iommu/omap-iommu-debug.c | 114 -----
> > drivers/iommu/omap-iommu.c | 13 -
> > drivers/iommu/omap-iommu.h | 8 +-
> > drivers/iommu/omap-iovmm.c | 791 ------------------------
> > include/linux/omap-iommu.h | 37 +-
> > include/linux/platform_data/iommu-omap.h | 6 -
> > 11 files changed, 8 insertions(+), 982 deletions(-)
> > delete mode 100644 drivers/iommu/omap-iovmm.c
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 00/14] AT91: PIT: Cleanups and move to drivers/clocksource
From: Daniel Lezcano @ 2014-07-21 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404207208-14513-1-git-send-email-maxime.ripard@free-electrons.com>
On 07/01/2014 11:33 AM, Maxime Ripard wrote:
> Hi everyone,
>
> This series cleans up the PIT driver in order for it to not depend on
> anything in mach-at91 anymore, and in the end move it out of
> mach-at91.
>
> Along the way, these patches also do a bit of cleanup.
>
> This has been tested on a G45-EK without DT and an Xplained with DT.
For the entire serie:
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v10 0/8] ARM: berlin: add AHCI support
From: Antoine Ténart @ 2014-07-21 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CA48F7.5020405@redhat.com>
Hi Hans,
On Sat, Jul 19, 2014 at 12:31:19PM +0200, Hans de Goede wrote:
> On 07/19/2014 12:18 PM, Hans de Goede wrote:
>
> >The problem is that:
> >
> >1) We need to enable resources before we can do ahci_save_initial_config()
> >2) We must do ahci_save_initial_config() before we can do ata_host_alloc_pinfo()
> >3) Therefor we don't have port_info at enable_resources time, which is when we
> >want to enable the phys (and we cannot just enable the phys elsewhere as
> >enable_resouces gets used on e.g. resume too).
> >
> >So I think it is best to just make the phy pointers an array inside
> >ahci_host_priv, with a comment that the array indexes must match port
> >indexes.
>
> So looking at "[PATCH v10 4/8] ata: libahci: allow to use multiple PHYs"
> I see that currently the phy array indexes do not necessarily match the
> port indexes. Since you already allocate the phys array at nports size,
> I suggest simply making the array sparse, leaving in NULL entries for
> unused ports, and adjusting enable / disable_phys to check for NULL
> pointers. This way we still have a 1:1 way to map ports <-> phys if
> we want to do something with phys on a per port basis in the future.
>
> Note please also add a check that reg < nports so that we don't use
> the array out of bounds if there is an error in the dts.
Ok. I'll rework patch 4 along with the other modifications requested,
and I'll send a new version early this week.
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v10 2/8] Documentation: bindings: add the Berlin SATA PHY
From: Antoine Ténart @ 2014-07-21 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C95900.9050200@cogentembedded.com>
Hi,
On Fri, Jul 18, 2014 at 09:27:28PM +0400, Sergei Shtylyov wrote:
> On 07/18/2014 04:30 PM, Antoine T?nart wrote:
>
> >diff --git a/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt
> >new file mode 100644
> >index 000000000000..88f8c23384c0
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt
> >@@ -0,0 +1,34 @@
> >+Berlin SATA PHY
> >+---------------
> >+
> >+Required properties:
> >+- compatible: should be "marvell,berlin2q-sata-phy"
> >+- address-cells: should be 1
> >+- size-cells: should be 0
> >+- phy-cells: from the generic PHY bindings, must be 1
>
> It's "#address-cells", "#size-cells", and "#phy-cells".
Sure.
>
> >+- reg: address and length of the register
> >+- clocks: reference to the clock entry
> >+
> >+Sub-nodes:
> >+Each PHY should be represented as a sub-node.
>
> Then "#phy-cells" should also belong to the sub-nodes.
No, because the PHY provider is still the parent.
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v10 3/8] ata: libahci_platform: move port_map parameters into the AHCI structure
From: Antoine Ténart @ 2014-07-21 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718134730.GA13012@htj.dyndns.org>
Hi,
On Fri, Jul 18, 2014 at 09:47:30AM -0400, Tejun Heo wrote:
> On Fri, Jul 18, 2014 at 02:30:02PM +0200, Antoine T?nart wrote:
> > @@ -321,6 +321,8 @@ struct ahci_host_priv {
> > u32 cap; /* cap to use */
> > u32 cap2; /* cap2 to use */
> > u32 port_map; /* port map to use */
> > + u32 force_port_map; /* force port map */
> > + u32 mask_port_map; /* mask out particular bits */
>
> So, ->flags and ->force/mask_port_map are the only input ones, right?
> Can we collect them to one spot and label them as such?
Yes. So you want a comment about this in the header?
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 12/12] ARM: tegra: Convert PMC to a driver
From: Thierry Reding @ 2014-07-21 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CCBCA9.7020907@nvidia.com>
On Mon, Jul 21, 2014 at 03:09:29PM +0800, Vince Hsu wrote:
>
> On 07/17/2014 07:01 PM, Thierry Reding wrote:
> >* PGP Signed by an unknown key
> >
> >On Thu, Jul 17, 2014 at 12:01:56PM +0300, Peter De Schrijver wrote:
> >>On Thu, Jul 17, 2014 at 10:53:08AM +0200, Peter De Schrijver wrote:
> >>>On Wed, Jul 16, 2014 at 08:57:16PM +0200, Thierry Reding wrote:
> >>>>>Old Signed by an unknown key
> >>>>On Wed, Jul 16, 2014 at 05:22:03PM +0200, Arnd Bergmann wrote:
> >>>>>On Wednesday 16 July 2014 17:14:29 Thierry Reding wrote:
> >>>>>>>Ok, I'll have a look. I think when this becomes a separate driver, it
> >>>>>>>should also have its own header file, so maybe you can in the meantime
> >>>>>>>make it a local header file in mach-tegra until we have found a good
> >>>>>>>place for it.
> >>>>>>Why do you think it should be a separate header? We already have a
> >>>>>>couple in include/linux and I'm not sure it's useful to add even more.
> >>>>>>If anything I would've thought it made sense to move the content of the
> >>>>>>other headers into tegra-soc.h.
> >>>>>I very much dislike the idea of having a per-vendor header file that
> >>>>>everything gets crammed into. We should try to have proper subsystems
> >>>>>and generic interfaces for these wherever possible.
> >>>>I completely agree. However spreading the SoC-specific functions across
> >>>>multiple header files isn't going to help. If we keep all the per-vendor
> >>>>APIs in one file it makes it easier to see what could still be moved off
> >>>>into a separate subsystem.
> >>>>
> >>>>Now for PMC specifically, we've investigated converting the powergate
> >>>>API to power domains. I don't think it will be possible to make that
> >>>>work. The issue is that there's a defined sequence that needs to be
> >>>>respected to make sure the device is powered up properly. That sequence
> >>>>involves the primary clock and reset of the device. It's been proposed
> >>>>to make these clocks available to the PMC driver so that it can control
> >>>>them, but then we can't make sure that clocks are really off if they
> >>>>need to be, since we have two drivers accessing them. The only way I see
> >>>resets do not have reference counts, so they can be controlled by a
> >>>powerdomain driver without any problems. For clocks, there would only be
> >>>a problem for the module clocks if the drivers don't use runtime PM. If
> >>>we move all drivers to runtime PM, the clock control can move into the
> >>>powerdomain code and runtime PM will ensure domains are not turned off
> >>>with active modules.
> >>>
> >>>>to make that work reliably is by moving complete control of the
> >>>>powergate into drivers so that they can make sure clocks and resets are
> >>>>in the correct states.
> >>>>
> >>>Which won't work if you have domains which contain several modules.
> >>We also need to control the memory clients in the domains using
> >>MC_CLIENT_HOTRESET_CTRL.
> >Oh, great. More interdependencies...
> Some domains depend on others. Can we take this into account?
I'm not aware of any dependencies. Can you point me at the relevant
section in the TRM?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/6ddc88eb/attachment.sig>
^ permalink raw reply
* [PATCH v10 4/8] ata: libahci: allow to use multiple PHYs
From: Antoine Ténart @ 2014-07-21 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718151745.0b0114a9@ipc1.ka-ro>
Hi,
On Fri, Jul 18, 2014 at 03:17:45PM +0200, Lothar Wa?mann wrote:
> Antoine T?nart wrote:
> > diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> > index db9b90d876dd..2c2439b4101d 100644
> > --- a/drivers/ata/libahci_platform.c
> > +++ b/drivers/ata/libahci_platform.c
> > @@ -39,6 +39,61 @@ static struct scsi_host_template ahci_platform_sht = {
> > };
> >
> > /**
> > + * ahci_platform_enable_phys - Enable PHYs
> > + * @hpriv: host private area to store config values
> > + *
> > + * This function enables all the PHYs found in hpriv->phys, if any.
> > + * If a PHY fails to be enabled, it disables all the PHYs already
> > + * enabled in reverse order and returns an error.
> > + *
> > + * RETURNS:
> > + * 0 on success otherwise a negative error code
> > + */
> > +int ahci_platform_enable_phys(struct ahci_host_priv *hpriv)
> > +{
> > + int i, rc = 0;
> > +
> You shouldn't have to initialize rc here, or does your gcc falsely
> complain about an uninitialized variable if you don't?
You're right, this is not needed.
Antoine
--
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718174334.209e99c1@bbrezillon>
On Fri, Jul 18, 2014 at 05:43:34PM +0200, Boris BREZILLON wrote:
[...]
> > > > > > + - atmel,panel: Should contain a phandle with 2 parameters.
> > > > > > + The first cell is a phandle to a DRM panel device
> > > > > > + The second cell encodes the RGB mode, which can take the following values:
> > > > > > + * 0: RGB444
> > > > > > + * 1: RGB565
> > > > > > + * 2: RGB666
> > > > > > + * 3: RGB888
> > > > >
> > > > > These are properties of the panel and should be obtained from the panel
> > > > > directly rather than an additional cell in this specifier.
> > > >
> > > > Okay.
> > > > What's the preferred way of doing this ?
> > > > What about defining an rgb-mode property in the panel node.
> > >
> > > There's .bpc in struct drm_display_info, I suspect that it could be used
> > > for this. Alternatively, maybe we could extend the list of color formats
> > > that go into drm_display_info.color_formats? RGB444 is already covered.
> >
>
> I forgot to ask about bpc meaning. If, as I think, it means "bits per
> color" then it cannot be used to encode RGB565 where green color is
> encoded on 6 bits and red and blue are encoded on 5 bits.
Yes, I agree that bps is not a good fit for what you need here.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/afb8110f/attachment-0001.sig>
^ permalink raw reply
* [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Arnd Bergmann @ 2014-07-21 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CCCCA8.1030509@samsung.com>
On Monday 21 July 2014 17:17:44 Chanwoo Choi wrote:
> On 07/21/2014 05:11 PM, Chanwoo Choi wrote:
> > On 07/21/2014 04:38 PM, Arnd Bergmann wrote:
> >> On Monday 21 July 2014 11:17:44 Chanwoo Choi wrote:
> >>>
> >>> This patchset support Exynos3250 ADC (Analog Digital Converter) because
> >>> Exynos3250 has additional special clock for ADC IP.
> >>>
> >>> Changes from v6:
> >>> - Use "exynos3250-adc" compatible string instead of "exynos3250-adc-v2"
> >>> - Use "sclk" clock name instead of "sclk_adc"
> >>> - Remove un-necessary macro for exyno-adc-data-v2 structure.
> >>> - Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
> >>> - Change the number of ADC channels (Exynos3250 has only two channels for ADC)
> >>>
> >>
> >> Looks good to me. Two small requests:
> >>
> >> a) if you don't mind, can you add my patch (1/2) to add support for s3c64xx to
> >> your series, adding your Signed-off-by line in addition to mine? I think
> >> that one was noncontroversial, while the second patch (2/2) need some more
> >> work to address the comments and do testing.
> >
> > OK, I'll add this patch.
> > But, I have a question.
> >
> > Your patch add following compatible string.
> > "s3c64100-adc" is right?
> >
> > static const struct of_device_id exynos_adc_match[] = {
> > {
> > + .compatible = "samsung,s3c64100-adc",
> > + .data = &exynos_adc_s3c64xx_data,
> > + }, {
>
> Additionally,
> Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt has not included
> "samsung,s3c6410-adc" compatible string. Should I add this string in exynos-adc.txt?
>
> drivers/iio/adc/exynos-adc.c has not includeded following compatible string.
> Should I add this compatible string on exynos-adc.c?
>
> + Must be "samsung,s3c2410-adc" for
> + the ADC in s3c2410 and compatibles
> + Must be "samsung,s3c2416-adc" for
> + the ADC in s3c2416 and compatibles
> + Must be "samsung,s3c2440-adc" for
> + the ADC in s3c2440 and compatibles
> + Must be "samsung,s3c2440-adc" for
> + the ADC in s3c2440 and compatibles
> + Must be "samsung,s3c2443-adc" for
> + the ADC in s3c2443 and compatibles
>
Yes, please.
Arnd
^ permalink raw reply
* [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Arnd Bergmann @ 2014-07-21 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CCCB20.50802@samsung.com>
On Monday 21 July 2014 17:11:12 Chanwoo Choi wrote:
> > work to address the comments and do testing.
>
> OK, I'll add this patch.
> But, I have a question.
>
> Your patch add following compatible string.
> "s3c64100-adc" is right?
>
> static const struct of_device_id exynos_adc_match[] = {
> {
> + .compatible = "samsung,s3c64100-adc",
> + .data = &exynos_adc_s3c64xx_data,
> + }, {
There is a typo, thanks for spotting this. It should be
"samsung,s3c6410-adc", not "samsung,s3c64100-adc".
> > b) For the "compatible" string, I think it makes sense to set a fallback to
> > "samsung,exynos-adc-v2" in the case for exynos3250, making the DT
> > representation
> >
> > compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2";
> >
> > It's not entirely compatible because of the addition of the clock, but
> > since the register layout is the same, I think it still make sense.
>
> OK, I'll add it in exynos3250.dtsi as following:
>
> adc: adc at 126C0000 {
> - compatible = "samsung,exynos-adc-v3";
> + compatible = "samsung,exynos3250-adc",
> + "samsung,exynos-adc-v2";
> reg = <0x126C0000 0x100>, <0x10020718 0x4>;
> interrupts = <0 137 0>;
> - clock-names = "adc", "sclk_tsadc";
> + clock-names = "adc", "sclk";
> clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
> #io-channel-cells = <1>;
> io-channel-ranges;
Ok, looks good.
Arnd
^ permalink raw reply
* [PATCH 2/3] ARM: smp_scu: enable SCU standby support
From: Will Deacon @ 2014-07-21 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405928755-19413-3-git-send-email-shawn.guo@freescale.com>
On Mon, Jul 21, 2014 at 08:45:54AM +0100, Shawn Guo wrote:
> With SCU standby enabled, SCU CLK will be turned off when all processors
> are in WFI mode. And the clock will be turned on when any processor
> leaves WFI mode.
>
> This behavior should be preferable in terms of power efficiency of
> system idle. So let's set the SCU standby bit to enable the support in
> function scu_enable().
>
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/kernel/smp_scu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> index c947508f84e6..9f29d167d02c 100644
> --- a/arch/arm/kernel/smp_scu.c
> +++ b/arch/arm/kernel/smp_scu.c
> @@ -18,6 +18,7 @@
>
> #define SCU_CTRL 0x00
> #define SCU_ENABLE (1 << 0)
> +#define SCU_STANDBY_ENABLE (1 << 5)
> #define SCU_CONFIG 0x04
> #define SCU_CPU_STATUS 0x08
> #define SCU_INVALIDATE 0x0c
> @@ -54,7 +55,7 @@ void scu_enable(void __iomem *scu_base)
> if (scu_ctrl & SCU_ENABLE)
> return;
>
> - scu_ctrl |= SCU_ENABLE;
> + scu_ctrl |= SCU_ENABLE | SCU_STANDBY_ENABLE;
I don't think this bit exists on all revisions of the A9.
Will
^ permalink raw reply
* [PATCH resend v2] arm64: dmi: Add SMBIOS/DMI support
From: Will Deacon @ 2014-07-21 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9K=Hp97cFK2D_HTe=CD6-spvUcP6itOyLB-DcgQatmyA@mail.gmail.com>
On Sun, Jul 20, 2014 at 11:25:34AM +0100, Ard Biesheuvel wrote:
> On 14 July 2014 15:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 14 July 2014 15:36, Will Deacon <will.deacon@arm.com> wrote:
> >> On Fri, Jul 11, 2014 at 12:46:50PM +0100, Ard Biesheuvel wrote:
> >>> From: Yi Li <yi.li@linaro.org>
> >>>
> >>> SMbios is important for server hardware vendors. It implements a spec for
> >>> providing descriptive information about the platform. Things like serial
> >>> numbers, physical layout of the ports, build configuration data, and the like.
> >>>
> >>> This has been tested by dmidecode and lshw tools.
> >>>
> >>> Signed-off-by: Yi Li <yi.li@linaro.org>
> >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >>> ---
> >>> Changes since previous version:
> >>> - changed double inclusion guard to arm64 flavour
> >>> - use kzalloc(GFP_KERNEL) as GFP_ATOMIC is not needed
> >>> - do a sanity check on the size of the requested mapping
> >>
> >> Technically, this patch looks fine to me:
> >>
> >> Reviewed-by: Will Deacon <will.deacon@arm.com>
> >>
>
> Hello Catalin,
>
> This has been tested by Yi on FVP and Juno.
> Are you ok to take this?
Out of interest, how did you test it on Juno? I tried but got some messages
about missing/invalid DMI data or something similar. Leif reckons I need
some tricked out firmware for the FVP to get something working, but even
then the information is apparently bogus.
Will
^ permalink raw reply
* [GIT PULL 4/5] Samsung exynos_mct update for v3.17
From: Daniel Lezcano @ 2014-07-21 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140719220623.GF15676@quad.lixom.net>
On 07/20/2014 12:06 AM, Olof Johansson wrote:
> On Sat, Jul 19, 2014 at 09:52:52AM +0900, Kukjin Kim wrote:
>> Note that this is also based on 3.16-rc5 because of dependency with
>> previous samsung fixes including exynos_mct already merged in
>> mainline during -rc.
>>
>> The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
>>
>> Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
>>
>> are available in the git repository at:
>>
>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> tags/exynos-mct
>>
>> for you to fetch changes up to 1a631118c1d085fe162f3b6d44f710c72206ef2d:
>>
>> clocksource: exynos_mct: Only use 32-bits where possible
>> (2014-07-19 03:07:52 +0900)
>>
>> ----------------------------------------------------------------
>> exynos_mct update for v3.17
>> - only use 32-bit access for performance benefits on exynos
>> 32-bit system and this means ARCH timer should be supported
>> on exynos 64-bit system instead of current MCT.
>> - use readl_relaxed/writel_relaxed to consistently use the
>> proper functions in exynos_mct.
>
> There's no reason for these to go through arm-soc, is there? They should
> go through the clocksource tree (Daniel Lezcano / Thomas Gleixner). They
> also lack acks from them if they for some reason need to go through arm-soc.
Yes, that's right. Furthermore I have been discussing with Doug about
these patches before.
Kukjin, is there any dependency on these patches ?
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 3/3] ARM: exynos_defconfig: Enable cpuidle driver
From: Krzysztof Kozlowski @ 2014-07-21 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405931771-24100-1-git-send-email-k.kozlowski@samsung.com>
The cpuidle driver for Exynos supports all SoCs now. AFTR is supported
only on Exynos4210 and Exynos5250 (WFI is used on other). Add the driver
to default exynos config.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
arch/arm/configs/exynos_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index fc7d1683bf67..237434e26565 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -24,6 +24,12 @@ CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc mem=256M"
+CONFIG_CPU_IDLE=y
+CONFIG_CPU_IDLE_MULTIPLE_DRIVERS=y
+CONFIG_CPU_IDLE_GOV_LADDER=y
+CONFIG_CPU_IDLE_GOV_MENU=y
+CONFIG_ARM_BIG_LITTLE_CPUIDLE=y
+CONFIG_ARM_EXYNOS_CPUIDLE=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_PM_RUNTIME=y
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ARM: EXYNOS: Enable cpuidle in WFI on all SoCs
From: Krzysztof Kozlowski @ 2014-07-21 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405931771-24100-1-git-send-email-k.kozlowski@samsung.com>
Add cpuidle device for each SoC but set AFTR enter function only on
supported ones (for now these are only Exynos4210 and Exynos5250). For
other chipsets use only WFI.
This actually does not give any special energy-saving benefits but
allows to track the idle time of each core.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
arch/arm/mach-exynos/exynos.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 2a43a1734eca..4109d592f6fc 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -171,14 +171,20 @@ static void exynos_restart(enum reboot_mode mode, const char *cmd)
static struct platform_device exynos_cpuidle = {
.name = "exynos_cpuidle",
- .dev.platform_data = exynos_enter_aftr,
+ /*
+ * Currently AFTR is not implemented for each SoC.
+ * Set this to exynos_enter_aftr() only for supported SoCs.
+ */
+ .dev.platform_data = NULL,
.id = -1,
};
void __init exynos_cpuidle_init(void)
{
if (soc_is_exynos4210() || soc_is_exynos5250())
- platform_device_register(&exynos_cpuidle);
+ exynos_cpuidle.dev.platform_data = exynos_enter_aftr;
+
+ platform_device_register(&exynos_cpuidle);
}
void __init exynos_cpufreq_init(void)
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] cpuidle: exynos: Allow to use the driver without AFTR
From: Krzysztof Kozlowski @ 2014-07-21 8:36 UTC (permalink / raw)
To: linux-arm-kernel
Allow the driver to be used when AFTR enter function is not provided
(device platform data is NULL).
This actually does not give any special energy-saving benefits but
allows to track the idle time of each core. Additionally it is a safe
way to validate supplied platform data.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
drivers/cpuidle/cpuidle-exynos.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-exynos.c b/drivers/cpuidle/cpuidle-exynos.c
index 7c0151263828..5325a394be7e 100644
--- a/drivers/cpuidle/cpuidle-exynos.c
+++ b/drivers/cpuidle/cpuidle-exynos.c
@@ -77,7 +77,10 @@ static int exynos_cpuidle_probe(struct platform_device *pdev)
{
int ret;
+ /* If NULL enter only WFI */
exynos_enter_aftr = (void *)(pdev->dev.platform_data);
+ if (!exynos_enter_aftr)
+ exynos_idle_driver.state_count = 1;
ret = cpuidle_register(&exynos_idle_driver, NULL);
if (ret) {
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH 1/1] ARM: DT: STi: STiH416: Add DT node for ST's SATA device
From: Lee Jones @ 2014-07-21 8:32 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree at vger.kernel.org
Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Documentation/devicetree/bindings/ata/ahci-st.txt | 2 +-
arch/arm/boot/dts/stih416-b2020.dts | 4 ++++
arch/arm/boot/dts/stih416-b2020e.dts | 4 ++++
arch/arm/boot/dts/stih416.dtsi | 16 ++++++++++++++++
4 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt
index 0574a77..9883542 100644
--- a/Documentation/devicetree/bindings/ata/ahci-st.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-st.txt
@@ -21,7 +21,7 @@ Example:
reg = <0xfe380000 0x1000>;
interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
interrupt-names = "hostc";
- phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ phys = <&phy_port0 MIPHY_TYPE_SATA>;
phy-names = "ahci_phy";
resets = <&powerdown STIH416_SATA0_POWERDOWN>,
<&softreset STIH416_SATA0_SOFTRESET>;
diff --git a/arch/arm/boot/dts/stih416-b2020.dts b/arch/arm/boot/dts/stih416-b2020.dts
index c3c2ac6..eb2f246 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -23,5 +23,9 @@
st,pcie-tx-pol-inv;
};
};
+
+ sata0: sata at fe380000{
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/stih416-b2020e.dts b/arch/arm/boot/dts/stih416-b2020e.dts
index 80aff0f..99a699e 100644
--- a/arch/arm/boot/dts/stih416-b2020e.dts
+++ b/arch/arm/boot/dts/stih416-b2020e.dts
@@ -41,5 +41,9 @@
st,pcie-tx-pol-inv;
};
};
+
+ sata0: sata at fe380000{
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 2b98a0a..060dd53 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -258,5 +258,21 @@
reg-names = "sata", "pcie", "syscfg";
};
};
+
+ sata0: sata at fe380000 {
+ compatible = "st,sti-ahci";
+ reg = <0xfe380000 0x1000>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
+ interrupt-names = "hostc";
+ phys = <&phy_port0 MIPHY_TYPE_SATA>;
+ phy-names = "sata-phy";
+ resets = <&powerdown STIH416_SATA0_POWERDOWN>,
+ <&softreset STIH416_SATA0_SOFTRESET>;
+ reset-names = "pwr-dwn", "sw-rst";
+ clock-names = "ahci_clk";
+ clocks = <&clk_s_a0_ls CLK_ICN_REG>;
+
+ status = "disabled";
+ };
};
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/1] ahci: st: Provide DT bindings for ST's SATA implementation
From: Lee Jones @ 2014-07-21 8:28 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree at vger.kernel.org
Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Hi Tejun,
This patch has been on the MLs for a few months now. It documents
ST's AHCI driver which was accepted by you and now resides in
Mainline.
Kind regards,
Lee
Documentation/devicetree/bindings/ata/ahci-st.txt | 31 +++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-st.txt
diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt
new file mode 100644
index 0000000..0574a77
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-st.txt
@@ -0,0 +1,31 @@
+STMicroelectronics STi SATA controller
+
+This binding describes a SATA device.
+
+Required properties:
+ - compatible : Must be "st,sti-ahci"
+ - reg : Physical base addresses and length of register sets
+ - interrupts : Interrupt associated with the SATA device
+ - interrupt-names : Associated name must be; "hostc"
+ - resets : The power-down and soft-reset lines of SATA IP
+ - reset-names : Associated names must be; "pwr-dwn" and "sw-rst"
+ - clocks : The phandle for the clock
+ - clock-names : Associated name must be; "ahci_clk"
+ - phys : The phandle for the PHY device
+ - phy-names : Associated name must be; "ahci_phy"
+
+Example:
+
+ sata0: sata at fe380000 {
+ compatible = "st,sti-ahci";
+ reg = <0xfe380000 0x1000>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
+ interrupt-names = "hostc";
+ phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
+ phy-names = "ahci_phy";
+ resets = <&powerdown STIH416_SATA0_POWERDOWN>,
+ <&softreset STIH416_SATA0_SOFTRESET>;
+ reset-names = "pwr-dwn", "sw-rst";
+ clocks = <&clk_s_a0_ls CLK_ICN_REG>;
+ clock-names = "ahci_clk";
+ };
--
1.8.3.2
^ permalink raw reply related
* [PATCH] ARM: i.MX6: add more chip revision support
From: Sascha Hauer @ 2014-07-21 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721070647.GK8537@dragon>
On Mon, Jul 21, 2014 at 03:06:48PM +0800, Shawn Guo wrote:
> On Mon, Jul 21, 2014 at 08:35:20AM +0200, Sascha Hauer wrote:
> > On Mon, Jul 21, 2014 at 01:38:11PM +0800, Shawn Guo wrote:
> > > From: Jason Liu <r64343@freescale.com>
> > >
> > > Add more revision support for the new i.MX6DQ tap-out (TO1.5). This
> > > TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
> > > and TO1.4 are never revealed.
> >
> > So the chip identifies itself as 1.5 but the data sheet refers to it as
> > 1.3. Is there a way to make that clear somewhere? Otherwise it's really
> > confusing.
>
> I can add a note about that in the code, but I'm not really sure if
> there is a better way to pass such info to end users. Suggestions are
> welcomed.
Since the anatop code can be used by other SoCs aswell and you're saying
that even the other i.MX6 SoC variants may have a different numbering I
think adding a comment to the code is the best we can do.
The only other possibility I can think of is to make the info string we
print during boot SoC specific again, but I think we are all glad that
this isn't the case anymore.
So adding a comment should be fine. At least the code would be the place
I would look if I remembered that there is some inconsistency and don't
know exactly what it was.
Sascha
--
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
* [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Chanwoo Choi @ 2014-07-21 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CCCB20.50802@samsung.com>
On 07/21/2014 05:11 PM, Chanwoo Choi wrote:
> On 07/21/2014 04:38 PM, Arnd Bergmann wrote:
>> On Monday 21 July 2014 11:17:44 Chanwoo Choi wrote:
>>>
>>> This patchset support Exynos3250 ADC (Analog Digital Converter) because
>>> Exynos3250 has additional special clock for ADC IP.
>>>
>>> Changes from v6:
>>> - Use "exynos3250-adc" compatible string instead of "exynos3250-adc-v2"
>>> - Use "sclk" clock name instead of "sclk_adc"
>>> - Remove un-necessary macro for exyno-adc-data-v2 structure.
>>> - Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
>>> - Change the number of ADC channels (Exynos3250 has only two channels for ADC)
>>>
>>
>> Looks good to me. Two small requests:
>>
>> a) if you don't mind, can you add my patch (1/2) to add support for s3c64xx to
>> your series, adding your Signed-off-by line in addition to mine? I think
>> that one was noncontroversial, while the second patch (2/2) need some more
>> work to address the comments and do testing.
>
> OK, I'll add this patch.
> But, I have a question.
>
> Your patch add following compatible string.
> "s3c64100-adc" is right?
>
> static const struct of_device_id exynos_adc_match[] = {
> {
> + .compatible = "samsung,s3c64100-adc",
> + .data = &exynos_adc_s3c64xx_data,
> + }, {
Additionally,
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt has not included
"samsung,s3c6410-adc" compatible string. Should I add this string in exynos-adc.txt?
drivers/iio/adc/exynos-adc.c has not includeded following compatible string.
Should I add this compatible string on exynos-adc.c?
+ Must be "samsung,s3c2410-adc" for
+ the ADC in s3c2410 and compatibles
+ Must be "samsung,s3c2416-adc" for
+ the ADC in s3c2416 and compatibles
+ Must be "samsung,s3c2440-adc" for
+ the ADC in s3c2440 and compatibles
+ Must be "samsung,s3c2440-adc" for
+ the ADC in s3c2440 and compatibles
+ Must be "samsung,s3c2443-adc" for
+ the ADC in s3c2443 and compatibles
Thanks,
Chanwoo Choi
^ permalink raw reply
* [PATCHv7 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Chanwoo Choi @ 2014-07-21 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14522743.f6oFhEQVv4@wuerfel>
On 07/21/2014 04:38 PM, Arnd Bergmann wrote:
> On Monday 21 July 2014 11:17:44 Chanwoo Choi wrote:
>>
>> This patchset support Exynos3250 ADC (Analog Digital Converter) because
>> Exynos3250 has additional special clock for ADC IP.
>>
>> Changes from v6:
>> - Use "exynos3250-adc" compatible string instead of "exynos3250-adc-v2"
>> - Use "sclk" clock name instead of "sclk_adc"
>> - Remove un-necessary macro for exyno-adc-data-v2 structure.
>> - Remove '(void *)' cast and mark the exynos-adc-data structure as 'const'
>> - Change the number of ADC channels (Exynos3250 has only two channels for ADC)
>>
>
> Looks good to me. Two small requests:
>
> a) if you don't mind, can you add my patch (1/2) to add support for s3c64xx to
> your series, adding your Signed-off-by line in addition to mine? I think
> that one was noncontroversial, while the second patch (2/2) need some more
> work to address the comments and do testing.
OK, I'll add this patch.
But, I have a question.
Your patch add following compatible string.
"s3c64100-adc" is right?
static const struct of_device_id exynos_adc_match[] = {
{
+ .compatible = "samsung,s3c64100-adc",
+ .data = &exynos_adc_s3c64xx_data,
+ }, {
>
> b) For the "compatible" string, I think it makes sense to set a fallback to
> "samsung,exynos-adc-v2" in the case for exynos3250, making the DT
> representation
>
> compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2";
>
> It's not entirely compatible because of the addition of the clock, but
> since the register layout is the same, I think it still make sense.
OK, I'll add it in exynos3250.dtsi as following:
adc: adc at 126C0000 {
- compatible = "samsung,exynos-adc-v3";
+ compatible = "samsung,exynos3250-adc",
+ "samsung,exynos-adc-v2";
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
- clock-names = "adc", "sclk_tsadc";
+ clock-names = "adc", "sclk";
clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
#io-channel-cells = <1>;
io-channel-ranges;
Thanks,
Chanwoo Choi
>
> Thanks.
>
> For the entire series,
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH 8/9] usb: phy: am335x: call usb_gen_phy_init()/usb_gen_phy_shutdown() in am335x_init()/am335x_shutdown()
From: Lothar Waßmann @ 2014-07-21 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718135713.GH24914@saruman.home>
Hi,
> On Fri, Jul 18, 2014 at 11:31:29AM +0200, Lothar Wa?mann wrote:
> > This patch makes it possible to use the musb driver with HW that
> > requires external regulators or clocks.
>
> can you provide an example of such HW ? Are you not using the internal
> PHYs ?
>
The Ka-Ro electronics TX48 module uses the mmc0_clk pin as VBUSEN
rathern than usb0_drvvbus. This patch makes it possible to use an
external regulator to handle the VBUS switch through the 'vcc-supply'
property of the underlying generic_phy device.
> > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> > ---
> > drivers/usb/phy/phy-am335x.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
> > index 6522fa7..de25674 100644
> > --- a/drivers/usb/phy/phy-am335x.c
> > +++ b/drivers/usb/phy/phy-am335x.c
> > @@ -22,6 +22,7 @@ static int am335x_init(struct usb_phy *phy)
> > {
> > struct am335x_phy *am_phy = dev_get_drvdata(phy->dev);
> >
> > + usb_gen_phy_init(phy);
> > phy_ctrl_power(am_phy->phy_ctrl, am_phy->id, true);
> > return 0;
> > }
> > @@ -31,6 +32,7 @@ static void am335x_shutdown(struct usb_phy *phy)
> > struct am335x_phy *am_phy = dev_get_drvdata(phy->dev);
> >
> > phy_ctrl_power(am_phy->phy_ctrl, am_phy->id, false);
> > + usb_gen_phy_shutdown(phy);
> > }
> >
> > static int am335x_phy_probe(struct platform_device *pdev)
> > --
> > 1.7.10.4
> >
>
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Arnd Bergmann @ 2014-07-21 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CC725C.9010406@samsung.com>
On Monday 21 July 2014 10:52:28 Chanwoo Choi wrote:
> > Yes, your current version is certainly better than this, but another way
> > to address Tomasz' comment would be to change the binding to list the "sclk"
> > as optional for any device and make the code silently ignore missing sclk
> > entries, like:
> >
> >
> > info->sclk = devm_clk_get(&pdev->dev, "sclk");
> > if (IS_ERR(info->sclk)) {
> > switch (PTR_ERR(info->sclk)) {
> > case -EPROBE_DEFER:
> > /* silently return error so we can retry */
> > return -EPROBE_DEFER:
> > case -ENOENT:
> > /* silently ignore missing optional clk */
> > info->sclk = NULL;
> > break;
> > default:
> > /* any other error: clk is defined by doesn't work */
> > dev_err(&pdev->dev, "failed getting sclk clock, err = %ld\n",
> > PTR_ERR(info->sclk));
> > return PTR_ERR(info->sclk));
> > }
> > }
>
> I tested this patch suggested by you.
> But, devm_clk_get returns always '-ENOENT' on follwong two cases:
>
> Case 1.
> ADC dt node in exynos3250.dtsi don't include 'sclk' clock as following:
>
> adc: adc at 126C0000 {
> compatible = "samsung,exynos3250-adc";
> reg = <0x126C0000 0x100>, <0x10020718 0x4>;
> interrupts = <0 137 0>;
> clock-names = "adc";
> clocks = <&cmu CLK_TSADC>;
> #io-channel-cells = <1>;
> io-channel-ranges;
> };
>
> Case 2.
> ADC dt node in exynos3250.dtsi don't include 'sclk' clock
> but, exynos3250 clock controller don't support CLK_SCLK_TSADC clock as following:
>
> adc: adc at 126C0000 {
> compatible = "samsung,exynos3250-adc";
> reg = <0x126C0000 0x100>, <0x10020718 0x4>;
> interrupts = <0 137 0>;
> clock-names = "adc", "sclk";
> clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
> #io-channel-cells = <1>;
> io-channel-ranges;
> };
But neither of those cases is actually a correct DT representation for
exynos3250: The first case describes an ADC that doesn't need a second
clock, so if the hardware actually needs it to function, it is clearly
unsufficiently described. The second case is even worse because it refers
to a clock that isn't there. Actually that should probably return a different
error code, but that's a different matter.
> So, I think exynos-adc needs to use 'needs_sclk' field suggested by Tomasz Figa.
I don't mind you adding a field to the data, especially since you already
need to have separate structures to encode the different number of channels.
However, I don't see it as necessary either. What you do here is just
checking the DT representation for correctness and consistency. It's not
harmful but we don't normally do that because passing incorrect DT blobs
can cause an infinite number of other problems that we don't check for.
Arnd
^ permalink raw reply
* [GIT PULL] ARM: OMAP2+: clock cleanup for 3.17
From: Tony Lindgren @ 2014-07-21 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1407171817440.22427@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [140717 11:20]:
> Hi Tony,
>
> The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:
>
> Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.17/omap-clock-a
>
> for you to fetch changes up to acd052bb8119dd9117e0af48ff0ac6e56e61b6b4:
>
> ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file (2014-07-15 14:09:24 -0600)
>
> ----------------------------------------------------------------
> An OMAP clock cleanup series for 3.17 from Tero Kristo.
> This is in preparation for moving this code into drivers/clk/ti.
>
> Basic build, boot, and PM test logs are here:
>
> http://www.pwsan.com/omap/testlogs/clock-a-v3.17/20140717034329/
Thanks pulling into omap-for-v3.17/soc.
Regards,
Tony
^ 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