* [PATCH] PCI: MVEBU: Use Device ID and revision from underlying endpoint
From: Thomas Petazzoni @ 2014-02-05 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205165432.GD29860@lunn.ch>
Dear Andrew Lunn,
On Wed, 5 Feb 2014 17:54:32 +0100, Andrew Lunn wrote:
> > > @@ -388,7 +380,8 @@ static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
> > >
> > > bridge->class = PCI_CLASS_BRIDGE_PCI;
> > > bridge->vendor = PCI_VENDOR_ID_MARVELL;
> >
> > This could also have been replaced by:
> >
> > bridge->vendor = mvebu_readl(port, PCIE_DEV_ID_OFF) & 0xff;
>
> O.K, but do we ever expect it not to be PCI_VENDOR_ID_MARVELL on the
> underlying hardware?
No, I don't expect it to be different. Which is why I said it "could"
have been replaced, because I am not sure it is worth doing it.
> > > - bridge->device = MARVELL_EMULATED_PCI_PCI_BRIDGE_ID;
> > > + bridge->device = mvebu_readl(port, PCIE_DEV_ID_OFF) >> 16;
> > > + bridge->revision = mvebu_readl(port, PCIE_DEV_REV_OFF) & 0xff;
> >
> > On Armada 370 and XP, this field is apparently always 0x0, so not very
> > useful. But if it's useful on other mvebu SoCs, that's fine, it's just
> > an informative field anyway.
>
> Humm, that should be the stepping, unless i have made a mistake. The
> code Gregory wrote for mvebu-soc-id.c does:
>
> /* SoC ID */
> soc_dev_id = readl(pci_base + PCIE_DEV_ID_OFF) >> 16;
>
> /* SoC revision */
> soc_rev = readl(pci_base + PCIE_DEV_REV_OFF) & SOC_REV_MASK;
>
> However, the box i'm testing on has stepping 0, so it is hard to test.
> Could you test this in an OpenBlocks AX3 B0, or some other B0 device?
Tested on a B0 now, and the revision returned is indeed 0x2, so you're
correct. Seems like the datasheet that indicates the value is 0x0 is
wrong :)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] PCI: MVEBU: Use Device ID and revision from underlying endpoint
From: Andrew Lunn @ 2014-02-05 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205172110.22507687@skate>
> > @@ -388,7 +380,8 @@ static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
> >
> > bridge->class = PCI_CLASS_BRIDGE_PCI;
> > bridge->vendor = PCI_VENDOR_ID_MARVELL;
>
> This could also have been replaced by:
>
> bridge->vendor = mvebu_readl(port, PCIE_DEV_ID_OFF) & 0xff;
O.K, but do we ever expect it not to be PCI_VENDOR_ID_MARVELL on the
underlying hardware?
>
> > - bridge->device = MARVELL_EMULATED_PCI_PCI_BRIDGE_ID;
> > + bridge->device = mvebu_readl(port, PCIE_DEV_ID_OFF) >> 16;
> > + bridge->revision = mvebu_readl(port, PCIE_DEV_REV_OFF) & 0xff;
>
> On Armada 370 and XP, this field is apparently always 0x0, so not very
> useful. But if it's useful on other mvebu SoCs, that's fine, it's just
> an informative field anyway.
Humm, that should be the stepping, unless i have made a mistake. The
code Gregory wrote for mvebu-soc-id.c does:
/* SoC ID */
soc_dev_id = readl(pci_base + PCIE_DEV_ID_OFF) >> 16;
/* SoC revision */
soc_rev = readl(pci_base + PCIE_DEV_REV_OFF) & SOC_REV_MASK;
However, the box i'm testing on has stepping 0, so it is hard to test.
Could you test this in an OpenBlocks AX3 B0, or some other B0 device?
Thanks
Andrew
^ permalink raw reply
* [PATCHv9 1/4] clk: socfpga: Add a clk-phase property to the "altr, socfpga-gate-clk"
From: Dinh Nguyen @ 2014-02-05 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205160350.22158.37384@quantum>
On Wed, 2014-02-05 at 08:03 -0800, Mike Turquette wrote:
> Quoting Dinh Nguyen (2014-01-15 04:36:52)
> > Hi Mike,
> >
> > Can you apply this to your clk tree?
>
> The patch looks good to me, but I think it depends on your pending pull
> request. Can you add this to that pull request and rebase it to
> 3.14-rc1?
Yes, I will send an updated pull request shortly.
Thanks,
Dinh
>
> Thanks,
> Mike
>
> >
> > Thanks,
> > Dinh
> >
>
^ permalink raw reply
* [PATCH 0/2] Add Ether's PHY IRQ support for Lager/Koelsh boards
From: Sergei Shtylyov @ 2014-02-05 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoRj9EVVZ+0Xx+7cm8s2=iBOfgNUXXR7uS=T-fKBUkczsw@mail.gmail.com>
Hello.
On 02/05/2014 10:25 AM, Magnus Damm wrote:
>> Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
>> 'renesas-devel-v3.14-rc1-20130204' tag. Here we add support for the Ether's PHY
>> IRQ to the R8A7790/Lager and R8A7791/Koelsch boards.
>> [1/2] ARM: shmobile: Lager: pass Ether PHY IRQ
>> [1/2] ARM: shmobile: Koelsch: pass Ether PHY IRQ
> Thanks, looking good!
Not at all, you've already tested these patches, IIRC.
> / magnus
WBR, Sergei
^ permalink raw reply
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Lars-Peter Clausen @ 2014-02-05 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+mB=1L9XFC8h_qW_-K-cv5sYondL_0NiLr=9XCFxwWRjDHn1Q@mail.gmail.com>
On 02/05/2014 05:25 PM, Srikanth Thokala wrote:
> On Fri, Jan 31, 2014 at 12:21 PM, Srikanth Thokala <sthokal@xilinx.com> wrote:
>> Hi Vinod,
>>
>> On Tue, Jan 28, 2014 at 8:43 AM, Vinod Koul <vinod.koul@intel.com> wrote:
>>> On Mon, Jan 27, 2014 at 06:42:36PM +0530, Srikanth Thokala wrote:
>>>> Hi Lars/Vinod,
>>>>>> The question here i think would be waht this device supports? Is the hardware
>>>>>> capable of doing interleaved transfers, then would make sense.
>>>>>
>>>>> The hardware does 2D transfers. The parameters for a transfer are height,
>>>>> width and stride. That's only a subset of what interleaved transfers can be
>>>>> (xt->num_frames must be one for 2d transfers). But if I remember correctly
>>>>> there has been some discussion on this in the past and the result of that
>>>>> discussion was that using interleaved transfers for 2D transfers is
>>>>> preferred over adding a custom API for 2D transfers.
>>>>
>>>> I went through the prep_interleaved_dma API and I see only one descriptor
>>>> is prepared per API call (i.e. per frame). As our IP supports upto 16 frame
>>>> buffers (can be more in future), isn't it less efficient compared to the
>>>> prep_slave_sg where we get a single sg list and can prepare all the descriptors
>>>> (of non-contiguous buffers) in one go? Correct me, if am wrong and let me
>>>> know your opinions.
>>> Well the descriptor maybe one, but that can represent multiple frames, for
>>> example 16 as in your case. Can you read up the documentation of how multiple
>>> frames are passed. Pls see include/linux/dmaengine.h
>>>
>>> /**
>>> * Interleaved Transfer Request
>>> * ----------------------------
>>> * A chunk is collection of contiguous bytes to be transfered.
>>> * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
>>> * ICGs may or maynot change between chunks.
>>> * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
>>> * that when repeated an integral number of times, specifies the transfer.
>>> * A transfer template is specification of a Frame, the number of times
>>> * it is to be repeated and other per-transfer attributes.
>>> *
>>> * Practically, a client driver would have ready a template for each
>>> * type of transfer it is going to need during its lifetime and
>>> * set only 'src_start' and 'dst_start' before submitting the requests.
>>> *
>>> *
>>> * | Frame-1 | Frame-2 | ~ | Frame-'numf' |
>>> * |====....==.===...=...|====....==.===...=...| ~ |====....==.===...=...|
>>> *
>>> * == Chunk size
>>> * ... ICG
>>> */
>>
>> Yes, it can handle multiple frames specified by 'numf' each of size
>> 'frame_size * sgl[0].size'.
>> But, I see it only works if all the frames' memory is contiguous and
>> in this case we
>> can just increment 'src_start' by the total frame size 'numf' number
>> of times to fill in
>> for each HW descriptor (each frame is one HW descriptor). So, there
>> is no issue when the
>> memory is contiguous. If the frames are non contiguous, we have to
>> call this API for each
>> frame (hence for each descriptor), as the src_start for each frame is
>> different. Is it correct?
>>
>> FYI: This hardware has an inbuilt Scatter-Gather engine.
>>
>
> Ping?
If you want to submit multiple frames at once I think you should look at how
the current dmaengine API can be extended to allow that. And also provide an
explanation on how this is superior over submitting them one by one.
- Lars
^ permalink raw reply
* [PATCH 5/5] ARM: tegra: cpuidle: use firmware call for power down
From: Stephen Warren @ 2014-02-05 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKLtC62+bujY4724hMV_6M8Ow0s=6zRn_M87VX4PHQgxA@mail.gmail.com>
On 01/23/2014 12:39 AM, Alexandre Courbot wrote:
> On Thu, Jan 23, 2014 at 5:45 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
>>> Invoke the do_idle() firmware call before suspending a CPU so that the
>>> underlying firmware (if any) can take necessary action.
>>
>>> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c b/arch/arm/mach-tegra/cpuidle-tegra114.c
>>
>>> @@ -45,6 +46,8 @@ static int tegra114_idle_power_down(struct cpuidle_device *dev,
>>>
>>> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
>>>
>>> + call_firmware_op(do_idle);
>>> +
>>> cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
>>>
>>> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
>>
>> Don't you need to have the kernel also *not* do something when entering
>> idle; doesn't the FW op replace some of the register writes that the
>> kernel would otherwise be doing?
>
> It seems like the operation is actually to inform the firmware that we
> are going to suspend the CPU. Downstream kernel also uses it that way.
> But you are right in that we should expect do_idle() to actually
> perform the suspend operation. Maybe a prepare_idle() operation should
> be added to the firmware interface for this purpose?
That sounds like a reasonable change. Is it easy to plumb in?
^ permalink raw reply
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Srikanth Thokala @ 2014-02-05 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+mB=1K8Cqe_c6_ce-fLyphvqcr90mhCjFdZ_d4BV-VkUk-gXw@mail.gmail.com>
On Fri, Jan 31, 2014 at 12:21 PM, Srikanth Thokala <sthokal@xilinx.com> wrote:
> Hi Vinod,
>
> On Tue, Jan 28, 2014 at 8:43 AM, Vinod Koul <vinod.koul@intel.com> wrote:
>> On Mon, Jan 27, 2014 at 06:42:36PM +0530, Srikanth Thokala wrote:
>>> Hi Lars/Vinod,
>>> >> The question here i think would be waht this device supports? Is the hardware
>>> >> capable of doing interleaved transfers, then would make sense.
>>> >
>>> > The hardware does 2D transfers. The parameters for a transfer are height,
>>> > width and stride. That's only a subset of what interleaved transfers can be
>>> > (xt->num_frames must be one for 2d transfers). But if I remember correctly
>>> > there has been some discussion on this in the past and the result of that
>>> > discussion was that using interleaved transfers for 2D transfers is
>>> > preferred over adding a custom API for 2D transfers.
>>>
>>> I went through the prep_interleaved_dma API and I see only one descriptor
>>> is prepared per API call (i.e. per frame). As our IP supports upto 16 frame
>>> buffers (can be more in future), isn't it less efficient compared to the
>>> prep_slave_sg where we get a single sg list and can prepare all the descriptors
>>> (of non-contiguous buffers) in one go? Correct me, if am wrong and let me
>>> know your opinions.
>> Well the descriptor maybe one, but that can represent multiple frames, for
>> example 16 as in your case. Can you read up the documentation of how multiple
>> frames are passed. Pls see include/linux/dmaengine.h
>>
>> /**
>> * Interleaved Transfer Request
>> * ----------------------------
>> * A chunk is collection of contiguous bytes to be transfered.
>> * The gap(in bytes) between two chunks is called inter-chunk-gap(ICG).
>> * ICGs may or maynot change between chunks.
>> * A FRAME is the smallest series of contiguous {chunk,icg} pairs,
>> * that when repeated an integral number of times, specifies the transfer.
>> * A transfer template is specification of a Frame, the number of times
>> * it is to be repeated and other per-transfer attributes.
>> *
>> * Practically, a client driver would have ready a template for each
>> * type of transfer it is going to need during its lifetime and
>> * set only 'src_start' and 'dst_start' before submitting the requests.
>> *
>> *
>> * | Frame-1 | Frame-2 | ~ | Frame-'numf' |
>> * |====....==.===...=...|====....==.===...=...| ~ |====....==.===...=...|
>> *
>> * == Chunk size
>> * ... ICG
>> */
>
> Yes, it can handle multiple frames specified by 'numf' each of size
> 'frame_size * sgl[0].size'.
> But, I see it only works if all the frames' memory is contiguous and
> in this case we
> can just increment 'src_start' by the total frame size 'numf' number
> of times to fill in
> for each HW descriptor (each frame is one HW descriptor). So, there
> is no issue when the
> memory is contiguous. If the frames are non contiguous, we have to
> call this API for each
> frame (hence for each descriptor), as the src_start for each frame is
> different. Is it correct?
>
> FYI: This hardware has an inbuilt Scatter-Gather engine.
>
Ping?
> Srikanth
>
>>
>> --
>> ~Vinod
>> --
>> 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
* [RFC/RFT 1/2] ARM: mm: introduce arch hooks for dma address translation routines
From: Dave Martin @ 2014-02-05 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3284212.inOfNqnVqs@wuerfel>
On Tue, Feb 04, 2014 at 06:04:56PM +0100, Arnd Bergmann wrote:
> On Tuesday 04 February 2014 11:38:32 Santosh Shilimkar wrote:
> > On Tuesday 04 February 2014 11:15 AM, Arnd Bergmann wrote:
> > > On Tuesday 04 February 2014, Santosh Shilimkar wrote:
>
> > > I think this is going into a wrong direction. DMA translation is not
> > > at all a platform-specific thing, but rather bus specific. The most
> > > common scenario is that you have some 64-bit capable buses and some
> > > buses that are limited to 32-bit DMA (or less if you are unfortunate).
> > >
> > I may be wrong but you could have 64 bit bus but 32 bit DMA controllers.
> > That is one of the case I am dealing with.
>
> You are absolutely right. In fact you could have any combination of
> bus widths between a device and the RAM and the correct way to deal
> with this is probably to follow the dma-ranges properties of each
> device in-between and take the intersection (that may not be the
> right term in English, but I think you know what I mean).
>
> > > I guess for the legacy cases (omap1, iop13xx, ks8695), we can
> > > hardcode dma_map_ops for all devices to get this right. For everything
> > > else, I'd suggest defaulting to the arm_dma_ops unless we get
> > > other information from DT. This means we have to create standardized
> > > properties to handle any combination of these:
> > >
> > Thats the case and the $subject series doesn't change that.
> >
> > > 1. DMA is coherent
> > > 2. DMA space is offset from phys space
> > > 3. DMA space is smaller than 32-bit
> > > 4. DMA space is larger than 32-bit
> > > 5. DMA goes through an IOMMU
As you explain above, these are properties of end-to-end paths between
a bus-mastering device and the destination. They aren't properties
of a device, or of a bus.
For example, we can have the following system, which ePAPR can't describe
and wouldn't occur with PCI (or, at least would occur in a transparent
way so that software does not need to understand the difference between
this structure and a simple CPU->devices tree).
C
|
v
I ---+
/ \ \
/ \ \
v v \
A ----> B \
\ v
+---------> D
This follows from the unidirectional and minimalistic nature of ARM SoC
buses (AMBA family, AHB, APB etc. ... and most likely many others too).
To describe A's DMA mappings correctly, the additional links must be
described, even though thay are irrelevant for direct CPU->device
transactions.
> > >
> > > The dma-ranges property can deal with 2-4. Highbank already introduced
> > > a "dma-coherent" flag for 1, and we can decide to generalize that.
> > > I don't know what the state of IOMMU support is, but we have to come
> > > up with something better than what we had on PowerPC, because we now
> > > have to deal with a combination of different IOMMUs in the same system,
> > > whereas the most complex case on PowerPC was some devices all going
> > > through one IOMMU and the other devices being linearly mapped.
> > >
> > Just to be clear, the patch set is not fiddling with dma_ops as such.
> > The dma_ops needs few accessors to convert addresses and these accessors
> > are different on few platforms. And hence needs to be patched.
>
> well, iop13xx is certainly not going to be multiplatform any time
> soon, so we don't have to worry about those. ks8695 won't be multiplatform
> unless I do it I suspect. I don't know about the plans for OMAP1,
> but since only the OHCI device is special there, it would be trivial
> to do a separate dma_map_ops for that device, or to extend arm_dma_ops
> to read the offset in a per-device variable as we probably have to
> do for DT/multiplatform as well.
>
> > We will try to look at "dma-ranges" to see if it can address my case.
> > Thanks for the pointer
dma-ranges does work for simpler cases. In particular, it works where all
bus-mastering children of a bus node can a) access each other using the
address space of the bus node, and b) all have the same view of the rest
of the system (which may be different from the view from outside the bus:
the dma-ranges property on the bus describes the difference).
Sometimes, we may be able to describe an otherwise undescribable situation
by introducing additional fake bus nodes. But if there are cross-links
between devices, this won't always work.
This may not be the common case, but it does happen: we need to decide
whether to describe it propertly, or to describe a fantasy in the DT
and bodge around it elsewhere when it happens.
Similarly, for IOMMU, the ARM SMMU is an independent component which is
not directly associated with a bus: nor is there guaranteed to be a 1:1
correspondence. Simply wedging properties in a bus or device node to say
"this is associated with an IOMMU" is not always going to work: it is
what you flow through on a given device->device path that matters, and
that can vary from path to path.
Santosh, bearing these arguments in mind, do you think that dma-ranges
is natural for your hardware?
The answer may be "yes", but if we're having to twist things to fit,
by having to describe something fake or unreal in DT and/or writing board
specific code to work around it, that motivates coming up with a better
way of describing the hardware in these cases.
I believe Jason also has examples of these issues from the Zynq family
of SoCs, which we were discussing last year.
Cheers
---Dave
^ permalink raw reply
* [PATCH] PCI: MVEBU: Use Device ID and revision from underlying endpoint
From: Thomas Petazzoni @ 2014-02-05 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391597749-29807-1-git-send-email-andrew@lunn.ch>
Dear Andrew Lunn,
On Wed, 5 Feb 2014 11:55:49 +0100, Andrew Lunn wrote:
> Marvell SoCs place the SoC number into the PCIe endpoint device ID.
> The SoC stepping is placed into the PCIe revision. The old plat-orion
> PCIe driver allowed this information to be seen in user space with a
> simple lspci command.
>
> The new driver places a virtual PCI-PCI bridge on top of these
> endpoints. It has its own hard coded PCI device ID. Thus it is no
> longer possible to see what the SoC is using lspci.
>
> When initializing the PCI-PCI bridge, set its device ID and revision
> from the underlying endpoint, thus restoring this functionality.
> Debian would like to use this in order to aid installing the correct
> DTB file.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/pci/host/pci-mvebu.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
I have two comments below, though.
>
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 13478ecd4113..0e79665afd44 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -60,14 +60,6 @@
> #define PCIE_DEBUG_CTRL 0x1a60
> #define PCIE_DEBUG_SOFT_RESET BIT(20)
>
> -/*
> - * This product ID is registered by Marvell, and used when the Marvell
> - * SoC is not the root complex, but an endpoint on the PCIe bus. It is
> - * therefore safe to re-use this PCI ID for our emulated PCI-to-PCI
> - * bridge.
> - */
> -#define MARVELL_EMULATED_PCI_PCI_BRIDGE_ID 0x7846
> -
> /* PCI configuration space of a PCI-to-PCI bridge */
> struct mvebu_sw_pci_bridge {
> u16 vendor;
> @@ -388,7 +380,8 @@ static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
>
> bridge->class = PCI_CLASS_BRIDGE_PCI;
> bridge->vendor = PCI_VENDOR_ID_MARVELL;
This could also have been replaced by:
bridge->vendor = mvebu_readl(port, PCIE_DEV_ID_OFF) & 0xff;
> - bridge->device = MARVELL_EMULATED_PCI_PCI_BRIDGE_ID;
> + bridge->device = mvebu_readl(port, PCIE_DEV_ID_OFF) >> 16;
> + bridge->revision = mvebu_readl(port, PCIE_DEV_REV_OFF) & 0xff;
On Armada 370 and XP, this field is apparently always 0x0, so not very
useful. But if it's useful on other mvebu SoCs, that's fine, it's just
an informative field anyway.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Matt Porter @ 2014-02-05 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1402051028350.1312-100000@iolanthe.rowland.org>
On Wed, Feb 05, 2014 at 10:30:29AM -0500, Alan Stern wrote:
> On Wed, 5 Feb 2014, Matt Porter wrote:
>
> > On Wed, Feb 05, 2014 at 10:08:18AM +0100, Wolfram Sang wrote:
> > > On Tue, Feb 04, 2014 at 07:19:07AM -0500, Matt Porter wrote:
> > >
> > > > Voltage regulators are needed very early due to deferred probe
> > > > being incompatible with built-in USB gadget drivers.
> > >
> > > What does it need to fix those instead?
> >
> > [added Alan/Felipe for more insight]
> >
> > Discussion on that topic came about from this submission:
> > http://www.spinics.net/lists/linux-usb/msg94217.html
> >
> > End of it is:
> > http://www.spinics.net/lists/linux-usb/msg94731.html
> >
> > We can either add to the many drivers that already do subsys_initcall()
> > for similar reasons...or I can drop this from the series and add gadget
> > probe ordering to my TODO list.
> >
> > In short, it can't be a late_initcall() hack like the original post and
> > really could be solved by converting to a real bus (and letting
> > deferred probe do its job)..but Alan voiced concerns about that.
>
> Don't worry too much about what I said. If adding a "gadget" bus will
> solve the problem in an appropriate way, and if nobody else objects
> (particularly Felipe, who is on vacation now), then go for it.
Ok, I'll take a look at what can be done and restart the conversation
when Felipe returns.
Wolfram: given this, as I mentioned, I'll simply drop this patch from
the series and work around it for now. This will probably make Lee and
Mark happy to not see subsys_initcall() in the MFD/regulator drivers as
well.
-Matt
^ permalink raw reply
* [PATCH v5 2/3] clocksource: keystone: add bindings for keystone timer
From: Ivan Khoronzhuk @ 2014-02-05 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKVc2fdg1Q+TH6ro9kpJmUYyHw8FCwhORfm2_oj6GYM2Q@mail.gmail.com>
On 02/05/2014 04:39 PM, Rob Herring wrote:
> On Wed, Feb 5, 2014 at 7:47 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote:
>> This patch provides bindings for the 64-bit timer in the KeyStone
>> architecture devices. The timer can be configured as a general-purpose 64-bit
>> timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
>> timers, each half can operate in conjunction (chain mode) or independently
>> (unchained mode) of each other.
> This is software configurable or h/w design time configurations?
>
> Rob
>
This is h/w design time configurations
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCHv9 1/4] clk: socfpga: Add a clk-phase property to the "altr, socfpga-gate-clk"
From: Mike Turquette @ 2014-02-05 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D680E4.6090608@gmail.com>
Quoting Dinh Nguyen (2014-01-15 04:36:52)
> Hi Mike,
>
> Can you apply this to your clk tree?
The patch looks good to me, but I think it depends on your pending pull
request. Can you add this to that pull request and rebase it to
3.14-rc1?
Thanks,
Mike
>
> Thanks,
> Dinh
>
^ permalink raw reply
* [GIT PULLv3] clk: socfpga: Clean-ups for 3.14
From: Mike Turquette @ 2014-02-05 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389788321-11260-1-git-send-email-dinguyen@altera.com>
Quoting dinguyen at altera.com (2014-01-15 04:18:41)
> Hi Mike,
>
> Please pull in these patches that cleans up the SOCFPGA clock driver. This is
> v3 of the pull request that includes 3 patches from Steffen Trumtrar. I have
> squashed the compiler error fix patch into the patch that introduced the error.
> Bisectability should now be fix.
Thanks for the rework. Can you rebase this onto 3.14-rc1 and send it
again?
Regards,
Mike
>
> Thanks,
> Dinh
>
> The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
>
> Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
>
> are available in the git repository at:
>
> git://git.rocketboards.org/linux-socfpga-next.git tags/socfpga-clk-for-3.14_v3
>
> for you to fetch changes up to 5710d11ab5230dce43e5edc09d9d5506d3d49663:
>
> clk: socfpga: split clk code (2014-01-15 05:56:07 -0600)
>
> ----------------------------------------------------------------
> v3: SOCFPGA clk cleanups for 3.14
>
> ----------------------------------------------------------------
> Dinh Nguyen (3):
> clk: socfpga: Map the clk manager base address in the clock driver
> clk: socfpga: Look for the GPIO_DB_CLK by its offset
> clk: socfpga: Remove socfpga_init_clocks
>
> Steffen Trumtrar (3):
> clk: socfpga: remove unused field
> clk: socfpga: fix define typo
> clk: socfpga: split clk code
>
> arch/arm/mach-socfpga/socfpga.c | 5 -
> drivers/clk/socfpga/Makefile | 3 +
> drivers/clk/socfpga/clk-gate.c | 195 ++++++++++++++++++++++
> drivers/clk/socfpga/clk-periph.c | 94 +++++++++++
> drivers/clk/socfpga/clk-pll.c | 111 +++++++++++++
> drivers/clk/socfpga/clk.c | 328 ++------------------------------------
> drivers/clk/socfpga/clk.h | 57 +++++++
> 7 files changed, 472 insertions(+), 321 deletions(-)
> create mode 100644 drivers/clk/socfpga/clk-gate.c
> create mode 100644 drivers/clk/socfpga/clk-periph.c
> create mode 100644 drivers/clk/socfpga/clk-pll.c
> create mode 100644 drivers/clk/socfpga/clk.h
>
^ permalink raw reply
* [PATCH] ARM: zynq: Move of_clk_init from clock driver
From: Michal Simek @ 2014-02-05 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e03e3ec-2fc7-40fc-a2cc-4a6c64379559@CO1EHSMHS025.ehs.local>
On 02/05/2014 04:41 PM, S?ren Brinkmann wrote:
> On Wed, Feb 05, 2014 at 03:56:37PM +0100, Michal Simek wrote:
>> Move of_clk_init() from clock driver to enable
>> options not to use zynq clock driver.
>> Use for example fixed clock setting.
> What is the use-case? Zynq w/o this driver makes no sense, IMHO. And
> even if you wanna fake clocks, why would this driver prevent it? Just
> replace all the input clocks with different ones and don't care about
> what this driver does?
One case is supervisor for example.
>
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>> Based on http://www.spinics.net/lists/arm-kernel/msg298287.html
>> series
>>
>> ---
>> arch/arm/mach-zynq/common.c | 1 +
>> drivers/clk/zynq/clkc.c | 2 --
>> 2 files changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
>> index 93ea19b..8df35f3 100644
>> --- a/arch/arm/mach-zynq/common.c
>> +++ b/arch/arm/mach-zynq/common.c
>> @@ -68,6 +68,7 @@ static void __init zynq_timer_init(void)
>> zynq_early_slcr_init();
>>
>> zynq_clock_init();
>> + of_clk_init(NULL);
> Now you have two clock init functions...
If I have two clock init functions now, what I had before?
You were calling of_clk_init from zynq_clock_init.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140205/a4179396/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/6] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: Hans de Goede @ 2014-02-05 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1676482.sbjAhaSLaV@dizzy-6.o2s.ch>
Hi David,
On 02/05/2014 02:01 PM, David Lanzend?rfer wrote:
> Hi Maxime
>> I have four comments here:
>> - Read Documentation/SubmittingPatches, especially Section 5 and 12
>> (hints, you forgot the clock maintainers for your clock patches
>> and you didn't put any signed-off-by tags)
> Oops. I added signed-offs now
>> - You ignored pretty much all the comments that were made during the
>> review of the first version. Go through
> Uh? I just fixed the commits and squashed them together for easier handling.
> I'm even using mmc_of_parse now...
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219339.
>> html and address the comments that were made.
>> - Each of your patches should compile. Fix the order of your
>> patches.
> Done.
>> - Submit a v3, with the changes you made. Otherwise we have no way
>> of knowing what have been fixed and what didn't
> Too many patches would be bloaty.
> That's why I've squashed them into small and corrected patches.
The squashing is fine, what Maxime means is that normally you would include
a changelog in the coverletter (the [patch 0/x] mail) documenting changes
done since the previous posting of the patchset, so for v3 that would have been
something like:
Changes since v1:
-use mmc_of_parse instead of diy dt parsing
-add nodes for all mmc controller to the dtsi files, including sofar unused
controllers
Changes since v2:
-Add missing Signed-off-by tags
-stop using __raw_readl / __raw_writel so that barriers are properly used
I've probably forgotten a few things, it would be good if you could send
a reply to the:
"[PATCH v3 0/7] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs"
mail with the above changelog, amended with whatever I've forgotten to add
to the above changelog
Thanks & Regards,
Hans
^ permalink raw reply
* [PATCH v4] gpio: davinci: reuse for keystone soc
From: Grygorii Strashko @ 2014-02-05 15:47 UTC (permalink / raw)
To: linux-arm-kernel
The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.
Hence, reuse Davinci GPIO driver for Keystone taking into
account that Keystone contains ARM GIC IRQ controller which
is implemented using IRQ Chip.
Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
Changes in v4:
- rebased on top of v3.14 +
[patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
.../devicetree/bindings/gpio/gpio-davinci.txt | 4 +-
drivers/gpio/gpio-davinci.c | 48 ++++++++++++++++----
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings
Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
- reg: Physical base address of the controller and the size of memory mapped
registers.
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index b0e98d3..5c97f61 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -37,6 +37,8 @@ struct davinci_gpio_regs {
u32 intstat;
};
+typedef struct irq_chip *(*gpio_get_irq_chip_cb_t)(unsigned int irq);
+
#define BINTEN 0x8 /* GPIO Interrupt Per-Bank Enable Register */
#define chip2controller(chip) \
@@ -413,6 +415,26 @@ static const struct irq_domain_ops davinci_gpio_irq_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
+static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip_type gpio_unbanked;
+
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+
+ return &gpio_unbanked.chip;
+};
+
+static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip gpio_unbanked;
+
+ gpio_unbanked = *irq_get_chip(irq);
+ return &gpio_unbanked;
+};
+
+static const struct of_device_id davinci_gpio_ids[];
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()
@@ -434,6 +456,18 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
struct davinci_gpio_regs __iomem *g;
struct irq_domain *irq_domain = NULL;
int irq;
+ const struct of_device_id *match;
+ struct irq_chip *irq_chip;
+ gpio_get_irq_chip_cb_t gpio_get_irq_chip;
+
+ /*
+ * Use davinci_gpio_get_irq_chip by default to handle non DT cases
+ */
+ gpio_get_irq_chip = davinci_gpio_get_irq_chip;
+ match = of_match_device(of_match_ptr(davinci_gpio_ids),
+ dev);
+ if (match)
+ gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;
ngpio = pdata->ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -490,8 +524,6 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (pdata->gpio_unbanked) {
- static struct irq_chip_type gpio_unbanked;
-
/* pass "bank 0" GPIO IRQs to AINTC */
chips[0].chip.to_irq = gpio_to_irq_unbanked;
chips[0].gpio_irq = bank_irq;
@@ -500,10 +532,9 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
/* AINTC handles mask/unmask; GPIO handles triggering */
irq = bank_irq;
- gpio_unbanked = *container_of(irq_get_chip(irq),
- struct irq_chip_type, chip);
- gpio_unbanked.chip.name = "GPIO-AINTC";
- gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
+ irq_chip = gpio_get_irq_chip(irq);
+ irq_chip->name = "GPIO-AINTC";
+ irq_chip->irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
g = gpio2regs(0);
@@ -512,7 +543,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < pdata->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_unbanked.chip);
+ irq_set_chip(irq, irq_chip);
irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
@@ -555,7 +586,8 @@ done:
#if IS_ENABLED(CONFIG_OF)
static const struct of_device_id davinci_gpio_ids[] = {
- { .compatible = "ti,dm6441-gpio", },
+ { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
+ { .compatible = "ti,dm6441-gpio", davinci_gpio_get_irq_chip},
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, davinci_gpio_ids);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] mvebu : pcie: dt: potential issue in range parsing
From: Thomas Petazzoni @ 2014-02-05 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389349431-7997-1-git-send-email-jjhiblot@traphandler.com>
Dear Jean-Jacques Hiblot,
On Fri, 10 Jan 2014 11:23:51 +0100, Jean-Jacques Hiblot wrote:
> The second parameter of of_read_number is not the index, but a size.
> As it happens, in this case it may work just fine because of the the conversion
> to u32 and the favorable endianness on this architecture.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> drivers/pci/host/pci-mvebu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index c269e43..877e8ce 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -768,7 +768,7 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
>
> for (i = 0; i < nranges; i++) {
> u32 flags = of_read_number(range, 1);
> - u32 slot = of_read_number(range, 2);
> + u32 slot = of_read_number(range + 1, 1);
> u64 cpuaddr = of_read_number(range + na, pna);
> unsigned long rtype;
>
Sorry for the long delay, and thanks for the fix!
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(on Armada 370, with PCIe cards plugged in)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: zynq: Move of_clk_init from clock driver
From: Sören Brinkmann @ 2014-02-05 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <572af6e4eaaaa1c74ea62364f8fa7ac5834cc754.1391612175.git.michal.simek@xilinx.com>
On Wed, Feb 05, 2014 at 03:56:37PM +0100, Michal Simek wrote:
> Move of_clk_init() from clock driver to enable
> options not to use zynq clock driver.
> Use for example fixed clock setting.
What is the use-case? Zynq w/o this driver makes no sense, IMHO. And
even if you wanna fake clocks, why would this driver prevent it? Just
replace all the input clocks with different ones and don't care about
what this driver does?
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> Based on http://www.spinics.net/lists/arm-kernel/msg298287.html
> series
>
> ---
> arch/arm/mach-zynq/common.c | 1 +
> drivers/clk/zynq/clkc.c | 2 --
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
> index 93ea19b..8df35f3 100644
> --- a/arch/arm/mach-zynq/common.c
> +++ b/arch/arm/mach-zynq/common.c
> @@ -68,6 +68,7 @@ static void __init zynq_timer_init(void)
> zynq_early_slcr_init();
>
> zynq_clock_init();
> + of_clk_init(NULL);
Now you have two clock init functions...
S?ren
^ permalink raw reply
* [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Alan Stern @ 2014-02-05 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205151826.GC22153@beef>
On Wed, 5 Feb 2014, Matt Porter wrote:
> On Wed, Feb 05, 2014 at 10:08:18AM +0100, Wolfram Sang wrote:
> > On Tue, Feb 04, 2014 at 07:19:07AM -0500, Matt Porter wrote:
> >
> > > Voltage regulators are needed very early due to deferred probe
> > > being incompatible with built-in USB gadget drivers.
> >
> > What does it need to fix those instead?
>
> [added Alan/Felipe for more insight]
>
> Discussion on that topic came about from this submission:
> http://www.spinics.net/lists/linux-usb/msg94217.html
>
> End of it is:
> http://www.spinics.net/lists/linux-usb/msg94731.html
>
> We can either add to the many drivers that already do subsys_initcall()
> for similar reasons...or I can drop this from the series and add gadget
> probe ordering to my TODO list.
>
> In short, it can't be a late_initcall() hack like the original post and
> really could be solved by converting to a real bus (and letting
> deferred probe do its job)..but Alan voiced concerns about that.
Don't worry too much about what I said. If adding a "gadget" bus will
solve the problem in an appropriate way, and if nobody else objects
(particularly Felipe, who is on vacation now), then go for it.
Alan Stern
^ permalink raw reply
* [PATCH RESEND] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
From: Matt Porter @ 2014-02-05 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F25122.50400@ti.com>
On Wed, Feb 05, 2014 at 08:56:34AM -0600, Nishanth Menon wrote:
> On 02/05/2014 08:38 AM, Matt Porter wrote:
> > On Wed, Feb 05, 2014 at 08:09:16AM -0600, Nishanth Menon wrote:
> >> On 02/05/2014 07:48 AM, Jack Mitchell wrote:
> [...]
> >>> + * --- a/arch/arm/boot/dts/am335x-boneblack.dts
> >>> + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> >>> + * @@ -73,6 +74,6 @@
> >>> + * pinctrl-names = "default", "off";
> >>> + * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
> >>> + * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
> >>> + * - status = "okay";
> >>> + * + status = "disabled";
> >>> + * };
> >>> + * };
> >>> + */
> >>> +
> >> how about making the audio-cape-reva.dts which includes and overrides
> >> parameters of boneblack.dts?
> >
> > Yeah, that might be a little cleaner. Black makes things unfortunately
> > messy for these capes that were really intended for BBW :(
>
> yes indeed - we might have to live with more dts in such a case.
> >
> >> Further, I see a bunch of capes in
> >> http://elinux.org/Beagleboard:BeagleBone_Capes
> >>
> >> Assuming that we dont want to discuss capebus all over again, is this
> >> the approach we'd like to consider in the interim?
> >
> > I think that's a fair assumption...I'll note that there is work slowly
> > in progress on a very minimal implementation DT overlays upstream. But
> > that doesn't exist. We are simply interested in a sane way to use the
> > hardware we own in mainline and this approach makes it possible to build
> > a kernel+dtb from mainline that works for this configuration. If
> > there's a better way to support this hardware *today* let's discuss it.
> > One of the big benefits to having this upstream is that it's no longer
> > out of sight out of mind. It should be managed alongside all the other
> > am335x dts data.
> >
> > Incidentally, I'm hoping to contribute a similar patch for the DVI cape
> > I have here.
>
> If I am not mistaken, the capes are stackable (within reason), and are
> not exactly hotpluggable.. question pops up as to how do we handle
> multiple cape descriptions on the same board without having the user
> to create custom dts which includes each relevant cape dts he has on
> his/her bone? I wonder(without proper research, just thinking aloud)
> if u-boot can do some sort of merge of dtbs - assuming ofcourse eeprom
> data is used to detect the capes plugged on board?
Well covered in the original discussion. gcl summarizes options in
https://lkml.org/lkml/2012/11/5/615
Since then, the basic overlay support for the kernel is pretty much a
done deal. It has a wide variety of users (FPGA folks) beyond this board
specific case. The problem you describe about resource management and
conflicts would probably need to be built on top of that. Pantelis
had a PoC implementation with capebus/not-a-capebus but that's not part
of what is being upstreamed. I'm not sure if there's anybody with enough
time out of the Beagleboard community to upstream a resource manager on
top of the basic overlay support that's in progress. However, it might
make a nice GSoC2014 project. :)
-Matt
^ permalink raw reply
* [PATCH v2 0/5] Split mach-msm into legacy and mach-qcom (multiplatform)
From: Kumar Gala @ 2014-02-05 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205004732.GB12815@codeaurora.org>
On Feb 4, 2014, at 6:47 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 02/04, Kumar Gala wrote:
>> This is the splits the Qualcomm MSM platform into legacy support that we will
>> not try and convert to multiplatform and multiplatform support.
>>
>> - k
>>
>> Changes from v1:
>> * Added patch to remove hotplug.c
>> * Added patch to rename msm_ to qcom_
>> * Changes the Kconfig to drop CPU_V7
>> * used wfi() in cpu_die function
>> * Added git tree to MAINTAINERS file
>
> What's the plan for this series combined with my SMP series? It
> looks like this isn't based on those patches, so we'll have some
> conflicts with the msm to qcom rename but it should be fairly
> minor.
I?ve rebased the smp patch series on top of this set, so will post the new version short (hopefully once we close on these).
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Matt Porter @ 2014-02-05 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205090818.GA2614@katana>
On Wed, Feb 05, 2014 at 10:08:18AM +0100, Wolfram Sang wrote:
> On Tue, Feb 04, 2014 at 07:19:07AM -0500, Matt Porter wrote:
>
> > Voltage regulators are needed very early due to deferred probe
> > being incompatible with built-in USB gadget drivers.
>
> What does it need to fix those instead?
[added Alan/Felipe for more insight]
Discussion on that topic came about from this submission:
http://www.spinics.net/lists/linux-usb/msg94217.html
End of it is:
http://www.spinics.net/lists/linux-usb/msg94731.html
We can either add to the many drivers that already do subsys_initcall()
for similar reasons...or I can drop this from the series and add gadget
probe ordering to my TODO list.
In short, it can't be a late_initcall() hack like the original post and
really could be solved by converting to a real bus (and letting
deferred probe do its job)..but Alan voiced concerns about that.
-Matt
^ permalink raw reply
* [PATCH] clk: add strict of_clk_init dependency check
From: Boris BREZILLON @ 2014-02-05 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F25324.90108@free-electrons.com>
On 05/02/2014 16:05, Gregory CLEMENT wrote:
> On 05/02/2014 15:48, Gregory CLEMENT wrote:
>> Hi Boris,
>>
>> On 05/02/2014 10:48, Boris BREZILLON wrote:
>>> The parent dependency check is only available on the first parent of a given
>>> clk.
>>>
>>> Add support for strict dependency check: all parents of a given clk must be
>>> initialized.
>>>
>>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>>> ---
>>>
>>> Hello Gregory,
>>>
>>> This patch adds support for strict check on clk dependencies (check if all
>>> parents specified by an DT clk node are initialized).
>>>
>>> I'm not sure this is what you were expecting (maybe testing the first parent
>>> is what you really want), so please feel free to tell me if I'm wrong.
>>>
>>> Best Regards,
>>>
>>> Boris
>>>
>>> drivers/clk/clk.c | 27 +++++++++++++++++++++------
>>> 1 file changed, 21 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>>> index beb0f8b..6849769 100644
>>> --- a/drivers/clk/clk.c
>>> +++ b/drivers/clk/clk.c
>>> @@ -2543,22 +2543,37 @@ static int parent_ready(struct device_node *np)
>>> {
>>> struct of_phandle_args clkspec;
>>> struct of_clk_provider *provider;
>>> + int num_parents;
>>> + bool found;
>>> + int i;
>>>
>>> /*
>>> * If there is no clock parent, no need to wait for them, then
>>> * we can consider their absence as being ready
>>> */
>>> - if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", 0,
>>> - &clkspec))
>>> + num_parents = of_count_phandle_with_args(np, "clocks", "#clock-cells");
>>> + if (num_parents <= 0)
>>> return 1;
>>>
>>> - /* Check if we have such a provider in our array */
>>> - list_for_each_entry(provider, &of_clk_providers, link) {
>>> - if (provider->node == clkspec.np)
>>> + for (i = 0; i < num_parents; i++) {
>>> + if (of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
>>> + &clkspec))
>>> return 1;
>>> +
>>> + /* Check if we have such a provider in our array */
>>> + found = false;
>>> + list_for_each_entry(provider, &of_clk_providers, link) {
>>> + if (provider->node == clkspec.np) {
>>> + found = true;
>>> + break;
>> Hum this means that as soon as you have one parent then you consider it
>> as ready. It is better of what I have done because I only test the 1st
>> parent. However I wondered if we should go further by ensuring all the
>> parents are ready.
> My bad, I read the code too fast. Your code already checks that all the
> parents are ready.
>
> So if you agree I will merge your code with mine and send a new patch.
That's fine by me.
>
>> If I am right, there is more than one parent only for the muxer. In this
>> case is it really expected that all the parent are ready?
>>
>> Thanks,
>>
>> Gregory
>>
>>> + }
>>> + }
>>> +
>>> + if (!found)
>>> + return 0;
>>> }
>>>
>>> - return 0;
>>> + return 1;
>>> }
>>>
>>> /**
>>>
>>
>
^ permalink raw reply
* [PATCH] ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
From: Illia Smyrnov @ 2014-02-05 15:06 UTC (permalink / raw)
To: linux-arm-kernel
Commit 313a76e (ARM: OMAP2+: hwmod: Fix SOFTRESET logic) introduced
softreset bit cleaning right after set one. It is caused L3 error for
OMAP4 ISS because ISS register write occurs when ISS reset process is in
progress. Avoid this situation by cleaning softreset bit later, when reset
process is successfully finished.
Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 42d8188..1f33f5d 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1947,29 +1947,31 @@ static int _ocp_softreset(struct omap_hwmod *oh)
goto dis_opt_clks;
_write_sysconfig(v, oh);
- ret = _clear_softreset(oh, &v);
- if (ret)
- goto dis_opt_clks;
-
- _write_sysconfig(v, oh);
if (oh->class->sysc->srst_udelay)
udelay(oh->class->sysc->srst_udelay);
c = _wait_softreset_complete(oh);
- if (c == MAX_MODULE_SOFTRESET_WAIT)
+ if (c == MAX_MODULE_SOFTRESET_WAIT) {
pr_warning("omap_hwmod: %s: softreset failed (waited %d usec)\n",
oh->name, MAX_MODULE_SOFTRESET_WAIT);
- else
+ ret = -ETIMEDOUT;
+ goto dis_opt_clks;
+ } else {
pr_debug("omap_hwmod: %s: softreset in %d usec\n", oh->name, c);
+ }
+
+ ret = _clear_softreset(oh, &v);
+ if (ret)
+ goto dis_opt_clks;
+
+ _write_sysconfig(v, oh);
/*
* XXX add _HWMOD_STATE_WEDGED for modules that don't come back from
* _wait_target_ready() or _reset()
*/
- ret = (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : 0;
-
dis_opt_clks:
if (oh->flags & HWMOD_CONTROL_OPT_CLKS_IN_RESET)
_disable_optional_clocks(oh);
--
1.8.5.3
^ permalink raw reply related
* [ath9k-devel] [PATCH 1/3] ath9k: Fix build error on ARM
From: Joe Perches @ 2014-02-05 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140205142126.GR26684@n2100.arm.linux.org.uk>
On Wed, 2014-02-05 at 14:21 +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 05, 2014 at 06:03:13AM -0800, Joe Perches wrote:
> > On Wed, 2014-02-05 at 13:39 +0000, Russell King - ARM Linux wrote:
> > > On Wed, Feb 05, 2014 at 05:04:54AM -0800, Joe Perches wrote:
> > > > On Wed, 2014-02-05 at 12:41 +0000, Russell King - ARM Linux wrote:
> > > > > On Wed, Feb 05, 2014 at 04:32:46AM -0800, Joe Perches wrote:
> > > > > > Apparently, people just convert stupidly large udelay()s
> > > > > > to mdelay and not be bothered.
> > > > >
> > > > > And that's the correct answer. Having udelay(10000) rather than mdelay(10)
> > > > > is a sign that they weren't paying that much attention when writing the
> > > > > code.
> > > >
> > > > Not really.
> > []
> > > > It's not so much not paying attention as not
> > > > knowing ARM is broken for large udelay().
> > >
> > > And now read my suggestion about how to avoid the "not knowing" problem. :)
> >
> > I'd read it already. I didn't and don't disagree.
>
> Please explain /why/ you don't agree.
Please reread what I wrote.
We agree a lot more than you seem to think.
> > I still think adding a #warning on large static udelay()s
> > would be sensible. Maybe adding another option like
> > #define UDELAY_TOO_BIG_I_KNOW_ALREADY_DONT_BOTHER_ME
> > guard to avoid seeing the #warning when there's no other
> > option.
>
> How does that help? It's /not/ a warning situation - if you ask for
> udelay(10000) on ARM, you will /not/ get a 10ms delay. You'll instead
> get something much shorter because the arithmetic will overflow.
> Now, you could argue that maybe ARM's udelay() implementation should
> know about this and implement a loop around the underlying udelay()
> implementation to achieve it,
I suggested something like that was possible.
> and I might agree with you - but I
> don't for one very simple reason: we /already/ have such an
> implementation. It's called mdelay():
I think mdelay should be for the case where the range
is too big for a udelay. I think arm's 11 bit range
is unfortunately small.
I think we agree be nice to get a generic compiler
#warning when a __builtin_constant_p value is too large
and a ratelimited dmesg/warning for the runtime case.
^ 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