Gilad Avidov wrote:
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
new file mode 100644
index 000..36a7746
--- /dev/null
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -0,0 +1,1808 @@
+/* Copyright (c) 2013-2015, The Linux
On Sat, Dec 19, 2015 at 12:37 PM, Andy Shevchenko
wrote:
>> +static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
>> +{
>> + struct platform_device *pdev_parent = of_find_device_by_node(np);
>> + struct platform_device_info pdevinfo;
>> + struct of_phandle_ar
David Miller wrote:
I think you did something much worse. You quoted the entire huge
patch which is entirely inappropriate given the feedback you were
trying to give.
Sorry about that. I usually do trim it, but I got tired and forgot
before I hit send.
--
Sent by an employee of the Qualcom
Arnd Bergmann wrote:
If that's in the probe() called from it function, just use writel() everywhere,
a few extra microseconds won't kill the boot time. In general, if a user would
notice the difference, use the relaxed version and add a comment to explain
how you proved it's correct, otherwise st
Arnd Bergmann wrote:
We generally want to use readl/writel rather than the relaxed versions,
unless it is in performance-critical code.
What about if we have 20+ writes in a row, for example, when
initializing a part? I've seen code like this:
writel_relaxed(...);
writel_rel
Al Stone wrote:
The issue for me in that case is that the SBSA requires a two stage timeout,
>
>Hmm - really ? This makes me want to step back a bit and re-read the
specification
>to understand where it says that, and what the reasoning might be for such a
>requirement.
As far as I can tell, t
On 11/12/2015 06:06 PM, Al Stone wrote:
If it is a NAK, that's fine, but I also want to be sure I understand what the
objections are. Based on my understanding of the discussion so far over the
multiple versions, I think the primary objection is that the use of pretimeout
makes this driver too c
Andy Shevchenko wrote:
>CC: Sinan Kaya
>Signed-off-by: Fengguang Wu
Who is the author?
I suppose Fengguang is the reporter, right?
These are Julia Lawall's coccinelle scripts that automatically run on
patches and report problems. Just treat them like normal code reviews
and incorporate the
Sinan Kaya wrote:
+ val = val & ~(MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS);
+ val = val | (mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS);
+ val = val & ~(MAX_BUS_REQ_LEN_MASK);
+ val = val | (mgmtdev->max_read_request);
val &= ~MAX_BUS_REQ_LEN_MASK << MAX_
On 11/05/2015 10:41 AM, Guenter Roeck wrote:
Ultimately, you'll have to decide if you want a simple driver accepted, or
a complex driver hanging in the review queue forever.
Please note that I did post such a driver back in May:
http://www.spinics.net/lists/linux-watchdog/msg06567.htm
Rob Herring wrote:
I'm saying document it as "qcom,-hidma-mgmt" and when you have
the part number update the binding. Meanwhile push on the powers that
be to decide on a part number.
Got it. But we should we do about this:
static const struct of_device_id qcom_hidma_mgmt_match[] = {
{
Fu Wei wrote:
Did you really read the "Note" above OK, let me paste it again
and again:
SBSA 2.3 Page 23 :
If a larger watch period is required then the compare value can be
programmed directly into the compare value register.
Well, okay. Sorry, I should have read what you pasted more
Fu Wei wrote:
SBSA 2.3 Page 23 :
Note: the watchdog offset register is 32 bits wide. This gives a
maximum watch period of around 10s at a system
counter frequency of 400MHz. If a larger watch period is required then
the compare value can be programmed
directly into the compare value register.
21
Guenter Roeck wrote:
I would feel much more comfortable if the driver would just use the
standard
watchdog timeout and live with (worst case) 20 seconds timeout for now.
Actually, I'm wondering where the 20 seconds comes from. When I load my
driver on our hardware, it calculates a maximum tim
Fu Wei wrote:
(1)It is not new.
pre-timeout concept has been used by two drivers before this driver.
and this concept has been in kernel documentation.
It's "new" in that it's a new infrastructure. The private API of two
other drivers doesn't count.
(1) if we don't, for this two stages t
On Tue, Oct 27, 2015 at 11:06 AM, wrote:
> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
> +{
> + struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id;
> + struct watchdog_device *wdd = &gwdt->wdd;
> +
> + /* We don't use pretimeout, trigger WS1 now */
> +
Arnd Bergmann wrote:
If you change the order in the Makefile, the management driver should
always get probed first if both are built-in. When the driver is a
loadable module, the ordering should work because of the way that the
modules are loaded.
This sounds like something that should be comme
On 11/02/2015 12:25 PM, Rob Herring wrote:
Then document it with "" and fill that in later. Just don't make
up version numbers.
I don't think you understand. We literally have no name for our chip.
The closest is what I used on the pin control driver, "qdf2xxx", which
really doesn't say anyt
On 11/02/2015 11:42 AM, Rob Herring wrote:
On Mon, Nov 2, 2015 at 11:26 AM, Timur Tabi wrote:
>On 11/02/2015 10:20 AM, Sinan Kaya wrote:
>>>
>>>
>>Is there a good example I can look or a wiki about the device-tree
>>naming conventions?
There are many examp
On 11/02/2015 10:20 AM, Sinan Kaya wrote:
Is there a good example I can look or a wiki about the device-tree
naming conventions?
I'm more of an ACPI person than DTS.
I think Rob is talking about something like this:
compatible="qcom,hidma-mgmt-1.0", "qcom,hidma-mgmt"
This specifies
Fu Wei wrote:
In virtualization system, Linux kernel with KVM support as a
Hypervisor, and guest are using a one of SBSA watchdog.
WS0 is handled by guest OS, and WS1 will be handled by Hypervisor.
I don't see how that would work, because the host kernel cannot
reconfigure the behavior of WS1.
Sinan Kaya wrote:
However, after issuing the command; I still need to wait some amount of
time until hardware acknowledges the commands like reset/enable/disable.
These are relatively faster operations happening in microseconds. That's
why, I have mdelay there.
Can you use readl_poll_timeout()?
Sinan Kaya wrote:
I expect this driver to grow in functionality over time. Right now, it
does the global init for the DMA. After that all channels execute on
their own without depending on each other. Global init has to be done
first before attempting to do any channel initialization.
There is
Sinan Kaya wrote:
I expect this driver to grow in functionality over time. Right now, it
does the global init for the DMA. After that all channels execute on
their own without depending on each other. Global init has to be done
first before attempting to do any channel initialization.
There is
On 10/30/2015 05:28 PM, Arnd Bergmann wrote:
> >Why ENODEV? Could you make this handle restarted system calls?
>
>This is the self test code. It gets called from probe. If there is a
>problem with the device or system configuration, I don't want to enable
>this device. I can certainly return a d
On 10/30/2015 04:42 PM, Sinan Kaya wrote:
if (WARN_ON(!pdev->dev.dma_mask))
return -ENXIO;
The dma mask has to always be set by the platform code before probe()
is called. If it is not set, you are not allowed to perform DMA.
I tested this on an ACPI platform BTW when I was workin
On 10/30/2015 02:05 PM, Mark Rutland wrote:
I was only asking why the interrupt was optional, and it seems per the
spec it's expected to be handed to an agent at a higher exception level.
That implies that the OS should only care about WS0, assuming that I've
understood correctly.
Yes, this my
On 10/30/2015 01:35 PM, Fu Wei wrote:
I think maybe Mark was asking why WS1 is optional, not the WS1
My answer is for "why WS1 is optional"!
>interrupt. Maybe you can reword the documentation to make is clear
>that
I didn't say : "only the*interrupt* for WS1 is optional."
WS1 itself is no
On Tue, Oct 27, 2015 at 11:10 PM, Fu Wei wrote:
>
>> Why is WS1 optional?
>
> According to the description of WS1 in SBSA 2.3 (5.2 Watchdog Operation) page
> 21
> -
> The signal is fed to a higher agent as an interrupt or reset for it to
> take executive action.
>
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:
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?
--
To unsubscribe from this list: send t
Alexander Popov wrote:
+- dma-names: should be "rx-tx";
Why bother, if it can only be one value?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fu Wei wrote:
>I think the sizes are wrong. They should be 0x1000 instead of 0x1.
This has been proved by test, it works well on Seattle
Foundation model has same value. So I don't think it is wrong
otherwise someone has the data sheet of Seattle B0, and it shows that is wrong.
The regis
On 06/10/2015 12:47 PM, fu@linaro.org wrote:
+ reg = <0x0 0xe0bb 0 0x1>,
+ <0x0 0xe0bc 0 0x1>;
I think the sizes are wrong. They should be 0x1000 instead of 0x1.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innova
fu@linaro.org wrote:
This patch enables ACPI GTDT support for ARM SBSA
watchdog driver automatically, if ACPI support is enabled.
You don't need this patch if you reorder your patches, like this:
#4 ACPI: add GTDT table parse driver into ACPI driver
#5 Watchdog: introduce ARM SBSA watchdog
fu@linaro.org wrote:
+ if (timeout <= gwdt->max_wor_timeout)
+ writel_relaxed(timeout * gwdt->clk,
+ gwdt->control_base + SBSA_GWDT_WOR);
+ else
+ writel_relaxed(gwdt->max_wor_timeout * gwdt->clk,
+
Fu Wei wrote:
Could you suggest a good way to use WS0, so we can follow SBSA spec?
To avoid the timeout/2 problem, WS0 calls panic, which is the "real"
timeout/reset. WS1 is then a "backup" that is ignored by the driver.
That is, the driver doesn't do anything with WS1 and it doesn't tell th
Fu Wei wrote:
If we make the first stage timeout is timeout/2, this violates the
definition of timeout.
The documentation says that the hardware needs to reset after the
timeout expires. If you program the hardware to timeout/2, the driver
can ignore WS0 and allow WS1 to reset the hardware.
Fu Wei wrote:
Another weakness of only using WOR is the timeout limited by this
32bit register.
10s @400MHz generic Timer
I don't think this limit is good for a server, once the server is in a
heavy load
Perhaps, but if that's the limitation of the hardware, then so be it.
--
Sent by an emplo
On 06/09/2015 11:45 AM, Guenter Roeck wrote:
I tend to agree that we should just forget about pretimeout and
use your original approach, where the timeout value is used
to program WOR. Everything else is really just asking for trouble.
The driver that I submitted is effectively the same as Fu'
On 06/09/2015 11:22 AM, Guenter Roeck wrote:
but I see your point. Essentially, the specification is broken
for all practical purposes, since, as you point out, enabling
the watchdog overwrites and explicitly sets WCV. Effectively
this means that just using WCV to program the timeout period
is
On 06/03/2015 01:25 PM, Guenter Roeck wrote:
In general the idea here would be to use a crashdump kernel, which,
when loaded, would reset the watchdog before it fires. This kernel
would then write a core dump to a specified location.
What is the mechanism for resetting the watchdog? The only c
On 06/01/2015 11:05 PM, fu@linaro.org wrote:
+ if (wdd->pretimeout)
+ /* The pretimeout is valid, go panic */
+ panic("SBSA Watchdog pre-timeout");
The problem with this is that WS1 will still occur. So a few seconds
after the panic() call, the hardware w
On 06/02/2015 11:55 AM, Fu Wei wrote:
+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+ struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id;
+ struct watchdog_device *wdd = &gwdt->wdd;
+
+ if (wdd->pretimeout)
+ /* The pretimeout is valid, go pan
On 06/01/2015 11:05 PM, fu@linaro.org wrote:
+/*
+ * help functions for accessing 32bit registers of SBSA Generic Watchdog
+ */
+static void sbsa_gwdt_cf_write(unsigned int reg, u32 val,
+ struct watchdog_device *wdd)
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_g
On 05/29/2015 12:53 PM, Fu Wei wrote:
If this interrupter is triggered, that means system has goes wrong,
who knows what is wrong ,
I have to make sure that system get into that routine ,because of the
WS0, if not I won't do panic.
But the interrupt handler is not registered as shared, which m
On 05/29/2015 09:32 AM, Fu Wei wrote:
It is a SPI, every CPU can get it,
But maybe I miss something, but please let me know if other CPU can
not get the interrupt.
There's only one watchdog device, so there's only one interrupt. I
don't know which CPU will get the interrupt, but the watchdog
Fu Wei wrote:
This should always be true. Instead of reading WCS, I think you should just
>panic().
I thinks I need to confirm it , in case this has been cleaned.
I don't see how it's possible for you to receive the interrupt and have
WCS be cleared.
--
Sent by an employee of the Qualcom
Hanjun Guo wrote:
I don't agree with this. The GTDT should be parsed even if there's no
watchdog driver compiled for this kernel. There are no other #ifdefs in
this file.
So what's the point of parse GTDT and alloc memories for it if there
is no watchdog driver compiled for the kernel?
I do
On 05/25/2015 05:03 AM, fu@linaro.org wrote:
+/*
+ * help functions for accessing 32bit registers of SBSA Generic Watchdog
+ */
+static void sbsa_gwdt_cf_write(unsigned int reg, u32 val,
+ struct watchdog_device *wdd)
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_g
On 05/26/2015 03:28 AM, Hanjun Guo wrote:
early_acpi_os_unmap_memory((char *)table, tbl_size);
}
please add
#ifdef CONFIG_ARM_SBSA_WATCHDOG
(acpi gtdt code)
#endif
I don't agree with this. The GTDT should be parsed even if there's no
watchdog driver compiled for this kernel. Ther
Fu Wei wrote:
Once the Linux kernel has KVM support and is in hyp mode. we
may need to use arch_counter_get_cntpct.
arch_counter_get_cntpct() does not appear to be valid for ARM64:
http://lxr.free-electrons.com/source/arch/arm64/include/asm/arch_timer.h#L108
--
Sent by an employee of the Qual
Guenter Roeck wrote:
The pseudo-code in the specification suggests that if WCV is configured,
WS0 = WCV
WS1 = WCV + WOR
Assuming that the implementation follows the pseudo-code in the
specification,
we would have separately programmable values. Since the pretimeout (per
ABI)
is the di
Fu Wei wrote:
I don't know why you want to do this tricky way. you can always
register the interrupt handler,
if pre-timeout is 0, system will just trigger WS1 right after WS0
But that only works if the pre-timeout and timeout can be programmed to
separate values. And as Guenter says, the SB
Guenter Roeck wrote:
The current watchdog API suggests that the pretimeout "allows Linux
to record useful information (like panic information and kernel
coredumps) before it resets". The call to panic() would be the
means to make this happen.
Now that I think about it, that does make sense.
H
Fu Wei wrote:
in the first timeout, just panic() maybe not enough, in [RFC]
version of my patchset, I offer some option as "preaction" to use, but
for simplifying the first version of driver, I have deleted them.
but at least, panic() is far more useful than a simple reset. at
least, it can pr
Guenter Roeck wrote:
Maybe you and/or Timur can test this on the real systems you
have access to. It should be quite straightforward to test -
have the interrupt handler only print a message, program some
values into the watchdog, and see when WS0 and WS1 occur.
I'll try, but on my system, WS1
Fu Wei wrote:
If pretimeout concept assumes that there are two timers, I
misunderstand the "pretimeout", then I will delete the pretimeout
immediately.
In my opinion, calling panic() on a pre-timeout is not useful, because
that's really just a normal timeout. If there were a way to "warn" use
Guenter Roeck wrote:
However, the pretimeout concept assumes that there are two timers
which can be set independently. As you had pointed out earlier,
and as the specification seems to confirm, that is not the case here.
As such, I don't really understand why and how the pretimeout / timeout
con
fu@linaro.org wrote:
From: Fu Wei
Parse SBSA Generic Watchdog Structure in GTDT table of ACPI,
and create a platform device with that information.
This platform device can be used by the ARM SBSA Generic
Watchdog driver.
Signed-off-by: Fu Wei
Tested-by: Timur Tabi
I have modified my
Fu Wei wrote:
Hi Timur,
On 21 May 2015 at 23:42, Timur Tabi wrote:
On 05/21/2015 03:32 AM, fu@linaro.org wrote:
+static void reload_timeout_to_wcv(struct watchdog_device *wdd)
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+ u64 wcv;
+
+ wcv
Fu Wei wrote:
Because there's no market for it. I'm not talking about what's
theoretically possible. I'm only talking about what makes sense and what
will actually happen. And I'm quite certain that we will never see an
actual 32-bit ARM SOC with an SBSA watchdog device in it.
Why are you q
Fu Wei wrote:
I wonder why you are so sure "that SOC won't have an SBSA watchdog in
it." any documentation ?
Sorry, I am not a chip design engineer, I can't see why 32-bit ARM
won't have an SBSA watchdog in it.
Because there's no market for it. I'm not talking about what's
theoretically poss
Guenter Roeck wrote:
I think it is quite unfortunate that the specification is not public.
We have heard many statements about what is in the spec or not.
All you need to do is go to
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029b/index.html,
get a free ARM account, and d
Arnd Bergmann wrote:
I think it's a reasonable assumption that someone will sooner or later
put that hardware into an ARM32 machine,
I'm going to have to disagree. If they haven't done it by now, I can't
imagine any ARM SOC vendor creating a 32-bit ARM SOC with an SBSA
watchdog in it. I can
On 05/22/2015 03:13 PM, Arnd Bergmann wrote:
That might still be helpful to get coverage from things like the public
coverity builds that always build x86 allmodconfig, but it's also a bit
ugly.
Adding #ifdefs to allow COMPILE_TEST to work seems ironic to me.
--
Qualcomm Innovation Center, In
On 05/22/2015 10:16 AM, Guenter Roeck wrote:
Doo bad that SBSA is not hardware independent enough to provide all
the information needed to implement such a driver:-(.
The SBSA is designed and intended only for ARM Servers. It has no value
on non-ARM SOCs and and non-server SOCs. The SBSA is
On 05/22/2015 10:24 AM, Arnd Bergmann wrote:
That will break the ACPI case, but ACPI could use platform_data to
pass the clock rate into the driver, to make it independent of
low-level APIs.
The clock rate isn't the only problem. You still need to current clock
timestamp, and that's ARM-speci
On 05/22/2015 10:01 AM, Guenter Roeck wrote:
>
Tricky, though. Since teh driver uses arm specific clock functions,
I don't think this can compile on a non-arm machine.
Any it doesn't need to. This driver is for 64-bit ARM Server SOCs.
There will never be any other kind of SOC that has an SBS
On 05/22/2015 09:55 AM, Arnd Bergmann wrote:
While SBSA requires this watchdog device, nothing prevents SoC
manufacturers from using the same design in something that is not
a server.
The first "S" in SBSA stands for "Server". I don't think it makes sense
to put an SBSA watchdog device in a
fu@linaro.org wrote:
Some devices get clock from system counter, like SBSA watchdog
driver. They may need to get system counter rate.
We don't need this patch. The watchdog driver can use
arch_timer_get_cntfrq() instead of arch_timer_get_rate(). There's
nothing wrong with arch_timer_get
On 05/21/2015 11:12 AM, Fu Wei wrote:
>
>Having said that, my personal preference would be for the counter
>and rate to be exported through the clock subsystem (ie with
>clk_get_rate). But that would still not provide the current counter
>value, so maybe that isn't even possible.
I will try to m
On 05/21/2015 03:32 AM, fu@linaro.org wrote:
+static void reload_timeout_to_wcv(struct watchdog_device *wdd)
+{
+ struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+ u64 wcv;
+
+ wcv = arch_counter_get_cntvct() +
+ (u64)(wdd->timeout - wdd->pretimeout) * gwdt->clk;
Guenter Roeck wrote:
+static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
+{
+struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+u64 timeleft = sbsa_gwdt_get_wcv(wdd) - arch_counter_get_cntvct();
+
Still not happy about the use of arch_counter_get_cntvct
instead of using
Xiubo Li wrote:
- sai->big_endian_data = of_property_read_bool(np, "big-endian-data");
+ sai->is_msb_first = of_property_read_bool(np, "msb-first");
This will break backwards compatibility with older device trees.
--
To unsubscribe from this list: send the line "unsubscribe devicetr
On 04/08/2014 09:18 AM, Timur Tabi wrote:
Back in July, Qualcomm submitted a patch that added this information
into the device tree:
http://marc.info/?t=13718516613&r=1&w=2
However, this was rejected. Now it appears that this information is
again being added to the device tree,
On 04/08/2014 08:46 AM, Ivan T. Ivanov wrote:
>This patch adds that same exact information into the device tree. Why
>are we duplicating that information? Why add it to the device tree when
>it's already in the driver (and already working).
Probably. It was my natural way of thinking. Pin ha
Ivan T. Ivanov wrote:
>I'm confused by this. Isn't this information already defined in the
>pinctrl-msm8x74.c driver?
>
>static const char * const blsp_spi8_groups[] = {
> "gpio45", "gpio46", "gpio47", "gpio48"
>};
I am not sure that I understand the question. This is one of
possible ways t
On Thu, Feb 6, 2014 at 9:28 AM, Ivan T. Ivanov wrote:
> + msmgpio: pinctrl@fd51 {
> + compatible = "qcom,msm8974-pinctrl";
> + reg = <0xfd51 0x4000>;
> + gpio-controller;
> + #gpio-cells
On Thu, Feb 6, 2014 at 9:28 AM, Ivan T. Ivanov wrote:
> + spi8_default: spi8_default {
> + mosi {
> + pins = "gpio45";
> + function = "blsp_spi8";
> +
Nicolin Chen wrote:
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
+ } else {
+
Chen Guangyu-B42378 wrote:
Without dual fifo support, handware underrun would occasionally
occur and then two audio channels would physically swap. This could
be easily reproduced in low bus frequency situation, while it would
be better if we enable dual fifo.
Ok.
ACK.
--
To unsubscribe from
Nicolin Chen wrote:
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
Have you measured any real performance gain with this patch? I
considered adding dual-FIFO support when I originally wrote this
Lars-Peter Clausen wrote:
>Maybe I've been out of the loop for too long, but why is that a particular
>problem with this driver?
It is usually something you'd want to check in general to make sure that you
don't have multiple device that access the same iomem region at the same time.
I under
Lars-Peter Clausen wrote:
>>+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>+sai->base = devm_ioremap_resource(&pdev->dev, res);
>
>Why not use of_iomap()?
Because it won't check for conflicting resource regions.
Maybe I've been out of the loop for too long, but why is that a
Xiubo Li wrote:
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ sai->base = devm_ioremap_resource(&pdev->dev, res);
Why not use of_iomap()?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More m
89 matches
Mail list logo
