Re: [PATCH tty v1 72/74] serial: ucc_uart: Use port lock wrappers

On Thu, Sep 14, 2023 at 1:39 PM John Ogness wrote: > Converted with coccinelle. No functional change. > > Signed-off-by: Thomas Gleixner > --- > drivers/tty/serial/ucc_uart.c | 4 ++-- Acked-by: Timur Tabi

Re: [PATCH] Documentation: devices.txt: reconcile serial/ucc_uart minor numers

to the location of the devices.txt > list in the kernel source tree. > > Fixes: d7584ed2b994 ("[POWERPC] qe-uart: add support for Freescale > QUICCEngine UART") > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") > Signed-off-by: Randy Dunlap > Cc: Timur Tabi > Cc:

Re: [PATCH] serial: Use of_property_read_bool() for boolean properties

lean properties to to of_property_read_bool(). > > Signed-off-by: Rob Herring > --- > drivers/tty/serial/imx.c | 14 +- > drivers/tty/serial/mxs-auart.c | 4 ++-- > drivers/tty/serial/ucc_uart.c | 2 +- ucc_uart.c portion: Acked-by: Timur Tabi

Re: [PATCH v2 1/5] serial: ucc_uart: Remove custom frame size calculation

x_length ("minus 1" part differs). That > comment seems a verbatim copy of that in cpm_uart/cpm_uart_core.c > anyway so perhaps it was just copied over w/o much thinking. > > Reviewed-by: Andy Shevchenko > Signed-off-by: Ilpo Järvinen Acked-by: Timur Tabi

Re: [PATCH] tty: serial: Fix refcount leak bug in ucc_uart.c

On Sat, Jun 18, 2022 at 1:09 AM Liang He wrote: > > In soc_info(), of_find_node_by_type() will return a node pointer > with refcount incremented. We should use of_node_put() when it is > not used anymore. > > Signed-off-by: Liang He Acked-by: Timur Tabi

Re: [PATCH -next 9/9] ASoC: fsl_xcvr: check return value after calling platform_get_resource_byname()

On Fri, Jun 11, 2021 at 4:32 AM Yang Yingliang wrote: > rx_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rxfifo"); > tx_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "txfifo"); > + if (!rx_res || !tx_res) { > + dev_err(dev, "Invalid

Re: [PATCH 1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver

On 9/18/20 9:21 AM, Viorel Suman (OSS) wrote: +static const u32 fsl_xcvr_earc_channels[] = { 1, 2, 8, 16, 32, }; /* +one bit 6, 12 ? */ What's the meaning of the comments? Just a thought noted as comment. HDMI2.1 spec defines 6- and 12-channels layout when one bit audio stream is transmitted

Re: [PATCH v2 net-next] net: convert suitable drivers to use phy_do_ioctl_running

On 1/21/20 3:09 PM, Heiner Kallweit wrote: drivers/net/ethernet/qualcomm/emac/emac.c | 14 +- Acked-by: Timur Tabi

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On 1/15/20 2:01 PM, Scott Wood wrote: FWIW I'd rather see the original patch, that keeps the raw asm hcall stuff as simple wrappers in one place. I can live with that.

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On 1/14/20 12:31 AM, Stephen Rothwell wrote: +/** + * ev_byte_channel_send - send characters to a byte stream + * @handle: byte stream handle + * @count: (input) num of chars to send, (output) num chars sent + * @bp: pointer to chars to send + * + * Returns 0 for success, or an error code. + */

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On 1/14/20 2:29 AM, Segher Boessenkool wrote: You have no working lswx I suppose?:-) I don't know if the P4080 supports lswx, but it does, than that would be an elegant way to fix this bug.

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On 1/14/20 3:18 AM, Laurentiu Tudor wrote: I can offer myself. I'll send a MAINTAINERS patch if nobody is against it. Yes, please do. I'm always available if you have any questions on the code.

Re: [PATCH] MAINTAINERS: Add myself as maintainer of ehv_bytechan tty driver

On 1/14/20 5:00 AM, Laurentiu Tudor wrote: Michael Ellerman made a call for volunteers from NXP to maintain this driver and I offered myself. Signed-off-by: Laurentiu Tudor Acked-by: Timur Tabi

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On 1/13/20 7:10 PM, Timur Tabi wrote: I would prefer that ev_byte_channel_send() is updated to access only 'count' bytes.  If that means adding a memcpy to the ev_byte_channel_send() itself, then so be it.  Trying to figure out how to stuff n bytes into 4 32-bit registers is probably

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On 1/13/20 2:25 PM, Stephen Rothwell wrote: The problem is not really the declaration, the problem is that ev_byte_channel_send always accesses 16 bytes from the buffer and it is not always passed a buffer that long (in one case it is passed a pointer to a single byte). So the alternative to

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On Thu, Jan 9, 2020 at 1:41 AM Stephen Rothwell wrote: > > ev_byte_channel_send() assumes that its third argument is a 16 byte array. > Some places where it is called it may not be (or we can't easily tell > if it is). Newer compilers have started producing warnings about this, > so make sure we

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On 1/13/20 8:34 AM, Laurentiu Tudor wrote: There are a few users that I know of, but I can't tell if that's enough to justify keeping the driver. [1]https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/hypervisor/ IIRC, the driver is the only reasonable way to get a serial console

Re: [PATCH] evh_bytechan: fix out of bounds accesses

On 1/13/20 6:26 AM, Michael Ellerman wrote: I've never heard of it, and I have no idea how to test it. It's not used by qemu, I guess there is/was a Freescale hypervisor that used it. Yes, there is/was a Freescale hypervisor that I and a few others worked on. I've added a couple people on

Re: [PATCH] serial: ucc_uart: remove redundant assignment to pointer bdp

Colin Ian King Acked-by: Timur Tabi Looks like this bug has been there since day 1.

Re: [PATCH v6 00/49] QUICC Engine support on ARM, ARM64, PPC64

...@rasmusvillemoes.dk/ If it helps: Entire series: Acked-by: Timur Tabi I've worked on all code covered by this patchset except for the hdlc driver. I don't know if my ACKs are acceptable to everyone, but you have them regardless.

Re: [PATCH v5 00/48] QUICC Engine support on ARM, ARM64, PPC64

...@rasmusvillemoes.dk/ This is excellent work, thank you. All patches: Reviewed-by: Timur Tabi Serial patches: Acked-by: Timur Tabi

Re: [PATCH v4 32/47] serial: ucc_uart: use of_property_read_u32() in ucc_uart_probe()

On 11/15/19 2:01 AM, Rasmus Villemoes wrote: That would be a separate patch, this patch is only concerned with eliminating the implicit assumption of the host being big-endian. And there's already been some pushback to adding arch-specific ifdefs (which I agree with, but as I responded there see

Re: [PATCH v4 45/47] net/wan/fsl_ucc_hdlc: reject muram offsets above 64K

On 11/15/19 1:44 AM, Rasmus Villemoes wrote: I can change it, sure, but it's a matter of taste. To me the above asks "does the value change when it is truncated to a u16" which makes perfect sense when the value is next used with iowrite16be(). Using a comparison to U16_MAX takes more brain

Re: [PATCH v4 46/47] net: ethernet: freescale: make UCC_GETH explicitly depend on PPC32

On 11/15/19 1:54 AM, Rasmus Villemoes wrote: "Also, the QE Ethernet has never been integrated on any non-PowerPC SoC and most likely will not be in the future." That works for me, thanks.

Re: [PATCH v4 46/47] net: ethernet: freescale: make UCC_GETH explicitly depend on PPC32

On 11/14/19 11:44 PM, Li Yang wrote: Can you add an explanation why we don't want ucc_geth on non-PowerPC platforms? I think it is because the QE Ethernet was never integrated in any non-PowerPC SoC and most likely will not be in the future. We probably can make it compile for other

Re: [PATCH v4 07/47] soc: fsl: qe: qe.c: guard use of pvr_version_is() with CONFIG_PPC32

On Fri, Nov 8, 2019 at 7:04 AM Rasmus Villemoes wrote: > > +static bool qe_general4_errata(void) > +{ > +#ifdef CONFIG_PPC32 > + return pvr_version_is(PVR_VER_836x) || pvr_version_is(PVR_VER_832x); > +#endif > + return false; > +} > + > /* Program the BRG to the given sampling rate

Re: [PATCH v4 45/47] net/wan/fsl_ucc_hdlc: reject muram offsets above 64K

On Fri, Nov 8, 2019 at 7:04 AM Rasmus Villemoes wrote: > diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c > index 8d13586bb774..f029eaa7cfc0 100644 > --- a/drivers/net/wan/fsl_ucc_hdlc.c > +++ b/drivers/net/wan/fsl_ucc_hdlc.c > @@ -245,6 +245,11 @@ static int

Re: [PATCH v4 46/47] net: ethernet: freescale: make UCC_GETH explicitly depend on PPC32

On Fri, Nov 8, 2019 at 7:04 AM Rasmus Villemoes wrote: > > Currently, QUICC_ENGINE depends on PPC32, so this in itself does not > change anything. In order to allow removing the PPC32 dependency from > QUICC_ENGINE and avoid allmodconfig build failures, add this explicit > dependency. Can you

Re: [PATCH v4 32/47] serial: ucc_uart: use of_property_read_u32() in ucc_uart_probe()

On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes wrote: > > + if (of_property_read_u32(np, "cell-index", ) && > + of_property_read_u32(np, "device-id", )) { I know that this is technically correct, but it's obfuscated IMHO. 'val' is set correctly only when

Re: [PATCH v4 32/47] serial: ucc_uart: use of_property_read_u32() in ucc_uart_probe()

On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes wrote: > > - if (*iprop) > - qe_port->port.uartclk = *iprop; > + if (val) > + qe_port->port.uartclk = val; > else { > /* > * Older versions of U-Boot do not initialize

Re: [PATCH v4 30/47] serial: ucc_uart: factor out soft_uart initialization

On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes wrote: > > - /* > -* Determine if we need Soft-UART mode > -*/ > if (of_find_property(np, "soft-uart", NULL)) { > dev_dbg(>dev, "using Soft-UART mode\n"); > soft_uart = 1; > + }

Re: [PATCH v4 04/47] soc: fsl: qe: introduce qe_io{read,write}* wrappers

On 11/12/19 1:14 AM, Rasmus Villemoes wrote: but that's because readl and writel by definition work on little-endian registers. I.e., on a BE platform, the readl and writel implementation must themselves contain a swab, so the above would end up doing two swabs on a BE platform. Do you know

Re: [PATCH v4 04/47] soc: fsl: qe: introduce qe_io{read, write}* wrappers

On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes wrote: > > The QUICC engine drivers use the powerpc-specific out_be32() etc. In > order to allow those drivers to build for other architectures, those > must be replaced by iowrite32be(). However, on powerpc, out_be32() is > a simple inline function

Re: [alsa-devel] [PATCH] ASoC: cs42xx8: Remove S32_LE in format list

On 3/1/19 12:32 AM, S.j. Wang wrote: This case is covered by S24_LE I think. The S32_LE means the data is 32bit and slot width Is 32bit, this is not in data sheet. The problem is that if you have 32-bit samples in your audio file, and you want to play them, then software (e.g. alsalib) will

Re: [PATCH] ASoC: cs42xx8: Remove S32_LE in format list

On 2/27/19 11:56 PM, S.j. Wang wrote: cs42xx8 is a 24-bit A/D and 24-bit D/A device, so the S32_LE should not be in the supported format list. Signed-off-by: Shengjiu Wang Is the device capable of accepting 32-bit samples, even if it downgrades it to 24-bit internally? If so, then maybe

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On 3/16/18 6:04 PM, Steve Wise wrote: Anybody understand why the PPC implementation of writeX_relaxed() isn't relaxed? You probably should ask that on the linuxppc-dev@lists.ozlabs.org mailing list. I've always wondered why PowerPC has non-standard I/O accessors. -- Qualcomm Datacenter

Re: [PATCH v4 00/11] ASoC: fsl_ssi: Clean up - coding style level

ode Acked-by: Timur Tabi <ti...@tabi.org>

Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

On 12/16/17 11:49 AM, Nicolin Chen wrote: I never said that I don't agree with Timur. Every change here is to simplify things. As long as Timur or any reviewer feels one of new comments is harder to understand, I am totally fine to rework. I respect everyone's opinion, but I hope everyone can

Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

On 12/16/17 11:30 AM, Caleb Crome wrote: Having come to work on this driver with very little knowledge about kernel programming, and i.MX, I have to agree with Timur. It's an amazingly complex driver (with support of so many variants). By eliminating verbose commentary, it's also wiping away a

Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

On 12/13/17 5:18 PM, Nicolin Chen wrote: - /* Used when using fsl-ssi as sound-card. This is only used by ppc and -* should be replaced with simple-sound-card. */ struct platform_device *pdev; Is this comment no longer true? + * 1) SSI in earlier SoCS has crtical bits

Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

On 12/16/17 12:10 AM, Nicolin Chen wrote: Hi, I am outside so can't use mutt. Sorry for that. This comment is going to be replaced in the 2nd set anyway because the whole function will be replaced. So you're asking me to review comment changes that will soon be deleted? Can you send out a

Re: [PATCH v3 00/11] ASoC: fsl_ssi: Clean up - coding style level

On 12/13/17 5:18 PM, Nicolin Chen wrote: Additionally, in order to fix/work-around hardware bugs and design flaws, the driver made a lot of compromise so now its program flow looks very complicated and it's getting hard to maintain or update. So I am going to clean up the driver on both coding

Re: [PATCH v3 03/11] ASoC: fsl_ssi: Refine all comments

On 12/13/17 5:18 PM, Nicolin Chen wrote: -* We are running on a SoC which does not support online SSI -* reconfiguration, so we have to enable all necessary flags at once -* even if we do not use them later (capture and playback configuration) +* Online

Re: [PATCH 0/3] tty/serial/ucc_uart: Adjustments for two functions

a typo in a comment line All three: Acked-by: Timur Tabi <ti...@tabi.org>

Re: [PATCH 04/10] ASoC: fsl_ssi: Refine all comments

On 12/4/17 2:46 PM, Nicolin Chen wrote: This patch refines the comments by: 1) Removing all out-of-date comments 2) Removing all not-so-useful comments 3) Unifying the styles of all comments 4) Simplifying over-descriptive comments 5) Adding comments to improve code readablity 6) Moving all

Re: [PATCH 05/11] serial: uuc_uart: constify uart_ops structures

Acked-by: Timur Tabi <ti...@tabi.org>

Re: [PATCH] sound: fsl_dma: remove dma_object path member

On 7/18/17 4:43 PM, Rob Herring wrote: - dev_err(>dev, "could not determine resources for %s\n", - ssi_np->full_name); + dev_err(>dev, "could not determine resources for %pOF\n", + ssi_np); I think you meant to include

Re: [PATCH] ASoC : fsl_ssi : Correct the condition to check AC97 mode

Andreas Schwab wrote: > + return !!(ssi_private->dai_fmt & SND_SOC_DAIFMT_AC97) == > + SND_SOC_DAIFMT_AC97; This is never true. I think the right parenthesis should be at the end of the expression.

Re: [PATCH 1/1] serial/uuc_uart: Set shutdown timeout to CONFIG_HZ independent 2ms

Alexander Stein wrote: Okay, I was just wondering why the timeout is dependant on the timer tick. That didn't seem obvious to me. Rethinking about this, I would rather replace those lines with msleep instead. What's wrong with leaving it as-is? The code is five years old, and Freescale/NXP

Re: [PATCH 1/1] serial/uuc_uart: Set shutdown timeout to CONFIG_HZ independent 2ms

Alexander Stein wrote: - schedule_timeout(2); + schedule_timeout(msecs_to_jiffies(2)); NACK. So I don't remember why I wrote this code, but I don't think I was expecting it to be 2ms. Instead, I think I just wanted it to be some delay, but I believed that

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Maciej S. Szmigiero wrote: On 17.01.2016 15:16, Maciej S. Szmigiero wrote: On 17.01.2016 06:16, Timur Tabi wrote: Maciej S. Szmigiero wrote: This is because (at least according to the datasheet) imx21-class SSI registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so reading them

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Maciej S. Szmigiero wrote: +static const struct regmap_config fsl_ssi_regconfig_imx21 = { + .max_register = CCSR_SSI_SRMSK, + .reg_bits = 32, + .val_bits = 32, + .reg_stride = 4, + .val_format_endian = REGMAP_ENDIAN_NATIVE, + .num_reg_defaults_raw =

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Maciej S. Szmigiero wrote: This is because (at least according to the datasheet) imx21-class SSI registers end at CCSR_SSI_SRMSK (no SACC{ST,EN,DIS} regs), so reading them for cache initialization may not be safe. Also, a "MXC 91221 only" comment before these regs in FSL tree

Re: [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

Lothar Waßmann wrote: Why? If more than one of the IMX6 SoCs are selected, both interfaces may be selected at the same time without any harm. Oh, ok. I thought the point behind the patch was that you *souldn't* enable the the SSI driver on an i.MX6UL.

Re: [PATCH 2/2] ASoC: fsl: select SND_SOC_FSL_SAI or SND_SOC_FSL_SSI depending on SoC type

Lothar Waßmann wrote: - select SND_SOC_FSL_SSI + select SND_SOC_FSL_SAI if SOC_IMX6UL + select SND_SOC_FSL_SSI if SOC_IMX6Q || SOC_IMX6SL || SOC_IMX6SX I don't think this is compatible with a multiarch kernel. ___ Linuxppc-dev

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Mark Brown wrote: regcache handles this fine, it's perfectly happy to just go and allocate the cache as registers get used (this is why the code that's doing the allocation exists...). What is causing problems here is that the first access to the register is happening in interrupt context so we

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Mark Brown wrote: Quite possibly (it'll be more efficient and it's intended for such use cases) but as I said in my other reply that then has the issue that it implicitly gives default values to all the registers so I'd expect we still need to handle the cache initialisation explicitly (or

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

Mark Brown wrote: That's possibly problematic because the flat cache will of necessity end up with defaults (of 0 from the kzalloc()) for all the registers. You'll still have default values in the cache, though some of the behaviour around optimising syncs does change without them explicitly

Re: [PATCH 1/3] ASoC: fsl_ssi: mark SACNT register volatile

Maciej S. Szmigiero wrote: + regmap_write(regs, CCSR_SSI_SACNT, + ssi_private->regcache_sacnt); So I'm not familiar with all of the regcache features, but I understand this patch. I was wondering if it makes sense to write the same exact value that was read

Re: [PATCH 2/3] ASoC: fsl_ssi: mark some registers precious

Maciej S. Szmigiero wrote: Mark some registers precious since their reads have side effects (like clearing flags). Signed-off-by: Maciej S. Szmigiero<m...@maciej.szmigiero.name> Acked-by: Timur Tabi <ti...@tabi.org> ___ Linuxppc-dev

Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults

in AC'97 mode. Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support MEGA Fast") Signed-off-by: Maciej S. Szmigiero<m...@maciej.szmigiero.name> Acked-by: Timur Tabi <ti...@tabi.org> I'm surprised that we're actually encouraging drivers to contai

Re: [alsa-devel] [PATCH 1/3] ASoC: fsl_ssi: mark SACNT register volatile

On Sun, Dec 20, 2015 at 2:30 PM, Maciej S. Szmigiero wrote: > SACNT register should be marked volatile since > its WR and RD bits are cleared by SSI after > completing the relevant operation. > This unbreaks AC'97 register access. > > Fixes: 05cf237972fe ("ASoC:

Re: [net-next v5 0/8] dpaa_eth: Add the Freescale DPAA Ethernet driver

On Thu, Dec 3, 2015 at 6:08 AM, <> wrote: > From: Madalin Bucur > > This patch series adds the Ethernet driver for the Freescale > QorIQ Data Path Acceleration Architecture (DPAA). Please fix your git-send-email configuration, so that your emails are formatted

Re: [PATCH 1/2] net/fsl_pq_mdio: check TBI address for consistency with mapped range

Gerlando Falauto wrote: Change-Id: If1e7d8931f440ea9259726c36d3df797dda016fb You need to remove these from patches that are emailed, and fix the pointer type comparison. Otherwise, Acked-by: Timur Tabi <ti...@tabi.org> ___ Linuxppc-dev m

Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver

On 09/30/2015 04:24 PM, Alexander Popov wrote: Can you test for "!cs" here instead? +e = -EFAULT; +goto err_param; +} Unfortunately no: 0 is a valid value for Chip Select. Is it OK to leave it like that? Yes. +lpbfifo.ram_bus_addr = sg_dma_address(); /* For

Re: [PATCH v3 2/3] powerpc/512x: add a device tree binding for LocalPlus Bus FIFO

Alexander Popov wrote: I've just followed devicetree/bindings/dma/dma.txt... This "rx-tx" doesn't mean much but it could show that LocalPlus Bus FIFO uses a single DMA read-write channel. Should I really drop it? Hmmm, I'm not sure. Is there anything else (besides your driver) that parses

Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver

Alexander Popov wrote: The only question I have: why calling dma_unmap_single() from within a spinlock is a bad practice? I don't know, but usually functions that allocate or free memory cannot be called from within a spinlock. You need to check that. Since the MPC5121 is a single-core

Re: [PATCH v3 2/3] powerpc/512x: add a device tree binding for LocalPlus Bus FIFO

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

Re: [PATCH v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()

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?

Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver

Alexander Popov wrote: +struct mpc512x_lpbfifo_request { + phys_addr_t bus_phys; /* physical address of some device on LPB */ Is this a phys_addr_t or a dma_addr_t? It can't be both a physical address and a bus address. + void *ram_virt; /* virtual address of some

Re: [PATCH v2] video: fbdev: fsl: Fix the sleep function for FSL DIU module

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

Re: [PATCH v2] video: fbdev: fsl: Fix the sleep function for FSL DIU module

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 Jinjason@freescale.com Signed-off-by: Wang Dongshengdongsheng.w...@freescale.com Acked-by: Timur Tabi ti...@tabi.org

Re: [alsa-devel][PATCH 2/2] ASoC: fsl_ssi: sound is wrong after suspend/resume

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 zidan.w...@freescale.com Shouldn't this be part of patch #1? ___ Linuxppc-dev

Re: [alsa-devel][PATCH 1/2] ASoC: fsl_ssi: Add driver suspend and resume to support MEGA Fast

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: + case

Re: [PATCH] ASoC: fsl_ssi: fix AC'97 mode

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

Re: [PATCH 3/6] ASoC: fsl_ssi: enable AC'97 asymmetric rates

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)) +

Re: [PATCH] ASoC: fsl_ssi: fix AC'97 mode

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. ___

Re: [PATCH] ASoC: fsl: Add dedicated DMA buffer size for each cpu dai

Chennicoleots...@gmail.com Acked-by: Timur Tabi ti...@tabi.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: new way of writing defconfigs for freescale's powerpc platforms

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 already

Re: new way of writing defconfigs for freescale's powerpc platforms

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:

Re: new way of writing defconfigs for freescale's powerpc platforms

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

Re: new way of writing defconfigs for freescale's powerpc platforms

On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood scottw...@freescale.com 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

Re: new way of writing defconfigs for freescale's powerpc platforms

On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan lijun@freescale.com 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

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()

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

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()

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

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()

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

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()

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 map

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()

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:

Re: [PATCH 1/3] qe-uart: modify qe-uart to adapt both powerpc and arm

On Fri, Oct 10, 2014 at 1:05 PM, Scott Wood scottw...@freescale.com 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

Re: [PATCH V2] ASoC: fsl_ssi: refine ipg clock usage in this module

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

Re: [PATCH V1] ASoC: fsl_ssi: refine ipg clock usage in this module

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

Re: [PATCH V1] ASoC: fsl_ssi: refine ipg clock usage in this module

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

Re: [PATCH V1] ASoC: fsl_ssi: refine ipg clock usage in this module

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.

Re: [PATCH V1] ASoC: fsl_ssi: refine ipg clock usage in this module

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,

Re: [PATCH V1] ASoC: fsl_ssi: refine ipg clock usage in this module

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

Re: qe: move qe from arch/powerpc to drivers

On Wed, Aug 6, 2014 at 3:53 AM, qiang.z...@freescale.com 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.

Re: qe: move qe from arch/powerpc to 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

Re: qe: move qe from arch/powerpc to drivers

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

Re: [PATCH 4/4] ASoC: fsl_ssi: Add stream names for DPCM usage

-by: Nicolin Chennicoleots...@gmail.com Acked-by: Timur Tabi ti...@tabi.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [RFC][PATCH v1] ASoC: fsl_ssi: Add DAI master mode support for SSI on i.MX series

On Thu, Dec 12, 2013 at 4:44 AM, Nicolin Chen guangyu.c...@freescale.com 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 =

  1   2   3   4   5   6   7   8   9   10   >