On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan wrote:
> Have just sent out a patch considering the previous discussion.
> http://patchwork.ozlabs.org/patch/462249/
> [PATCH] powerpc/defconfig: new way of writing defconfig
The ability to merge defconfigs is a feature that's been requested by
many pe
On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote:
>
>
> The ability to merge configs is already there. We're just talking about
> using that functionality.
Why do you need a powerpc-specific way to use merge_config.sh? Other
architectures have the same problem with defconfigs.
Besides, wouldn
Scott Wood wrote:
>
>Why do you need a powerpc-specific way to use merge_config.sh? Other
>architectures have the same problem with defconfigs.
What are you perceiving as "powerpc-specific" about what we're
proposing?
Well, there's the subject of this thread, which is "new way of writing
d
Scott Wood wrote:
We want single-name config targets to still work from the user's
perspective, but we want to reduce the (often imperfect) duplication
under the hood.
Ok, then define a new Kconfig option that merge_config.sh will look for.
So in p1_defconfig, there will be this line:
CONFI
On 04/21/2015 12:55 PM, Scott Wood wrote:
>
>Ok, then define a new Kconfig option that merge_config.sh will look for.
> So in p1_defconfig, there will be this line:
>
>CONFIG_OTHER_DEFCONFIGS=fsl_basic_config
If you want to do that go ahead. In the meantime we'll use the
mechanism that alread
Shengjiu Wang wrote:
+ if (ssi_private->soc->imx)
+ clk_prepare_enable(ssi_private->clk);
How about this instead?
if (ssi_private->clk)
clk_prepare_enable(ssi_private->clk);
___
Linuxppc-dev mailing list
Linuxppc-dev@list
On 09/09/2014 10:21 AM, Mark Brown wrote:
if (ssi_private->clk)
>clk_prepare_enable(ssi_private->clk);
Should be a !IS_ERR() - NULL is a valid clock.
In that case, ssi_private->clk needs to be initialized to -EINVAL or
something, so that the check works on systems that don't have any cl
On 09/09/2014 01:38 PM, Nicolin Chen wrote:
make sure to have the call for imx only because it seems that
the other platforms do not depend on the clock.
Although I doubt anyone will every add support for clocks to PowerPC
"side" of this driver, I would prefer to avoid IMX-specific changes.
I
On 09/09/2014 02:59 PM, Nicolin Chen wrote:
+ /*
+* Initially mark the clock to NULL for all platforms so that later
+* clk_prepare_enable() will ignore and return 0 for non-clock cases.
+*/
+ ssi_private->clk = NULL;
According to Mark, NULL is a valid clock,
On 09/09/2014 03:27 PM, Nicolin Chen wrote:
I guess Mark's comment is merely against the check for clk validation
because if talking about clk validation, we should check IS_ERR(clk)
rather than check !=NULL directly.
Ah, that makes sense now.
However, my approach doesn't need any check. The
Shengjiu Wang wrote:
+ ret = clk_prepare_enable(ssi_private->clk);
+ if (ret)
+ return ret;
Will this work on PowerPC, where ssi_private->clk is always NULL?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https:/
On Fri, Oct 10, 2014 at 1:05 PM, Scott Wood wrote:
> There are many changes in here that ought to be separate patches with
> separate justification.
>
> Also, some of the QE changes seem to be reasonable cleanup, but not
> related to making the code work on ARM.
I agree with Scott. This patch al
On 12/01/2014 10:49 AM, Lars-Peter Clausen wrote:
The driver creates the mapping by calling irq_of_parse_and_map(), so it
also has to dispose the mapping. But the easy way out is to simply use
platform_get_irq() instead of irq_of_parse_map(). In this case the
mapping is not managed by the device
On 12/01/2014 10:49 AM, Lars-Peter Clausen wrote:
The driver creates the mapping by calling irq_of_parse_and_map(), so it
also has to dispose the mapping.
I agree with Markus, this does seem weird. It sounds like you're saying
that irq_of_parse_and_map() and devm_request_irq() are incompatibl
On 12/01/2014 01:56 PM, Arnd Bergmann wrote:
All other drivers that call irq_of_parse_and_map and pass that into
devm_request_irq just never unmap, and their interrupts are already
mapped by the platform code, so I think it's not even a leak.
Does this mean that fsl_ssi.c should not be calling
On 12/01/2014 02:01 PM, Arnd Bergmann wrote:
>Does this mean that fsl_ssi.c should not be calling
>irq_of_parse_and_map? How else should it get the IRQ?
platform_get_irq()
Ok, but that function also calls irq_create_of_mapping(). So it still
appears that the only way to get the IRQ is to ma
On 12/01/2014 02:40 PM, Fabio Estevam wrote:
>Hm... that's new. But it's not really a driver issue anymore if it is done
>in the core. So I guess for now just use platform_get_irq() and ignore the
>other issue.
With the suggested changes below, the removal of the driver works fine on a mx6:
On Thu, May 16, 2013 at 1:52 AM, Benjamin Herrenschmidt
wrote:
>> 3) run " pix altbak" command
>>
>> 4) check you are on bank4
>
> It stays on bank 0
pix altbank
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listin
GFP_KERNEL);
Nicolin's patch is wrong. Do not apply it.
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Libo Chen wrote:
when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen
Acked-by: Timur Tabi
Thanks for catching this.
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
Benjamin Herrenschmidt wrote:
PHY reset timed out
PHY reset timed out
PHY reset timed out
PHY reset timed out
This usually means that your RCW does not match your dip switch settings.
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev
27;t had a chance to review the patch in detail, but I can tell you
that breaking compatibility with older device trees is unacceptable. You
need to add some code, even if it's an ugly hack, to support those trees.
--
Timur Tabi
___
Linuxppc-dev
On Wed, Jun 12, 2013 at 1:31 PM, Scott Wood wrote:
>
> I'm not sure it's stable material if this is something that has never
> worked...
>
> The device tree binding will also need to be fixed to note the difference in
> "reg" between "fsl,gianfar-mdio" and "fsl-gianfar-tbi" -- and should give an
>
R("Alexander Popov ");
+MODULE_DESCRIPTION("MPC512x LocalPlus FIFO device driver");
+MODULE_LICENSE("GPL");
aren't these usually at the end of the source for quick lookup?
Yes, and it should be "GPL v2" also.
--
Timur Tabi
___
k hasn't
pushed it to the branch yet.
Please test it for me. Thank you.
I definitely want to. Unfortunately, I'm literally in the middle of
moving into a new house, and so everything is packed up. I won't be able
to look at it for
Nicolin Chen wrote:
Oh, I see. Actually we've been using this patch for quite a while,
it should be okay.
Have you tested it on PowerPC?
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/lis
e PowerPC SDK and do
compile tests? At least that way you won't have to wait for me for every
little thing.
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Jul 18, 2013 at 4:30 PM, Peter LaDow wrote:
>
> It does seem that for incoming PCI transactions the Freescale DMA
> engine is not used. And in our device tree we have the DMA engine
> commented out. That is, the "fsl,mpc8349-dma" and "fsl,elo-dma"
> compatible items are not present in th
in Chen
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Maciej S. Szmigiero wrote:
+ if (newbinding && fsl_ssi_is_ac97(ssi_private)) {
Is the "newbinding" necessary? I thought only the original PowerPC
device trees were the only one that have the old binding, and they never
supported AC97.
___
Li
Maciej S. Szmigiero wrote:
If there isn't going to be new platforms added with old bindings then this
won't be needed - I'll remove it.
I would love it if someone would port those original device trees to the
new binding, so that we can get rid of the old one. But we should
definitely not a
Maciej S. Szmigiero wrote:
/* Are the RX and the TX clocks locked? */
if (!of_find_property(np, "fsl,ssi-asynchronous", NULL)) {
- ssi_private->cpu_dai_drv.symmetric_rates = 1;
+ if (!fsl_ssi_is_ac97(ssi_private))
+ ssi_private->cp
On Jul 6, 2015, at 4:49 AM, Zidan Wang wrote:
> The register SFCSR is volatile, but some bits in it need to be
> recovered after suspend/resume.
>
> Signed-off-by: Zidan Wang
Shouldn't this be part of patch #1?
___
Linuxppc-dev mailing list
Linuxppc-d
On Jul 6, 2015, at 4:49 AM, Zidan Wang wrote:
> +static bool fsl_ssi_readable_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case CCSR_SSI_STX0:
> + case CCSR_SSI_STX1:
> + case CCSR_SSI_SRX0:
> + case CCSR_SSI_SRX1:
> + case CCSR_SSI_SCR:
> + ca
Dongsheng Wang wrote:
For deep sleep, the diu module will power off, when wake up
from the deep sleep, the registers need to be reinitialized.
Signed-off-by: Jason Jin
Signed-off-by: Wang Dongsheng
Acked-by: Timur Tabi
___
Linuxppc-dev mailing
Wang Dongsheng wrote:
Thanks Timur.
@Scott,
Could you apply this patch?
You need to ask the fbdev maintainer to apply it, because it has to go
through his tree.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/l
On Wed, Aug 21, 2013 at 6:31 PM, Scott Wood wrote:
>
>> > Other than "this is how the existing binding works and we're not going
>> > to break compatibility", it allows the OS more flexibility to choose
>> > whether to bind to controllers or directly to the channels. Sometimes a
>> > channel will
On Thu, Sep 19, 2013 at 4:00 AM, Prabhakar Kushwaha
wrote:
> - Video
> - DIU supports video at up to 1280x1024x32bpp
You mention DIU support, except there's no DIU enablement in the
platform file. You need the T104x equivalent of
p1022ds_set_pixel_clock() and the other functions.
Kushwaha Prabhakar-B32579 wrote:
My primary object is to put base patch in Linux. once it done other things can
be enabled one by one.
Any features which are not enabled must be specified in the patch
description. The patch says that the board supports DIU, but the code
doesn't, so that's m
Prabhakar Kushwaha wrote:
I think patch set is OK for now. No need to send v4.
It needs an updated patch description because the patch lies. It
advertises DIU support, which is not true.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Scott Wood wrote:
The patch is not "lying". It is describing the board, not what the
patch supports. This was something you used to constantly tell people
to do...
The patch says:
"DIU supports video at up to 1280x1024x32bpp"
How is this not misleading?
I understand that the patch
Scott Wood wrote:
>I think it should be okay to leave the DIU node. I think the kernel
>will crash if you try to enable a DIU console (video= on the kernel
>command line), but I think it's okay to ignore that for the moment.
Sounds like a bug in the DIU driver. It should fail gracefully in t
On Tue, Sep 24, 2013 at 8:06 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, linux-next builds (powerpc allmodconfig)
> fail like this:
>
> drivers/tty/ehv_bytechan.c:362:1: error: type defaults to 'int' in
> declaration of 'console_initcall' [-Werror=implicit-int]
>
> C
On Wed, Sep 18, 2013 at 6:02 AM, Minghuan Lian
wrote:
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 38f3b7e..6fd6348 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -690,6 +690,7 @@ config FSL_SOC
>
> config FSL_PCI
> bool
> + select PCI_F
On Sun, Sep 29, 2013 at 8:52 PM, Lian Minghuan-b31939
wrote:
>
> How about PCI_FSL_COMMON?
That's not any better. The problem is that you have two symbols for
generic/common FSL PCI support. Adding the word "common" does not
help. You need to make the symbols distinct. Either that, or merge
t
On Mon, Sep 30, 2013 at 10:49 PM, Prabhakar Kushwaha
wrote:
>
> do we have any scripts which check for whitespace as checkpatch never give
> any warning/error.
> it is a very silly mistake which I am doing continuously :(
Use a proper code editor. I've never had this problem, so I'm
guessing you
Xiubo Li wrote:
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ sai->base = devm_ioremap_resource(&pdev->dev, res);
Why not use of_iomap()?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/list
Lars-Peter Clausen wrote:
>>+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>+sai->base = devm_ioremap_resource(&pdev->dev, res);
>
>Why not use of_iomap()?
Because it won't check for conflicting resource regions.
Maybe I've been out of the loop for too long, but why is that a
Lars-Peter Clausen wrote:
>Maybe I've been out of the loop for too long, but why is that a particular
>problem with this driver?
It is usually something you'd want to check in general to make sure that you
don't have multiple device that access the same iomem region at the same time.
I under
Xiubo Li-B47053 wrote:
The CONFIG_SND_SOC_FSL_SGTL5000 micro will be renamed to
CONFIG_SND_SOC_FSL_SGTL5000_VF610.
In VF610, there has not Power Manager Module, so whether the CONFIG_REGULATOR
is enable or
Disabled, there will always some errors booting...
That's just not acceptable. You hav
Nicolin Chen wrote:
This patch enables Tx-related SIER_FLAGS only when direction is PLAYBACK
and does same thing for CAPTURE. Also, after TRIGGER_STOP/PAUSE, it will
disable SIER_xFLAGS for symmetric.
I'm okay with this patch in principle, but why bother? The sysfs entry
is going to display a
Nicolin Chen wrote:
Well, actually I just wanted to clear T/RDMAE to disable DMA request,
but it seems to be much easier to do it like this based on current
code and disabling unused interrupts should be better right?:)
It's not better if it complicates the code and has no real impact. The
co
Nicolin Chen wrote:
The DMA request might be remaining high if not disabling it.
Might? Are you just guessing?
This would
cause SDMA re-check this request, while it has no BD existing. For the
other interrupts, if you don't like it, I can drop it. Just modification
to the driver might not be
Nicolin Chen wrote:
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
Have you measured any real performance gain with this patch? I
considered adding dual-FIFO support when I originally wrote this
Chen Guangyu-B42378 wrote:
Without dual fifo support, handware underrun would occasionally
occur and then two audio channels would physically swap. This could
be easily reproduced in low bus frequency situation, while it would
be better if we enable dual fifo.
Ok.
ACK.
___
Chen Guangyu-B42378 wrote:
I mean there is a possibility.
I'm sorry if my patch is kinda annoying and it really bother you, sir. I also
want to make things better.
It does not bother me. I'm glad people are working on my driver. I
just want to make sure that my driver does not get bloate
Nicolin Chen wrote:
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
+ } else {
+
Li Xiubo wrote:
But fsl-ssi.o and fsl-spdif.o is based PowrePC platform? Which we can see from
the comments.
fsl_ssi was originally PPC-only, but it now supports PPC and ARM. You
can see that from the git history.
If there are any comments that say PPC but are not PPC-specific, that
shoul
Li Xiubo wrote:
If there are any comments that say PPC but are not PPC-specific, that
>should be fixed.
Yes, find it.
The comments is in "sound/soc/fsl/Makefile" :
+++
"# Freescale PowerPC SSI/DMA Platform Support"
---
But fsl-spdif.o is also under it.
And this is also support
On Mon, Nov 11, 2013 at 1:25 PM, Lijun Pan wrote:
> +CONFIG_P1023_RDB=y
I think this is the only line you should be adding to the defconfigs.
None of the others should be necessary.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lis
From: Timur Tabi
The Freescale DIU driver was recently updated to not require a
set_monitor_port platform function if there is only one monitor port. This
is the case on the P1022 RDK and the MPC5121 ADS boards. So now we can
remove those functions.
Signed-off-by: Timur Tabi
---
arch
From: Timur Tabi
Fix and/or improve the compatible strings of the PCI device tree nodes for
some Freescale SOCs. This fixes some issues and improves consistency among
the SOCs.
Specifically:
1) The P1022 has a v1 PCIe controller, so the compatible property should just
say "fsl,mpc8548
From: Timur Tabi
The PAMU caches use the LIODNs to determine which cache lines hold the
entries for the corresponding LIODs. The LIODNs must therefore be
carefully assigned to avoid cache thrashing -- two active LIODs with
LIODNs that put them in the same cache line.
Currently, LIODNs are
From: Timur Tabi
The Freescale DIU driver was recently updated to not require every DIU
platform function, so now we can remove the unneeded functions from
some boards.
Signed-off-by: Timur Tabi
---
arch/powerpc/platforms/512x/mpc512x_shared.c |5 ---
arch/powerpc/platforms/85xx
+ return -ENOMEM;
> + }
> +
> + out_be32(&lpc->cs_cfg[cs], val);
You forgot the iounmap() if lpc == NULL.
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(mpc512x_cs_config);
EXPORT_SYMBOL, please, to match the rest of the Freescale platforms.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Fri, Feb 1, 2013 at 6:31 PM, Scott Wood wrote:
>
> I guess the reason you're not using fsl/mpc8548si-post.dtsi is that you
> don't want PCI. Maybe PCI and srio should be moved out of that file, or
> ifdeffed if 85xx ever ends up using the preprocessor for its device trees.
Wouldn't it be easi
__be32 will *avoid* sparse warnings.
You forgot the iounmap() if lpc == NULL.
No, it is intentional, no need to map/unmap again and again for all
subsequent calls.
Sorry, for some reason I thought that lpc was a parameter that you passed in.
--
Timur Tabi
On Sat, Feb 2, 2013 at 1:25 PM, Stef van Os wrote:
>> I guess the reason you're not using fsl/mpc8548si-post.dtsi is that you
>> don't want PCI. Maybe PCI and srio should be moved out of that file, or
>> ifdeffed if 85xx ever ends up using the preprocessor for its device trees.
>>
> I went with
bled";
+ };
I was hoping you'd follow my example and include a comment indicating
why the PCI devices are all disabled.
+static void ppa8548_show_cpuinfo(struct seq_file *m)
+{
+ uint svid, phid1;
Please don't used unsized integers for hardware registers.
erface after loading firmware into it. A driver
> can easily reconfigure the LPC CS parameters using this function.
>
> Signed-off-by: Anatolij Gustschin
> ---
Acked-by: Timur Tabi
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-d
On Tue, Feb 12, 2013 at 3:08 AM, Stefan Roese wrote:
> +* First try to read MAC address from DT
> +*/
> + p = of_get_property(np, "local-mac-address", NULL);
of_get_mac_address()
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.oz
eescale PowerQUICC III MPC8548 processor
> - 1 GB DDR2 @ 266 MHz
> - 8 MB NOR flash
> - Serial RapidIO 1.2
> - 1 x 10/100/1000 BASE-T front ethernet
> - 1 x 1000 BASE-BX ethernet on AMC connector
>
> Signed-off-by: Stef van Os
Acked-by: Timur Tabi
_
t year in patches.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Fri, Mar 8, 2013 at 10:47 AM, Timur Tabi wrote:
>
> You forgot to update p1022ds_3b.dts.
I meant p1022ds_32b.dts -- the 32-bit DTS for the P1022DS.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxp
24 2 0 0
> + 16 2 1 1>;
> + };
You need to add the PAMU topology.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
r you!
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Mar 21, 2013 at 4:26 AM, Zhicheng Fan wrote:
> + qe: qe@fffe8 {
> + ranges = <0x0 0xf 0xffe8 0x4>;
Are you sure this works? The QE can't handle 36-bit addresses, and I
think the MURAM is located inside the QE address space.
hysical address. Your patch *can* work if you
*also* set this register to 0xF. Look for that register.
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Fri, Mar 22, 2013 at 1:43 AM, Zhicheng Fan wrote:
> + qe: qe@fffe8 {
> + ranges = <0x0 0xf 0xffe8 0x4>;
> + reg = <0xf 0xffe8 0 0x480>;
> + brg-frequency = <0>;
> + bus-frequency = <0>;
These four lines should be un
On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel wrote:
> > + panic("\n");
>
> A kernel panic seems like an over-reaction to an access violation.
We have no way to determining what code caused the violation, so we
can't just kill the process. I agree it seems like overkill, but what
else shoul
On Tue, Apr 9, 2013 at 10:36 PM, wrote:
>
> + /* Found it! return success */
I'm pretty sure this comment is in the wrong place.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxpp
Tang Yuantian-B29983 wrote:
>On Tue, Apr 9, 2013 at 10:36 PM, wrote:
> >
> >+ /* Found it! return success */
>
>I'm pretty sure this comment is in the wrong place.
It is not perfect, but acceptable.
Like I said, I'm pretty sure it&
Tang Yuantian-B29983 wrote:
It was placed on ELSE statement originally, I moved it to IF statement.
Why is it so wrong?
Because the logic of the comment applies to the else-condition, not the
if-condtion.
--
Timur Tabi
___
Linuxppc-dev mailing
On Wed, Apr 17, 2013 at 9:57 AM, Grant Likely wrote:
>
>> I really preciate if you can spend some times to review this patch.
>
> Applied, thanks.
Pff. Why do I bother?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.or
On 05/30/2014 01:03 AM, eshe168 wrote:
@timur
hi,
Audio card (wm8776) cannot work in full duplex, CPU is FSL P1022.
The PCB design about audio card reference FSL P1022 development board,
and palying or recording is OK separately.
My question is whether P1022 audio driver cannot support full duple
eshe...@gmail.com wrote:
I have another question. Did you test full duplex in P1022 RDK board?
Our design is same with P1022 RDK.
No, I don't think I did. The P1022RDK was not a board that my team was
responsible for, so I only did minimal work on it. I added support for
it in the upstream
On Thu, Dec 12, 2013 at 4:44 AM, Nicolin Chen
wrote:
>
> +static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
> + int clk_id, unsigned int freq, int dir)
> +{
> + struct fsl_ssi_private *ssi_private =
> snd_soc_dai_get_drvdata(cpu_dai);
> + s
On Thu, Jun 12, 2014 at 10:21 PM, Nicolin Chen
wrote:
> It compiles well with my ARM cross compiler. I guess it might be related
> to the compiler's version? But we should fix it anyway. Would you mind if
> I submit a patch? Or you do it directly?
I just submitted a patch, but I can't test the c
: Nicolin Chen
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, Aug 6, 2014 at 3:53 AM, qiang.z...@freescale.com
wrote:
>
> Actually qe is a kind of IP block, so in my opinion, it is proper to put it
> under driver/(just in my opinion).
The QE library is not a driver, however. It doesn't register as a
driver with the kernel.
Scott suggests drivers/
On 08/07/2014 03:08 PM, Scott Wood wrote:
>Scott suggests drivers/soc. I'm not crazy about that, but I don't
>maintain that code any more.
Do you have a better suggestion?
Leave it where it is?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozla
On 08/07/2014 03:11 PM, Scott Wood wrote:
> >Do you have a better suggestion?
>
>Leave it where it is?
We need it on ARM as well.
In that case, drivers/soc is the least-bad option.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https:
On 03/25/2014 02:56 AM, Dongsheng Wang wrote:
From: Jason Jin
For deep sleep, the diu module will power off, when wake up
from the deep sleep, the registers need to be reinitialized.
Signed-off-by: Jason Jin
Signed-off-by: Wang Dongsheng
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/vid
On 03/26/2014 12:41 PM, Jason Jin wrote:
This board sepecific initialization mechanism is not feasible i
for corenet platform as the corenet platform file is a
abstraction of serveral platforms.
You can't make it 100% abstract. The DIU driver requires some sort of
board support. I think you
On 03/26/2014 12:41 PM, Jason Jin wrote:
+ if (!diu_ops.set_pixel_clock) {
+ data->saved_pixel_clock = 0;
+ if (of_address_to_resource(ofdev->dev.of_node, 1, &res))
+ pr_err(KERN_ERR "No pixel clock set func and no pixel
node!\n");
+
jason@freescale.com wrote:
However, the DIU is already initialized in u-boot and we can
rely on the settings in u-boot for corenet platform,
I don't like that at all.
[Jason Jin-R64188] What's the potential issue of this? Most of the
IPs need the platform initialization in u-boot. For exam
jason@freescale.com wrote:
[Jason Jin-R64188] It's not hackish, we can provide the pixel clock register in
the DIU node, I did not provide the dts update as this is only tested on T1040
platform. For other platforms such as p1022 and 8610, we still can use the
pixel clock setting function
On 03/16/2015 02:17 PM, Fabian Frederick wrote:
of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: Fabian Frederick
...
drivers/tty/serial/ucc_uart.c | 2 +-
For this driver:
Acked-by: Timur Tabi
Alexander Popov wrote:
Initialize Freescale MPC512x DMA driver with subsys_initcall()
to allow the depending drivers to call dma_request_slave_channel()
during their probe.
Signed-off-by: Alexander Popov
Is there any way we can use -EPROBEDEFER instead?
Alexander Popov wrote:
+- dma-names: should be "rx-tx";
Why bother, if it can only be one value?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
1 - 100 of 1188 matches
Mail list logo
