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
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:
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
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
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
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
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
On 1/21/20 3:09 PM, Heiner Kallweit wrote:
drivers/net/ethernet/qualcomm/emac/emac.c | 14 +-
Acked-by: Timur Tabi
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.
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.
+ */
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.
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.
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
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
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
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
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
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
Colin Ian King
Acked-by: Timur Tabi
Looks like this bug has been there since day 1.
...@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.
...@rasmusvillemoes.dk/
This is excellent work, thank you.
All patches:
Reviewed-by: Timur Tabi
Serial patches:
Acked-by: Timur Tabi
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
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
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.
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
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
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
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
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
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
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;
> + }
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
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
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
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
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
ode
Acked-by: Timur Tabi <ti...@tabi.org>
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
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
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
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
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
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
a typo in a comment line
All three:
Acked-by: Timur Tabi <ti...@tabi.org>
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
Acked-by: Timur Tabi <ti...@tabi.org>
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
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.
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
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
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
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 =
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
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.
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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:
+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
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
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
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
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
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
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))
+
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.
___
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
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
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:
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
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
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
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
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
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 map
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:
;
\
Timur, do you remember why that final if (!__ret) __ret = (condition);
is needed?
powerpc: Fix spin_event_timeout() to be robust over context switches
Current implementation of spin_event_timeout can be interrupted
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
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
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
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.
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
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.
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
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
-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
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 - 100 of 1269 matches
Mail list logo