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
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
>
roperties 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
m's rx_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 resou
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 pr
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 the
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 from
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 CC
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 cycle
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 architectur
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 an
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 uhdlc_ini
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 add
On Fri, Nov 8, 2019 at 7:03 AM Rasmus Villemoes
wrote:
>
> + if (of_property_read_u32(np, "cell-index", &val) &&
> + of_property_read_u32(np, "device-id", &val)) {
I know that this is technically correct, but it's obfuscated IMHO.
'val' is set correctly only when of_property_read_
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 t
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(&ofdev->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 whe
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 SNDR
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 Tech
On 12/19/17 11:00 AM, Nicolin Chen wrote:
This series of patches is the second set to clean up fsl_ssi driver
in the program flow level. Any patch here may impact a fundamental
test case like playback or record.
With Christmas happening over the next two weeks, I don't think I'll be
able to re
ode
Acked-by: Timur Tabi
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 res
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 l
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 i
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 s
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 configurati
typo in a comment line
All three:
Acked-by: Timur Tabi
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 regis
On 8/13/17 1:21 AM, Julia Lawall wrote:
These uart_ops structures are only stored in the ops field of a
uart_port structure and this fields is const, so the uart_ops
structures can also be const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
Acked-by: Timur Tabi
On 7/18/17 4:43 PM, Rob Herring wrote:
- dev_err(&pdev->dev, "could not determine resources for %s\n",
- ssi_np->full_name);
+ dev_err(&pdev->dev, "could not determine resources for %pOF\n",
+ ssi_np);
I think you meant to
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 ba
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 schedul
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 for
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
(drivers/mxc/ssi/re
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 = CCSR_SSI_SR
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 mailin
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
altern
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:
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
give
in AC'97 mode.
Fixes: 05cf237972fe ("ASoC: fsl_ssi: Add driver suspend and resume to support MEGA
Fast")
Signed-off-by: Maciej S. Szmigiero
Acked-by: Timur Tabi
I'm surprised that we're actually encouraging drivers to contain
h
Maciej S. Szmigiero wrote:
Mark some registers precious since their
reads have side effects (like clearing flags).
Signed-off-by: Maciej S. Szmigiero
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
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 previo
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: fsl_ssi: Add driver suspend and res
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 properly. This is the From: header
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
___
Linuxppc-dev mailing list
Linuxppc-dev
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(&sg); /* For fre
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 thi
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 CPU,
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 reg
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?
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
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
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
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
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
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:
+ 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
in Chen
Acked-by: Timur Tabi
___
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 alread
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
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
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
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 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
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 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 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 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 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 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
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 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 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 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 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
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 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 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 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/
1 - 100 of 1188 matches
Mail list logo
