* [PATCH] ARM: footbridge: Switch to sched_clock_register()
From: Stephen Boyd @ 2014-02-04 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389922207-5154-1-git-send-email-sboyd@codeaurora.org>
On 01/16, Stephen Boyd wrote:
> The 32 bit sched_clock interface supports 64 bits since 3.13-rc1.
> Upgrade to the 64 bit function to allow us to remove the 32 bit
> registration interface.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Russell,
Can you please apply this for 3.14? This is the last user of the
deprecated interface in linus' tree. Once this is merged I will
remove setup_sched_clock(). It's 7945/1 in the patch tracker.
>
> Based on rmk/for-next
>
> arch/arm/mach-footbridge/dc21285-timer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-footbridge/dc21285-timer.c b/arch/arm/mach-footbridge/dc21285-timer.c
> index 3971104d32d4..5d2725fd878c 100644
> --- a/arch/arm/mach-footbridge/dc21285-timer.c > +++ b/arch/arm/mach-footbridge/dc21285-timer.c
> @@ -125,7 +125,7 @@ void __init footbridge_timer_init(void)
> clockevents_config_and_register(ce, rate, 0x4, 0xffffff);
> }
>
> -static u32 notrace footbridge_read_sched_clock(void)
> +static u64 notrace footbridge_read_sched_clock(void)
> {
> return ~*CSR_TIMER3_VALUE;
> }
> @@ -138,5 +138,5 @@ void __init footbridge_sched_clock(void)
> *CSR_TIMER3_CLR = 0;
> *CSR_TIMER3_CNTL = TIMER_CNTL_ENABLE | TIMER_CNTL_DIV16;
>
> - setup_sched_clock(footbridge_read_sched_clock, 24, rate);
> + sched_clock_register(footbridge_read_sched_clock, 24, rate);
> }
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 2/3] PCI: ARM: add support for virtual PCI host controller
From: Arnd Bergmann @ 2014-02-04 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391532784-1953-3-git-send-email-will.deacon@arm.com>
On Tuesday 04 February 2014 16:53:03 Will Deacon wrote:
> +
> +- ranges : As described in IEEE Std 1275-1994, but must provide
> + at least a definition of the Configuration Space plus
> + one or both of IO and Memory Space.
> +
I might need to reread the spec, but I think the config space is not
actually supposed to be in the 'ranges' of the host bridge at all,
and it should just be listed in the 'reg'.
IIRC the reason why the config space is part of the three-cell address
is so that you can have funky ways to say "memory space of the device
with bus/dev/fn is actually translated to address X rather then Y".
It's too late to change that for the other drivers now, after the
binding is established.
> +Configuration Space is assumed to be memory-mapped (as opposed to being
> +accessed via an ioport) and laid out with a direct correspondence to the
> +geography of a PCI bus address, by concatenating the various components
> +to form a 24-bit offset:
> +
> + cfg_offset(bus, device, function, register) =
> + bus << 16 | device << 11 | function << 8 | register
This won't allow extended config space. Why not just do the
regular mmconfig layout and make this:
cfg_offset(bus, device, function, register) =
bus << 20 | device << 15 | function << 12 | register;
> +static int virt_pci_setup(int nr, struct pci_sys_data *sys)
> +{
> + struct virt_pci *pci = sys->private_data;
> +
> + if (resource_type(&pci->io)) {
> + pci_add_resource(&sys->resources, &pci->io);
> + pci_ioremap_io(nr * resource_size(&pci->io), pci->io.start);
> + }
This should really compute an io_offset.
> + if (resource_type(&pci->mem))
> + pci_add_resource(&sys->resources, &pci->mem);
and also a mem_offset, which is something different.
> + pci->cfg_base = devm_ioremap_resource(pci->dev, &pci->cfg);
> + return !IS_ERR(pci->cfg_base);
> +}
> +
> +static const struct of_device_id virt_pci_of_match[] = {
> + { .compatible = "linux,pci-virt" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, virt_pci_of_match);
I don't think we even want "virt" in the compatible string. The
binding should be generic enough that it can actually work with
real hardware.
> + for_each_of_pci_range(&parser, &range) {
> + u32 restype = range.flags & IORESOURCE_TYPE_BITS;
> +
> + switch (restype) {
> + case IORESOURCE_IO:
> + if (resource_type(&pci->io))
> + dev_warn(dev,
> + "ignoring additional io resource\n");
> + else
> + of_pci_range_to_resource(&range, np, &pci->io);
> + break;
> + case IORESOURCE_MEM:
> + if (resource_type(&pci->mem))
> + dev_warn(dev,
> + "ignoring additional mem resource\n");
> + else
> + of_pci_range_to_resource(&range, np, &pci->mem);
> + break;
This shows once more that the range parser code is suboptimal. So far
every single driver got the I/O space wrong here, because the obvious
way to write this function is also completely wrong.
What you get out of "of_pci_range_to_resource(&range, np, &pci->io)"
is not the resource you want to pass into pci_add_resource()
later.
> + memset(&hw, 0, sizeof(hw));
> + hw.nr_controllers = 1;
> + hw.private_data = (void **)&pci;
> + hw.setup = virt_pci_setup;
> + hw.map_irq = of_irq_parse_and_map_pci;
> + hw.ops = &virt_pci_ops;
> + pci_common_init_dev(dev, &hw);
Since most fields here are constant, I'd just write this as
struct hw_pci hw = {
.nr_controllers = 1,
.setup = virt_pci_setup,
...
};
Arnd
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Jason Gunthorpe @ 2014-02-04 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8676627.b6SYsazoah@wuerfel>
On Tue, Feb 04, 2014 at 07:34:50PM +0100, Arnd Bergmann wrote:
> Well, the way I see it, we already have support for arbitrary
> PCI domains in the kernel, and that works fine, so we can just
> as well use it. That way we don't have to partition the available
> 256 buses among the host bridges, and anything that needs a separate
> PCI config space can live in its own world. Quite often when you
> have multiple PCI hosts, they actually have different ways to
> get at the config space and don't even share the same driver.
> On x86, any kind of HT/PCI/PCIe/PCI-x bridge is stuffed into a
> single domain so they can support OSs that only know the
> traditional config space access methods, but I don't see
> any real advantage to that for other architectures.
Supporting a standard configration interface is a solid reason, but
there is alot more going on.
For instance to support peer-to-peer IO you need to have a consisent,
non-overlapping set of bus/device/function/tag to uniquely route TLPs
within the chip. Cross domain TLP routing in HW is non-trivial.
IOMMUs (and SR-IOv) rely on the BDF to identify the originating device
for each TLP. Multiple domains means a much more complex IOMMU
environment.
Failure to integrate on-chip devices into the PCI world also means
thing like SR-IOv won't work sanely with on-chip devices.
The only reason we should see multi-domain on a SOC is because the HW
design was lazy. Being lazy misses the Big Picture where PCI is the
cornerstone of many important Server/Enterprise technologies.
> > SOC internal peripherals should all show up in the bus 0 config space
> > of the only domain and SOC PCI-E physical ports should show up on bus
> > 0 as PCI-PCI bridges. This is all covered in the PCI-E specs regarding
> > the root complex.
> >
> > Generally I would expect the internal peripherals to still be
> > internally connected with AXI, but also connected through the ECAM
> > space for configuration, control, power management and address
> > assignment.
>
> That would of course be very nice from a software perspective,
> but I think that is much less likely for any practical
> implementation.
Well, all x86 implementations do this already.. It actually isn't that
big a deal from a HW perspective, you just have to think about it
fully, understand PCI, and position your registers accordingly.
Jason
^ permalink raw reply
* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Bjorn Andersson @ 2014-02-04 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204181831.GP22609@sirena.org.uk>
On Tue, Feb 4, 2014 at 10:18 AM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Feb 04, 2014 at 10:02:14AM -0800, Bjorn Andersson wrote:
>> On Tue, Feb 4, 2014 at 3:05 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > Why not do this at the time we apply the voltage? That would seem to be
>> > more robust, doing it in a separate place means that we might update one
>> > bit of code and not the other or might change the execution path so that
>> > one gets run and the other doesn't.
>
>> I do share your concerns about having this logic mirrored here is
>> risky, unfortunately the regulator object is created upon request from
>> a consumer; so it is not available when regulator_register() calls
>> set_machine_constraints().
>
> Oh, hang on - that's what you mean by a regulator object... I don't
> think this fixes the problem you think it does. What is the actual
> problem you're trying to fix here? The min_uV and max_uV on a consumer
> struct are supposed to be the request from that consumer, they should
> only be set if the consumer actually made a request for a voltage range.
I have a regulator that's being configured from DT as:
regulator-min-microvolt = <2950000>;
regulator-max-microvolt = <2950000>;
In the consumer I do regulator_set_voltage(2.95V).
As min == max the voltage is applied by the regulator framework on registration
of the regulator; and the regulator_set_voltage() fails as
REGULATOR_CHANGE_VOLTAGE is not set for this regulator.
This makes sense, until I change regulator-min-microvolt to say 2000000 then
the regulator_set_voltage() succeeds; and the call is required for the device to
function properly.
So in the consumer I get different behavior depending on how the regulator is
configured in DT.
The proposed fix solves this by making the consumer object aware of
the initialized
voltage (as it's fixed in this case), making it okay for calls to
regulator_set_voltage()
given that it's the same value as the configured value; failing for others.
>
>> An alternative is to drop the conditional setting of
>> REGULATOR_CHANGE_VOLTAGE from of_regulator.c and force the regulator
>> drivers to set this flag explicitly; to avoid the difference in
>> behavior depending on configuration.
>
> Why would having each individual driver open code things help?
Without this fix I explicitly need to add REGULATOR_CHANGE_VOLTAGE to the
valid_ops_mask of my regulators, ignoring the fact that
of_get_regulation_constraints()
does apply some logic in this area.
Regards,
Bjorn
^ permalink raw reply
* [GIT PULL] irqchip: dove: drivers for v3.14
From: Jason Cooper @ 2014-02-04 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1402041959110.24986@ionos.tec.linutronix.de>
On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote:
> On Tue, 28 Jan 2014, Jason Cooper wrote:
> > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting
> > near to the end of the merge window and there's been no activity on this
> > pull request.
> >
> > Please let us know if there's anything we can do to assist.
>
> Nah. I simply forgot about it. About to send a pull request to Linus.
Great, thanks!
Jason.
^ permalink raw reply
* [PATCH v3 3/5] ASoC: tda998x: add DT documentation of the tda998x CODEC
From: Jean-Francois Moine @ 2014-02-04 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204181213.GO22609@sirena.org.uk>
On Tue, 4 Feb 2014 18:12:13 +0000
Mark Brown <broonie@kernel.org> wrote:
> On Sat, Feb 01, 2014 at 05:48:49PM +0100, Jean-Francois Moine wrote:
>
> > + - compatible: must be "nxp,tda998x-codec".
>
> It's not clear to me why there's a separate compatible here - as far as
> I can see this can only appear as part of one of these devices and
> there's no addressing or other information that'd account for chip
> variation so I'd not expect to need to bind this independently of the
> parent.
If there is no 'compatible', the CODEC module is not loaded, and, when
the module is in the core, no CODEC device can be created from the DT.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [GIT PULL] irqchip: dove: drivers for v3.14
From: Thomas Gleixner @ 2014-02-04 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128173531.GT29184@titan.lakedaemon.net>
On Tue, 28 Jan 2014, Jason Cooper wrote:
> I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting
> near to the end of the merge window and there's been no activity on this
> pull request.
>
> Please let us know if there's anything we can do to assist.
Nah. I simply forgot about it. About to send a pull request to Linus.
^ permalink raw reply
* [PATCH v3 2/5] ASoC: tda998x: add a codec driver for the TDA998x
From: Jean-Francois Moine @ 2014-02-04 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204175410.GL22609@sirena.org.uk>
On Tue, 4 Feb 2014 17:54:10 +0000
Mark Brown <broonie@kernel.org> wrote:
> On Tue, Feb 04, 2014 at 06:16:05PM +0100, Jean-Francois Moine wrote:
> > Mark Brown <broonie@kernel.org> wrote:
>
> > > > + /* load the optional CODEC */
> > > > + of_platform_populate(np, NULL, NULL, &client->dev);
>
> > > Why is this using of_platform_populate()? That's a very odd way of
> > > doing things.
>
> > The i2c does not populate the subnodes in the DT. I did not find why,
> > but, what is sure is that if of_platform_populate() is not called, the
> > tda CODEC module is not loaded.
>
> You shouldn't be representing this as a separate node in the DT unless
> there really is a distinct and reusable IP, otherwise you're putting
> Linux implementation details in there. Describe the hardware, not the
> implemementation.
If there is no 'compatible' node for the tda998x CODEC in the DT, the
simple-card is not usable, simply because you want the CODEC DAIs to be
defined by 'phandle + index' instead of by DAI name.
> > You may find an other example in drivers/mfd/twl-core.c.
>
> The TWL drivers aren't always a shining example of how to do things -
> they were one of the earliest MFDs so there's warts in there.
>
> > > > +config SND_SOC_TDA998X
> > > > + tristate
> > > > + depends on OF
> > > > + default y if DRM_I2C_NXP_TDA998X=y
> > > > + default m if DRM_I2C_NXP_TDA998X=m
>
> > > Make this visible if it can be selected from DT so it can be used with
> > > generic cards.
>
> > I don't understand. The tda CODEC can only be used with the TDA998x I2C
> > driver. It might have been included in the tda998x source as well.
>
> You shouldn't have the default settings there at all, that's not the
> normal idiom for MFDs. I'd also not expect to have to build the CODEC
> driver just because I built the DRM component.
As the tda998x handles audio in HDMI, it would be a pity if you should
connect an other cable to your screen.
> > Now, the CODEC is declared inside the tda998x as a node child. But, in
> > a bad DT, the tda CODEC could be declared anywhere, even inside a other
> > DRM I2C slave encoder, in which case, bad things would happen...
>
> So, part of the problem here is that this is being explicitly declared
> in the DT leading to more sources for error.
Simple-card constraint.
> > > What does this actually do? No information is being passed in to the
> > > core function here, not even any information on if it's starting or
> > > stopping. Looking at the rest of the code I can't help thinking it
> > > might be clearer to inline this possibly with a lookup helper, the code
> > > is very small and the lack of parameters makes it hard to follow.
>
> > I thought it was simple enough. The function tda_start_stop() is called
> > from 2 places:
>
> It's not at all obvious - _audio_update() isn't a terribly descriptive
> name, just looking at that function by itself I had no idea what it was
> supposed to be doing.
The first purpose of the function is to set the audio input port in the
tda998x. Streaming stop could have been omitted, but I thought it could
be interesting to stop HDMI audio when there is a super HiFi device
connected to the S/PDIF connector.
> > - on audio start in tda_startup with the audio type (DAI id)
> > priv->dai_id = dai->id;
>
> > - on audio stop with a null audio type
> > priv->dai_id = 0; /* streaming stop */
>
> > On stream start, the DAI id is never null, as explained in the patch 1:
>
> > The audio format values in the encoder configuration interface are
> > changed to non null values so that the value 0 is used in the audio
> > function to indicate that audio streaming is stopped.
>
> > and on streaming stop the port is not meaningful.
>
> > I will add a null item in the enum (AFMT_NO_AUDIO).
>
> So we can't use both streams simultaneously then? That's a bit sad.
That's how the NXP tda998x family works (and surely many other HDMI
transmitters).
So, as I understand from your remarks, the CODEC should be included in
the tda998x driver, and, then, as the simple-card cannot be used, there
should be a Cubox specific audio card driver for the (kirkwood audio +
tda998x HDMI + S/PDIF) set. Am I right?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH] dma: mv_xor: Silence a bunch of LPAE-related warnings
From: Dan Williams @ 2014-02-04 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPcyv4jwwRT_+c-yDycgY0d79nByvAVWH6waFWeodE9yi=7CDg@mail.gmail.com>
On Tue, Feb 4, 2014 at 10:57 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Feb 4, 2014 at 10:30 AM, Olof Johansson <olof@lixom.net> wrote:
>> On Tue, Feb 4, 2014 at 9:00 AM, Jason Cooper <jason@lakedaemon.net> wrote:
>>> On Tue, Feb 04, 2014 at 10:53:29AM +0530, Vinod Koul wrote:
>>>> On Mon, Feb 03, 2014 at 05:13:23PM -0800, Olof Johansson wrote:
>>>> > Enabling some of the mvebu platforms in the multiplatform config for ARM
>>>> > enabled these drivers, which also triggered a bunch of warnings when LPAE
>>>> > is enabled (thus making phys_addr_t 64-bit).
>>>> >
>>>> > Most changes are switching printk formats, but also a bit of changes to what
>>>> > used to be array-based pointer arithmetic that could just be done with the
>>>> > address types instead.
>>>> >
>>>> > The warnings were:
>>>> >
>>>> > drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
>>>> > drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
>>>> > 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
>>>> > drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
>>>> > drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
>>>> > different size [-Wint-to-pointer-cast]
>>>> > drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
>>>> > different size [-Wpointer-to-int-cast]
>>>> > drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
>>>> > drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
>>>> > 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
>>>> > drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
>>>> > 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
>>>> > drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
>>>> > drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
>>>> > 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
>>>> >
>>>> > Signed-off-by: Olof Johansson <olof@lixom.net>
>>>> Acked-by: Vinod Koul <vinod.koul@intel.com>
>>>
>>> Olof, would you like me to queue it up? Or do you want to take it
>>> directly?
>>>
>>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>>
>> I'm confused. I sent the patch to the drivers/dma maintainers and they
>> just acked it without asking me to pick it up myself.
>>
>> Vinod, did you ack it for me to pick it up, or for some other reason?
>> If you don't want to take it through your tree I'll be happy to take
>> it through arm-soc, just looking to clarify.
>>
>> (Jason, I can apply it directly)
>
> Vinod will correct me if I am wrong, but I take his acks to mean "yup,
> take it through your tree". For this specific problem I thought we
> had a comprehensive fix pending from Joe Perches to add a new %pX
> format specifier for dma addresses?
Never mind... that's what you are using. Sorry for the noise.
^ permalink raw reply
* [PATCH] dma: mv_xor: Silence a bunch of LPAE-related warnings
From: Dan Williams @ 2014-02-04 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMg0mrikAp7cDkm9+5=TfR7bj7_f4=JPMxBbabEPwkQs9Q@mail.gmail.com>
On Tue, Feb 4, 2014 at 10:30 AM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Feb 4, 2014 at 9:00 AM, Jason Cooper <jason@lakedaemon.net> wrote:
>> On Tue, Feb 04, 2014 at 10:53:29AM +0530, Vinod Koul wrote:
>>> On Mon, Feb 03, 2014 at 05:13:23PM -0800, Olof Johansson wrote:
>>> > Enabling some of the mvebu platforms in the multiplatform config for ARM
>>> > enabled these drivers, which also triggered a bunch of warnings when LPAE
>>> > is enabled (thus making phys_addr_t 64-bit).
>>> >
>>> > Most changes are switching printk formats, but also a bit of changes to what
>>> > used to be array-based pointer arithmetic that could just be done with the
>>> > address types instead.
>>> >
>>> > The warnings were:
>>> >
>>> > drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
>>> > drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
>>> > 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
>>> > drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
>>> > drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
>>> > different size [-Wint-to-pointer-cast]
>>> > drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
>>> > different size [-Wpointer-to-int-cast]
>>> > drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
>>> > drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
>>> > 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
>>> > drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
>>> > 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
>>> > drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
>>> > drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
>>> > 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
>>> >
>>> > Signed-off-by: Olof Johansson <olof@lixom.net>
>>> Acked-by: Vinod Koul <vinod.koul@intel.com>
>>
>> Olof, would you like me to queue it up? Or do you want to take it
>> directly?
>>
>> Acked-by: Jason Cooper <jason@lakedaemon.net>
>
> I'm confused. I sent the patch to the drivers/dma maintainers and they
> just acked it without asking me to pick it up myself.
>
> Vinod, did you ack it for me to pick it up, or for some other reason?
> If you don't want to take it through your tree I'll be happy to take
> it through arm-soc, just looking to clarify.
>
> (Jason, I can apply it directly)
Vinod will correct me if I am wrong, but I take his acks to mean "yup,
take it through your tree". For this specific problem I thought we
had a comprehensive fix pending from Joe Perches to add a new %pX
format specifier for dma addresses?
^ permalink raw reply
* arm64: kernel panic in paging_init()
From: Mark Salter @ 2014-02-04 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204121452.GI30676@arm.com>
On Tue, 2014-02-04 at 12:14 +0000, Catalin Marinas wrote:
> On Mon, Feb 03, 2014 at 08:50:49PM +0000, Mark Salter wrote:
> > I'm seeing the following panic in paging init. This is on the foundation
> > model with a modified dtb memory node which has a non section-aligned
> > bank:
> > memory at 80000000 {
> > device_type = "memory";
> > reg = <0x00000000 0x80000000 0 0x20000000>,
> > <0x00000000 0xa0300000 0 0x1fd00000>;
> > };
> >
> > I only see this with 64k pagesize configured. What happens is the
> > non section-aligned bank causes alloc_init_pte() to allocate a page
> > for the new pte from the end of the first bank (the failing address
> > 0xfffffe001fff0000 [0x9fff0000 phys]). This should be a valid page
> > since it was mapped during the create_mapping() call for the first
> > memory bank. A flush_tlb_all() added to the end of create_mapping()
> > makes the panic go away so I think the problem is something stale
> > cached before the page with the failing address was mapped.
>
> I think it goes like this:
>
> head.S maps enough memory to get started but using 64K pages rather than
> 512M sections with a single pgd entry and several ptes. This never gets
> to the end of the first block (just up to KERNEL_END).
>
> create_mapping() realises it can do a 512M section mapping, overriding
> the original table pgd entry with a block one. The memblock limit is set
> correctly PGDIR_SIZE but create_mapping, when it replaces the table pgd
> with a block one doesn't do any TLB invalidation.
>
> So I wouldn't do a TLB invalidation all the time but only when the old
> pmd was set. Please give the patch below a try, I only compiled it (I'll
> add some text afterwards):
Yes, that works. Thanks.
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index f557ebbe7013..f8dc7e8fce6f 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -203,10 +203,18 @@ static void __init alloc_init_pmd(pud_t *pud, unsigned long addr,
> do {
> next = pmd_addr_end(addr, end);
> /* try section mapping first */
> - if (((addr | next | phys) & ~SECTION_MASK) == 0)
> + if (((addr | next | phys) & ~SECTION_MASK) == 0) {
> + pmd_t old_pmd =*pmd;
> set_pmd(pmd, __pmd(phys | prot_sect_kernel));
> - else
> + /*
> + * Check for previous table entries created during
> + * boot (__create_page_tables) and flush them.
> + */
> + if (!pmd_none(old_pmd))
> + flush_tlb_all();
> + } else {
> alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys));
> + }
> phys += next - addr;
> } while (pmd++, addr = next, addr != end);
> }
>
>
> Thanks.
>
^ permalink raw reply
* [PATCH 00/11] ARM: shmobile: RSPI RZ and QSPI SoC and board integration
From: Geert Uytterhoeven @ 2014-02-04 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204173733.GI22609@sirena.org.uk>
Hi Mark,
On Tue, Feb 4, 2014 at 6:37 PM, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Feb 04, 2014 at 04:23:54PM +0100, Geert Uytterhoeven wrote:
>> Hi Simon, Magnus,
>>
>> This patch series contains SoC and board integration for
>> 1. RSPI in the r7s72100 aka RZ/A1H SoC on the Genmai reference board,
>> 2. QSPI in the r8a7791 aka R-Car M2 SoC on the Koelsch reference board.
>> It was rebased on top of renesas-devel-v3.14-rc1-20140204.
>
> Can you please stop CCing arch/arm only patch serieses like this to the
> SPI list - they just mean I have to go through patchwork and mark them
> as not applicable.
Sorry, you're right. Only a few of them contained SPI-specific code.
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 00/17] amba: PM fixups for amba bus and some amba drivers
From: Mark Brown @ 2014-02-04 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391529538-21685-1-git-send-email-ulf.hansson@linaro.org>
On Tue, Feb 04, 2014 at 04:58:41PM +0100, Ulf Hansson wrote:
> The fixes for the amba bus needs to be merged prior to the other, thus I think
> it could make sense to merge this complete patchset through Russell's tree,
> if he and the other maintainers think this is okay.
What are the actual dependencies for the SPI bit? AFAICT it's probably
the first patch needs the bus updating?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/98dc336f/attachment-0001.sig>
^ permalink raw reply
* [PATCH resend 1/2] arm64: defer reloading a task's FPSIMD state to userland resume
From: Ard Biesheuvel @ 2014-02-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204172737.GD664@mudshark.cambridge.arm.com>
On 4 February 2014 18:27, Will Deacon <will.deacon@arm.com> wrote:
> Hello,
>
> On Tue, Feb 04, 2014 at 02:49:14PM +0000, Ard Biesheuvel wrote:
>> On 3 February 2014 17:36, Will Deacon <will.deacon@arm.com> wrote:
>> > On Fri, Jan 31, 2014 at 10:13:15AM +0000, Ard Biesheuvel wrote:
>> >> If a task gets scheduled out and back in again and nothing has touched
>> >> its FPSIMD state in the mean time, there is really no reason to reload
>> >> it from memory. Similarly, repeated calls to kernel_neon_begin() and
>> >> kernel_neon_end() will preserve and restore the FPSIMD state every time.
>> >>
>> >> This patch defers the FPSIMD state restore to the last possible moment,
>> >> i.e., right before the task re-enters userland. If a task does not enter
>> >> userland at all (for any reason), the existing FPSIMD state is preserved
>> >> and may be reused by the owning task if it gets scheduled in again on the
>> >> same CPU.
>> >
>> > The one situation I'm unsure of here is how you deal with the saved fpsimd
>> > state potentially being updated by a signal handler or a debugger. In this
>> > case, we probably need to set _TIF_FOREIGN_FPSTATE to force a reload, or are
>> > you handling this some other way?
>> >
>>
>> If I am reading the code correctly, the signal handler is entered
>> using the normal userland resume path, so I don't think it requires
>> special treatment.
>
> It was the exiting of the signal handler that I was worried about, where it
> may have modified the interrupted programs fpsimd state on the stack.
>
Ah, ok, I see what you mean.
I will update the patch so
(a) it only saves the state if _TIF_FOREIGN_FPSTATE is cleared (so we
don't overwrite the task's saved state inadvertently), and
(b) it sets _TIF_FOREIGN_FPSTATE instead of performing the restore
upon return from the signal handler.
>> For the ptrace() case, it should suffice to set the 'last_cpu' field
>> to (u32)-1 to indicate that the FPSIMD context should be reloaded from
>> memory regardless of which CPU the debuggee is restarted on.
>
> Something like that sounds right, but it needs adding/testing.
>
OK, I will add the above and do some more testing.
Cheers,
Ard.
^ permalink raw reply
* [PATCH v4] of: add functions to count number of elements in a property
From: Heiko Stübner @ 2014-02-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204173034.2D899C4050F@trevor.secretlab.ca>
Hi Grant,
On Tuesday, 4. February 2014 17:30:34 Grant Likely wrote:
> On Sat, 18 Jan 2014 09:07:30 -0600, Rob Herring <robherring2@gmail.com>
wrote:
> > On Sat, Jan 18, 2014 at 6:02 AM, Heiko St??bner <heiko@sntech.de> wrote:
> > > The need to know the number of array elements in a property is
> > > a common pattern. To prevent duplication of open-coded implementations
> > > add a helper static function that also centralises strict sanity
> > > checking and DTB format details, as well as a set of wrapper functions
> > > for u8, u16, u32 and u64.
> > >
> > > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > > ---
> >
> > Looks good. Do you plan to convert some users to use this?
>
> I'll take that as an acked-by. Merged, thanks.
before you taking this patch, I was planning on simply sending this as part of
my rockchip-smp series - as I'm currently the only user of it :-) .
This going through your tree is most likely the better way, but now I need it
to somehow make its way into arm-soc too ... I guess some sort of stable
branch arm-soc could pull?
Thanks
Heiko
^ permalink raw reply
* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Arnd Bergmann @ 2014-02-04 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391531796.2538.21.camel@joe-AO722>
On Tuesday 04 February 2014 08:36:36 Joe Perches wrote:
> On Tue, 2014-02-04 at 08:03 +0100, Holger Schurig wrote:
> > Joe, look in linux/arch/arm/include/asm/delay.h. The macro udelay
> > cannot handle large values because of lost-of-precision.
> >
> > IMHO udelay on ARM is broken, because it also cannot work with fast
> > ARM processors (where bogomips >= 3355, which is in sight now). It's
> > just not broken enought that someone did something against it ... so
> > the current kludge is good enought.
>
> Maybe something like this would be better?
>
I actually like the fact that we get link errors for insane 'udelay'
times. In most cases it's a driver bug because we shouldn't keep
the CPU busy for an eternity in the kernel (and call msleep() instead).
For the rare cases where mdelay makes sense, we also want to add
a comment to the code explaining why msleep cannot be used.
Arnd
^ permalink raw reply
* Weird sched_clock behaviour during boot with -rc1
From: Will Deacon @ 2014-02-04 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi guys,
Booting -rc1 on my TC2 gives the following strange entries in the dmesg:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[...]
[ 0.000000] HighMem zone: 329728 pages, LIFO batch:31
[ 7.789662] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
[ 0.000129] PERCPU: Embedded 9 pages/cpu @ee7bd000 s12800 r8192 d15872 u36864
[...]
[ 0.868297] NR_IRQS:16 nr_irqs:16 16
[ 0.886350] Architected cp15 timer(s) running at 24.00MHz (phys).
[ 2915.164998] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 2863311519744ns
[ 0.000002] Switching to timer-based delay loop
[ 0.014249] Console: colour dummy device 80x30
so it looks like something whacky goes on during sched_clock registration.
Sure enough, we're doing a pr_info in-between updating cs.* and calling
update_sched_clock(), so moving the print sorts things out (diff below).
What I can't figure out is why this has suddenly started happening with
3.14. Any ideas?
Cheers,
Will
--->8
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 0abb36464281..f3de5d113afc 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -147,9 +147,6 @@ void __init sched_clock_register(u64 (*read)(void), int bits,
/* calculate the ns resolution of this counter */
res = cyc_to_ns(1ULL, cd.mult, cd.shift);
- pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n",
- bits, r, r_unit, res, wrap);
-
update_sched_clock();
/*
@@ -161,6 +158,9 @@ void __init sched_clock_register(u64 (*read)(void), int bits,
if (irqtime > 0 || (irqtime == -1 && rate >= 1000000))
enable_sched_clock_irqtime();
+ pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps every %lluns\n",
+ bits, r, r_unit, res, wrap);
+
pr_debug("Registered %pF as sched_clock source\n", read);
}
^ permalink raw reply related
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204181514.GA25695@obsidianresearch.com>
On Tuesday 04 February 2014 11:15:14 Jason Gunthorpe wrote:
> On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
>
> > Now I want to integrate the EHCI into my SoC and not waste one
> > of my precious PCIe root ports, so I have to create another PCI
> > domain with its own ECAM compliant config space to put it into.
> > Fortunately SBSA lets me add an arbitrary number of PCI domains,
> > as long as they are all strictly compliant. To software it will
>
> Just to touch on this for others who might be reading..
>
> IMHO any simple SOC that requires multiple domains is *broken*. A
> single domain covers all reasonable needs until you get up to
> mega-scale NUMA systems, encouraging people to design with multiple
> domains only complicates the kernel :(
Well, the way I see it, we already have support for arbitrary
PCI domains in the kernel, and that works fine, so we can just
as well use it. That way we don't have to partition the available
256 buses among the host bridges, and anything that needs a separate
PCI config space can live in its own world. Quite often when you
have multiple PCI hosts, they actually have different ways to
get at the config space and don't even share the same driver.
On x86, any kind of HT/PCI/PCIe/PCI-x bridge is stuffed into a
single domain so they can support OSs that only know the
traditional config space access methods, but I don't see
any real advantage to that for other architectures.
> SOC internal peripherals should all show up in the bus 0 config space
> of the only domain and SOC PCI-E physical ports should show up on bus
> 0 as PCI-PCI bridges. This is all covered in the PCI-E specs regarding
> the root complex.
>
> Generally I would expect the internal peripherals to still be
> internally connected with AXI, but also connected through the ECAM
> space for configuration, control, power management and address
> assignment.
That would of course be very nice from a software perspective,
but I think that is much less likely for any practical
implementation.
> > 2. all address windows are set up by the boot loader, we only
> > need to know the location (IMHO this should be the
> > preferred way to do things regardless of SBSA).
>
> Linux does a full address map re-assignment on boot, IIRC. You need
> more magics to inhibit that if your BAR's and bridge windows don't
> work.
>
> Hot plug is a whole other thing..
I meant the I/O and memory space windows of the host bridge here,
which typically don't get reassigned (except on mvebu). For the
device resources, there is a per-host PCI_REASSIGN_ALL_RSRC
flag and pcibios_assign_all_busses() function that we typically
set on embedded systems where we don't trust the boot loader
to set this up correctly, or at all.
On server systems, I would expect to have the firmware assign
all resources and the kernel to leave them alone. On sparc
and powerpc servers, there is even a third method, which
is to trust firmware to put the correct resources for each
device into DT, overriding what is written in the BAR.
> > it's possible that the designware based ones get point 4 right.
>
> The designware one's also appear to be re-purposed end point cores, so
> their config handling is somewhat bonkers. Tegra got theirs sort of
> close because they re-used knowledge/IP from their x86 south bridges -
> but even then they didn't really implement ECAM properly for an ARM
> environment.
>
> Since config space is where everyone to date has fallen down, I think
> the SBSA would have been wise to list dword by dword what a typical
> ECAM config space should look like.
I absolutely agree.
Arnd
^ permalink raw reply
* [PATCH] dma: mv_xor: Silence a bunch of LPAE-related warnings
From: Olof Johansson @ 2014-02-04 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204170019.GI8533@titan.lakedaemon.net>
On Tue, Feb 4, 2014 at 9:00 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Tue, Feb 04, 2014 at 10:53:29AM +0530, Vinod Koul wrote:
>> On Mon, Feb 03, 2014 at 05:13:23PM -0800, Olof Johansson wrote:
>> > Enabling some of the mvebu platforms in the multiplatform config for ARM
>> > enabled these drivers, which also triggered a bunch of warnings when LPAE
>> > is enabled (thus making phys_addr_t 64-bit).
>> >
>> > Most changes are switching printk formats, but also a bit of changes to what
>> > used to be array-based pointer arithmetic that could just be done with the
>> > address types instead.
>> >
>> > The warnings were:
>> >
>> > drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
>> > drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
>> > 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
>> > drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
>> > drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
>> > different size [-Wint-to-pointer-cast]
>> > drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
>> > different size [-Wpointer-to-int-cast]
>> > drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
>> > drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
>> > 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
>> > drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
>> > 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
>> > drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
>> > drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
>> > 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
>> >
>> > Signed-off-by: Olof Johansson <olof@lixom.net>
>> Acked-by: Vinod Koul <vinod.koul@intel.com>
>
> Olof, would you like me to queue it up? Or do you want to take it
> directly?
>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
I'm confused. I sent the patch to the drivers/dma maintainers and they
just acked it without asking me to pick it up myself.
Vinod, did you ack it for me to pick it up, or for some other reason?
If you don't want to take it through your tree I'll be happy to take
it through arm-soc, just looking to clarify.
(Jason, I can apply it directly)
-Olof
^ permalink raw reply
* [PATCH 2/2] arm64: vdso: update wtm fields for CLOCK_MONOTONIC_COARSE
From: Will Deacon @ 2014-02-04 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391456932-17815-3-git-send-email-nathan_lynch@mentor.com>
On Mon, Feb 03, 2014 at 07:48:52PM +0000, Nathan Lynch wrote:
> Update wall-to-monotonic fields in the VDSO data page
> unconditionally. These are used to service CLOCK_MONOTONIC_COARSE,
> which is not guarded by use_syscall.
>
> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 1/2] arm64: vdso: fix coarse clock handling
From: Will Deacon @ 2014-02-04 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391456932-17815-2-git-send-email-nathan_lynch@mentor.com>
Hi Nathan,
Thanks for the patch!
On Mon, Feb 03, 2014 at 07:48:51PM +0000, Nathan Lynch wrote:
> When __kernel_clock_gettime is called with a CLOCK_MONOTONIC_COARSE or
> CLOCK_REALTIME_COARSE clock id, it returns incorrectly to whatever the
> caller has placed in x2. Fix this by saving x30/LR to x2
> unconditionally.
>
> Also: the tv_nsec field in the result is shifted by the value in x12.
> In the high-precision case x12 is cs_shift from the data page, but
> for coarse clocks x12 is uninitialized. Fix this by setting x12 to 0
> once we know we are dealing with a coarse clock.
How are you managing to see these failures? It's clear that our LTP testing
isn't hitting this path...
> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
> ---
> arch/arm64/kernel/vdso/gettimeofday.S | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
> index f0a6d10b5211..6c37ae4a70c0 100644
> --- a/arch/arm64/kernel/vdso/gettimeofday.S
> +++ b/arch/arm64/kernel/vdso/gettimeofday.S
> @@ -88,13 +88,13 @@ ENDPROC(__kernel_gettimeofday)
> /* int __kernel_clock_gettime(clockid_t clock_id, struct timespec *tp); */
> ENTRY(__kernel_clock_gettime)
> .cfi_startproc
> + mov x2, x30
> + .cfi_register x30, x2
> +
> cmp w0, #CLOCK_REALTIME
> ccmp w0, #CLOCK_MONOTONIC, #0x4, ne
> b.ne 2f
>
> - mov x2, x30
> - .cfi_register x30, x2
> -
Could we avoid the redundant moves by instead doing this around the bl
__do_get_tspec?
> /* Get kernel timespec. */
> adr vdso_data, _vdso_data
> 1: seqcnt_acquire
> @@ -118,6 +118,9 @@ ENTRY(__kernel_clock_gettime)
> ccmp w0, #CLOCK_MONOTONIC_COARSE, #0x4, ne
> b.ne 8f
>
> + /* Set shift to 0 for coarse clocks */
> + mov x12, #0
Worth mentioning that xtime_coarse_nsec is pre-shifted for us, rather than
shifting not actually being required.
Also, rather than shift by #0, can we move the lsl instruction immediately
before the b 4f earlier on?
Will
^ permalink raw reply
* Extending OPP bindings
From: Mark Brown @ 2014-02-04 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F12AE7.904@ti.com>
On Tue, Feb 04, 2014 at 12:01:11PM -0600, Nishanth Menon wrote:
> As long as the key to the data sets are all the same (frequency),
> information in data set #0 is maintained. It would be in our common
> long term interest to maintain the split.
You're assuming that the frequency is a unique key here. That may not
be the case, for example two OPPs might have the same CPU clock
(assuming that's the frequency you're referring to) but different bus
clocking and of course the CPUs or CPU clusters might be individually
scalable (this is common in big.LITTLE designs I think).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/8dd2600f/attachment.sig>
^ permalink raw reply
* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Mark Brown @ 2014-02-04 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJAp7OjCnJ=P9Gi20=D9gybREiSaqd1CaQ0K=9fGbCzU1gTFLw@mail.gmail.com>
On Tue, Feb 04, 2014 at 10:02:14AM -0800, Bjorn Andersson wrote:
> On Tue, Feb 4, 2014 at 3:05 AM, Mark Brown <broonie@kernel.org> wrote:
> > Why not do this at the time we apply the voltage? That would seem to be
> > more robust, doing it in a separate place means that we might update one
> > bit of code and not the other or might change the execution path so that
> > one gets run and the other doesn't.
> I do share your concerns about having this logic mirrored here is
> risky, unfortunately the regulator object is created upon request from
> a consumer; so it is not available when regulator_register() calls
> set_machine_constraints().
Oh, hang on - that's what you mean by a regulator object... I don't
think this fixes the problem you think it does. What is the actual
problem you're trying to fix here? The min_uV and max_uV on a consumer
struct are supposed to be the request from that consumer, they should
only be set if the consumer actually made a request for a voltage range.
> An alternative is to drop the conditional setting of
> REGULATOR_CHANGE_VOLTAGE from of_regulator.c and force the regulator
> drivers to set this flag explicitly; to avoid the difference in
> behavior depending on configuration.
Why would having each individual driver open code things help?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/9e18bf84/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] clk: shmobile: handle multiple parent clocks for cpg clocks
From: William Towle @ 2014-02-04 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391537858-28593-1-git-send-email-william.towle@codethink.co.uk>
The current action on registering the cpg_clocks is to have
them all registered with a single parent clock. This is not
the correct action, as some of the clocks such as the SDHI
and QSPI are actually parented to PLL1 or PLL1/2.
This also requires a change to the device-tree files to make
sure that appropriate parent clocks are assigned.
[ben.dooks at codethink.co.uk: updated patch description]
Signed-off-by: William Towle <william.towle@codethink.co.uk>
Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/clk/shmobile/clk-rcar-gen2.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c b/drivers/clk/shmobile/clk-rcar-gen2.c
index df4a1e6..57bc2e4 100644
--- a/drivers/clk/shmobile/clk-rcar-gen2.c
+++ b/drivers/clk/shmobile/clk-rcar-gen2.c
@@ -185,7 +185,7 @@ static u32 cpg_mode __initdata;
static struct clk * __init
rcar_gen2_cpg_register_clock(struct device_node *np, struct rcar_gen2_cpg *cpg,
const struct cpg_pll_config *config,
- const char *name)
+ const char *name, int index)
{
const struct clk_div_table *table = NULL;
const char *parent_name = "main";
@@ -193,8 +193,13 @@ rcar_gen2_cpg_register_clock(struct device_node *np, struct rcar_gen2_cpg *cpg,
unsigned int mult = 1;
unsigned int div = 1;
+ parent_name = of_clk_get_parent_name(np, index);
+ if (!parent_name) {
+ pr_err("no parent set for clocks array\n");
+ return ERR_PTR(-ENOENT);
+ }
+
if (!strcmp(name, "main")) {
- parent_name = of_clk_get_parent_name(np, 0);
div = config->extal_div;
} else if (!strcmp(name, "pll0")) {
/* PLL0 is a configurable multiplier clock. Register it as a
@@ -279,7 +284,7 @@ static void __init rcar_gen2_cpg_clocks_init(struct device_node *np)
of_property_read_string_index(np, "clock-output-names", i,
&name);
- clk = rcar_gen2_cpg_register_clock(np, cpg, config, name);
+ clk = rcar_gen2_cpg_register_clock(np, cpg, config, name, i);
if (IS_ERR(clk))
pr_err("%s: failed to register %s %s clock (%ld)\n",
__func__, np->name, name, PTR_ERR(clk));
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] ARM: shmobile: r8a7790: specify multiple parents for cpg_clks
From: William Towle @ 2014-02-04 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391537858-28593-1-git-send-email-william.towle@codethink.co.uk>
The current drivers/clk/shmobile/clk-rcar-gen2.c uses the
extal_clk reference for the parent of all the clocks that
it registers. However the lb, qspi, sdh, sd0 and sd1 clocks
are all parented to either pll1 or pll1_div2 which means
that the clock rates are incorrect.
This is part of the fix that corrects the SDHI0 clock
rate error where it reports 1MHz instead of 97.5:
sh_mobile_sdhi ee100000.sd: mmc0 base at 0xee100000 clock rate 1 MHz
Notes:
- May require cross-merge with clk-rcar-gen2.c fix
- Also not clear which clock "z" is to fix it.
[ben.dooks at codethink.co.uk: updated patch description]
Signed-off-by: William Towle <william.towle@codethink.co.uk>
Reviewed-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
arch/arm/boot/dts/r8a7790.dtsi | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ff55c6e..242e6e2 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -446,7 +446,13 @@
compatible = "renesas,r8a7790-cpg-clocks",
"renesas,rcar-gen2-cpg-clocks";
reg = <0 0xe6150000 0 0x1000>;
- clocks = <&extal_clk>;
+ clocks = <&extal_clk>, <&extal_clk>, <&extal_clk>, <&extal_clk>,
+ <&cpg_clocks R8A7790_CLK_PLL1>,
+ <&pll1_div2_clk>,
+ <&cpg_clocks R8A7790_CLK_PLL1>,
+ <&cpg_clocks R8A7790_CLK_PLL1>,
+ <&cpg_clocks R8A7790_CLK_PLL1>
+ /* not known for "z" ...,<> */;
#clock-cells = <1>;
clock-output-names = "main", "pll0", "pll1", "pll3",
"lb", "qspi", "sdh", "sd0", "sd1",
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox