* Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
From: Ohad Ben-Cohen @ 2011-10-10 22:49 UTC (permalink / raw)
To: Roedel, Joerg
Cc: iommu@lists.linux-foundation.org, linux-omap@vger.kernel.org,
Laurent Pinchart, David Woodhouse,
linux-arm-kernel@lists.infradead.org, David Brown, Arnd Bergmann,
linux-kernel@vger.kernel.org, Stepan Moskovchenko,
kvm@vger.kernel.org, Hiroshi Doyu
In-Reply-To: <20111010153609.GB2138@amd.com>
Hi Joerg,
On Mon, Oct 10, 2011 at 5:36 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> The master branch is best to base your patches on for generic work.
Done. I've revised the patches and attached the main one
below; please tell me if it looks ok, and then I'll resubmit the
entire patch set.
Thanks,
Ohad.
commit bf1d730b5f4f7631becfcd4be52693d85bfea36b
Author: Ohad Ben-Cohen <ohad@wizery.com>
Date: Mon Oct 10 23:50:55 2011 +0200
iommu/core: split mapping to page sizes as supported by the hardware
When mapping a memory region, split it to page sizes as supported
by the iommu hardware. Always prefer bigger pages, when possible,
in order to reduce the TLB pressure.
The logic to do that is now added to the IOMMU core, so neither the iommu
drivers themselves nor users of the IOMMU API have to duplicate it.
This allows a more lenient granularity of mappings; traditionally the
IOMMU API took 'order' (of a page) as a mapping size, and directly let
the low level iommu drivers handle the mapping, but now that the IOMMU
core can split arbitrary memory regions into pages, we can remove this
limitation, so users don't have to split those regions by themselves.
Currently the supported page sizes are advertised once and they then
remain static. That works well for OMAP and MSM but it would probably
not fly well with intel's hardware, where the page size capabilities
seem to have the potential to be different between several DMA
remapping devices.
register_iommu() currently sets a default pgsize behavior, so we can convert
the IOMMU drivers in subsequent patches, and after all the drivers
are converted, register_iommu will be changed (and the temporary
default settings will be removed).
Mainline users of the IOMMU API (kvm and omap-iovmm) are adopted
to send the mapping size in bytes instead of in page order.
Many thanks to Joerg Roedel <Joerg.Roedel@amd.com> for significant review!
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: KyongHo Cho <pullip.cho@samsung.com>
Cc: Hiroshi DOYU <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: kvm@vger.kernel.org
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 73778b7..909b0d2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -16,6 +16,8 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/bug.h>
@@ -47,6 +49,19 @@ int bus_set_iommu(struct bus_type *bus, struct
iommu_ops *ops)
if (bus->iommu_ops != NULL)
return -EBUSY;
+ /*
+ * Set the default pgsize values, which retain the existing
+ * IOMMU API behavior: drivers will be called to map
+ * regions that are sized/aligned to order of 4KiB pages.
+ *
+ * This will be removed once all drivers are migrated.
+ */
+ if (!ops->pgsize_bitmap)
+ ops->pgsize_bitmap = ~0xFFFUL;
+
+ /* find out the minimum page size only once */
+ ops->min_pagesz = 1 << __ffs(ops->pgsize_bitmap);
+
bus->iommu_ops = ops;
/* Do IOMMU specific setup for this bus-type */
@@ -157,33 +172,117 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
int iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, int gfp_order, int prot)
+ phys_addr_t paddr, int size, int prot)
{
- size_t size;
+ unsigned long orig_iova = iova;
+ int ret = 0, orig_size = size;
if (unlikely(domain->ops->map == NULL))
return -ENODEV;
- size = PAGE_SIZE << gfp_order;
+ /*
+ * both the virtual address and the physical one, as well as
+ * the size of the mapping, must be aligned (at least) to the
+ * size of the smallest page supported by the hardware
+ */
+ if (!IS_ALIGNED(iova | paddr | size, domain->ops->min_pagesz)) {
+ pr_err("unaligned: iova 0x%lx pa 0x%lx size 0x%x min_pagesz "
+ "0x%x\n", iova, (unsigned long)paddr,
+ size, domain->ops->min_pagesz);
+ return -EINVAL;
+ }
+
+ pr_debug("map: iova 0x%lx pa 0x%lx size 0x%x\n", iova,
+ (unsigned long)paddr, size);
+
+ while (size) {
+ unsigned long pgsize, addr_merge = iova | paddr;
+ unsigned int pgsize_idx;
+
+ /* Max page size that still fits into 'size' */
+ pgsize_idx = __fls(size);
+
+ /* need to consider alignment requirements ? */
+ if (likely(addr_merge)) {
+ /* Max page size allowed by both iova and paddr */
+ unsigned int align_pgsize_idx = __ffs(addr_merge);
+
+ pgsize_idx = min(pgsize_idx, align_pgsize_idx);
+ }
+
+ /* build a mask of acceptable page sizes */
+ pgsize = (1UL << (pgsize_idx + 1)) - 1;
+
+ /* throw away page sizes not supported by the hardware */
+ pgsize &= domain->ops->pgsize_bitmap;
+
+ /* make sure we're still sane */
+ BUG_ON(!pgsize);
- BUG_ON(!IS_ALIGNED(iova | paddr, size));
+ /* pick the biggest page */
+ pgsize_idx = __fls(pgsize);
+ pgsize = 1UL << pgsize_idx;
- return domain->ops->map(domain, iova, paddr, gfp_order, prot);
+ /* convert index to page order */
+ pgsize_idx -= PAGE_SHIFT;
+
+ pr_debug("mapping: iova 0x%lx pa 0x%lx order %u\n", iova,
+ (unsigned long)paddr, pgsize_idx);
+
+ ret = domain->ops->map(domain, iova, paddr, pgsize_idx, prot);
+ if (ret)
+ break;
+
+ iova += pgsize;
+ paddr += pgsize;
+ size -= pgsize;
+ }
+
+ /* unroll mapping in case something went wrong */
+ if (ret)
+ iommu_unmap(domain, orig_iova, orig_size);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_map);
-int iommu_unmap(struct iommu_domain *domain, unsigned long iova, int gfp_order)
+int iommu_unmap(struct iommu_domain *domain, unsigned long iova, int size)
{
- size_t size;
+ int order, unmapped_size, unmapped_order, total_unmapped = 0;
if (unlikely(domain->ops->unmap == NULL))
return -ENODEV;
- size = PAGE_SIZE << gfp_order;
+ /*
+ * The virtual address, as well as the size of the mapping, must be
+ * aligned (at least) to the size of the smallest page supported
+ * by the hardware
+ */
+ if (!IS_ALIGNED(iova | size, domain->ops->min_pagesz)) {
+ pr_err("unaligned: iova 0x%lx size 0x%x min_pagesz 0x%x\n",
+ iova, size, domain->ops->min_pagesz);
+ return -EINVAL;
+ }
+
+ pr_debug("unmap this: iova 0x%lx size 0x%x\n", iova, size);
+
+ while (size > total_unmapped) {
+ order = get_order(size - total_unmapped);
+
+ unmapped_order = domain->ops->unmap(domain, iova, order);
+ if (unmapped_order < 0)
+ break;
+
+ pr_debug("unmapped: iova 0x%lx order %d\n", iova,
+ unmapped_order);
+
+ unmapped_size = 0x1000UL << unmapped_order;
- BUG_ON(!IS_ALIGNED(iova, size));
+ iova += unmapped_size;
+ total_unmapped += unmapped_size;
+ }
- return domain->ops->unmap(domain, iova, gfp_order);
+ return total_unmapped;
}
EXPORT_SYMBOL_GPL(iommu_unmap);
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index e8fdb88..4a8f761 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -409,7 +409,6 @@ static int map_iovm_area(struct iommu_domain
*domain, struct iovm_struct *new,
unsigned int i, j;
struct scatterlist *sg;
u32 da = new->da_start;
- int order;
if (!domain || !sgt)
return -EINVAL;
@@ -428,12 +427,10 @@ static int map_iovm_area(struct iommu_domain
*domain, struct iovm_struct *new,
if (bytes_to_iopgsz(bytes) < 0)
goto err_out;
- order = get_order(bytes);
-
pr_debug("%s: [%d] %08x %08x(%x)\n", __func__,
i, da, pa, bytes);
- err = iommu_map(domain, da, pa, order, flags);
+ err = iommu_map(domain, da, pa, bytes, flags);
if (err)
goto err_out;
@@ -448,10 +445,9 @@ err_out:
size_t bytes;
bytes = sg->length + sg->offset;
- order = get_order(bytes);
/* ignore failures.. we're already handling one */
- iommu_unmap(domain, da, order);
+ iommu_unmap(domain, da, bytes);
da += bytes;
}
@@ -474,13 +470,11 @@ static void unmap_iovm_area(struct iommu_domain
*domain, struct omap_iommu *obj,
start = area->da_start;
for_each_sg(sgt->sgl, sg, sgt->nents, i) {
size_t bytes;
- int order;
bytes = sg->length + sg->offset;
- order = get_order(bytes);
- err = iommu_unmap(domain, start, order);
- if (err < 0)
+ err = iommu_unmap(domain, start, bytes);
+ if (err < bytes)
break;
dev_dbg(obj->dev, "%s: unmap %08x(%x) %08x\n",
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 710291f..a10a86c 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -48,6 +48,22 @@ struct iommu_domain {
#ifdef CONFIG_IOMMU_API
+/**
+ * struct iommu_ops - iommu ops and capabilities
+ * @domain_init: init iommu domain
+ * @domain_destroy: destroy iommu domain
+ * @attach_dev: attach device to an iommu domain
+ * @detach_dev: detach device from an iommu domain
+ * @map: map a physically contiguous memory region to an iommu domain
+ * @unmap: unmap a physically contiguous memory region from an iommu domain
+ * @iova_to_phys: translate iova to physical address
+ * @domain_has_cap: domain capabilities query
+ * @commit: commit iommu domain
+ * @pgsize_bitmap: bitmap of supported page sizes
+ * @min_pagesz: smallest page size supported. note: this member is private
+ * to the IOMMU core, and maintained only for efficiency sake;
+ * drivers don't need to set it.
+ */
struct iommu_ops {
int (*domain_init)(struct iommu_domain *domain);
void (*domain_destroy)(struct iommu_domain *domain);
@@ -62,6 +78,8 @@ struct iommu_ops {
int (*domain_has_cap)(struct iommu_domain *domain,
unsigned long cap);
void (*commit)(struct iommu_domain *domain);
+ unsigned long pgsize_bitmap;
+ unsigned int min_pagesz;
};
extern int bus_set_iommu(struct bus_type *bus, struct iommu_ops *ops);
@@ -73,9 +91,9 @@ extern int iommu_attach_device(struct iommu_domain *domain,
extern void iommu_detach_device(struct iommu_domain *domain,
struct device *dev);
extern int iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, int gfp_order, int prot);
+ phys_addr_t paddr, int size, int prot);
extern int iommu_unmap(struct iommu_domain *domain, unsigned long iova,
- int gfp_order);
+ int size);
extern phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain,
unsigned long iova);
extern int iommu_domain_has_cap(struct iommu_domain *domain,
diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c
index ca409be..26b3199 100644
--- a/virt/kvm/iommu.c
+++ b/virt/kvm/iommu.c
@@ -111,7 +111,7 @@ int kvm_iommu_map_pages(struct kvm *kvm, struct
kvm_memory_slot *slot)
/* Map into IO address space */
r = iommu_map(domain, gfn_to_gpa(gfn), pfn_to_hpa(pfn),
- get_order(page_size), flags);
+ page_size, flags);
if (r) {
printk(KERN_ERR "kvm_iommu_map_address:"
"iommu failed to map pfn=%llx\n", pfn);
@@ -292,15 +292,15 @@ static void kvm_iommu_put_pages(struct kvm *kvm,
while (gfn < end_gfn) {
unsigned long unmap_pages;
- int order;
+ int size;
/* Get physical address */
phys = iommu_iova_to_phys(domain, gfn_to_gpa(gfn));
pfn = phys >> PAGE_SHIFT;
/* Unmap address from IO address space */
- order = iommu_unmap(domain, gfn_to_gpa(gfn), 0);
- unmap_pages = 1ULL << order;
+ size = iommu_unmap(domain, gfn_to_gpa(gfn), PAGE_SIZE);
+ unmap_pages = 1ULL << get_order(size);
/* Unpin all pages we just unmapped to not leak any memory */
kvm_unpin_pages(kvm, pfn, unmap_pages);
^ permalink raw reply related
* Re: [PATCH 8/8] OMAP3: powerdomain data: add wake-up latency figures
From: Paul Walmsley @ 2011-10-10 22:44 UTC (permalink / raw)
To: Jean Pihet
Cc: Kevin Hilman, Linux PM mailing list, linux-omap,
Rafael J. Wysocki, magnus.damm, Todd Poynor, Jean Pihet
In-Reply-To: <CAORVsuX2PUubPzO3mWTaO0Lg6Mdog8wjDY6hm93qheMwoz27CA@mail.gmail.com>
On Mon, 10 Oct 2011, Jean Pihet wrote:
> On Fri, Oct 7, 2011 at 6:17 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Wed, 21 Sep 2011, jean.pihet@newoldbits.com wrote:
> >
> >> From: Jean Pihet <j-pihet@ti.com>
> >>
> >> Figures are added to the power domains structs for RET and OFF modes.
> >>
> >> Note: the latency figures for MPU, PER, CORE, NEON have been obtained
> >> from actual measurements.
> >> The latency figures for the other power domains are preliminary and
> >> shall be added.
> >>
> >> Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
> >> for a detailed explanation on where are the numbers magically coming from.
> >>
> >> Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
> >> on MPU, CORE and PER.
> >
> > Do the CSWR measurements include the time for the PMIC to scale the
> > voltage, or do they just represent the time to enter and exit clock stop
> > (presumably with DPLL idling)?
>
> As described at [1] the measurements have not been performed with
> sys_offmode and sys_clkreq signals toggling correctly, because of the
> lack of support for it in the kernel.
> However the results are including a correction for the sys_offmode
> transition time (11.5ms), but no correction for the sys_clkreq signal
> (which should be 1ms for sysclk on, 2.5ms for sysclk off).
>
> [1] http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#cpuidle_results
OK. sys_offmode only applies to OFF mode. Voltage scaling can also occur
during RETENTION and INACTIVE ("sleep"). So were these results with
retention and voltage scaling disabled?
- Paul
^ permalink raw reply
* Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
From: Paul Walmsley @ 2011-10-10 22:35 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Kristo, Tero, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4E936F0E.9050203@ti.com>
On Tue, 11 Oct 2011, Cousson, Benoit wrote:
> On 10/10/2011 10:42 PM, Paul Walmsley wrote:
>
> > If it's the "3xxx" that you're objecting to in the name, we could call it
> > "prm2" or "prmxyz" - the '3xxx' just seemed like the most logical
> > approach. The name of the hwmod class in the patch is still "prm", of
> > course.
>
> Yes, but that's different, the number is supposed to represent the instance
> number in the IP naming convention. So prm2 != prmv2.
Heh, that works as long as there's no "prmv" IP block ;-)
> > Thoughts?
>
> In fact the device name does not have to match the hwmod name. So we can just
> create an "omap2_prm" omap_device for OMAP2, "omap3_prm" omap_device for
> OMAP3...
> That will allow the relevant PRM driver to be bound to the proper device.
We can, we'd just need to add this extra mapping layer, so it doesn't
become a nasty special-case hack for each IP block that this applies to.
Sounds like something for 3.3 (if ever...)
- Paul
^ permalink raw reply
* Re: [PATCH v6 05/16] OMAP2+: UART: Cleanup part of clock gating mechanism for uart
From: Kevin Hilman @ 2011-10-10 22:30 UTC (permalink / raw)
To: Govindraj.R
Cc: linux-omap, linux-serial, linux-arm-kernel, Tony Lindgren,
Partha Basak, Vishwanath Sripathy, Rajendra Nayak,
Santosh Shilimkar
In-Reply-To: <1317380495-584-5-git-send-email-govindraj.raja@ti.com>
"Govindraj.R" <govindraj.raja@ti.com> writes:
> Currently we use a shared irq handler to identify uart activity and then
> trigger a timer.
OK.
> Based the timeout value set from sysfs the timer used to expire.
Please re-phrase as I'm not sure what is being said here.
> If no uart-activity was detected timer-expiry func sets can_sleep
> flag. Based on this we will disable the uart clocks in idle path.
>
> Since the clock gating mechanism is outside the uart driver, we currently
> use this mechanism. In preparation to runtime implementation for omap-serial
> driver we can cleanup this mechanism and use runtime API's to gate uart clocks.
>
> Also remove timer related info from local uart_state struct and remove
> the code used to set timeout value from sysfs. Remove un-used function
> omap_uart_check_wakeup.
>
> Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
The patch itself fine, and is a well-neede cleanup, but changelog
(especially the first part) does not read well.
Kevin
^ permalink raw reply
* Re: [PATCH v6 02/16] OMAP2+: hwmod: Add API to check IO PAD wakeup status
From: Kevin Hilman @ 2011-10-10 22:24 UTC (permalink / raw)
To: Govindraj
Cc: Rajendra Nayak, Govindraj.R, linux-omap, linux-serial,
linux-arm-kernel, Tony Lindgren, Partha Basak,
Vishwanath Sripathy, Santosh Shilimkar
In-Reply-To: <CAAL8m4xkC1Ftnr=RpAK5m2PVvPx3yzitO5gNJfOKiD0_YkGkdA@mail.gmail.com>
Govindraj <govindraj.ti@gmail.com> writes:
> On Mon, Oct 3, 2011 at 10:53 AM, Rajendra Nayak <rnayak@ti.com> wrote:
>> On Monday 03 October 2011 10:30 AM, Govindraj wrote:
>>
>>> On Sat, Oct 1, 2011 at 8:03 PM, Rajendra Nayak<rnayak@ti.com> wrote:
>>>>
>>>> On Friday 30 September 2011 04:31 PM, Govindraj.R wrote:
>>>>>
>>>>> Add API to determine IO-PAD wakeup event status for a given
>>>>> hwmod dynamic_mux pad.
>>>>>
>>>>> Wake up event set will be cleared on pad mux_read.
>>>>
>>>> Are these api's even getting used in this series?
>>>
>>> Used in Tero's irq_chaining patches.
>>
>> So shouldn't this patch be part of his series instead?
>
> Yes it is. Part of his v9-series.
>
Then please drop from this series and state the introductory patch
(PATCH 0/n) that this series has a dependency on Tero's series.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
From: Cousson, Benoit @ 2011-10-10 22:17 UTC (permalink / raw)
To: Paul Walmsley
Cc: Kristo, Tero, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.DEB.2.00.1110101416530.5205@utopia.booyaka.com>
On 10/10/2011 10:42 PM, Paul Walmsley wrote:
> Hi Benoît
>
> On Mon, 10 Oct 2011, Cousson, Benoit wrote:
>
>> On 10/10/2011 9:24 PM, Paul Walmsley wrote:
>>> On Fri, 23 Sep 2011, Tero Kristo wrote:
>>>
>>>> This patch is temporary until Paul can provide a final version.
>>>>
>>>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>>>
>>> Here's an updated version of this one. The one change is that the hwmod's
>>> name is now "prm3xxx" to reflect that the register layout of this IP block
>>> is quite different from its OMAP2 predecessors and OMAP4 successors.
>>> This should avoid some of the special-purpose driver probing code.
>>
>> This is not really aligned with the naming convention we've been using so far.
>> In both cases, the hwmod should just be named "prm". If a version information
>> is needed, then it should be added in the revision class field.
>>
>> It will make the device creation even simpler and not dependent of the SoC
>> version.
>
> The problem in this case is that we should be using a completely different
> device driver for the PRM that's in the OMAP3 chips, from the driver used
> for OMAP2 or OMAP4 PRM blocks, due to the completely different register
> layout. As far as I know, we haven't yet used the hwmod IP version to
> probe a different device driver when the version number changes. There's
> no support for that in the current Linux platform* code, so we'd need
> special-purpose code for that.
>
> In an ideal world, we'd have an omap_bus, etc., which would include an
> additional interface version number as part of its driver matching
> criteria. Device drivers would then specify which interface version
> numbers they supported. The device data would specify that interface
> version number should be matched.
>
> But as it is right now in the current platform_device/platform_driver
> based system, we have only the name to match. We could implement
> something where we concatenate the existing IP version number onto the
> hwmod name, and modify the device drivers to use that name. But that
> seems like a lot of potential churn in light of a future DT and/or
> omap_bus migration.
>
> So I'm proposing to use the IP version number field that's in the hwmod
> data to indicate evolutionary revisions of an IP block -- rather than
> revolutionary revisions that would require a new driver. Then, since we
> use the hwmod name for driver matching, we'd use a different name for
> radically different IPs.
>
> If it's the "3xxx" that you're objecting to in the name, we could call it
> "prm2" or "prmxyz" - the '3xxx' just seemed like the most logical
> approach. The name of the hwmod class in the patch is still "prm", of
> course.
Yes, but that's different, the number is supposed to represent the
instance number in the IP naming convention. So prm2 != prmv2.
> Thoughts?
In fact the device name does not have to match the hwmod name. So we can
just create an "omap2_prm" omap_device for OMAP2, "omap3_prm"
omap_device for OMAP3...
That will allow the relevant PRM driver to be bound to the proper device.
> N.B., it's true that by waiting, this problem will presumably go away,
> with DT, in which the driver matching data would go into the
> "compatible" string in the DT.
Yes, this will become indeed straightforward with DT.
We will just have something like:
prm {
compatible = "prm-omap2";
ti,hwmods = "prm";
}
> But I guess it would be good to figure out a clean approach in the
> meantime.
I guess the different device names should make that work in the meantime.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Paul Walmsley @ 2011-10-10 22:13 UTC (permalink / raw)
To: Felipe Balbi
Cc: Munegowda, Keshava, linux-usb, linux-omap, linux-kernel, khilman,
b-cousson, gadiyar, sameo, parthab, tony, johnstul, vishwanath.bs
In-Reply-To: <alpine.DEB.2.00.1110101509580.5205@utopia.booyaka.com>
Hi
On Mon, 10 Oct 2011, Paul Walmsley wrote:
> So then you'd just create a TLL driver with something like these two
> symbols exported:
>
> omap_usbhost_tll_enable_port();
> omap_usbhost_tll_disable_port();
N.B., since I don't think Linux has any formal support to map USB ports to
TLL ports, you'll probably need to create a couple of functions in your
drivers/mfd/omap-usb-host.c that your EHCI/OHCI drivers could call during
init/exit to get and put the TLL struct device, to pass to those above
functions. Since the MFD driver is what creates the TLL struct devices,
the MFD driver will have the TLL struct device pointers. Something like
omap_usbhost_get_tll_device() and omap_usbhost_put_tll_device().
One other thing. Not sure what the correct generic name prefix for these
functions should be, since I don't know the provenance of the USBHOST IP
block; but maybe the function prefix should be something like 'ti_usbhost'
instead, to indicate that it isn't OMAP-specific? You would know better
than I.
- Paul
^ permalink raw reply
* Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware
From: Ohad Ben-Cohen @ 2011-10-10 22:01 UTC (permalink / raw)
To: Roedel, Joerg
Cc: iommu@lists.linux-foundation.org, linux-omap@vger.kernel.org,
Laurent Pinchart, David Woodhouse,
linux-arm-kernel@lists.infradead.org, David Brown, Arnd Bergmann,
linux-kernel@vger.kernel.org, Stepan Moskovchenko,
kvm@vger.kernel.org, Hiroshi Doyu
In-Reply-To: <CAK=WgbYR_qx53Z7s3R=q29KYo8ebYCH9H9=2OrrWXWMv6=-iOQ@mail.gmail.com>
> On Mon, Oct 10, 2011 at 5:36 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
>> The master branch is best to base your patches on for generic work.
It looks like the master branch is missing something like this:
>From acb316aa4bcaf383e8cb1580e30c8635e0a34369 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen <ohad@wizery.com>
Date: Mon, 10 Oct 2011 23:55:51 +0200
Subject: [PATCH] iommu/core: fix build issue
Fix this:
drivers/iommu/iommu.c: In function 'iommu_commit':
drivers/iommu/iommu.c:291: error: 'iommu_ops' undeclared (first use in
this function)
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/iommu/iommu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 909b0d2..a5131f1 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -288,7 +288,7 @@ EXPORT_SYMBOL_GPL(iommu_unmap);
void iommu_commit(struct iommu_domain *domain)
{
- if (iommu_ops->commit)
- iommu_ops->commit(domain);
+ if (domain->ops->commit)
+ domain->ops->commit(domain);
}
EXPORT_SYMBOL_GPL(iommu_commit);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Paul Walmsley @ 2011-10-10 21:49 UTC (permalink / raw)
To: Felipe Balbi
Cc: Munegowda, Keshava, linux-usb, linux-omap, linux-kernel, khilman,
b-cousson, gadiyar, sameo, parthab, tony, johnstul, vishwanath.bs
In-Reply-To: <20111010090330.GE6685@legolas.emea.dhcp.ti.com>
Hi
On Mon, 10 Oct 2011, Felipe Balbi wrote:
> On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
>
> > Here is the highlights of the change in the design of USB Host which
> > we can do after kernel 3.2 release;
> >
> > 1. separate the TLL changes from UHH
> > 2. The TLL is be a new platform driver in ./drivers/mfd
> > 3. the TLL platform driver will export apis for enable/disable clocks
> > and settings.
>
> TLL should control its clocks through pm_runtime APIs like anything
> else. If you really must export APIs to be used by UHH, you need to have
> an API so that you can claim/release a TLL channel and get/put for
> increasing/decreasing PM counters.
>
> I still think though, you should try to avoid exporting OMAP-specific
> APIs all over the place. Ideally, we would be able to have some way of
> saying that UHH and TLL are closely related... something like having the
> ability to say e.g. two devices are sibblings of each other, so that we
> could ask for a sibbling to wakeup/sleep depending if we need it or not.
>
> Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
> APIs is wise.
I'm not an USBHOST expert, but I don't think any special sibling
relationships or OMAP subarchitecture-specific APIs are needed. The OMAP
EHCI/OHCI drivers just need to call a couple of functions in the OMAP TLL
driver. Linux already handles function call dependencies between
loadable modules transparently (see "man 8 depmod" and EXPORT_SYMBOL).
Looks to me like the TLL IP block is only needed for OHCI and some EHCI
port modes[1]. The TLL doesn't seem to need much care and feeding.
Currently it's programmed during init[2] and then you just enable it when
the port is in use[3] and disable it when it is no longer in use[4].
Looks to me like the TLL init function could be rolled into the enable
function.
So then you'd just create a TLL driver with something like these two
symbols exported:
omap_usbhost_tll_enable_port();
omap_usbhost_tll_disable_port();
The first function would be called from drivers/usb/host/ehci-omap.c or
drivers/usb/host/ohci-omap3.c during omap_usbhs_enable(). It would take
the TLL configuration for that port and would reserve it while it is in
use. It would call pm_runtime_get_sync() to ensure its clocks were on,
etc.
The second function would be called from drivers/usb/host/ehci-omap.c or
drivers/usb/host/ohci-omap3.c during omap_usbhs_disable(). It would
release an already in-use TLL port and would call pm_runtime_put_sync() to
allow its clocks to be cut, etc.
So it doesn't seem like any extraordinary Linux support is needed to
handle this cleanly. But maybe I'm missing something?
- Paul
All references are as of Linux v3.1-rc9.
1. drivers/mfd/omap-usb-host.c:887,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l887
2. drivers/mfd/omap-usb-host.c:894,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l894
3. drivers/mfd/omap-usb-host.c:845,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l845
4. drivers/mfd/omap-usb-host.c:999,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l999
^ permalink raw reply
* Re: [PATCH v2 6/6] OMAP4: Clock: Correct the name of SLIMBUS interface clocks
From: Jon Hunter @ 2011-10-10 21:34 UTC (permalink / raw)
To: Cousson, Benoit; +Cc: Paul Walmsley, linux-omap, linux-arm
In-Reply-To: <4E92C0D9.3090402@ti.com>
Hi Benoit,
On 10/10/2011 4:54, Cousson, Benoit wrote:
> Hi Jon,
>
> On 10/8/2011 12:46 AM, Hunter, Jon wrote:
>> Hi Benoit,
>>
>> On 10/7/2011 3:23, Cousson, Benoit wrote:
>>> Hi Paul& Jon,
>>>
>>> On 10/7/2011 3:42 AM, Paul Walmsley wrote:
>>>> + Benoît
>>>>
>>>> On Fri, 16 Sep 2011, Jon Hunter wrote:
>>>>
>>>>> From: Jon Hunter<jon-hunter@ti.com>
>>>>>
>>>>> Currently the interface clocks for the two SLIMBUS peripherals are
>>>>> named slimbus1_fck and slimbus2_fck. Rename these clocks to be
>>>>> slimbus1_ick and slimbus2_ick so it is clear that these are
>>>>> interface clocks and not functional clocks.
>>>>>
>>>>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>>>>
>>>> This one, I don't quite understand. We should probably be removing
>>>> these
>>>> MODULEMODE-only clocks from the OMAP4 tree, and using their parent
>>>> clock
>>>> as the main_clk. That would be a good cleanup for 3.3...
>>>
>>> Yes, but in order to remove that from the clock data we must ensure that
>>> the hwmod entry is there.
>>> I kept a lot of legacy MODULEMODE clocks just because of missing hwmod /
>>> runtime_pm adaptation on some drivers.
>>>
>>> In the case of slimbus, there is no main_clk but a bunch of optional
>>> clocks. It looks similar to the DSS case. So we should not use the
>>> parent clock as a main_clk.
>>>
>>> We should probably promote one of the opt_clk as the main_clk. The
>>> slimbus_clk seems to be the good candidate for both instances.
>>>
>>> static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = {
>>> { .role = "fclk_1", .clk = "slimbus1_fclk_1" },
>>> { .role = "fclk_0", .clk = "slimbus1_fclk_0" },
>>> { .role = "fclk_2", .clk = "slimbus1_fclk_2" },
>>> { .role = "slimbus_clk", .clk = "slimbus1_slimbus_clk" },
>>> };
>>>
>>> static struct omap_hwmod_opt_clk slimbus2_opt_clks[] = {
>>> { .role = "fclk_1", .clk = "slimbus2_fclk_1" },
>>> { .role = "fclk_0", .clk = "slimbus2_fclk_0" },
>>> { .role = "slimbus_clk", .clk = "slimbus2_slimbus_clk" },
>>> };
>>>
>>> Jon,
>>> Do you know if that one is indeed mandatory to use the slimbus IP?
>>
>> Sorry, are you asking about the clocks I was re-naming or the
>> slimbus_clk you are referring to above?
>
> The clocks you are renaming should not exist at all, so I was referring
> to the real clocks that are all listed as optional clocks.
These clocks are the interface clocks enabled via the module-mode. So
you are saying you want to remove the interface clocks from the list of
clocks?
> Usually we do need to have a main_clk in order to access the IP
> registers (at least the sysconfig). But for some IPs, the iclk can be
> enough.
> If the interface clock is enough, then potentially that main clock is
> not mandatory. But if one functional clock is mandatory, then we have to
> figured out which one from the various optional functional clocks can be
> used as the main_clk.
>
>> Looking at the clock tree tool, the slimbus_clk is the actual external
>> slimbus clock that can be generated by OMAP or by an external device.
>>
>> The TRM states ...
>>
>> "Most of the SLIMbus module runs off two main clocks: the L4 interface
>> clock for the data input and output registers, and the control and
>> status control registers; and the SLIMbus clock, taken from the serial
>> interface (CLK line) for the SLIMbus-side logic.
>>
>> The SLIMbus controller operates as clock source component (active
>> framer), which drives the SLIMbus clock line CLK, or as clock receiver
>> component, which gets its clock from the same CLK line."
>>
>> So, if you are operating as the clock source component on the bus then
>> one of the optional clocks to drive the peripheral logic and if you are
>> the clock receiver then you use slimbus_clk.
>
> OK, so clearly, the slimbus_clk cannot be a main_clk. We have to check
> if the registers can be accessed only with the iclk.
I ran a quick test. If I just set the module mode to 0x2 (enabled), then
I can access the registers. So no need to turn on any of the
optional/functional clocks just the iclk.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3.1-rc3] gpio/omap: fix build error with certain OMAP1 configs
From: Aaro Koskinen @ 2011-10-10 21:12 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Kevin Hilman, Grant Likely, linux-kernel, linux-omap, tony
In-Reply-To: <201110071430.14420.jkrzyszt@tis.icnet.pl>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1375 bytes --]
Hi,
On Fri, 7 Oct 2011, Janusz Krzysztofik wrote:
> Dnia wtorek, 23 sierpnia 2011 o 19:11:47 Kevin Hilman napisał(a):
>> Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> writes:
>>> With commit f64ad1a0e21a, "gpio/omap: cleanup _set_gpio_wakeup(), remove
>>> ifdefs", access to build time conditionally omitted 'suspend_wakeup'
>>> member of the 'gpio_bank' structure has been placed unconditionally in
>>> function _set_gpio_wakeup(), which is always built. This resulted in the
>>> driver compilation broken for certain OMAP1, i.e., non-OMAP16xx,
>>> configurations.
>>>
>>> Really required or not in previously excluded cases, define this
>>> structure member unconditionally as a fix.
>>>
>>> Tested with a custom OMAP1510 only configuration.
>>>
>>> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
>>
>> Verified that this fixes a build problem when building for OMAP1
>> (730/850 only)
>>
>> Acked-by: Kevin Hilman <khilman@ti.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
>> Grant, can you queue this as a fix for 3.1-rc?
>
> Sorry for being so late with checking this, but it looks like this patch
> never got into 3.1-rc, as it should, leaving the issue not fixed.
> Any chance for it still being pushed into 3.1?
This patch is one-liner, and still needed to get 3.1-rc9 compiled and
running on e.g. Amstrad E3, so I think it should get into 3.1.
A.
^ permalink raw reply
* Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Paul Walmsley @ 2011-10-10 20:59 UTC (permalink / raw)
To: Munegowda, Keshava
Cc: linux-usb, linux-omap, linux-kernel, balbi, khilman, b-cousson,
gadiyar, sameo, parthab, tony, johnstul, vishwanath.bs
In-Reply-To: <CAP05o4+ybhZwRaXZPgS-ZdTL_0gjz1VLf6LuUtMgm_txNPwrnw@mail.gmail.com>
Hi
On Mon, 10 Oct 2011, Munegowda, Keshava wrote:
> Here is the highlights of the change in the design of USB Host which
> we can do after kernel 3.2 release;
>
> 1. separate the TLL changes from UHH
> 2. The TLL is be a new platform driver in ./drivers/mfd
> 3. the TLL platform driver will export apis for enable/disable clocks
> and settings.
> 3. the UHH drivers uses these APIS of TLL based on the port
> configurations from board files
> you don't need the TLL clocks to
> be on while all the ports are in phy mode.
>
> please let me know your thoughts about it.
The TLL driver shouldn't be in drivers/mfd, since it's not an MFD device.
The TLL driver should go somewhere under drivers/usb.
Basically, the existing OMAP USB subsystem MFD driver should create a TLL
device. Then the existing Linux driver probing system can associate the
TLL driver with the TLL device.
- Paul
^ permalink raw reply
* Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
From: Paul Walmsley @ 2011-10-10 20:42 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Kristo, Tero, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4E934D79.4080000@ti.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2941 bytes --]
Hi Benoît
On Mon, 10 Oct 2011, Cousson, Benoit wrote:
> On 10/10/2011 9:24 PM, Paul Walmsley wrote:
> > On Fri, 23 Sep 2011, Tero Kristo wrote:
> >
> > > This patch is temporary until Paul can provide a final version.
> > >
> > > Signed-off-by: Tero Kristo<t-kristo@ti.com>
> >
> > Here's an updated version of this one. The one change is that the hwmod's
> > name is now "prm3xxx" to reflect that the register layout of this IP block
> > is quite different from its OMAP2 predecessors and OMAP4 successors.
> > This should avoid some of the special-purpose driver probing code.
>
> This is not really aligned with the naming convention we've been using so far.
> In both cases, the hwmod should just be named "prm". If a version information
> is needed, then it should be added in the revision class field.
>
> It will make the device creation even simpler and not dependent of the SoC
> version.
The problem in this case is that we should be using a completely different
device driver for the PRM that's in the OMAP3 chips, from the driver used
for OMAP2 or OMAP4 PRM blocks, due to the completely different register
layout. As far as I know, we haven't yet used the hwmod IP version to
probe a different device driver when the version number changes. There's
no support for that in the current Linux platform* code, so we'd need
special-purpose code for that.
In an ideal world, we'd have an omap_bus, etc., which would include an
additional interface version number as part of its driver matching
criteria. Device drivers would then specify which interface version
numbers they supported. The device data would specify that interface
version number should be matched.
But as it is right now in the current platform_device/platform_driver
based system, we have only the name to match. We could implement
something where we concatenate the existing IP version number onto the
hwmod name, and modify the device drivers to use that name. But that
seems like a lot of potential churn in light of a future DT and/or
omap_bus migration.
So I'm proposing to use the IP version number field that's in the hwmod
data to indicate evolutionary revisions of an IP block -- rather than
revolutionary revisions that would require a new driver. Then, since we
use the hwmod name for driver matching, we'd use a different name for
radically different IPs.
If it's the "3xxx" that you're objecting to in the name, we could call it
"prm2" or "prmxyz" - the '3xxx' just seemed like the most logical
approach. The name of the hwmod class in the patch is still "prm", of
course.
Thoughts?
...
N.B., it's true that by waiting, this problem will presumably go away,
with DT, in which the driver matching data would go into the
"compatible" string in the DT.
But I guess it would be good to figure out a clean approach in the
meantime.
- Paul
^ permalink raw reply
* [GIT PULL v2] ARM: OMAP: new miscellaneous clock/hwmod data for 3.2
From: Paul Walmsley @ 2011-10-10 20:16 UTC (permalink / raw)
To: tony
Cc: linux-omap, linux-arm-kernel, santosh.shilimkar, b-cousson,
keshava_mgowda
In-Reply-To: <alpine.DEB.2.00.1110101342010.5205@utopia.booyaka.com>
Hi,
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 clock_hwmod_devel_3.2
This second version drops the PRM hwmod since it needs more discussion.
Benoit Cousson (1):
ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP4
Keshava Munegowda (1):
ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3
Santosh Shilimkar (1):
ARM: OMAP4: clock: Add CPU local timer clock node.
arch/arm/mach-omap2/clock44xx_data.c | 9 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 217 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 206 ++++++++++++++++++++++++++-
3 files changed, 431 insertions(+), 1 deletions(-)
- Paul
^ permalink raw reply
* Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
From: Paul Walmsley @ 2011-10-10 20:11 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Kristo, Tero, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4E934D79.4080000@ti.com>
On Mon, 10 Oct 2011, Cousson, Benoit wrote:
> Hi Paul,
>
> On 10/10/2011 9:24 PM, Paul Walmsley wrote:
> > Hi Tero
> >
> > On Fri, 23 Sep 2011, Tero Kristo wrote:
> >
> > > This patch is temporary until Paul can provide a final version.
> > >
> > > Signed-off-by: Tero Kristo<t-kristo@ti.com>
> >
> > Here's an updated version of this one. The one change is that the hwmod's
> > name is now "prm3xxx" to reflect that the register layout of this IP block
> > is quite different from its OMAP2 predecessors and OMAP4 successors.
> > This should avoid some of the special-purpose driver probing code.
>
> This is not really aligned with the naming convention we've been using so far.
> In both cases, the hwmod should just be named "prm". If a version information
> is needed, then it should be added in the revision class field.
>
> It will make the device creation even simpler and not dependent of the SoC
> version.
> I did not check the whole series, but I'm not sure we need a special treatment
> in the case of the prm.
OK, sounds like this needs more discussion, so will drop this patch from
the pull request.
- Paul
^ permalink raw reply
* Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Felipe Balbi @ 2011-10-10 20:10 UTC (permalink / raw)
To: Alan Stern
Cc: Felipe Balbi, Munegowda, Keshava, Paul Walmsley, linux-usb,
linux-omap, linux-kernel, khilman, b-cousson, gadiyar, sameo,
parthab, tony, johnstul, vishwanath.bs, Greg KH
In-Reply-To: <Pine.LNX.4.44L0.1110101551510.24082-100000@netrider.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]
Hi,
On Mon, Oct 10, 2011 at 03:55:30PM -0400, Alan Stern wrote:
> On Mon, 10 Oct 2011, Felipe Balbi wrote:
>
> > On Mon, Oct 10, 2011 at 11:19:43AM -0400, Alan Stern wrote:
> > > On Mon, 10 Oct 2011, Felipe Balbi wrote:
> > >
> > > > > > do we have sibling structures today? I dont think so.
> > > > >
> > > > > no we don't.
> > > >
> > > > Ok, here's a first shot at it:
> > >
> > > In fact we do already have sibling lists. They are maintained as part
> > > of the device_private structure. What we are missing is a
> > > device_for_each_sibling() routine. It could be added pretty easily; it
> > > would be similar to device_for_each_child().
> >
> > care to point out where is ?
> >
> > 68 struct device_private {
> > 69 struct klist klist_children;
> > 70 struct klist_node knode_parent;
> -------------^ Here. The "parent" in the name refers to where the
> head of the list is stored.
>
> > 71 struct klist_node knode_driver;
> > 72 struct klist_node knode_bus;
> > 73 void *driver_data;
> > 74 struct device *device;
> > 75 };
>
> From device_add():
>
> if (parent)
> klist_add_tail(&dev->p->knode_parent,
> &parent->p->klist_children);
that's a parent -> child relationship. What we have on this case is:
-------------- ---------------
| | | | |\
| UHH | clocks, etc | USBTLL | | |
| | <==========> | | <======> | | <====> ports
| ------- | | (Transceiver- | | |
| | EHCI | | | less Link) | |/
| ------- | | | Port MUX
| | | |
| ------- | | |
| | OHCI | | | |
| ------- | | |
| | | |
-------------- ---------------
It doesn't shown here, but the TLL link is completely optional. It's
mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI
and OHCI will depend on a clock provided by the USBTLL block.
Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI
blocks. We can, from a code perspective, make USBTLL into a parent of
UHH to make things simpler, but this will mean that calling
pm_runtime_get() will also unconditionaly turn on TLL clock, unless we
add some nasty hacks to allow TLL know if *HCI port is in TLL mode.
That's why I decided for making TLL and UHH siblings, because that's a
closer relationship than parent-child.
Can you see the problem now ?
ps: the best picture is on TI's OMAP4430 TRM (it's publicly available
from TI's website). So, if you want a better rendering of the
integration model, take a look at chapter 23.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structures for omap4
From: Alan Stern @ 2011-10-10 19:55 UTC (permalink / raw)
To: Felipe Balbi
Cc: Munegowda, Keshava, Paul Walmsley, linux-usb, linux-omap,
linux-kernel, khilman, b-cousson, gadiyar, sameo, parthab, tony,
johnstul, vishwanath.bs, Greg KH
In-Reply-To: <20111010160354.GP6685@legolas.emea.dhcp.ti.com>
On Mon, 10 Oct 2011, Felipe Balbi wrote:
> On Mon, Oct 10, 2011 at 11:19:43AM -0400, Alan Stern wrote:
> > On Mon, 10 Oct 2011, Felipe Balbi wrote:
> >
> > > > > do we have sibling structures today? I dont think so.
> > > >
> > > > no we don't.
> > >
> > > Ok, here's a first shot at it:
> >
> > In fact we do already have sibling lists. They are maintained as part
> > of the device_private structure. What we are missing is a
> > device_for_each_sibling() routine. It could be added pretty easily; it
> > would be similar to device_for_each_child().
>
> care to point out where is ?
>
> 68 struct device_private {
> 69 struct klist klist_children;
> 70 struct klist_node knode_parent;
-------------^ Here. The "parent" in the name refers to where the
head of the list is stored.
> 71 struct klist_node knode_driver;
> 72 struct klist_node knode_bus;
> 73 void *driver_data;
> 74 struct device *device;
> 75 };
>From device_add():
if (parent)
klist_add_tail(&dev->p->knode_parent,
&parent->p->klist_children);
Alan Stern
^ permalink raw reply
* Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
From: Cousson, Benoit @ 2011-10-10 19:54 UTC (permalink / raw)
To: Paul Walmsley
Cc: Kristo, Tero, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <alpine.DEB.2.00.1110101320180.5205@utopia.booyaka.com>
Hi Paul,
On 10/10/2011 9:24 PM, Paul Walmsley wrote:
> Hi Tero
>
> On Fri, 23 Sep 2011, Tero Kristo wrote:
>
>> This patch is temporary until Paul can provide a final version.
>>
>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>
> Here's an updated version of this one. The one change is that the hwmod's
> name is now "prm3xxx" to reflect that the register layout of this IP block
> is quite different from its OMAP2 predecessors and OMAP4 successors.
> This should avoid some of the special-purpose driver probing code.
This is not really aligned with the naming convention we've been using
so far.
In both cases, the hwmod should just be named "prm". If a version
information is needed, then it should be added in the revision class field.
It will make the device creation even simpler and not dependent of the
SoC version.
I did not check the whole series, but I'm not sure we need a special
treatment in the case of the prm.
Regards,
Benoit
>
>
> - Paul
>
> From: Paul Walmsley<paul@pwsan.com>
> Date: Mon, 10 Oct 2011 13:11:11 -0600
> Subject: [PATCH] OMAP3xxx: hwmod data: add PRM hwmod
>
> Add a hwmod for the Power& Reset Management (PRM) IP block that is
> present on OMAP3xxx SoCs.
>
> Signed-off-by: Paul Walmsley<paul@pwsan.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62 ++++++++++++++++++++++++++++
> 1 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index ab35acb..382fad9 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -160,6 +160,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
> };
>
> static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
> +static struct omap_hwmod omap3xxx_prm_hwmod;
> static struct omap_hwmod omap3xxx_uart1_hwmod;
> static struct omap_hwmod omap3xxx_uart2_hwmod;
> static struct omap_hwmod omap3xxx_uart3_hwmod;
> @@ -475,6 +476,29 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
> .flags = HWMOD_NO_IDLEST,
> };
>
> +static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
> + {
> + .pa_start = 0x48306000,
> + .pa_end = 0x48306000 + SZ_8K + SZ_4K - 1,
> + .flags = ADDR_TYPE_RT
> + },
> + { }
> +};
> +
> +/* L4_WKUP -> PRM interface */
> +static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
> + .master =&omap3xxx_l4_wkup_hwmod,
> + .slave =&omap3xxx_prm_hwmod,
> + .clk = "wkup_l4_ick",
> + .addr = omap3xxx_prm_addrs,
> + .user = OCP_USER_MPU,
> +};
> +
> +/* Master interfaces on the L4_WKUP interconnect */
> +static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
> + &omap3xxx_l4_wkup__prm,
> +};
> +
> /* Slave interfaces on the L4_WKUP interconnect */
> static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
> &omap3xxx_l4_core__l4_wkup,
> @@ -484,11 +508,46 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
> static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
> .name = "l4_wkup",
> .class =&l4_hwmod_class,
> + .masters = omap3xxx_l4_wkup_masters,
> + .masters_cnt = ARRAY_SIZE(omap3xxx_l4_wkup_masters),
> .slaves = omap3xxx_l4_wkup_slaves,
> .slaves_cnt = ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
> .flags = HWMOD_NO_IDLEST,
> };
>
> +/* Slave interfaces on the L4_WKUP interconnect */
> +static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
> + &omap3xxx_l4_wkup__prm,
> +};
> +
> +static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
> + .rev_offs = 0x0804,
> + .sysc_offs = 0x0814,
> + .sysc_flags = SYSC_HAS_AUTOIDLE,
> + .sysc_fields =&omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
> + .name = "prm",
> + .sysc =&omap3xxx_prm_sysc,
> +};
> +
> +static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
> + { .irq = 11 },
> + { .irq = -1 }
> +};
> +
> +/* PRM */
> +static struct omap_hwmod omap3xxx_prm_hwmod = {
> + .name = "prm3xxx",
> + .mpu_irqs = omap3xxx_prm_irqs,
> + .class =&omap3xxx_prm_hwmod_class,
> + .main_clk = "wkup_32k_fck",
> + .slaves = omap3xxx_prm_slaves,
> + .slaves_cnt = ARRAY_SIZE(omap3xxx_prm_slaves),
> + .flags = HWMOD_NO_IDLEST,
> +};
> +
> /* Master interfaces on the MPU device */
> static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
> &omap3xxx_mpu__l3_main,
> @@ -3128,6 +3187,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
> &omap3xxx_l4_core_hwmod,
> &omap3xxx_l4_per_hwmod,
> &omap3xxx_l4_wkup_hwmod,
> +
> + &omap3xxx_prm_hwmod,
> +
> &omap3xxx_mmc1_hwmod,
> &omap3xxx_mmc2_hwmod,
> &omap3xxx_mmc3_hwmod,
^ permalink raw reply
* [GIT PULL] ARM: OMAP: new miscellaneous clock/hwmod data for 3.2
From: Paul Walmsley @ 2011-10-10 19:44 UTC (permalink / raw)
To: tony
Cc: linux-omap, linux-arm-kernel, santosh.shilimkar, b-cousson,
keshava_mgowda
Hi Tony,
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 clock_hwmod_devel_3.2
Benoit Cousson (1):
ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP4
Keshava Munegowda (1):
ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3
Paul Walmsley (1):
ARM: OMAP3xxx: hwmod data: add PRM hwmod
Santosh Shilimkar (1):
ARM: OMAP4: clock: Add CPU local timer clock node.
arch/arm/mach-omap2/clock44xx_data.c | 9 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 279 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 206 ++++++++++++++++++++-
3 files changed, 493 insertions(+), 1 deletions(-)
- Paul
^ permalink raw reply
* Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
From: Paul Walmsley @ 2011-10-10 19:24 UTC (permalink / raw)
To: Tero Kristo; +Cc: linux-omap, linux-arm-kernel, linux-kernel
In-Reply-To: <1316781986-30642-4-git-send-email-t-kristo@ti.com>
Hi Tero
On Fri, 23 Sep 2011, Tero Kristo wrote:
> This patch is temporary until Paul can provide a final version.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
Here's an updated version of this one. The one change is that the hwmod's
name is now "prm3xxx" to reflect that the register layout of this IP block
is quite different from its OMAP2 predecessors and OMAP4 successors.
This should avoid some of the special-purpose driver probing code.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Mon, 10 Oct 2011 13:11:11 -0600
Subject: [PATCH] OMAP3xxx: hwmod data: add PRM hwmod
Add a hwmod for the Power & Reset Management (PRM) IP block that is
present on OMAP3xxx SoCs.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 62 ++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ab35acb..382fad9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -160,6 +160,7 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod = {
};
static struct omap_hwmod omap3xxx_l4_wkup_hwmod;
+static struct omap_hwmod omap3xxx_prm_hwmod;
static struct omap_hwmod omap3xxx_uart1_hwmod;
static struct omap_hwmod omap3xxx_uart2_hwmod;
static struct omap_hwmod omap3xxx_uart3_hwmod;
@@ -475,6 +476,29 @@ static struct omap_hwmod omap3xxx_l4_per_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+static struct omap_hwmod_addr_space omap3xxx_prm_addrs[] = {
+ {
+ .pa_start = 0x48306000,
+ .pa_end = 0x48306000 + SZ_8K + SZ_4K - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* L4_WKUP -> PRM interface */
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__prm = {
+ .master = &omap3xxx_l4_wkup_hwmod,
+ .slave = &omap3xxx_prm_hwmod,
+ .clk = "wkup_l4_ick",
+ .addr = omap3xxx_prm_addrs,
+ .user = OCP_USER_MPU,
+};
+
+/* Master interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
+ &omap3xxx_l4_wkup__prm,
+};
+
/* Slave interfaces on the L4_WKUP interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
&omap3xxx_l4_core__l4_wkup,
@@ -484,11 +508,46 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
.name = "l4_wkup",
.class = &l4_hwmod_class,
+ .masters = omap3xxx_l4_wkup_masters,
+ .masters_cnt = ARRAY_SIZE(omap3xxx_l4_wkup_masters),
.slaves = omap3xxx_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
.flags = HWMOD_NO_IDLEST,
};
+/* Slave interfaces on the L4_WKUP interconnect */
+static struct omap_hwmod_ocp_if *omap3xxx_prm_slaves[] = {
+ &omap3xxx_l4_wkup__prm,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_prm_sysc = {
+ .rev_offs = 0x0804,
+ .sysc_offs = 0x0814,
+ .sysc_flags = SYSC_HAS_AUTOIDLE,
+ .sysc_fields = &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_prm_hwmod_class = {
+ .name = "prm",
+ .sysc = &omap3xxx_prm_sysc,
+};
+
+static struct omap_hwmod_irq_info omap3xxx_prm_irqs[] = {
+ { .irq = 11 },
+ { .irq = -1 }
+};
+
+/* PRM */
+static struct omap_hwmod omap3xxx_prm_hwmod = {
+ .name = "prm3xxx",
+ .mpu_irqs = omap3xxx_prm_irqs,
+ .class = &omap3xxx_prm_hwmod_class,
+ .main_clk = "wkup_32k_fck",
+ .slaves = omap3xxx_prm_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_prm_slaves),
+ .flags = HWMOD_NO_IDLEST,
+};
+
/* Master interfaces on the MPU device */
static struct omap_hwmod_ocp_if *omap3xxx_mpu_masters[] = {
&omap3xxx_mpu__l3_main,
@@ -3128,6 +3187,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
&omap3xxx_l4_core_hwmod,
&omap3xxx_l4_per_hwmod,
&omap3xxx_l4_wkup_hwmod,
+
+ &omap3xxx_prm_hwmod,
+
&omap3xxx_mmc1_hwmod,
&omap3xxx_mmc2_hwmod,
&omap3xxx_mmc3_hwmod,
--
1.7.6.3
^ permalink raw reply related
* Re: [PATCH] leds-class: change back LEDS_CLASS to tristate instead of bool
From: Anton Vorontsov @ 2011-10-10 18:54 UTC (permalink / raw)
To: Bryan Wu
Cc: akpm, linux-omap, linux, tony, linus.walleij, linux-mmc,
linux-kernel, rpurdie, manuel.lauss, cjb, dwmw2, linux-arm-kernel
In-Reply-To: <1317113432-7299-1-git-send-email-bryan.wu@canonical.com>
On Tue, Sep 27, 2011 at 04:50:32PM +0800, Bryan Wu wrote:
> LEDS_CLASS is required by leds and trigger drivers, but we can build it as
> module. So change this option back as tristate and treak the help message
> as well.
>
> LEDS_TRIGGERS depends on LEDS_CLASSS, which should be tristate. So set it
> as tristate too and update header files as well.
>
> Change those ifdefs to take care of module configuration.
>
> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
Won't this break linking if POWER_SUPPLY=y and LEDS_TRIGGERS=m?
Thanks,
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
^ permalink raw reply
* Re: [PATCH] ARM: omap2+: stub out omap*_volt_data
From: Kevin Hilman @ 2011-10-10 18:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Tony Lindgren, Paul Walmsley, Nishanth Menon, linux-omap,
linux-arm-kernel
In-Reply-To: <1397689.kebELtC4N3@wuerfel>
Arnd Bergmann <arnd@arndb.de> writes:
> When CONFIG_PM_OPP is not set, the definitions for these variables
> are not available, so we should conditionally define them to
> NULL.
>
> arch/arm/mach-omap2/built-in.o: In function `omap3xxx_voltagedomains_init':
> voltagedomains3xxx_data.c:100: undefined reference to `omap36xx_vddmpu_volt_data'
> voltagedomains3xxx_data.c:100: undefined reference to `omap34xx_vddmpu_volt_data'
> voltagedomains3xxx_data.c:100: undefined reference to `omap36xx_vddcore_volt_data'
> voltagedomains3xxx_data.c:100: undefined reference to `omap34xx_vddcore_volt_data'
> arch/arm/mach-omap2/built-in.o: In function `omap44xx_voltagedomains_init':
> voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_mpu_volt_data'
> voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_iva_volt_data'
> voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_core_volt_data'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kevin Hilman <khilman@ti.com>
> ---
> I got this build error only now after pulling in the latest omap series, but
> I cannot tell what caused it. It's also not clear to me if this is the correct
> solution. Please ack or provide a better fix.
This code was merged for v2.6.39, so not sure why this error is only
showing up for you now. I just tried a !CONFIG_PM_OPP build on v2.6.39
and get the same errors, so it's been lingering.
Maybe you haven't had a randconfig that disabled CONFIG_PM_OPP before?
Anyways, the fix is fine with me.
Kevin
^ permalink raw reply
* Re: [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
From: Kevin Hilman @ 2011-10-10 18:01 UTC (permalink / raw)
To: Santosh Shilimkar; +Cc: linux-omap, linux-arm-kernel
In-Reply-To: <1316844884-21700-1-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
> suspend (S2R), CPU hotplug and CPUidle.
There are a few more compile errors when doing OMAP1-only builds.
You'll need a way to eliminate the secure calls for OMAP1.
This series causes a couple build errors when doing OMAP1-only builds
(I used omap1_defconfig):
First:
/work/kernel/omap/pm/arch/arm/plat-omap/common.c:24:30: fatal error: mach/omap-secure.h: No such file or directory
And trying creating a dummy header to see if it would continue to build gives:
/work/kernel/omap/pm/arch/arm/plat-omap/common.c: In function 'omap_reserve':
/work/kernel/omap/pm/arch/arm/plat-omap/common.c:70:2: error: implicit declaration of function 'omap_secure_ram_reserve_memblock'
make[2]: *** [arch/arm/plat-omap/common.o] Error 1
make[1]: *** [arch/arm/plat-omap] Error 2
Kevin
^ permalink raw reply
* Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Andrei Warkentin @ 2011-10-10 17:37 UTC (permalink / raw)
To: Greg KH
Cc: G, Manjunath Kondaiah, linux-arm-kernel, Grant Likely, linux-omap,
linux-mmc, linux-kernel, Dilan Lee, Mark Brown, Manjunath,
Josh Triplett
In-Reply-To: <20111008155502.GB616@kroah.com>
Hi,
----- Original Message -----
> From: "Greg KH" <greg@kroah.com>
> To: "Josh Triplett" <josh@joshtriplett.org>
> Cc: "G, Manjunath Kondaiah" <manjugk@ti.com>, linux-arm-kernel@lists.infradead.org, "Grant Likely"
> <grant.likely@secretlab.ca>, linux-omap@vger.kernel.org, linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
> "Dilan Lee" <dilee@nvidia.com>, "Mark Brown" <broonie@opensource.wolfsonmicro.com>, Manjunath@jasper.es
> Sent: Saturday, October 8, 2011 11:55:02 AM
> Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
>
I'm a bit of a fly on the wall here, but I'm curious how this impacts suspend/resume.
device_initialize->device_pm_init are called from device_register, so certainly this
patch doesn't also ensure that the PM ordering matches probe ordering, which is bound
to break suspend, right? Was this ever tested with the OMAP target? Shouldn't the
PM change be also part of this patch set? I don't see why you would want to have this in
without the PM changes.
Maybe I have it all wrong though :-).
A
^ permalink raw reply
* Re: [PATCH v2 5/5] regulator: map consumer regulator based on device tree
From: Mark Brown @ 2011-10-10 17:35 UTC (permalink / raw)
To: Rajendra Nayak
Cc: b-cousson, patches, tony, devicetree-discuss, linux-kernel,
grant.likely, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <1318263578-7407-6-git-send-email-rnayak@ti.com>
On Mon, Oct 10, 2011 at 09:49:38PM +0530, Rajendra Nayak wrote:
> Device nodes in DT can associate themselves with one or more
> regulators/supply by providing a list of phandles (to regulator nodes)
> and corresponding supply names.
Mostly looks good.
> +/**
> + * of_get_regulator - get a regulator device node based on supply name
> + * @dev: Device pointer for the consumer (of regulator) device
> + * @supply: regulator supply name
> + *
> + * Extract the regulator device node corresponding to the supply name.
> + * retruns the device node corresponding to the regulator if found, else
> + * returns NULL.
> + */
> +struct device_node *of_get_regulator(struct device *dev, const char *supply)
> +{
Should be static.
> @@ -1178,6 +1225,10 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
> goto found;
> }
> }
> + if (!dev)
> + list_for_each_entry(rdev, ®ulator_list, list)
> + if (strcmp(rdev_get_name(rdev), id))
> + goto found;
>
This looks really strange, we didn't remove any old lookup code and the
DT lookup jumps to found by iself so why are we adding code here?
> + if (supply) {
> + struct regulator_dev *r;
> + struct device_node *node;
> +
> + /* first do a dt based lookup */
> + if (dev) {
> + node = of_get_regulator(dev, supply);
> + if (node)
> + list_for_each_entry(r, ®ulator_list, list)
> + if (node == r->dev.parent->of_node)
> + goto found;
> }
>
> - if (!found) {
> - dev_err(dev, "Failed to find supply %s\n",
> - init_data->supply_regulator);
> - ret = -ENODEV;
> - goto scrub;
> - }
> + /* next try doing it non-dt way */
> + list_for_each_entry(r, ®ulator_list, list)
> + if (strcmp(rdev_get_name(r), supply) == 0)
> + goto found;
>
> + dev_err(dev, "Failed to find supply %s\n", supply);
> + ret = -ENODEV;
> + goto scrub;
> +
> +found:
This is all getting *really* complicated and illegible. I'm not sure
what the best way to structure is but erroring out early looks useful.
^ 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