* Re: FSL SPI driver question
From: Norbert van Bolhuis @ 2012-01-26 15:07 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-dev
In-Reply-To: <OF248EC14B.3E5BA3A6-ON88257990.006C779B-88257990.006CE971@selinc.com>
Hi Bruce,
On 01/25/12 20:49, Bruce_Leonard@selinc.com wrote:
.
.
.
> Thanks for the reply. Yes I did find spidev_fdx.c and in fact copied it
> for my tests. I still see SPICLK active only during the time the 8308 is
> sending data (read cmd + address). Nothing happens with the clock after
> that when the NvRAM is ready to send data.
>
> Bruce
>
ok, then I don't know.
I doubt this is a spidev or FSP SPI driver problem though.
Questions like:
Could it be a HW problem ?
Is the correct SPI mode used ?
Does it work in u-boot ?
Come to mind in a situation like this.
Norbert.
^ permalink raw reply
* Re: [RFC 1/2] irq_domain: Create common xlate functions that device drivers can use
From: Grant Likely @ 2012-01-26 18:15 UTC (permalink / raw)
To: Rob Herring; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <4F216819.7030106@gmail.com>
On Thu, Jan 26, 2012 at 7:50 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 01/25/2012 11:59 AM, Grant Likely wrote:
>> On Tue, Jan 24, 2012 at 10:35 PM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>> On Tue, Jan 24, 2012 at 6:50 PM, Rob Herring <robherring2@gmail.com> wr=
ote:
>>>>
>>>>
>>>> On 01/24/2012 06:18 PM, Grant Likely wrote:
>>>>> Rather than having each interrupt controller driver creating its own =
barely
>>>>> unique .xlate function for irq_domain, create a library of translator=
s which
>>>>> any driver can use directly.
>>>>>
>>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>>> index e7379a3..5e497a0 100644
>>>>> --- a/include/linux/irqdomain.h
>>>>> +++ b/include/linux/irqdomain.h
>>>>> @@ -110,6 +110,9 @@ struct irq_domain {
>>>>> =A0 =A0 =A0 void *host_data;
>>>>> =A0 =A0 =A0 irq_hw_number_t inval_irq;
>>>>>
>>>>> + =A0 =A0 /* Data for common irq xlate functions */
>>>>> + =A0 =A0 unsigned int xlate_type;
>>>>> +
>>>>
>>>> How does this get set? Do we want interrupt controllers messing with t=
he
>>>> domain struct directly long term?
>>>
>>> It defaults to IRQ_TYPE_NONE in the alloc function and drivers can
>>> override it. =A0Alternately it could be made part of the
>>> irq_domain_add() arguments, but I'm not thrilled with adding a whole
>>> bunch of arguments to the function prototype.
>>
>> Do you like this better (built on top of this patch)?
>
> Yes, I think it's better.
I've changed my mind on this after looking at the generated code.
These functions are so simple that it actually is larger (both in
source and object size) to call out to a common function. I've gone
back to each _xlate_*() function open coding the two assignments.
g.
>
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index ef2b1fe..7856c04 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -701,12 +701,10 @@ int irq_domain_xlate_onecell(struct irq_domain
>> *d, struct device_node *ctrlr,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const u32 *intspe=
c, unsigned int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *ou=
t_hwirq, unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 1))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> - =A0 =A0 *out_hwirq =3D intspec[0];
>> - =A0 =A0 *out_type =3D d->xlate_type;
>> - =A0 =A0 return 0;
>> + =A0 =A0 return irq_domain_xlate_onetwocell(d, ctrlr, intspec, 1,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0out_hwirq, out_type);
>> =A0}
>> =A0EXPORT_SYMBOL_GPL(irq_domain_xlate_onecell);
>>
>> @@ -721,12 +719,10 @@ int irq_domain_xlate_twocell(struct irq_domain
>> *d, struct device_node *ctrlr,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *intspec, unsigned=
int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq_hw_number_t *out_hwirq, =
unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 2, "Bad intspec for %s: intsize=3D%i < 2\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 2))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> - =A0 =A0 *out_hwirq =3D intspec[0];
>> - =A0 =A0 *out_type =3D intspec[1] & IRQ_TYPE_SENSE_MASK;
>> - =A0 =A0 return 0;
>> + =A0 =A0 return irq_domain_xlate_onetwocell(d, ctrlr, intspec, intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0out_hwirq, out_type);
>> =A0}
>> =A0EXPORT_SYMBOL_GPL(irq_domain_xlate_twocell);
>>
>> @@ -746,8 +742,7 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d=
,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *i=
ntspec, unsigned int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned lon=
g *out_hwirq, unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 1))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> =A0 =A0 =A0 *out_hwirq =3D intspec[0];
>> =A0 =A0 =A0 *out_type =3D d->xlate_type;
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: FSL SPI driver question
From: Bruce_Leonard @ 2012-01-26 19:49 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev
In-Reply-To: <4F216C25.6000303@aimvalley.nl>
Norbert,
>
> ok, then I don't know.
>
> I doubt this is a spidev or FSP SPI driver problem though.
>
> Questions like:
>
> Could it be a HW problem ?
> Is the correct SPI mode used ?
> Does it work in u-boot ?
>
> Come to mind in a situation like this.
>
Thanks for the suggestions. I finally found it in the wee hours this
morning, and it was operator error. The CY14 by default powers up in the
write protect state and from the factory is erased to all zeros. So my
writes and subsequent reads appeared to fail by the "fact" that I could
never read what I wrote. Guess I need better reading glasses in my old
age :-/
Anyway, I'm happily up and talking using the Freescale SPI driver and
spidev. Thanks for the help and sorry for the noise on the list.
Bruce
^ permalink raw reply
* [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-01-26 20:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dan Williams
The mpc8349ea has been observed to generate spurious end of segments
interrupts despite the fact that they are not enabled by this driver.
Check for them and ignore them to avoid a kernel error message.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Dan Williams <dan.j.williams@intel.com>
---
drivers/dma/fsldma.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8a78154..7dc9689 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1052,6 +1052,16 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
stat &= ~FSL_DMA_SR_EOLNI;
}
+ /*
+ * This driver does not use this feature, therefore we shouldn't
+ * ever see this bit set in the status register. However, it has
+ * been observed on MPC8349EA parts.
+ */
+ if (stat & FSL_DMA_SR_EOSI) {
+ chan_dbg(chan, "irq: End-of-Segments INT\n");
+ stat &= ~FSL_DMA_SR_EOSI;
+ }
+
/* check that the DMA controller is really idle */
if (!dma_is_idle(chan))
chan_err(chan, "irq: controller not idle!\n");
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/1] carma-fpga: fix lockdep warning
From: Ira W. Snyder @ 2012-01-26 20:59 UTC (permalink / raw)
To: linuxppc-dev
Lockdep occasionally complains with the message:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
This is caused by calling videobuf_dma_unmap() under spin_lock_irq(). To
fix the warning, we drop the lock before unmapping and freeing the
buffer.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/misc/carma/carma-fpga.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c
index 14e974b2..4fd896d 100644
--- a/drivers/misc/carma/carma-fpga.c
+++ b/drivers/misc/carma/carma-fpga.c
@@ -1079,6 +1079,7 @@ static ssize_t data_read(struct file *filp, char __user *ubuf, size_t count,
struct fpga_reader *reader = filp->private_data;
struct fpga_device *priv = reader->priv;
struct list_head *used = &priv->used;
+ bool drop_buffer = false;
struct data_buf *dbuf;
size_t avail;
void *data;
@@ -1166,10 +1167,12 @@ have_buffer:
* One of two things has happened, the device is disabled, or the
* device has been reconfigured underneath us. In either case, we
* should just throw away the buffer.
+ *
+ * Lockdep complains if this is done under the spinlock, so we
+ * handle it during the unlock path.
*/
if (!priv->enabled || dbuf->size != priv->bufsize) {
- videobuf_dma_unmap(priv->dev, &dbuf->vb);
- data_free_buffer(dbuf);
+ drop_buffer = true;
goto out_unlock;
}
@@ -1178,6 +1181,12 @@ have_buffer:
out_unlock:
spin_unlock_irq(&priv->lock);
+
+ if (drop_buffer) {
+ videobuf_dma_unmap(priv->dev, &dbuf->vb);
+ data_free_buffer(dbuf);
+ }
+
return count;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/1] carma-fpga: fix race between data dumping and DMA callback
From: Ira W. Snyder @ 2012-01-26 21:00 UTC (permalink / raw)
To: linuxppc-dev
When the system is under heavy load, we occasionally saw a problem where
the system would get a legitimate interrupt when they should be
disabled.
This was caused by the data_dma_cb() DMA callback unconditionally
re-enabling FPGA interrupts even when data dumping is disabled. When
data dumping was re-enabled, the irq handler would fire while a DMA was
in progress. The "BUG_ON(priv->inflight != NULL);" during the second
invocation of the DMA callback caused the system to crash.
To fix the issue, the priv->enabled boolean is moved under the
protection of the priv->lock spinlock. The DMA callback checks the
boolean to know whether to re-enable FPGA interrupts before it returns.
Now that it is fixed, the driver keeps FPGA interrupts disabled when it
expects that they are disabled, fixing the bug.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/misc/carma/carma-fpga.c | 101 +++++++++++++++++++++++---------------
1 files changed, 61 insertions(+), 40 deletions(-)
diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c
index 4fd896d..0cfc5bf 100644
--- a/drivers/misc/carma/carma-fpga.c
+++ b/drivers/misc/carma/carma-fpga.c
@@ -560,6 +560,9 @@ static void data_enable_interrupts(struct fpga_device *priv)
/* flush the writes */
fpga_read_reg(priv, 0, MMAP_REG_STATUS);
+ fpga_read_reg(priv, 1, MMAP_REG_STATUS);
+ fpga_read_reg(priv, 2, MMAP_REG_STATUS);
+ fpga_read_reg(priv, 3, MMAP_REG_STATUS);
/* switch back to the external interrupt source */
iowrite32be(0x3F, priv->regs + SYS_IRQ_SOURCE_CTL);
@@ -591,8 +594,12 @@ static void data_dma_cb(void *data)
list_move_tail(&priv->inflight->entry, &priv->used);
priv->inflight = NULL;
- /* clear the FPGA status and re-enable interrupts */
- data_enable_interrupts(priv);
+ /*
+ * If data dumping is still enabled, then clear the FPGA
+ * status registers and re-enable FPGA interrupts
+ */
+ if (priv->enabled)
+ data_enable_interrupts(priv);
spin_unlock_irqrestore(&priv->lock, flags);
@@ -708,6 +715,15 @@ static irqreturn_t data_irq(int irq, void *dev_id)
spin_lock(&priv->lock);
+ /*
+ * This is an error case that should never happen.
+ *
+ * If this driver has a bug and manages to re-enable interrupts while
+ * a DMA is in progress, then we will hit this statement and should
+ * start paying attention immediately.
+ */
+ BUG_ON(priv->inflight != NULL);
+
/* hide the interrupt by switching the IRQ driver to GPIO */
data_disable_interrupts(priv);
@@ -762,11 +778,15 @@ out:
*/
static int data_device_enable(struct fpga_device *priv)
{
+ bool enabled;
u32 val;
int ret;
/* multiple enables are safe: they do nothing */
- if (priv->enabled)
+ spin_lock_irq(&priv->lock);
+ enabled = priv->enabled;
+ spin_unlock_irq(&priv->lock);
+ if (enabled)
return 0;
/* check that the FPGAs are programmed */
@@ -797,6 +817,9 @@ static int data_device_enable(struct fpga_device *priv)
goto out_error;
}
+ /* prevent the FPGAs from generating interrupts */
+ data_disable_interrupts(priv);
+
/* hookup the irq handler */
ret = request_irq(priv->irq, data_irq, IRQF_SHARED, drv_name, priv);
if (ret) {
@@ -804,11 +827,13 @@ static int data_device_enable(struct fpga_device *priv)
goto out_error;
}
- /* switch to the external FPGA IRQ line */
- data_enable_interrupts(priv);
-
- /* success, we're enabled */
+ /* allow the DMA callback to re-enable FPGA interrupts */
+ spin_lock_irq(&priv->lock);
priv->enabled = true;
+ spin_unlock_irq(&priv->lock);
+
+ /* allow the FPGAs to generate interrupts */
+ data_enable_interrupts(priv);
return 0;
out_error:
@@ -834,41 +859,40 @@ out_error:
*/
static int data_device_disable(struct fpga_device *priv)
{
- int ret;
+ spin_lock_irq(&priv->lock);
/* allow multiple disable */
- if (!priv->enabled)
+ if (!priv->enabled) {
+ spin_unlock_irq(&priv->lock);
return 0;
+ }
+
+ /*
+ * Mark the device disabled
+ *
+ * This stops DMA callbacks from re-enabling interrupts
+ */
+ priv->enabled = false;
- /* switch to the internal GPIO IRQ line */
+ /* prevent the FPGAs from generating interrupts */
data_disable_interrupts(priv);
+ /* wait until all ongoing DMA has finished */
+ while (priv->inflight != NULL) {
+ spin_unlock_irq(&priv->lock);
+ wait_event(priv->wait, priv->inflight == NULL);
+ spin_lock_irq(&priv->lock);
+ }
+
+ spin_unlock_irq(&priv->lock);
+
/* unhook the irq handler */
free_irq(priv->irq, priv);
- /*
- * wait for all outstanding DMA to complete
- *
- * Device interrupts are disabled, therefore another buffer cannot
- * be marked inflight.
- */
- ret = wait_event_interruptible(priv->wait, priv->inflight == NULL);
- if (ret)
- return ret;
-
/* free the correlation table */
sg_free_table(&priv->corl_table);
priv->corl_nents = 0;
- /*
- * We are taking the spinlock not to protect priv->enabled, but instead
- * to make sure that there are no readers in the process of altering
- * the free or used lists while we are setting this flag.
- */
- spin_lock_irq(&priv->lock);
- priv->enabled = false;
- spin_unlock_irq(&priv->lock);
-
/* free all buffers: the free and used lists are not being changed */
data_free_buffers(priv);
return 0;
@@ -896,15 +920,6 @@ static unsigned int list_num_entries(struct list_head *list)
static int data_debug_show(struct seq_file *f, void *offset)
{
struct fpga_device *priv = f->private;
- int ret;
-
- /*
- * Lock the mutex first, so that we get an accurate value for enable
- * Lock the spinlock next, to get accurate list counts
- */
- ret = mutex_lock_interruptible(&priv->mutex);
- if (ret)
- return ret;
spin_lock_irq(&priv->lock);
@@ -917,7 +932,6 @@ static int data_debug_show(struct seq_file *f, void *offset)
seq_printf(f, "num_dropped: %d\n", priv->num_dropped);
spin_unlock_irq(&priv->lock);
- mutex_unlock(&priv->mutex);
return 0;
}
@@ -970,7 +984,13 @@ static ssize_t data_en_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
struct fpga_device *priv = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
+ int ret;
+
+ spin_lock_irq(&priv->lock);
+ ret = snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
+ spin_unlock_irq(&priv->lock);
+
+ return ret;
}
static ssize_t data_en_set(struct device *dev, struct device_attribute *attr,
@@ -986,6 +1006,7 @@ static ssize_t data_en_set(struct device *dev, struct device_attribute *attr,
return -EINVAL;
}
+ /* protect against concurrent enable/disable */
ret = mutex_lock_interruptible(&priv->mutex);
if (ret)
return ret;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 1/1] carma-fpga: fix race between data dumping and DMA callback
From: Benjamin Herrenschmidt @ 2012-01-26 21:25 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev
In-Reply-To: <1327611614-18508-1-git-send-email-iws@ovro.caltech.edu>
On Thu, 2012-01-26 at 13:00 -0800, Ira W. Snyder wrote:
>
> @@ -970,7 +984,13 @@ static ssize_t data_en_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> struct fpga_device *priv = dev_get_drvdata(dev);
> - return snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
> + int ret;
> +
> + spin_lock_irq(&priv->lock);
> + ret = snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
> + spin_unlock_irq(&priv->lock);
> +
> + return ret;
> }
I don't think the lock buys you anything here.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFCv2 00/14]
From: Grant Likely @ 2012-01-26 21:33 UTC (permalink / raw)
To: Rob Herring
Cc: Cousson, Benoit, devicetree-discuss, linux-kernel, Milton Miller,
Shawn Guo, linuxppc-dev
In-Reply-To: <4F204F1C.70908@gmail.com>
On Wed, Jan 25, 2012 at 11:51 AM, Rob Herring <robherring2@gmail.com> wrote=
:
> On 01/25/2012 08:13 AM, Cousson, Benoit wrote:
>> On 1/23/2012 10:53 PM, Rob Herring wrote:
>>> On 01/23/2012 03:07 PM, Grant Likely wrote:
>>>>
>>>> Hey everyone,
>>>>
>>>> Here's the second RFC for the irq_domain patches. =A0I could use some
>>>> help testing now. =A0I still expect there will be a few bugs. =A0The
>>>> series is based on v3.3-rc1, and I've pushed it out to my git server:
>>>>
>>>> git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
>>>
>>> Can you post to linux-arm-kernel too so people are aware of this work
>>> and stop posting dead-end irqdomain patches.
>>
>> Good point, I have two pending series that are using the
>> irq_domain_add() so far, so it will be good to have that branch pulled
>> in arm-soc.
>>
>>> I tested what you had as of this morning and it works fine for me. Look=
s
>>> like the only diff is the VExpress code. I'm working on rebasing my
>>> domain support for generic irqchip now.
>>
>> In fact your generic irqchip should even avoid us to use
>> irq_domain_add_legacy() since both GPIO and OMAP3 intc are already using
>> the irqchip.
>>
>> I guess you are not going to change the interface so the patches I did
>> on your previous branch to try them should be good already, isn't it?
>
> I've got it rebased on top of Grant's tree. I will send it out soon.
>
> One problem that still remains is it breaks x86 and any platform using
> generic irq chip, but not selecting IRQ_DOMAIN. Grant, do you plan to
> enable IRQ_DOMAIN for x86 in your series? MIPS may also need fixing.
I've got the x86 fix in my tree now. It will be part of the next
merge. MIPS, Microblaze and OpenRISC cannot turn on CONFIG_IRQ_DOMAIN
without rework. I just hacked together the microblaze version, but
Michal will have to verify that it is correct. I just posted it. It
will be similar for the other two.
The real problem is sparc which does something entirely different for
irqs. Rather than resolving irqs on-demand, it calculates the Linux
irq numbers at boot time for every node in the tree. The irq_domains
will need to be set up for all interrupt controllers before sparc
begins it's big walk of the tree to resolve interrupts. I haven't dug
into everything that needs to be done to support this.
I don't think you can count on turning on IRQ_DOMAIN on all
architectures just yet. Adding irq_domain support directly to
irq_generic_chip is going to be difficult for that reason. However,
it would be useful to have an irq_domain+irq_generic_chip wrapper that
can be enabled only when IRQ_DOMAIN is enabled.
g.
^ permalink raw reply
* [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
From: Alexandre Bounine @ 2012-01-26 21:22 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev, vinod.koul, dan.j.williams
Cc: Jassi Brar, Alexandre Bounine, Russell King
As we agreed during our discussion about adding DMA Engine support for RapidIO
subsystem, RapidIO and similar clients may benefit from adding an extra context
parameter to device_prep_slave_sg() callback.
See https://lkml.org/lkml/2011/10/24/275 for more details.
Adding the context parameter will allow to pass client/target specific
information associated with an individual data transfer request.
In the case of RapidIO support this additional information consists of target
destination ID and its buffer address (which is not mapped into the local CPU
memory space). Because a single RapidIO-capable DMA channel may queue data
transfer requests to different target devices, the per-request configuration
is required.
The proposed change eliminates need for new subsystem-specific API.
Existing DMA_SLAVE clients will ignore the new parameter.
This RFC only demonstrates the API change and does not include corresponding
changes to existing DMA_SLAVE clients. Complete set of patches will be provided
after (if) this API change is accepted.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
---
include/linux/dmaengine.h | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 679b349..79d71bb 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -575,7 +575,7 @@ struct dma_device {
struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
- unsigned long flags);
+ unsigned long flags, void *context);
struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction);
@@ -607,12 +607,13 @@ static inline int dmaengine_slave_config(struct dma_chan *chan,
static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
struct dma_chan *chan, void *buf, size_t len,
- enum dma_transfer_direction dir, unsigned long flags)
+ enum dma_transfer_direction dir, unsigned long flags, void *context)
{
struct scatterlist sg;
sg_init_one(&sg, buf, len);
- return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags);
+ return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags,
+ context);
}
static inline int dmaengine_terminate_all(struct dma_chan *chan)
--
1.7.8.4
^ permalink raw reply related
* Re: tlb flushing on Power
From: Benjamin Herrenschmidt @ 2012-01-26 21:39 UTC (permalink / raw)
To: Brian King; +Cc: Seth Jennings, Robert Jennings, linuxppc-dev, Dave Hansen
In-Reply-To: <4F216620.2010509@linux.vnet.ibm.com>
On Thu, 2012-01-26 at 08:41 -0600, Brian King wrote:
> CC'ing linuxppc-dev...
>
>
> On 01/26/2012 08:18 AM, Seth Jennings wrote:
> > Hey Dave,
> >
> > So I submitted the zsmalloc patches to lkml at the beginning
> > of the year
> >
> > https://lkml.org/lkml/2012/1/9/389
> >
> > I found there are two functions Nitin used in the mapping
> > functions that are not supported in the powerpc arch:
> > set_pte() and __flush_tlb_one().
.../...
The arch management of page tables can be tricky indeed :-) I need to
have a better understanding of what you are doing to see how I can try
to adapt it to power.
set_pte() is long gone on all archs really (or if it's still there it's
not meant to be used as is), use set_pte_at().
__flush_tlb_one() doesn't mean anything as an arch independent
functionality. We have a local_flush_tlb_page() that -might- do what you
want but why in hell is that patch not using proper existing
interfaces ?
Can you explain to me a bit more the whole business in this patch set
about doing kmap_atomic() vs. manually trying to populate the PTEs ? Why
not just use two kmap atomic entries ? If interrupts are disabled
kmap_atomic() should give you contiguous ones I suppose (unless NMIs are
allowed to use kmap_atomic, are they ?)
Cheers,
Ben.
^ permalink raw reply
* Re: tlb flushing on Power
From: Dave Hansen @ 2012-01-26 22:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Brian King, Seth Jennings, Robert Jennings, linuxppc-dev
In-Reply-To: <1327613953.24487.9.camel@pasglop>
On 01/26/2012 01:39 PM, Benjamin Herrenschmidt wrote:
> Can you explain to me a bit more the whole business in this patch set
> about doing kmap_atomic() vs. manually trying to populate the PTEs ?
They're compressing pages and the allocator is trying getting very poor
packing of compressed pages in to PAGE_SIZE chunks. So, they're moving
to 2-page allocations that they need to be mapped contiguously to make
it easier on the users of the allocator.
> Why not just use two kmap atomic entries ? If interrupts are disabled
> kmap_atomic() should give you contiguous ones I suppose
I think you and I are at least on the same page on this one:
https://lkml.org/lkml/2012/1/26/355
> (unless NMIs are allowed to use kmap_atomic, are they ?)
Surely they can't be. Even if they could use it, they'd have to return
the __kmap_atomic_idx back to the place where it started before they
returned, so the interrupted code wouldn't notice.
^ permalink raw reply
* Re: tlb flushing on Power
From: Benjamin Herrenschmidt @ 2012-01-27 2:40 UTC (permalink / raw)
To: Dave Hansen; +Cc: Brian King, Seth Jennings, Robert Jennings, linuxppc-dev
In-Reply-To: <4F21D3F4.7020904@linux.vnet.ibm.com>
On Thu, 2012-01-26 at 14:30 -0800, Dave Hansen wrote:
> On 01/26/2012 01:39 PM, Benjamin Herrenschmidt wrote:
> > Can you explain to me a bit more the whole business in this patch set
> > about doing kmap_atomic() vs. manually trying to populate the PTEs ?
>
> They're compressing pages and the allocator is trying getting very poor
> packing of compressed pages in to PAGE_SIZE chunks. So, they're moving
> to 2-page allocations that they need to be mapped contiguously to make
> it easier on the users of the allocator.
>
> > Why not just use two kmap atomic entries ? If interrupts are disabled
> > kmap_atomic() should give you contiguous ones I suppose
>
> I think you and I are at least on the same page on this one:
>
> https://lkml.org/lkml/2012/1/26/355
Right. We probably want to document this somewhere if we start relying
on that behaviour or at the very least add a WARN_ON() and fail from the
compressed allocator if we end up with non-contiguous pages.
> > (unless NMIs are allowed to use kmap_atomic, are they ?)
>
> Surely they can't be. Even if they could use it, they'd have to return
> the __kmap_atomic_idx back to the place where it started before they
> returned, so the interrupted code wouldn't notice.
Ah indeed, that's for talking before I had breakfast :-)
Cheers,
Ben.
^ permalink raw reply
* (no subject)
From: Bruce_Leonard @ 2012-01-27 4:29 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm using the 3.0.3 kernel on an MPC8308 and have turned on GPIO support
(CONFIG_GPIOLIB = Y) because the SPI sub-system needed to use it for the
GPIO pin I'm using as a CS to a NvRAM part. I also have some jumpers on
the processor GPIO pins and I thought it would be really slick to use the
built in GPIO support in the kernel rather than roll my own driver to read
five pins. So I've got GPIO sysfs support turned on (CONFIG_GPIO_SYSFS =
Y) and everything shows up in /sys/class/gpio and works as advertised.
Really nice.
The problem is we've got a number of other things hooked up to the GPIO
pins that it would be very bad if someone from user space played with
them, like our FPGA configuration pin. Some one toggles that and our box
goes stupid. So what I'm wondering is if there's a way, preferably via
the device tree, to limit the GPIOs that GPIO Lib exposes to user space?
I tried the following in my device tree without success:
gpio1: gpio@c00 {
#gpio-cells = <2>;
device_type = "gpio";
compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
reg = <0xc00 0x18>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
gpio-controller;
gpios = <&gpio1 0 0
&gpio1 1 0
&gpio1 2 0
&gpio1 3 0
&gpio1 4 0
&gpio1 5 0
&gpio1 6 0>;
};
I also thought maybe a separate child node of the gpio1 node, but I think
it would require a "compatible" attribute which would mean a driver to
bind it to, and the whole point is to avoid writing a driver if someone
else has already got something that will work.
Thanks.
Bruce
^ permalink raw reply
* Question about GPIO Lib
From: Bruce_Leonard @ 2012-01-27 4:31 UTC (permalink / raw)
To: linuxppc-dev
(This time with a subject line, sorry)
Hi,
I'm using the 3.0.3 kernel on an MPC8308 and have turned on GPIO support
(CONFIG_GPIOLIB = Y) because the SPI sub-system needed to use it for the
GPIO pin I'm using as a CS to a NvRAM part. I also have some jumpers on
the processor GPIO pins and I thought it would be really slick to use the
built in GPIO support in the kernel rather than roll my own driver to read
five pins. So I've got GPIO sysfs support turned on (CONFIG_GPIO_SYSFS =
Y) and everything shows up in /sys/class/gpio and works as advertised.
Really nice.
The problem is we've got a number of other things hooked up to the GPIO
pins that it would be very bad if someone from user space played with
them, like our FPGA configuration pin. Some one toggles that and our box
goes stupid. So what I'm wondering is if there's a way, preferably via
the device tree, to limit the GPIOs that GPIO Lib exposes to user space?
I tried the following in my device tree without success:
gpio1: gpio@c00 {
#gpio-cells = <2>;
device_type = "gpio";
compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
reg = <0xc00 0x18>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
gpio-controller;
gpios = <&gpio1 0 0
&gpio1 1 0
&gpio1 2 0
&gpio1 3 0
&gpio1 4 0
&gpio1 5 0
&gpio1 6 0>;
};
I also thought maybe a separate child node of the gpio1 node, but I think
it would require a "compatible" attribute which would mean a driver to
bind it to, and the whole point is to avoid writing a driver if someone
else has already got something that will work.
Thanks.
Bruce
^ permalink raw reply
* Another FSL SPI driver question (warning long post)
From: Bruce_Leonard @ 2012-01-27 6:43 UTC (permalink / raw)
To: linuxppc-dev
Hi Kumar,
I'm using the 3.0.3 kernel on an MPC8308 and utilizing the spi_fsl_spi
driver to talk with an Cypress NvRAM device. I've gotten that working
now, but I've come across something I don't understand in the driver and
I'm not sure if it's just me or if there's a bug. My issue relates to
chip selects, their active state, and their specification in the device
tree (lots of moving parts here, so I hope I describe it well enough to be
understood). The chip select for the NvRAM is active low, but setting
everything up they way I _think_ it should be for an active low signal
gets me an active high signal.
The device tree entry is:
spi@7000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl,spi";
reg = <0x7000 0x1000>;
interrupts = <16 0x8>;
interrupt-parent = <&ipic>;
mode = "cpu";
gpios = <&gpio1 16 1>;
nvram@0 {
compatible = "spidev";
spi-max-frequency = <40000000>;
reg = <0>;
};
};
And the relevant driver code is the fsl_spi_chipselect and the
fsl_spi_cs_control functions shown below (line numbers are for reference
only and don't match lines numbers in .../drivers/spi/spi_fsl_spi.c):
1 static void fsl_spi_chipselect(struct spi_device *spi, int value)
2 {
3 struct mpc8xxx_spi *mpc8xxx_spi =
spi_master_get_devdata(spi->master);
4 struct fsl_spi_platform_data *pdata =
spi->dev.parent->platform_data;
5 bool pol = spi->mode & SPI_CS_HIGH;
6 struct spi_mpc8xxx_cs *cs = spi->controller_state;
7
8 if (value == BITBANG_CS_INACTIVE) {
9 if (pdata->cs_control)
10 pdata->cs_control(spi, !pol);
11 }
12
13 if (value == BITBANG_CS_ACTIVE) {
14 mpc8xxx_spi->rx_shift = cs->rx_shift;
15 mpc8xxx_spi->tx_shift = cs->tx_shift;
16 mpc8xxx_spi->get_rx = cs->get_rx;
17 mpc8xxx_spi->get_tx = cs->get_tx;
18
19 fsl_spi_change_mode(spi);
20
21 if (pdata->cs_control)
22 pdata->cs_control(spi, pol);
23 }
24 }
25
26 static void fsl_spi_cs_control(struct spi_device *spi, bool on)
27 {
28 struct device *dev = spi->dev.parent;
29 struct mpc8xxx_spi_probe_info *pinfo =
to_of_pinfo(dev->platform_data);
30 u16 cs = spi->chip_select;
31 int gpio = pinfo->gpios[cs];
32 bool alow = pinfo->alow_flags[cs];
33
34 gpio_set_value(gpio, on ^ alow);
35 }
The variable "pol" comes from spi->mode & SPI_CS_HIGH (line 5) and
spi->mode gets it's value based on the spi-cs-high attribute in the device
tree via .../drivers/of/of_spi.c like this:
if (of_find_property(nc, "spi-cs-high", NULL))
spi->mode |= SPI_CS_HIGH;
In my case I want an active low CS so I don't include this attribute and
spi->mode doesn't get the bit set. "alow" (line 32) ultimately comes from
the flags part of the gpios specifier in the SPI node of my device tree
via the of_fsl_spi_probe function like this:
gpio = of_get_gpio_flags(np, i, &flags); <- flags gets a direct copy of
flags in the gpios specifier
pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
OF_GPIO_ACTIVE_LOW is an enum with a value of 0x1, implying that a value
of "1" in the flags in my gpios specifier is saying the GPIO signal is
active low. So if my understanding is right, I've got everything set up
in my device tree correctly to have an active low CS.
Now to the crux of the problem, line 34, the gpio_set_value call. When an
SPI transaction is started and the CS needs to be driven to it's active
state (low in my case) fsl_spi_chipselect is called with value =
BITBANG_CS_ACTIVE, which leads to line 22, calling fsl_spi_cs_control with
pol = 0 because spi->mode doesn't have the SPI_CS_HIGH bit set (line 5)
which becomes "on" in fsl_spi_cs_control. alow = 1(line 32) because flags
is 1 in the gpios specifier. "on" = 0 XORed with "alow" = 1 equals 1 when
gpio_set_value is called, setting my chipselect HIGH not low. Then when
the transaction is done fsl_spi_chipselect is called with value =
BITBANG_CS_INACTIVE which leads to line 10 calling fsl_spi_cs_control with
!pol = 1, alow is still a 1 and 1 XOR 1 = 0 when gpio_set_value is called,
setting my chipselect to LOW.
I did an experiment in which I added the spi-cs-high attribute to my
device tree (which should have made the signal active high) and the result
was the signal operated in the opposite way from what the name of the
attribute implies.
So (if my understanding of the device tree entries is correct) the logic
on line 34 appears to be flawed, but since I'm not 100% sure of my
understanding I wanted to ask people smarter than I am.
More over, I don't think I understand why a device tree entry is used to
indicate which state to change the chipselect to. Wouldn't it make more
sense if lines 10 and 22 pass in a "1" for "set the CS to the active
state" and a "0" for "set the CS to the inactive state"? You could even
use the already existing BITBANG_* macros. Something like this:
1 static void fsl_spi_chipselect(struct spi_device *spi, int value)
2 {
3 struct mpc8xxx_spi *mpc8xxx_spi =
spi_master_get_devdata(spi->master);
4 struct fsl_spi_platform_data *pdata =
spi->dev.parent->platform_data;
5 bool pol = spi->mode & SPI_CS_HIGH;
6 struct spi_mpc8xxx_cs *cs = spi->controller_state;
7
8 if (value == BITBANG_CS_INACTIVE) {
9 if (pdata->cs_control)
10 pdata->cs_control(spi, BITBANG_CS_INACTIVE); <--
change
11 }
12
13 if (value == BITBANG_CS_ACTIVE) {
14 mpc8xxx_spi->rx_shift = cs->rx_shift;
15 mpc8xxx_spi->tx_shift = cs->tx_shift;
16 mpc8xxx_spi->get_rx = cs->get_rx;
17 mpc8xxx_spi->get_tx = cs->get_tx;
18
19 fsl_spi_change_mode(spi);
20
21 if (pdata->cs_control)
22 pdata->cs_control(spi, BITBANG_CS_ACTIVE);
<--change
23 }
24 }
25
26 static void fsl_spi_cs_control(struct spi_device *spi, bool on)
27 {
28 struct device *dev = spi->dev.parent;
29 struct mpc8xxx_spi_probe_info *pinfo =
to_of_pinfo(dev->platform_data);
30 u16 cs = spi->chip_select;
31 int gpio = pinfo->gpios[cs];
32 bool alow = pinfo->alow_flags[cs];
33
34 gpio_set_value(gpio, on ^ alow);
35 }
Comments? Am I totally screwed up in my understanding?
Thanks.
Bruce
^ permalink raw reply
* [PATCH] ALSA: aoa: Convert onyx and tas codec drivers to module_i2c_driver
From: Axel Lin @ 2012-01-27 7:23 UTC (permalink / raw)
To: alsa-devel; +Cc: Takashi Iwai, Johannes Berg, linuxppc-dev, Jaroslav Kysela
This patch converts onyx and tas codec drivers to use the module_i2c_driver()
macro which makes the code smaller and a bit simpler.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
sound/aoa/codecs/onyx.c | 13 +------------
sound/aoa/codecs/tas.c | 13 +------------
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/sound/aoa/codecs/onyx.c b/sound/aoa/codecs/onyx.c
index 762af68..270790d 100644
--- a/sound/aoa/codecs/onyx.c
+++ b/sound/aoa/codecs/onyx.c
@@ -1132,15 +1132,4 @@ static struct i2c_driver onyx_driver = {
.id_table = onyx_i2c_id,
};
-static int __init onyx_init(void)
-{
- return i2c_add_driver(&onyx_driver);
-}
-
-static void __exit onyx_exit(void)
-{
- i2c_del_driver(&onyx_driver);
-}
-
-module_init(onyx_init);
-module_exit(onyx_exit);
+module_i2c_driver(onyx_driver);
diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
index fd2188c..8e63d1f 100644
--- a/sound/aoa/codecs/tas.c
+++ b/sound/aoa/codecs/tas.c
@@ -1026,15 +1026,4 @@ static struct i2c_driver tas_driver = {
.id_table = tas_i2c_id,
};
-static int __init tas_init(void)
-{
- return i2c_add_driver(&tas_driver);
-}
-
-static void __exit tas_exit(void)
-{
- i2c_del_driver(&tas_driver);
-}
-
-module_init(tas_init);
-module_exit(tas_exit);
+module_i2c_driver(tas_driver);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] mtd/nand:Fix wrong usage of is_blank() in fsl_ifc_run_command
From: Artem Bityutskiy @ 2012-01-27 13:15 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: Scott Wood, linux-mtd, linuxppc-dev, Poonam Aggrwal
In-Reply-To: <1326859991-7469-1-git-send-email-prabhakar@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On Wed, 2012-01-18 at 09:43 +0530, Prabhakar Kushwaha wrote:
> Freescale IFC NAND Machine calculates ECC on 512byte sector and same is used in
> fsl_ifc_run_command() during ECC status verification. Also this sector is passed
> to is_blank() for blank checking. It is wrong at first place because
> is_blank()'s implementation checks for Page size and OOB area size.
> is_blank() should be called per page for main and OOB area verification.
>
> Variables name are redefined to avoid confusion between buffer and ecc sector.
>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
The driver is not in 3.3-rc1, so I skip this patch.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH] mtd/nand:Fix wrong usage of is_blank() in fsl_ifc_run_command
From: Kushwaha Prabhakar-B32579 @ 2012-01-27 14:20 UTC (permalink / raw)
To: dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org, Aggrwal Poonam-B10812,
linuxppc-dev@lists.ozlabs.org, Wood Scott-B07421
In-Reply-To: <1327670133.26648.40.camel@sauron.fi.intel.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQXJ0ZW0gQml0eXV0c2tp
eSBbbWFpbHRvOmRlZGVraW5kMUBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAy
NywgMjAxMiA2OjQ2IFBNDQo+IFRvOiBLdXNod2FoYSBQcmFiaGFrYXItQjMyNTc5DQo+IENjOiBs
aW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgtbXRkQGxpc3RzLmluZnJhZGVhZC5v
cmc7IFdvb2QNCj4gU2NvdHQtQjA3NDIxOyBBZ2dyd2FsIFBvb25hbS1CMTA4MTINCj4gU3ViamVj
dDogUmU6IFtQQVRDSF0gbXRkL25hbmQ6Rml4IHdyb25nIHVzYWdlIG9mIGlzX2JsYW5rKCkgaW4N
Cj4gZnNsX2lmY19ydW5fY29tbWFuZA0KPiANCj4gT24gV2VkLCAyMDEyLTAxLTE4IGF0IDA5OjQz
ICswNTMwLCBQcmFiaGFrYXIgS3VzaHdhaGEgd3JvdGU6DQo+ID4gRnJlZXNjYWxlIElGQyBOQU5E
IE1hY2hpbmUgY2FsY3VsYXRlcyBFQ0Mgb24gNTEyYnl0ZSBzZWN0b3IgYW5kIHNhbWUNCj4gPiBp
cyB1c2VkIGluDQo+ID4gZnNsX2lmY19ydW5fY29tbWFuZCgpIGR1cmluZyBFQ0Mgc3RhdHVzIHZl
cmlmaWNhdGlvbi4gQWxzbyB0aGlzIHNlY3Rvcg0KPiA+IGlzIHBhc3NlZCB0byBpc19ibGFuaygp
IGZvciBibGFuayBjaGVja2luZy4gSXQgaXMgd3JvbmcgYXQgZmlyc3QgcGxhY2UNCj4gPiBiZWNh
dXNlIGlzX2JsYW5rKCkncyBpbXBsZW1lbnRhdGlvbiBjaGVja3MgZm9yIFBhZ2Ugc2l6ZSBhbmQg
T09CIGFyZWENCj4gc2l6ZS4NCj4gPiBpc19ibGFuaygpIHNob3VsZCBiZSBjYWxsZWQgcGVyIHBh
Z2UgZm9yIG1haW4gYW5kIE9PQiBhcmVhDQo+IHZlcmlmaWNhdGlvbi4NCj4gPg0KPiA+IFZhcmlh
YmxlcyBuYW1lIGFyZSByZWRlZmluZWQgdG8gYXZvaWQgY29uZnVzaW9uIGJldHdlZW4gYnVmZmVy
IGFuZCBlY2MNCj4gc2VjdG9yLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogUG9vbmFtIEFnZ3J3
YWwgPHBvb25hbS5hZ2dyd2FsQGZyZWVzY2FsZS5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogU2Nv
dHQgV29vZCA8c2NvdHR3b29kQGZyZWVzY2FsZS5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogUHJh
Ymhha2FyIEt1c2h3YWhhIDxwcmFiaGFrYXJAZnJlZXNjYWxlLmNvbT4NCj4gDQo+IFRoZSBkcml2
ZXIgaXMgbm90IGluIDMuMy1yYzEsIHNvIEkgc2tpcCB0aGlzIHBhdGNoLg0KPiANCg0KDQpUaGlz
IHBhdGNoIGlzIHNxdWFzaGVkIGluIExpbnV4IE5BTkQgZHJpdmVyIHBhdGNoLiBJdCB3aWxsIGJl
IHByb3ZpZGVkIGJ5IGdhbGFrJ3MgdHJlZQ0KDQoiTkFORCBNYWNoaW5lIHN1cHBvcnQgZm9yIElu
dGVncmF0ZWQgRmxhc2ggQ29udHJvbGxlciINCmh0dHA6Ly9wYXRjaHdvcmsub3psYWJzLm9yZy9w
YXRjaC8xMzcwMjQvDQoNCi0tUHJhYmhha2FyDQoNCg==
^ permalink raw reply
* [PATCH] powerpc: use string library
From: Akinobu Mita @ 2012-01-27 14:24 UTC (permalink / raw)
To: linux-kernel, akpm; +Cc: linuxppc-dev, Akinobu Mita
- Use memchr_inv to check if the data contains all 0xFF bytes.
It is faster than looping for each byte.
- Use memcmp to compare memory areas
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/powermac/nvram.c | 42 ++++++++++++++-----------------
1 files changed, 19 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/nvram.c b/arch/powerpc/platforms/powermac/nvram.c
index 54d2271..da18b26 100644
--- a/arch/powerpc/platforms/powermac/nvram.c
+++ b/arch/powerpc/platforms/powermac/nvram.c
@@ -279,7 +279,7 @@ static u32 core99_check(u8* datas)
static int sm_erase_bank(int bank)
{
- int stat, i;
+ int stat;
unsigned long timeout;
u8 __iomem *base = (u8 __iomem *)nvram_data + core99_bank*NVRAM_SIZE;
@@ -301,11 +301,10 @@ static int sm_erase_bank(int bank)
out_8(base, SM_FLASH_CMD_CLEAR_STATUS);
out_8(base, SM_FLASH_CMD_RESET);
- for (i=0; i<NVRAM_SIZE; i++)
- if (base[i] != 0xff) {
- printk(KERN_ERR "nvram: Sharp/Micron flash erase failed !\n");
- return -ENXIO;
- }
+ if (memchr_inv(base, 0xff, NVRAM_SIZE)) {
+ printk(KERN_ERR "nvram: Sharp/Micron flash erase failed !\n");
+ return -ENXIO;
+ }
return 0;
}
@@ -336,17 +335,16 @@ static int sm_write_bank(int bank, u8* datas)
}
out_8(base, SM_FLASH_CMD_CLEAR_STATUS);
out_8(base, SM_FLASH_CMD_RESET);
- for (i=0; i<NVRAM_SIZE; i++)
- if (base[i] != datas[i]) {
- printk(KERN_ERR "nvram: Sharp/Micron flash write failed !\n");
- return -ENXIO;
- }
+ if (memcmp(base, datas, NVRAM_SIZE)) {
+ printk(KERN_ERR "nvram: Sharp/Micron flash write failed !\n");
+ return -ENXIO;
+ }
return 0;
}
static int amd_erase_bank(int bank)
{
- int i, stat = 0;
+ int stat = 0;
unsigned long timeout;
u8 __iomem *base = (u8 __iomem *)nvram_data + core99_bank*NVRAM_SIZE;
@@ -382,12 +380,11 @@ static int amd_erase_bank(int bank)
/* Reset */
out_8(base, 0xf0);
udelay(1);
-
- for (i=0; i<NVRAM_SIZE; i++)
- if (base[i] != 0xff) {
- printk(KERN_ERR "nvram: AMD flash erase failed !\n");
- return -ENXIO;
- }
+
+ if (memchr_inv(base, 0xff, NVRAM_SIZE)) {
+ printk(KERN_ERR "nvram: AMD flash erase failed !\n");
+ return -ENXIO;
+ }
return 0;
}
@@ -429,11 +426,10 @@ static int amd_write_bank(int bank, u8* datas)
out_8(base, 0xf0);
udelay(1);
- for (i=0; i<NVRAM_SIZE; i++)
- if (base[i] != datas[i]) {
- printk(KERN_ERR "nvram: AMD flash write failed !\n");
- return -ENXIO;
- }
+ if (memcmp(base, datas, NVRAM_SIZE)) {
+ printk(KERN_ERR "nvram: AMD flash write failed !\n");
+ return -ENXIO;
+ }
return 0;
}
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 1/1] carma-fpga: fix race between data dumping and DMA callback
From: Ira W. Snyder @ 2012-01-27 16:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1327613137.24487.0.camel@pasglop>
On Fri, Jan 27, 2012 at 08:25:37AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-01-26 at 13:00 -0800, Ira W. Snyder wrote:
> >
> > @@ -970,7 +984,13 @@ static ssize_t data_en_show(struct device *dev, struct device_attribute *attr,
> > char *buf)
> > {
> > struct fpga_device *priv = dev_get_drvdata(dev);
> > - return snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
> > + int ret;
> > +
> > + spin_lock_irq(&priv->lock);
> > + ret = snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
> > + spin_unlock_irq(&priv->lock);
> > +
> > + return ret;
> > }
>
> I don't think the lock buys you anything here.
>
You're right. Feel free to drop the hunk.
Ira
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: Question about GPIO Lib
From: Bill Gatliff @ 2012-01-27 18:42 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-dev
In-Reply-To: <OF2BD13139.450D178D-ON88257992.0018BB93-88257992.0018CFCA@selinc.com>
Bruce:
On Fri, Jan 27, 2012 at 5:31 AM, <Bruce_Leonard@selinc.com> wrote:
>
> The problem is we've got a number of other things hooked up to the GPIO
> pins that it would be very bad if someone from user space played with
> them, like our FPGA configuration pin. =A0Some one toggles that and our b=
ox
> goes stupid. =A0So what I'm wondering is if there's a way, preferably via
> the device tree, to limit the GPIOs that GPIO Lib exposes to user space?
Sounds like you DON'T want to merely export that GPIO pin to userspace.
If you have anything in kernel space doing a gpio_request() on that
pin, it won't be exportable to userspace anyway. Regardless, you are
probably better off implement a DEVICE_ATTR that, in its store()
method, treads lightly on said pin. And then do a gpio_request() in
kernel space so that users can't ever see the pin directly.
Just my $0.02.
b.g.
--=20
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* MPC5200B FEC TX packets getting stuck
From: Joey Nelson @ 2012-01-27 20:14 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]
In my application, I have a PC connected through TCP to a MPC5200B based
system. The PC sends a short request, the MPC5200B receives the request
and sends the data back. It is doing this about 300 times per second.
Normally exchange happens in just handful of milliseconds. But randomly
every 2 to 15 minutes the MPC5200B sends all but the last packet of the
response, and about 200ms later the PC sends a delayed ACK, and the
MPC5200B TCP stack figures the packet was lost. It then sends two nearly
identical packets (The IP header Identification and Checksum fields are
incremented). I can also see that RetransSegs in /proc/net/snmp increments
by one for each of these delays.
My theory is that the packet is getting suck somewhere in the network stack
(most likely toward the bottom). Then when another packet is sent, the
suck one gets pushed out.
I've done a test where I have another task on the MPC5200B sending UDP
packets to a different PC every 10ms. This eliminated the long delays, and
seems to support my stuck packet theory.
I'm seeing the same issue with 2.6.23 and 3.1.6.
I'm getting ready to dive into the hairy world of Bestcomm and FEC, but I
figured I'd see if anyone else has any suggestions before I make my decent.
Has anyone seen this behavior before? Any likely candidates for where the
packet is getting stuck? General advice for reference materials (I've
started on Linux Device Drivers 3rd Ed, BestComm AN2604, and the Datasheets)
Thanks in advance.
Joey Nelson
joey@joescan.com
[-- Attachment #2: Type: text/html, Size: 1770 bytes --]
^ permalink raw reply
* [PATCH v3 00/25] irq_domain generalization and refinement
From: Grant Likely @ 2012-01-27 21:35 UTC (permalink / raw)
To: linux-kernel, Benjamin Herrenschmidt, Thomas Gleixner,
Milton Miller, Rob Herring, Stephen Rothwell
Cc: devicetree-discuss, linuxppc-dev, linux-arm-kernel
Hey everyone,
This patch series is ready for much wider consumption now. I'd like
to get it into linux-next ASAP because there will be ARM board support
depending on it. I'll wait a few days before I ask Stephen to pull
this in.
Stephen/Milton/Ben, any testing you can help with here would be
appreciated since you've got access to a wider variety of Power
machines than I do.
Thomas, I think it makes sense to maintain this in a separate branch
from other irq changes until the next merge window. If you prefer,
I'm happy to maintain this branch until then.
Cheers,
g.
The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
Linux 3.3-rc1 (2012-01-19 15:04:48 -0800)
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 irqdomain/next
Grant Likely (24):
irq_domain: add documentation and MAINTAINERS entry.
dt: Make irqdomain less verbose
irq_domain: Make irq_domain structure match powerpc's irq_host
irq_domain: convert microblaze from irq_host to irq_domain
irq_domain/powerpc: Use common irq_domain structure instead of irq_host
irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead
irq_domain/powerpc: Eliminate virq_is_host()
irq_domain: Move irq_domain code from powerpc to kernel/irq
irqdomain: remove NO_IRQ from irq domain code
irq_domain: Remove references to old irq_host names
irq_domain: Replace irq_alloc_host() with revmap-specific initializers
irq_domain: Add support for base irq and hwirq in legacy mappings
irq_domain: Remove 'new' irq_domain in favour of the ppc one
irq_domain: Remove irq_domain_add_simple()
irq_domain: Create common xlate functions that device drivers can use
irq_domain: constify irq_domain_ops
irq_domain/c6x: constify irq_domain structures
irq_domain/c6x: Use library of xlate functions
irq_domain/powerpc: constify irq_domain_ops
irqdomain/powerpc: Replace custom xlate functions with library functions
irq_domain/x86: Convert x86 (embedded) to use common irq_domain
irq_domain: Include hwirq number in /proc/interrupts
irq_domain: remove "hint" when allocating irq numbers
irq_domain: mostly eliminate slow-path revmap lookups
Mark Salter (1):
irq_domain/c6x: Convert c6x to use generic irq_domain support.
Documentation/IRQ-domain.txt | 113 +++
MAINTAINERS | 9 +
arch/arm/common/gic.c | 95 ++--
arch/arm/common/vic.c | 16 +-
arch/arm/include/asm/hardware/gic.h | 4 +-
arch/arm/include/asm/hardware/vic.h | 2 +
arch/arm/mach-exynos/common.c | 2 +-
arch/arm/mach-imx/mach-imx6q.c | 3 +-
arch/arm/mach-msm/board-msm8x60.c | 8 +-
arch/arm/mach-mx5/imx51-dt.c | 4 +-
arch/arm/mach-mx5/imx53-dt.c | 4 +-
arch/arm/mach-omap2/board-generic.c | 2 +-
arch/arm/mach-prima2/irq.c | 2 +-
arch/arm/mach-versatile/core.c | 5 +-
arch/c6x/Kconfig | 1 +
arch/c6x/include/asm/irq.h | 245 +-------
arch/c6x/kernel/irq.c | 612 +----------------
arch/c6x/platforms/megamod-pic.c | 25 +-
arch/microblaze/include/asm/irq.h | 4 +-
arch/microblaze/kernel/irq.c | 2 +-
arch/microblaze/kernel/setup.c | 2 -
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/ehv_pic.h | 2 +-
arch/powerpc/include/asm/i8259.h | 2 +-
arch/powerpc/include/asm/irq.h | 247 +-------
arch/powerpc/include/asm/mpic.h | 2 +-
arch/powerpc/include/asm/xics.h | 2 +-
arch/powerpc/kernel/irq.c | 617 +----------------
arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 12 +-
arch/powerpc/platforms/52xx/media5200.c | 15 +-
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 16 +-
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 12 +-
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 14 +-
arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 15 +-
arch/powerpc/platforms/86xx/gef_pic.c | 15 +-
arch/powerpc/platforms/cell/axon_msi.c | 29 +-
arch/powerpc/platforms/cell/beat_interrupt.c | 16 +-
arch/powerpc/platforms/cell/interrupt.c | 16 +-
arch/powerpc/platforms/cell/spider-pic.c | 14 +-
arch/powerpc/platforms/embedded6xx/flipper-pic.c | 30 +-
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 35 +-
arch/powerpc/platforms/iseries/irq.c | 11 +-
arch/powerpc/platforms/powermac/pic.c | 26 +-
arch/powerpc/platforms/powermac/smp.c | 9 +-
arch/powerpc/platforms/ps3/interrupt.c | 11 +-
arch/powerpc/platforms/wsp/opb_pic.c | 26 +-
arch/powerpc/sysdev/cpm1.c | 9 +-
arch/powerpc/sysdev/cpm2_pic.c | 23 +-
arch/powerpc/sysdev/ehv_pic.c | 14 +-
arch/powerpc/sysdev/fsl_msi.c | 10 +-
arch/powerpc/sysdev/fsl_msi.h | 2 +-
arch/powerpc/sysdev/i8259.c | 15 +-
arch/powerpc/sysdev/ipic.c | 31 +-
arch/powerpc/sysdev/ipic.h | 2 +-
arch/powerpc/sysdev/mpc8xx_pic.c | 11 +-
arch/powerpc/sysdev/mpic.c | 17 +-
arch/powerpc/sysdev/mpic_msi.c | 2 +-
arch/powerpc/sysdev/mv64x60_pic.c | 11 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 26 +-
arch/powerpc/sysdev/qe_lib/qe_ic.h | 2 +-
arch/powerpc/sysdev/tsi108_pci.c | 22 +-
arch/powerpc/sysdev/uic.c | 26 +-
arch/powerpc/sysdev/xics/xics-common.c | 28 +-
arch/powerpc/sysdev/xilinx_intc.c | 19 +-
arch/x86/Kconfig | 2 +
arch/x86/include/asm/irq_controller.h | 12 -
arch/x86/include/asm/prom.h | 10 -
arch/x86/kernel/devicetree.c | 101 +--
drivers/gpio/gpio-mpc8xxx.c | 30 +-
drivers/mfd/twl-core.c | 12 +-
drivers/net/phy/mdio-gpio.c | 4 +-
include/linux/irqdomain.h | 190 ++++--
kernel/irq/irqdomain.c | 816 +++++++++++++++++++---
kernel/irq/proc.c | 3 +
74 files changed, 1334 insertions(+), 2471 deletions(-)
create mode 100644 Documentation/IRQ-domain.txt
delete mode 100644 arch/x86/include/asm/irq_controller.h
^ permalink raw reply
* [PATCH v3 01/25] irq_domain: add documentation and MAINTAINERS entry.
From: Grant Likely @ 2012-01-27 21:35 UTC (permalink / raw)
To: linux-kernel, Benjamin Herrenschmidt, Thomas Gleixner,
Milton Miller, Rob Herring, Stephen Rothwell
Cc: devicetree-discuss, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1327700179-17454-1-git-send-email-grant.likely@secretlab.ca>
Documentation for irq_domain library which will be created in subsequent
patches.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Milton Miller <miltonm@bga.com>
---
Documentation/IRQ-domain.txt | 113 ++++++++++++++++++++++++++++++++++++++++++
MAINTAINERS | 9 +++
2 files changed, 122 insertions(+), 0 deletions(-)
create mode 100644 Documentation/IRQ-domain.txt
diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
new file mode 100644
index 0000000..247f32a
--- /dev/null
+++ b/Documentation/IRQ-domain.txt
@@ -0,0 +1,113 @@
+irq_domain interrupt number mapping library
+
+The current design of the Linux kernel uses a single large number
+space where each separate IRQ source is assigned a different number.
+This is simple when there is only one interrupt controller, but in
+systems with controllers the kernel must ensure that each one does not
+get assigned overlapping allocations of Linux irq numbers.
+
+The irq_alloc_desc*() and irq_free_desc*() API provides allocation of
+irq numbers, but it doesn't provide any support for reverse mapping of
+the controller-local irq (hwirq) number into the Linux irq number
+space.
+
+The irq_domain library adds mapping between hwirq and irq numbers on
+top of the irq_alloc_desc*() API. An irq_domain to manage mapping is
+preferred over interrupt controller drivers open coding their own
+reverse mapping scheme.
+
+irq_domain also implements translation from Device Tree interrupt
+specifiers to hwirq numbers, and can be easily extended to support
+other irq topology data sources.
+
+=== irq_domain usage ===
+An interrupt controller driver creates and registers an irq_domain by
+calling one of the irq_domain_add_*() functions (each mapping method
+has a different allocator function, more on that later). The function
+will return a pointer to the irq_domain on success. It must provide
+the allocator function with an irq_domain_ops structure with the .map
+callback populated as a minimum.
+
+In most cases, the irq_domain will begin empty without any mappings
+between hwirq and irq numbers. Mappings are added to the irq_domain
+by calling irq_create_mapping() which accepts the irq_domain and a
+hwirq number as arguments. If a mapping for the hwirq doesn't already
+exist then it will allocate a new linux irq_desc, associate it with
+the hwirq, and call the .map() callback so the driver can perform any
+required hardware setup.
+
+When an interrupt is received, irq_find_mapping() function should
+be used to find the Linux irq number from the hwirq number.
+
+If the driver has the Linux irq number or the irq_data pointer, and
+needs to know the associated hwirq number (such as in the irq_chip
+callbacks) then it can be directly obtained from irq_data->hwirq.
+
+=== Types of irq_domain mappings ===
+There are several mechanisms available for reverse mapping from hwirq
+to Linux irq, and each mechanism uses a different allocation function.
+Which reverse map type should be used depends on the use case. Each
+of the reverse map types are described below:
+
+==== Linear ====
+irq_domain_add_linear()
+
+The linear reverse map maintains a fixed size table indexed by the
+hwirq number. When a hwirq is mapped, an irq_desc is allocated for
+the hwirq, and the irq number is stored in the table.
+
+The Linear map is a good choice when the maximum number of hwirqs is
+fixed and a relatively small number (~ < 256). The advantages of this
+map are fixed time lookup for irq numbers, and irq_descs are only
+allocated for in-use irqs. The disadvantage is that the table must be
+as large as the largest possible hwirq number.
+
+The majority of drivers should use the linear map.
+
+==== Tree ====
+irq_domain_add_tree()
+
+The irq_domain maintains a radix tree map from hwirq numbers to linux
+irqs. When an hwirq is mapped, and irq_desc is allocated and the
+hwirq is used as the lookup key for the radix tree.
+
+The tree map is a good choice if the hwirq number can be very large
+since it doesn't need to allocate a table as large as the largest
+hwirq number. The disadvantage is that hwirq to irq number lookup is
+dependent on how many entries are in the table.
+
+Very few drivers should need this mapping. At the moment, powerpc
+iseries is the only user.
+
+==== No Map ===-
+irq_domain_add_nomap()
+
+The No Map mapping is to be used when the hwirq number is
+programmable in the hardware. In this case it is best to program the
+Linux irq number into the hardware itself so that no mapping is
+required. Calling irq_create_direct_mapping() will allocate a linux
+irq number and call the .map() callback so that driver can program the
+Linux irq number into the hardware.
+
+Most drivers cannot use this mapping.
+
+==== Legacy ====
+irq_domain_add_legacy()
+irq_domain_add_legacy_isa()
+
+The Legacy mapping is a special case for drivers that already have a
+range of irq_descs allocated for the hwirqs. It is used when the
+driver cannot be immediately converted to use the linear mapping, such
+as when the driver is used in a system with fixed irq number
+assignments, as is typical in many embedded system board files.
+
+The legacy map assumes a contiguous range of irq numbers has already
+been allocated for the controller and that the irq number can be
+calculated by adding a fixed offset to the hwirq number, and
+visa-versa. The disadvantage is that it requires the interrupt
+controller to manage irq allocations and it requires an irq_desc to be
+allocated for every hwirq, even if it is unused.
+
+Drivers should only use the legacy map if they have fixed irq mappings
+(#define IRQ_* in embedded board files). For example, ISA controllers
+mapped to Linux irqs 0-15 would use the legacy map.
diff --git a/MAINTAINERS b/MAINTAINERS
index 89b70df..d308f0f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3626,6 +3626,15 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
F: kernel/irq/
+IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
+M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+M: Grant Likely <grant.likely@secretlab.ca>
+T: git git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
+S: Maintained
+F: Documentation/IRQ-domain.txt
+F: include/linux/irqdomain.h
+F: kernel/irq/irqdomain.c
+
ISAPNP
M: Jaroslav Kysela <perex@perex.cz>
S: Maintained
--
1.7.5.4
^ permalink raw reply related
* [PATCH v3 02/25] dt: Make irqdomain less verbose
From: Grant Likely @ 2012-01-27 21:35 UTC (permalink / raw)
To: linux-kernel, Benjamin Herrenschmidt, Thomas Gleixner,
Milton Miller, Rob Herring, Stephen Rothwell
Cc: devicetree-discuss, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1327700179-17454-1-git-send-email-grant.likely@secretlab.ca>
It printk's too much. Drop some output.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
kernel/irq/irqdomain.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 1f9e265..cc2cd43 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -170,13 +170,11 @@ void irq_domain_generate_simple(const struct of_device_id *match,
u64 phys_base, unsigned int irq_start)
{
struct device_node *node;
- pr_info("looking for phys_base=%llx, irq_start=%i\n",
+ pr_debug("looking for phys_base=%llx, irq_start=%i\n",
(unsigned long long) phys_base, (int) irq_start);
node = of_find_matching_node_by_address(NULL, match, phys_base);
if (node)
irq_domain_add_simple(node, irq_start);
- else
- pr_info("no node found\n");
}
EXPORT_SYMBOL_GPL(irq_domain_generate_simple);
#endif /* CONFIG_OF_IRQ */
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox