* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Mark Brown @ 2008-01-03 23:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477D280C.4000800@freescale.com>
On Thu, Jan 03, 2008 at 12:23:08PM -0600, Timur Tabi wrote:
> Mark Brown wrote:
> > To cover everything you'd need to be able to specify all the clocking
> > parameters, especially a PLL configuration, and also specify more than
> > one of each item. Even then you'd still have problems like...
> The ASoC V1 API for communicating clock data from the fabric driver to the
> codec driver only allows for three parameters.
Each individual call to set_sysclk() only takes three parameters but it
can be called repeatedly and some configurations are going to require
this. There's also the set_pll() call which will be required by some
things too (and again that can support multiple PLLs).
For example, something like this isn't unknown:
- Set PLL input to pin A.
- Configure PLL input/output frequencies.
- Set codec system clock source to be the PLL
and of course the ordering matters. You can also have other dividers
and clock sources within the codec which need configuring and other
components outside the codec which need configuring to supply the clocks
to the codec.
> > According to the documentation in your patch the bus frequency should
> > already be optional
> My code does not currently support that configuration, and I don't have any
> hardware that works that way, so I don't know what it would look like. I'm
> just trying to make the driver as flexible as possible, given ASoC V1 constraints.
Indeed. Providing the device tree stuff doesn't get set in stone I'm
not sure we need to nail this down perfectly for ASoC v1 when we're
running into trouble working around it.
^ permalink raw reply
* [PATCh v3] powerpc: add hugepagesz boot-time parameter
From: Jon Tollefson @ 2008-01-03 22:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: arnd, mel, David Gibson, linuxppc-dev, csnook
Paul, please include this in 2.6.25 if there are no objections.
This patch adds the hugepagesz boot-time parameter for ppc64. It lets
one pick the size for huge pages. The choices available are 64K and 16M
when the base page size is 4k. It defaults to 16M (previously the only
only choice) if nothing or an invalid choice is specified.
Tested 64K huge pages successfully with the libhugetlbfs 1.2.
Changes from v2:
Moved functions from header file into hugetlbpage.c where they are used.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 33121d6..2fc1fb8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file
See Documentation/isdn/README.HiSax.
hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages.
+ hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages.
i8042.direct [HW] Put keyboard port into non-translated mode
i8042.dumbkbd [HW] Pretend that controller can only read data from
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index cbbd8b0..9326a69 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -369,18 +369,11 @@ static void __init htab_init_page_sizes(void)
* on what is available
*/
if (mmu_psize_defs[MMU_PAGE_16M].shift)
- mmu_huge_psize = MMU_PAGE_16M;
+ set_huge_psize(MMU_PAGE_16M);
/* With 4k/4level pagetables, we can't (for now) cope with a
* huge page size < PMD_SIZE */
else if (mmu_psize_defs[MMU_PAGE_1M].shift)
- mmu_huge_psize = MMU_PAGE_1M;
-
- /* Calculate HPAGE_SHIFT and sanity check it */
- if (mmu_psize_defs[mmu_huge_psize].shift > MIN_HUGEPTE_SHIFT &&
- mmu_psize_defs[mmu_huge_psize].shift < SID_SHIFT)
- HPAGE_SHIFT = mmu_psize_defs[mmu_huge_psize].shift;
- else
- HPAGE_SHIFT = 0; /* No huge pages dude ! */
+ set_huge_psize(MMU_PAGE_1M);
#endif /* CONFIG_HUGETLB_PAGE */
}
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 71efb38..a02266d 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -24,18 +24,17 @@
#include <asm/cputable.h>
#include <asm/spu.h>
+#define HPAGE_SHIFT_64K 16
+#define HPAGE_SHIFT_16M 24
+
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
-#ifdef CONFIG_PPC_64K_PAGES
-#define HUGEPTE_INDEX_SIZE (PMD_SHIFT-HPAGE_SHIFT)
-#else
-#define HUGEPTE_INDEX_SIZE (PUD_SHIFT-HPAGE_SHIFT)
-#endif
-#define PTRS_PER_HUGEPTE (1 << HUGEPTE_INDEX_SIZE)
-#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) << HUGEPTE_INDEX_SIZE)
+unsigned int hugepte_shift;
+#define PTRS_PER_HUGEPTE (1 << hugepte_shift)
+#define HUGEPTE_TABLE_SIZE (sizeof(pte_t) << hugepte_shift)
-#define HUGEPD_SHIFT (HPAGE_SHIFT + HUGEPTE_INDEX_SIZE)
+#define HUGEPD_SHIFT (HPAGE_SHIFT + hugepte_shift)
#define HUGEPD_SIZE (1UL << HUGEPD_SHIFT)
#define HUGEPD_MASK (~(HUGEPD_SIZE-1))
@@ -82,11 +81,35 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
return 0;
}
+/* Base page size affects how we walk hugetlb page tables */
+#ifdef CONFIG_PPC_64K_PAGES
+#define hpmd_offset(pud, addr) pmd_offset(pud, addr)
+#define hpmd_alloc(mm, pud, addr) pmd_alloc(mm, pud, addr)
+#else
+static inline
+pmd_t *hpmd_offset(pud_t *pud, unsigned long addr)
+{
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
+ return pmd_offset(pud, addr);
+ else
+ return (pmd_t *) pud;
+}
+static inline
+pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr)
+{
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
+ return pmd_alloc(mm, pud, addr);
+ else
+ return (pmd_t *) pud;
+}
+#endif
+
/* Modelled after find_linux_pte() */
pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
{
pgd_t *pg;
pud_t *pu;
+ pmd_t *pm;
BUG_ON(get_slice_psize(mm, addr) != mmu_huge_psize);
@@ -96,14 +119,9 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
if (!pgd_none(*pg)) {
pu = pud_offset(pg, addr);
if (!pud_none(*pu)) {
-#ifdef CONFIG_PPC_64K_PAGES
- pmd_t *pm;
- pm = pmd_offset(pu, addr);
+ pm = hpmd_offset(pu, addr);
if (!pmd_none(*pm))
return hugepte_offset((hugepd_t *)pm, addr);
-#else
- return hugepte_offset((hugepd_t *)pu, addr);
-#endif
}
}
@@ -114,6 +132,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr)
{
pgd_t *pg;
pud_t *pu;
+ pmd_t *pm;
hugepd_t *hpdp = NULL;
BUG_ON(get_slice_psize(mm, addr) != mmu_huge_psize);
@@ -124,14 +143,9 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, unsigned long addr)
pu = pud_alloc(mm, pg, addr);
if (pu) {
-#ifdef CONFIG_PPC_64K_PAGES
- pmd_t *pm;
- pm = pmd_alloc(mm, pu, addr);
+ pm = hpmd_alloc(mm, pu, addr);
if (pm)
hpdp = (hugepd_t *)pm;
-#else
- hpdp = (hugepd_t *)pu;
-#endif
}
if (! hpdp)
@@ -158,7 +172,6 @@ static void free_hugepte_range(struct mmu_gather *tlb, hugepd_t *hpdp)
PGF_CACHENUM_MASK));
}
-#ifdef CONFIG_PPC_64K_PAGES
static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
unsigned long addr, unsigned long end,
unsigned long floor, unsigned long ceiling)
@@ -191,7 +204,6 @@ static void hugetlb_free_pmd_range(struct mmu_gather *tlb, pud_t *pud,
pud_clear(pud);
pmd_free_tlb(tlb, pmd);
}
-#endif
static void hugetlb_free_pud_range(struct mmu_gather *tlb, pgd_t *pgd,
unsigned long addr, unsigned long end,
@@ -210,9 +222,15 @@ static void hugetlb_free_pud_range(struct mmu_gather *tlb, pgd_t *pgd,
continue;
hugetlb_free_pmd_range(tlb, pud, addr, next, floor, ceiling);
#else
- if (pud_none(*pud))
- continue;
- free_hugepte_range(tlb, (hugepd_t *)pud);
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K) {
+ if (pud_none_or_clear_bad(pud))
+ continue;
+ hugetlb_free_pmd_range(tlb, pud, addr, next, floor, ceiling);
+ } else {
+ if (pud_none(*pud))
+ continue;
+ free_hugepte_range(tlb, (hugepd_t *)pud);
+ }
#endif
} while (pud++, addr = next, addr != end);
@@ -526,6 +544,57 @@ repeat:
return err;
}
+void set_huge_psize(int psize)
+{
+ /* Check that it is a page size supported by the hardware and
+ * that it fits within pagetable limits. */
+ if (mmu_psize_defs[psize].shift && mmu_psize_defs[psize].shift < SID_SHIFT &&
+ (mmu_psize_defs[psize].shift > MIN_HUGEPTE_SHIFT ||
+ mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
+ HPAGE_SHIFT = mmu_psize_defs[psize].shift;
+ mmu_huge_psize = psize;
+#ifdef CONFIG_PPC_64K_PAGES
+ hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+#else
+ if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
+ hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+ else
+ hugepte_shift = (PUD_SHIFT-HPAGE_SHIFT);
+#endif
+
+ } else
+ HPAGE_SHIFT = 0;
+}
+
+static int __init hugepage_setup_sz(char *str)
+{
+ unsigned long long size;
+ int mmu_psize = -1;
+ int shift;
+
+ size = memparse(str, &str);
+
+ shift = __ffs(size);
+ switch (shift) {
+#ifndef CONFIG_PPC_64K_PAGES
+ case HPAGE_SHIFT_64K:
+ mmu_psize = MMU_PAGE_64K;
+ break;
+#endif
+ case HPAGE_SHIFT_16M:
+ mmu_psize = MMU_PAGE_16M;
+ break;
+ }
+
+ if (mmu_psize >=0 && mmu_psize_defs[mmu_psize].shift)
+ set_huge_psize(mmu_psize);
+ else
+ printk(KERN_WARNING "Invalid huge page size specified(%llu)\n", size);
+
+ return 1;
+}
+__setup("hugepagesz=", hugepage_setup_sz);
+
static void zero_ctor(struct kmem_cache *cache, void *addr)
{
memset(addr, 0, kmem_cache_size(cache));
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 12e5e77..2fda33c 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -278,6 +278,7 @@ extern int hash_huge_page(struct mm_struct *mm, unsigned long access,
extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
unsigned long pstart, unsigned long mode,
int psize, int ssize);
+extern void set_huge_psize(int psize);
extern void htab_initialize(void);
extern void htab_initialize_secondary(void);
^ permalink raw reply related
* Re: [PATCH] IB/ehca: Forward event client-reregister-required to registered clients
From: Hoang-Nam Nguyen @ 2008-01-03 22:43 UTC (permalink / raw)
To: Roland Dreier
Cc: fenkes, linux-kernel, linuxppc-dev, Christoph Raisch, general,
stefan.roscher
In-Reply-To: <200712201506.34253.hnguyen@linux.vnet.ibm.com>
Hi Roland,
Just want to make sure you've seen this patch and if it looks ok for you.
Thanks
Nam
On Thursday 20 December 2007 15:06, Hoang-Nam Nguyen wrote:
> This patch allows ehca to forward event client-reregister-required to
> registered clients. Such one event is generated by the switch eg. after
> its reboot.
>
> Signed-off-by: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
> ---
> drivers/infiniband/hw/ehca/ehca_irq.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: Drivers' probe function calling order
From: Alessandro Rubini @ 2008-01-03 21:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8EC2DE1E@aquib01a>
> how can I force the system to call
> probe function of the spi driver first?
You can declare their init functions at different initcall level. For
example declaring the dataflash one as late_initcall(). Or declare
the spi one as subsys_initcall() -- whatever makes more sense.
There might be cleaner ways according to your setup, but this will
surely work.
/alessandro
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Scott Wood @ 2008-01-03 19:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <fa686aa40801031113od68e2a3m6cb60b8fa6f26c17@mail.gmail.com>
Grant Likely wrote:
> On 1/3/08, Scott Wood <scottwood@freescale.com> wrote:
>> I'd just link in both directions, and let software follow it in
>> whichever direction it prefers.
>
> Gah! Don't do that! Then you need to maintain both directions in the
> dts file. Software is good at generating reverse mappings.
Software is, however, lousy at correctly wading through
poorly-structured data (which device trees are full of) to figure out
how to locate the link it wants to follow backwards.
-Scott
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-03 19:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <477D2F52.7090306@freescale.com>
On 1/3/08, Scott Wood <scottwood@freescale.com> wrote:
> Grant Likely wrote:
> > On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
> >> Grant Likely wrote:
> >>
> >>> Why not be a child of the i2c bus with a phandle to the ssi bus?
> >> Because when I probe the SSI node, I want to know what the attached codec is.
> >> So if anything, I would need a pointer from the SSI bus *to* the respective
> >> child on the I2C bus.
> >
> > That's fine too (it's what is done with Ethernet PHYs). My preference
> > is the other way around, but it's not a big issue in this case.
>
> I'd just link in both directions, and let software follow it in
> whichever direction it prefers.
Gah! Don't do that! Then you need to maintain both directions in the
dts file. Software is good at generating reverse mappings. Don't put
that burden on the dts author. (the software principle of defining
things in one place only applies here)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Reading a config file in a driver ....
From: Carlos Munoz @ 2008-01-03 18:43 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <20080103163019.GA4223@lixom.net>
Olof Johansson wrote:
> On Wed, Jan 02, 2008 at 09:03:20PM -0800, Misbah khan wrote:
>
>> Hi all ....
>>
>> I am writing a LCD driver in which the default configuration for LCD would
>> be loded at the Init . This default configuration if keep in the driver then
>> for a change in default configuration we need to compile the driver which we
>> never want . Hence we want a .config file in /etc/lcd.config dir which could
>> be changed and the next boot will take this configuration as the default
>> configuration.
>>
>> I need to know How to read from the config file in the driver form the dir
>> /etc/lcd.config. The driver would be installed at boot up
>>
>
> The driver/kernel shouldn't read the file directly, if anything you
> should have a userspace tool that reads it and adjusts the driver via
> sysfs or similar. That tool can be run from some of the init scripts,
> or from the ramdisk in case you want to do it early.
>
What I've done in the past is to use module_param() to define variables
that get set when the module is loaded. Then all you need to do is edit
the /etc/modules file and change the parameter value. However, this
technique is only efficient if only a few parameters will ever change.
If you need to change more than a few parameters, Olof's suggestion
would be preferred.
Carlos
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Scott Wood @ 2008-01-03 18:54 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <fa686aa40801031017n42f6fbf1nb2da5097ef13cf3c@mail.gmail.com>
Grant Likely wrote:
> On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
>> Grant Likely wrote:
>>
>>> Why not be a child of the i2c bus with a phandle to the ssi bus?
>> Because when I probe the SSI node, I want to know what the attached codec is.
>> So if anything, I would need a pointer from the SSI bus *to* the respective
>> child on the I2C bus.
>
> That's fine too (it's what is done with Ethernet PHYs). My preference
> is the other way around, but it's not a big issue in this case.
I'd just link in both directions, and let software follow it in
whichever direction it prefers.
-Scott
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-03 18:38 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477D296A.6040202@freescale.com>
On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > Make the compatible property tell you! :-) If it's connected to an
> > I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or
> > for AC7, compatible = "fsl,mpc8610-ssi,ac97"
>
> That won't work. There are too many variations. I think a separate property
> just makes more sense. Frankly, I don't see what's wrong with it.
Sure it will, that's exactly what I'm doing with the 5200, but I won't
argue the point. My *opinion* is that using compatible is a more
elegant approach for this type of multifunction device, but using a
mode property is neither wrong or bad.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-03 18:32 UTC (permalink / raw)
To: Timur Tabi; +Cc: Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <477D276B.2060300@freescale.com>
On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > The device tree is a description of the hardware; not software. It's
> > not a good idea to break with convention due to current driver
> > architecture.
>
> I believe that with ASoC V1, I'm stuck between a rock and a hard place, and so
> the only way to make this code work is to bend some rules. Right now, the
> CS4270 driver does not support platform drivers or the device tree, so there's
> no point in putting a child I2C node for it. As I mentioned in other posts, I
> will be more than happy to update the CS4270 driver to support this new
> paradigm (which was invented after the CS4270 driver was written) *after* this
> current patchset is applied.
If you need to bend rules, then do it in a place where it won't bite
us in the butt down the road. (ie. not with the device tree). Do
hacky stuff in the platform code if you need to because it can be
changed easily down the road.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:28 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40801031025r10c31ce6x203755fe532f0c88@mail.gmail.com>
Grant Likely wrote:
> Make the compatible property tell you! :-) If it's connected to an
> I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or
> for AC7, compatible = "fsl,mpc8610-ssi,ac97"
That won't work. There are too many variations. I think a separate property
just makes more sense. Frankly, I don't see what's wrong with it.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
From: Scott Wood @ 2008-01-03 18:26 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <477D28D3.3000102@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
>>>>> +static struct of_platform_driver ucc_uart_of_driver = {
>>>>> + .owner = THIS_MODULE,
>>>>> + .name = "ucc_uart",
>>>> Maybe better fsl,ucc_uart?
>>
>> fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
>
> Wait, I'm confused. What does the of_platform_driver.name string have
> to do with the compatible field in the device tree?
Bah. Details.
/me resolves to read the context next time.
-Scott
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-03 18:25 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477D25F4.6020700@freescale.com>
On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > Does that mean with ASoC V2 you can instantiate it with the board
> > specific platform code instead?
>
> I don't know. I haven't really looked at V2 yet. You'll have to ask Liam
> Girdwood.
>
> > This is one of the examples of where the compatible properties are
> > trying to be far to generic about what they are. How do you define
> > what "fsl,ssi" is?
>
> The SSI is a specific Freescale device, so I think it's pretty well defined.
>
> > What happens when Freescale produces another
> > peripheral that can do ssi but isn't register level compatible?
>
> It won't be called the SSI. It will be called something else.
Heh, I've seen enough to know that it's virtually impossible for a
company to maintain a consistent naming scheme all the time. Better
to be specific now and add generic names sometime in the future rather
than the other way around.
> > In my opinion, it is far better to be specific in the device tree and
> > teach the driver about what versions it is able to bind against. In
> > this case, I would use "fsl,mpc8610-ssi" or maybe better yet:
> > "fsl,mpc8610-ssi,i2s" (MPC8610 SSI device in I2S mode).
>
> I can work with that, but the SSI could be placed into any future 83xx, 85xx,
> or 86xx SOC, and the driver will still work with it as-is.
The have the device trees claim compatibility with the older
fsl,mpc8610-ssi device specifically. ie: compatible =
"fsl,mpc83<whatever>-ssi,ac97", "fsl,mpc8610-ssi,ac97";
>
> > I don't like the idea of a separate fsl,mode property to describe the
> > behaviour of multifunction peripherals. It makes probing more
> > difficult when there is a different driver for each mode.
>
> Can you propose an alternative? The driver needs to know what mode to use
> when communicating with its codec. How am I supposed to know if I have an I2S
> codec or an AC97 codec?
Make the compatible property tell you! :-) If it's connected to an
I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or
for AC7, compatible = "fsl,mpc8610-ssi,ac97"
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v2] ucc_uart: add support for Freescale QUICCEngine UART
From: Timur Tabi @ 2008-01-03 18:26 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080102181226.GA4486@loki.buserror.net>
Scott Wood wrote:
>>>> +static struct of_platform_driver ucc_uart_of_driver = {
>>>> + .owner = THIS_MODULE,
>>>> + .name = "ucc_uart",
>>> Maybe better fsl,ucc_uart?
>
> fsl,qe-uart is defined by Documentation/powerpc/booting-without-of.txt.
Wait, I'm confused. What does the of_platform_driver.name string have to do
with the compatible field in the device tree? Like I said earlier, I'm just
following the example of the other QE device drivers. If you want me to break
that example, I'm going to need an explanation why the other drivers do it wrong.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:23 UTC (permalink / raw)
To: Timur Tabi, Jon Smirl, linuxppc-dev, alsa-devel
In-Reply-To: <20080102172340.GA2007@sirena.org.uk>
Mark Brown wrote:
>> clock1 = <0, bb8000>
>
>> Would that be better?
>
> To cover everything you'd need to be able to specify all the clocking
> parameters, especially a PLL configuration, and also specify more than
> one of each item. Even then you'd still have problems like...
The ASoC V1 API for communicating clock data from the fabric driver to the
codec driver only allows for three parameters.
> According to the documentation in your patch the bus frequency should
> already be optional
My code does not currently support that configuration, and I don't have any
hardware that works that way, so I don't know what it would look like. I'm
just trying to make the driver as flexible as possible, given ASoC V1 constraints.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:20 UTC (permalink / raw)
To: Grant Likely; +Cc: Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <fa686aa40801031013w54b15286u8e6e2561219422f2@mail.gmail.com>
Grant Likely wrote:
> The device tree is a description of the hardware; not software. It's
> not a good idea to break with convention due to current driver
> architecture.
I believe that with ASoC V1, I'm stuck between a rock and a hard place, and so
the only way to make this code work is to bend some rules. Right now, the
CS4270 driver does not support platform drivers or the device tree, so there's
no point in putting a child I2C node for it. As I mentioned in other posts, I
will be more than happy to update the CS4270 driver to support this new
paradigm (which was invented after the CS4270 driver was written) *after* this
current patchset is applied.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* RE: MPC8260ADS and linux-2.6
From: Rune Torgersen @ 2008-01-03 18:18 UTC (permalink / raw)
To: Scott Wood, suja Baburaj; +Cc: linuxppc-embedded
In-Reply-To: <477D2255.3040803@freescale.com>
> From: Scott Wood
> Sent: Thursday, January 03, 2008 11:59 AM
> To: suja Baburaj
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC8260ADS and linux-2.6
>=20
> suja Baburaj wrote:
> > I have an MPC8260ADS board with (eldk)linux-2.4.25 working=20
> fine on it.
> > Now i want to try linux-2.6.X on the board.
>=20
> There's no support for that specific board in mainstream 2.6=20
> yet, but it=20
> should be fairly simple to get it working using the=20
> mpc8272ads support=20
> as an example.
There is support, but it is in arch/ppc not arch/powerpc
(PQ2FADS support works for this board in arch/ppc)
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-03 18:17 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477D24AA.4050804@freescale.com>
On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
> Grant Likely wrote:
>
> > Why not be a child of the i2c bus with a phandle to the ssi bus?
>
> Because when I probe the SSI node, I want to know what the attached codec is.
> So if anything, I would need a pointer from the SSI bus *to* the respective
> child on the I2C bus.
That's fine too (it's what is done with Ethernet PHYs). My preference
is the other way around, but it's not a big issue in this case.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:16 UTC (permalink / raw)
To: Timur Tabi, Jon Smirl, linuxppc-dev, alsa-devel
In-Reply-To: <20080103044432.GB25357@localhost.localdomain>
David Gibson wrote:
> Instantiating the fabric driver off any node is wrong, precisely
> because it is an abstraction. The fabric driver should be
> instantiated by the platform code.
Can you tell me how to do that?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:16 UTC (permalink / raw)
To: Grant Likely, Timur Tabi, linuxppc-dev, alsa-devel
In-Reply-To: <20080102184957.GB2007@sirena.org.uk>
Mark Brown wrote:
> The machine support code (fabric driver in PowerPC terms, I think?)
> tells the core how everything is connected together by registering
> devices representing the links (eg, I2S) between the codecs, CPU and
> other devices. The ASoC core is then responsible for ensuring that all
> the required components are present before it registers with the ALSA
> core.
I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal*
situation would be if the ASoC fabric driver were generic, maybe even part of
ASoC itself, and everything it needed could be obtained from the device tree.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Grant Likely @ 2008-01-03 18:13 UTC (permalink / raw)
To: Timur Tabi; +Cc: Liam Girdwood, alsa-devel, linuxppc-dev
In-Reply-To: <477D2150.4020506@freescale.com>
On 1/3/08, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
> > Don't we want to follow the device tree policy of putting the device
> > on the controlling bus and then link it to the data bus?
>
> Normally, that sounds like a good idea, but the cs4270 is an I2S device first,
> and an I2C device second. I need to be able to find that codec from the I2S
> node. My I2S driver would not know to scan all I2C devices to find the codec.
The device tree is a description of the hardware; not software. It's
not a good idea to break with convention due to current driver
architecture.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40801020828u5103d09cn2aa5eab7dda2fcff@mail.gmail.com>
Grant Likely wrote:
> Does that mean with ASoC V2 you can instantiate it with the board
> specific platform code instead?
I don't know. I haven't really looked at V2 yet. You'll have to ask Liam
Girdwood.
> This is one of the examples of where the compatible properties are
> trying to be far to generic about what they are. How do you define
> what "fsl,ssi" is?
The SSI is a specific Freescale device, so I think it's pretty well defined.
> What happens when Freescale produces another
> peripheral that can do ssi but isn't register level compatible?
It won't be called the SSI. It will be called something else.
> In my opinion, it is far better to be specific in the device tree and
> teach the driver about what versions it is able to bind against. In
> this case, I would use "fsl,mpc8610-ssi" or maybe better yet:
> "fsl,mpc8610-ssi,i2s" (MPC8610 SSI device in I2S mode).
I can work with that, but the SSI could be placed into any future 83xx, 85xx,
or 86xx SOC, and the driver will still work with it as-is.
> I don't like the idea of a separate fsl,mode property to describe the
> behaviour of multifunction peripherals. It makes probing more
> difficult when there is a different driver for each mode.
Can you propose an alternative? The driver needs to know what mode to use
when communicating with its codec. How am I supposed to know if I have an I2S
codec or an AC97 codec?
>> The fabric driver is specific to the board. So you should be using
>> Kconfig to select the fabric driver. There is no node in the device
>> tree for fabric drivers. I thought that was the consensus.
>
> No, the desire is to go multiplatform in ppc. That means you cannot
> use Kconfig to select the correct fabric driver.
I don't see any way of avoiding this with ASoC V1.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-03 18:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <fa686aa40801020812o471e18e6u9fe20676d320e958@mail.gmail.com>
Grant Likely wrote:
> Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to know what the attached codec is.
So if anything, I would need a pointer from the SSI bus *to* the respective
child on the I2C bus.
I know little about platform devices/drivers, so I don't know how to use them.
Currently, I have a design flaw in my driver in that if I have two SSIs, and
each one is attached to a CS4270, I don't have any way of making sure that the
right CS4270 is using the right I2C address. I'm guessing that if I switch to
a platform-based model, I can resolve this issue. But for now, the CS4270
doesn't support that, so that patchset I have submitted works with what I
have. After my patchset has been applied, I'll be more than happy to look
into updating the CS4270 (and everything else) to use the platform model for I2C.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Drivers' probe function calling order
From: Jeff Mock @ 2008-01-03 18:04 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8EC2DE1E@aquib01a>
The only way I've know to do this is to build the drivers as modules and
load them in the desired order from the startup scripts called from init.
If there's a better way I would like to know about it also...
jeff
DI BACCO ANTONIO - technolabs wrote:
> How can I fix the calling order of two monolithic drivers? I have an spi
> driver and a driver for a dataflash, how can I force the system to call
> probe function of the spi driver first?
>
> Bye and thanks.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: MPC8260ADS and linux-2.6
From: Scott Wood @ 2008-01-03 17:58 UTC (permalink / raw)
To: suja Baburaj; +Cc: linuxppc-embedded
In-Reply-To: <a3b98ac10801022105w240b0f96race4d3aa84e51f27@mail.gmail.com>
suja Baburaj wrote:
> I have an MPC8260ADS board with (eldk)linux-2.4.25 working fine on it.
> Now i want to try linux-2.6.X on the board.
There's no support for that specific board in mainstream 2.6 yet, but it
should be fairly simple to get it working using the mpc8272ads support
as an example.
-Scott
^ 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