RE: [PATCHv1 5/8] ASoC: sgtl5000: Revise the bugs about the sgt15000 codec.
> > @@ -883,14 +883,19 @@ static int ldo_regulator_register(struct
> snd_soc_codec *codec,
> > struct regulator_init_data *init_data,
> > int voltage)
> > {
> > +#ifdef CONFIG_SND_SOC_FSL_SGTL5000
> > + return 0;
> > +#else
> > dev_err(codec->dev, "this setup needs regulator support in the
> kernel\n");
> > return -EINVAL;
> > +#endif
> > }
>
> If these systems don't actually need the internal regulator then should
> they not be trying to enable it?
>
Yes, I think do not trying to enable the regulator is much better.
>Alternatively if it's OK to ignore this then why is this conditional in the
>board?
>
The CONFIG_SND_SOC_FSL_SGTL5000 micro maybe confuse you and others.
And it should be CONFIG_SND_SOC_FSL_SGTL5000_VF610
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
Hi Dan, Vinod,
> > +static int fsl_sai_probe(struct platform_device *pdev) {
> [...]
> > +
> > + sai->dma_params_rx.addr = res->start + SAI_RDR;
> > + sai->dma_params_rx.maxburst = 6;
> > + index = of_property_match_string(np, "dma-names", "rx");
> > + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
> > + &dma_args);
> > + if (ret)
> > + return ret;
> > + sai->dma_params_rx.slave_id = dma_args.args[1];
> > +
> > + sai->dma_params_tx.addr = res->start + SAI_TDR;
> > + sai->dma_params_tx.maxburst = 6;
> > + index = of_property_match_string(np, "dma-names", "tx");
> > + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
> > + &dma_args);
> > + if (ret)
> > + return ret;
> > + sai->dma_params_tx.slave_id = dma_args.args[1];
>
> The driver should not have to manually parse the dma devicetree
> properties, this is something that should be handled by the dma engine
> driver.
>
What do you think about the DMA slave_id ?
I have been noticed by one colleague that this should be parsed here, which
is from your opinions ?
> > +
> > + ret = snd_soc_register_component(&pdev->dev, &fsl_component,
> > + &fsl_sai_dai, 1);
> > + if (ret)
> > + return ret;
> > +
> > + ret = fsl_pcm_dma_init(pdev);
> > + if (ret)
> > + goto out;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: FA_DUMP depends on KEXEC
If you try and build the FA_DUMP code with CONFIG_KEXEC=n, you see errors such as the following: arch/powerpc/kernel/fadump.c 408:2: error: 'crashing_cpu' undeclared (first use in this function) 410:2: error: implicit declaration of function 'crash_save_vmcoreinfo' 513:22: error: storage size of 'prstatus' isn't known 520:2: error: implicit declaration of function 'elf_core_copy_kernel_regs' 521:36: error: 'KEXEC_CORE_NOTE_NAME' undeclared (first use in this function) 624:49: error: 'note_buf_t' undeclared (first use in this function) 872:2: error: implicit declaration of function 'paddr_vmcoreinfo_note' 874:18: error: 'vmcoreinfo_max_size' undeclared (first use in this function) This is because although FA_DUMP doesn't use kexec as the actual reboot mechanism, it does use parts of the kexec code to assemble/disassemble the crash image. Signed-off-by: Michael Ellerman --- arch/powerpc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 38f3b7e..9d4e80e 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -404,7 +404,7 @@ config CRASH_DUMP config FA_DUMP bool "Firmware-assisted dump" - depends on PPC64 && PPC_RTAS && CRASH_DUMP + depends on PPC64 && PPC_RTAS && CRASH_DUMP && KEXEC help A robust mechanism to get reliable kernel crash dump with assistance from firmware. This approach does not use kexec, -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
> > +1. Clock Block Binding
> > +
> > +Required properties:
> > +- compatible: Should include one or more of the following:
> > + - "fsl,-clockgen": for chip specific clock block
> > + - "fsl,qoriq-clockgen-[1,2].x": for chassis 1.x and 2.x clock
> > +- reg: Offset and length of the clock register set
> > +- clock-frequency: Indicates input clock frequency of clock block.
> > + Will be set by u-boot
> > +
> > +Recommended properties:
> > +- #ddress-cells: Specifies the number of cells used to represent
>
> typo
Thanks, someone else already pointed out it. Will fix in next patch.
Regards,
Yuantian
>
> > + physical base addresses. Must be present if the device has
> > + sub-nodes and set to 1 if present
> > +- #size-cells: Specifies the number of cells used to represent
> > + the size of an address. Must be present if the device has
> > + sub-nodes and set to 1 if present
> > +
> > +2. Clock Provider/Consumer Binding
> > +
> > +Most of the binding are from the common clock binding[1].
> > + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +
> > +Required properties:
> > +- compatible : Should include one or more of the following:
> > + - "fsl,qoriq-core-pll-[1,2].x": Indicates a core PLL clock device
> > + - "fsl,qoriq-core-mux-[1,2].x": Indicates a core multiplexer clock
> > + device; divided from the core PLL clock
> > + - "fixed-clock": From common clock binding; indicates output clock
> > + of oscillator
> > + - "fsl,qoriq-sysclk-[1,2].x": Indicates input system clock
> > +- #clock-cells: From common clock binding; indicates the number of
> > + output clock. 0 is for one output clock; 1 for more than one clock
> > +
> > +Recommended properties:
> > +- clocks: Should be the phandle of input parent clock
> > +- clock-names: From common clock binding, indicates the clock name
> > +- clock-output-names: From common clock binding, indicates the names
> of
> > + output clocks
> > +- reg: Should be the offset and length of clock block base address.
> > + The length should be 4.
>
> Binding looks reasonable to me.
>
> g.
>
> > +
> > +Example for clock block and clock provider:
> > +/ {
> > + clockgen: global-utilities@e1000 {
> > + compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
> > + reg = <0xe1000 0x1000>;
> > + clock-frequency = <0>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + sysclk: sysclk {
> > + #clock-cells = <0>;
> > + compatible = "fsl,qoriq-sysclk-1.0", "fixed-clock";
> > + clock-output-names = "sysclk";
> > + }
> > +
> > + pll0: pll0@800 {
> > + #clock-cells = <1>;
> > + reg = <0x800 0x4>;
> > + compatible = "fsl,qoriq-core-pll-1.0";
> > + clocks = <&sysclk>;
> > + clock-output-names = "pll0", "pll0-div2";
> > + };
> > +
> > + pll1: pll1@820 {
> > + #clock-cells = <1>;
> > + reg = <0x820 0x4>;
> > + compatible = "fsl,qoriq-core-pll-1.0";
> > + clocks = <&sysclk>;
> > + clock-output-names = "pll1", "pll1-div2";
> > + };
> > +
> > + mux0: mux0@0 {
> > + #clock-cells = <0>;
> > + reg = <0x0 0x4>;
> > + compatible = "fsl,qoriq-core-mux-1.0";
> > + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
> > + clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
> > + clock-output-names = "cmux0";
> > + };
> > +
> > + mux1: mux1@20 {
> > + #clock-cells = <0>;
> > + reg = <0x20 0x4>;
> > + compatible = "fsl,qoriq-core-mux-1.0";
> > + clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
> > + clock-names = "pll0_0", "pll0_1", "pll1_0", "pll1_1";
> > + clock-output-names = "cmux1";
> > + };
> > + };
> > + }
> > +
> > +Example for clock consumer:
> > +
> > +/ {
> > + cpu0: PowerPC,e5500@0 {
> > + ...
> > + clocks = <&mux0>;
> > + ...
> > + };
> > + }
> > diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> > b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> > index 5a6615d..e910e82 100644
> > --- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
> > @@ -86,6 +86,41 @@
> >
> > clockgen: global-utilities@e1000 {
> > compatible = "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + sysclk: sysclk {
> > + #clock-cells = <0>;
> > + compatible = "fsl,qoriq-sysclk-2.0", "fixed-clock";
> > +
Re: [PATCH 2/2] powerpc: Move local setup.h declarations to arch includes
On Fri, Oct 25, 2013 at 02:25:07PM -0500, Robert C Jennings wrote: > Move the few declarations from arch/powerpc/kernel/setup.h > into arch/powerpc/include/asm/setup.h. This resolves a > sparse warning for arch/powerpc/mm/numa.c which defines > do_init_bootmem() but can't include the setup.h header > in the prior path. > > Resolves: > arch/powerpc/mm/numa.c:998:13: > warning: symbol 'do_init_bootmem' was not declared. > Should it be static? There's always a tension between too many well-focused-micro-headers, and too few random-piles-of-junk headers. I tend towards the former, but in this case I think you're right to drop setup.h. > diff --git a/arch/powerpc/include/asm/setup.h > b/arch/powerpc/include/asm/setup.h > index d3ca855..5e24df0 100644 > --- a/arch/powerpc/include/asm/setup.h > +++ b/arch/powerpc/include/asm/setup.h > @@ -23,6 +23,11 @@ extern void reloc_got2(unsigned long); > > #define PTRRELOC(x) ((typeof(x)) add_reloc_offset((unsigned long)(x))) > > +extern void check_for_initrd(void); > +extern void do_init_bootmem(void); > +extern void setup_panic(void); > +extern int do_early_xmon; I don't see do_early_xmon used anywhere? Looks like I forgot to clean it up in 47679283. Mind dropping it? I think these days it's trendy to not use extern in headers. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: sync ppc64, ppc64e and pseries configs
On Tue, Oct 22, 2013 at 11:44:50AM +1100, Anton Blanchard wrote: > > Run savedefconfig over the ppc64, ppc64e and pseries config > -CONFIG_EXPERIMENTAL=y This went way. > -CONFIG_EFI_PARTITION=y This became default y. > -CONFIG_HOTPLUG_CPU=y This isn't going away, it's selected by pseries, so doesn't need to be in the defconfig. > -CONFIG_PPC_DENORMALISATION=y This is default y if POWERNV, so I guess that's why it isn't needed. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?
Hi, I was wondering if anyone here on this list still has a machine with an old ATMEL TPM (trusted platform module) lying around? >From the kconfig entry it becomes evident that it was only supported on ppc64 machines. config TCG_ATMEL tristate "Atmel TPM Interface" depends on PPC64 || HAS_IOPORT ---help--- If you have a TPM security chip from Atmel say Yes and it will be accessible from within Linux. To compile this driver as a module, choose M here; the module will be called tpm_atmel. The hardware/driver is pretty old and the driver might have contained a bug that made it unusable for the last 6 years ;) So if anyone still has this kind of hardware around, please reply. Thanks, Peter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH TRIVIAL] powerpc: Fix a typo in comments of va to pa conversion
This patch fixes typo in comments virtual to physical address conversion. Signed-off-by: Vaishnavi Bhat --- arch/powerpc/include/asm/page.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h index b9f4262..753c662 100644 --- a/arch/powerpc/include/asm/page.h +++ b/arch/powerpc/include/asm/page.h @@ -78,7 +78,7 @@ extern unsigned int HPAGE_SHIFT; * * Also, KERNELBASE >= PAGE_OFFSET and PHYSICAL_START >= MEMORY_START * - * There are two was to determine a physical address from a virtual one: + * There are two ways to determine a physical address from a virtual one: * va = pa + PAGE_OFFSET - MEMORY_START * va = pa + KERNELBASE - PHYSICAL_START * -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
Dear Scott, In message <1382697373.3926.36.ca...@aoeu.buserror.net> you wrote: > > Has anyone measured how much this slows things down with a typical > userspace? In the applications I found to trigger this issue the number of traps is so small that I can't even reliably measure any difference. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When it is incorrect, it is, at least *authoritatively* incorrect. - Hitchiker's Guide To The Galaxy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
Dear Kumar, In message <6bfc8eb0-1a75-41c3-985a-e3ed14846...@kernel.crashing.org> you wrote: > > Fair enough > > > > I'm not too worried as long as we warn and account them. > > Than, I'd ask this be under a Kconfig option that is disabled by > default. Users should have to explicitly enable this so they know what > they are doing. Is this really worth the effort? Under normal situations (users are using a user space environment that has been properly buiult for the processor variant they are using) nobody should ever run into this situation. It happens only if you are already doing something wrong - like using user space that has not been built for an E500 core on such a machine. In this situation, it seems more useful to me if a "standard" kernel just works with a "standard" user space environment, even if this includes some performance penalty - which actually should be neglibale. In my tests (when running standard Debian for PPC on a E500 only very few programs actually triggered this situation, and none of them in a time-critical way. I doubt I would even be able to measure the performance impact. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "...all the good computer designs are bootlegged; the formally planned products, if they are built at all, are dogs!" - David E. Lundstrom, "A Few Good Men From Univac", MIT Press, 1987 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
Peter Zijlstra wrote on 10/25/2013 07:37:49 PM: > I would argue for: > > READ ->data_tail READ ->data_head > smp_rmb() (A) smp_rmb() (C) > WRITE $data READ $data > smp_wmb() (B) smp_mb() (D) > STORE ->data_headWRITE ->data_tail > > Where A pairs with D, and B pairs with C. 1. I agree. My only concern is that architectures which do use atomic operations with memory barriers, will issue two consecutive barriers now, which is sub-optimal. 2. I think the comment in "include/linux/perf_event.h" describing "data_head" and "data_tail" for user space need an update as well. Current version - /* * Control data for the mmap() data buffer. * * User-space reading the @data_head value should issue an rmb(), on * SMP capable platforms, after reading this value -- see * perf_event_wakeup(). * * When the mapping is PROT_WRITE the @data_tail value should be * written by userspace to reflect the last read data. In this case * the kernel will not over-write unread data. */ __u64 data_head; /* head in the data section */ __u64 data_tail; /* user-space written tail */ - say nothing about the need of memory barrier before "data_tail" write. -- Victor ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
