On Wed, Sep 27, 2023 at 9:03 AM Bjorn Helgaas wrote:
>
> On Fri, Sep 22, 2023 at 10:46:36AM +0800, Shuai Xue wrote:
> > ...
>
> > Actually, this is a question from my colleague from firmware team.
> > The original question is that:
> >
> > "Should I set CPER_SEV_FATAL for Generic Error Status
On 2023/9/27 07:02, Bjorn Helgaas wrote:
> On Fri, Sep 22, 2023 at 10:46:36AM +0800, Shuai Xue wrote:
>> ...
>
>> Actually, this is a question from my colleague from firmware team.
>> The original question is that:
>>
>> "Should I set CPER_SEV_FATAL for Generic Error Status Block when a
>>
On Fri, Sep 22, 2023 at 10:46:36AM +0800, Shuai Xue wrote:
> ...
> Actually, this is a question from my colleague from firmware team.
> The original question is that:
>
> "Should I set CPER_SEV_FATAL for Generic Error Status Block when a
> PCIe fatal error is detected? If set, kernel will
From: Shuai Xue
> Sent: 25 September 2023 02:44
>
> On 2023/9/21 21:20, David Laight wrote:
> > ...
> > I've got a target to generate AER errors by generating read cycles
> > that are inside the address range that the bridge forwards but
> > outside of any BAR because there are 2 different sized B
On Fri, Sep 22, 2023 at 8:23 AM David Laight wrote:
>
> > It would be nice if they worked the same, but I suspect that vendors
> > may rely on the fact that CPER_SEV_FATAL forces a restart/panic as
> > part of their system integrity story.
>
> The file system errors created by a panic (especially
On 2023/9/21 21:20, David Laight wrote:
> ...
> I've got a target to generate AER errors by generating read cycles
> that are inside the address range that the bridge forwards but
> outside of any BAR because there are 2 different sized BARs.
> (Pretty easy to setup.)
> On the system I was using
+ @Rafael for the APEI/GHES part.
On 2023/9/22 05:52, Bjorn Helgaas wrote:
> On Thu, Sep 21, 2023 at 08:10:19PM +0800, Shuai Xue wrote:
>> On 2023/9/21 07:02, Bjorn Helgaas wrote:
>>> On Mon, Sep 18, 2023 at 05:39:58PM +0800, Shuai Xue wrote:
>> ...
>
>>> I guess your point is that for CPER_SEV_F
> It would be nice if they worked the same, but I suspect that vendors
> may rely on the fact that CPER_SEV_FATAL forces a restart/panic as
> part of their system integrity story.
The file system errors created by a panic (especially an NMI panic)
could easily be more problematic than a failed PCI
On Thu, Sep 21, 2023 at 08:10:19PM +0800, Shuai Xue wrote:
> On 2023/9/21 07:02, Bjorn Helgaas wrote:
> > On Mon, Sep 18, 2023 at 05:39:58PM +0800, Shuai Xue wrote:
> ...
> > I guess your point is that for CPER_SEV_FATAL errors, the APEI/GHES
> > path always panics but the native path never does,
...
I've got a target to generate AER errors by generating read cycles
that are inside the address range that the bridge forwards but
outside of any BAR because there are 2 different sized BARs.
(Pretty easy to setup.)
On the system I was using they didn't get propagated all the way
to the root bri
s ago.
>> I am very curious about the expected behavior of the software.
>> I first recap the error classification and then list my questions bellow it.
>>
>> ## Recap: Error classification
>>
>> - Fatal Errors
>>
>> Fatal errors are uncorrectabl
e software.
> I first recap the error classification and then list my questions bellow it.
>
> ## Recap: Error classification
>
> - Fatal Errors
>
> Fatal errors are uncorrectable error conditions which render the particular
> Link and related hardware unreliable. For Fatal
Hi, all folks,
Error reporting and recovery are one of the important features of PCIe, and
the kernel has been supporting them since version 2.6, 17 years ago.
I am very curious about the expected behavior of the software.
I first recap the error classification and then list my questions bellow
On Thu, 24 Nov 2022 17:14:27 +0530
"Naveen N. Rao" wrote:
> Jinyang He wrote:
> > 在 2022/11/17 21:09, Masami Hiramatsu (Google) 写道:
> >
> >> On Thu, 17 Nov 2022 09:07:37 +0800
> >> Tiezhu Yang wrote:
> >>
> >>> Hi KPROBES maintainers,
> >>>
> >>> There are some differences of kprobe handler imp
Jinyang He wrote:
在 2022/11/17 21:09, Masami Hiramatsu (Google) 写道:
On Thu, 17 Nov 2022 09:07:37 +0800
Tiezhu Yang wrote:
Hi KPROBES maintainers,
There are some differences of kprobe handler implementations on various
archs, the implementations are almost same on arm64, riscv, csky, the
cod
On 09/04/2014 11:43 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-09-04 at 11:34 +0200, Daniel Vetter wrote:
>> On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote:
>>> Last time I tested, (and it seems like Michel is on the same track),
>>> writing with the CPU to write-combined me
On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote:
> Last time I tested, (and it seems like Michel is on the same track),
> writing with the CPU to write-combined memory was substantially faster
> than writing to cached memory, with the additional side-effect that CPU
> caches are le
Hi!
Let me try to bring some clarity and suggestions into this.
On 09/04/2014 02:12 AM, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> I've been tracking down some problems with the recent DRI on powerpc and
> stumbled upon something that doesn't look right, and not necessarily
> only for us.
>
>
On 09/04/2014 10:06 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-09-04 at 09:44 +0200, Thomas Hellstrom wrote:
>
>>> This will, from what I can tell, try to use the same caching mode as the
>>> original object:
>>>
>>> if ((cur_placement & caching) != 0)
>>> result |= (cur_place
On Thu, 2014-09-04 at 11:34 +0200, Daniel Vetter wrote:
> On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote:
> > Last time I tested, (and it seems like Michel is on the same track),
> > writing with the CPU to write-combined memory was substantially faster
> > than writing to cached
On Thu, 2014-09-04 at 16:59 +0900, Michel Dänzer wrote:
>
> Define 'not reliably'. I have uptimes of weeks, and I'm pretty sure I'm
> not alone, at least with AGP 1x it seems to work quite well for most
> people. So I don't see the justification for intentionally breaking it
> completely for al
On Thu, 2014-09-04 at 09:44 +0200, Thomas Hellstrom wrote:
> > This will, from what I can tell, try to use the same caching mode as the
> > original object:
> >
> > if ((cur_placement & caching) != 0)
> > result |= (cur_placement & caching);
> >
> > And cur_placement comes from bo-
On 04.09.2014 16:59, Michel Dänzer wrote:
On 04.09.2014 16:54, Benjamin Herrenschmidt wrote:
On Thu, 2014-09-04 at 16:19 +0900, Michel Dänzer wrote:
+#else /* CONFIG_X86 */
+int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
*placement)
+{
+ if (*placement & (TTM_PL_TT | TTM_PL
On 04.09.2014 16:54, Benjamin Herrenschmidt wrote:
On Thu, 2014-09-04 at 16:19 +0900, Michel Dänzer wrote:
+#else /* CONFIG_X86 */
+int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
*placement)
+{
+ if (*placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
+ ttm->caching
On Thu, 2014-09-04 at 16:19 +0900, Michel Dänzer wrote:
> > +#else /* CONFIG_X86 */
> > +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
> *placement)
> > +{
> > + if (*placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
> > + ttm->caching_state = tt_cached;
> > +
On 04.09.2014 10:55, Jerome Glisse wrote:
While i agree about the issue of incoherent double map of same page, i
think we have more issue. For instance lattely AMD have been pushing a
lot of patches to move things to use uncached memory for radeon and as
usual thoses patches comes with no commen
On 04.09.2014 11:36, Jerome Glisse wrote:
On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
So in the meantime the attached patch should work, it just s
On Wed, Sep 03, 2014 at 10:36:57PM -0400, Jerome Glisse wrote:
> On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> > On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > >
> > > > So in the meantime
On Wed, 2014-09-03 at 22:36 -0400, Jerome Glisse wrote:
> On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> > On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > >
> > > > So in the meantime the at
On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> >
> > > So in the meantime the attached patch should work, it just silently ignore
> > > the cachin
On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> >
> > > So in the meantime the attached patch should work, it just silently ignore
> > > the cachin
On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
>
> > So in the meantime the attached patch should work, it just silently ignore
> > the caching attribute request on non x86 instead of pretending that things
> > are
On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> So in the meantime the attached patch should work, it just silently ignore
> the caching attribute request on non x86 instead of pretending that things
> are setup as expected and then latter the radeon ou nouveau hw unsetting
> the snoop b
On Wed, 2014-09-03 at 21:55 -0400, Jerome Glisse wrote:
> So i think we need to get a platform flags and or set_pages_array_wc|uc
> needs to fail and this would fallback to cached mapping if the fallback
> code still works. So if your arch properly return and error for those
> cache changing functi
On Wed, Sep 03, 2014 at 09:55:53PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 10:12:27AM +1000, Benjamin Herrenschmidt wrote:
> > Hi folks !
> >
> > I've been tracking down some problems with the recent DRI on powerpc and
> > stumbled upon something that doesn't look right, and not nece
On Thu, Sep 04, 2014 at 10:12:27AM +1000, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> I've been tracking down some problems with the recent DRI on powerpc and
> stumbled upon something that doesn't look right, and not necessarily
> only for us.
>
> Now it's possible that I haven't fully unders
Hi folks !
I've been tracking down some problems with the recent DRI on powerpc and
stumbled upon something that doesn't look right, and not necessarily
only for us.
Now it's possible that I haven't fully understood the code here and I
also don't know to what extent some of that behaviour is nece
On Mon, 2014-05-26 at 15:20 -0700, shiva7 wrote:
> shiva7 wrote
> > Thanks again Scott.
> /
> >> Any idea whether the DBCR0 BRT bit actually works(??),
> >
> >> Do you have reason to believe that it might not?
> /
> >
> > I'm facing a strange problem which was not there on server processor. Let
eral, if I
> have an application running on server where tracing was based on BE bit
> and same can run on e500mc with DE & BRT combination?
>
>
> Thanks In Advance.
Could someone help on this regard?
--
View this message in context:
http://linuxppc.10917.n7.nabble.com/q
scussions so far I have surfed are related to branch
taken/fall through(not taken) semantics related. But, in general, if I have
an application running on server where tracing was based on BE bit and same
can run on e500mc with DE & BRT combination?
Thanks In Advance.
--
View this message in conte
unsubcribe linuxppc-dev
On Fri, Apr 12, 2013 at 4:51 AM, Chris Friesen
wrote:
> Hi all,
>
> Sorry for the bunch of emails, I'm working on some new stuff and running
> into issues.
>
> For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP but
> not DBCR0_BRT. Is that just becau
On Sun, 2014-05-18 at 16:38 -0700, shiva7 wrote:
> Thanks Scott.
>
> Apologize for not quoting the old email reference.
You did it again. :-)
> I assumed the old archive content always will be in the trail.
It's in the archives (as I noted), but it's a pain to search for it
versus having releva
dedicated DEBUG_DEBUG prolog and dedicated registers DSRR0 and
DSRR1.
I can see the debug handler already have HACK to simulate the branch taken
case and SIGTRAP to user space.
Thanks in Advance.
--
View this message in context:
http://linuxppc.10917.n7.nabble.com/questions-on-CONFIG-PPC-ADV-DEBUG-
On Tue, 2014-04-22 at 17:31 -0500, Scott Wood wrote:
> On Tue, 2014-04-22 at 05:43 -0700, shiva7 wrote:
> > I have the same question as like above posted by Mr. Chirs.
>
> I had to google the subject to find what e-mail you were talking about
> -- it was posted a year ago:
>
> http://marc.info/?
On Tue, 2014-04-22 at 05:43 -0700, shiva7 wrote:
> I have the same question as like above posted by Mr. Chirs.
I had to google the subject to find what e-mail you were talking about
-- it was posted a year ago:
http://marc.info/?l=linuxppc-embedded&m=136572252330650&w=2
Next time please quote t
I have the same question as like above posted by Mr. Chirs.
Could someone help to understand why the debug BRT bit not handled in debug
context sys call? Intentional or need volunteer to finish up this part :)
--
View this message in context:
http://linuxppc.10917.n7.nabble.com/questions-on
On Fri, 2013-12-06 at 18:48 -0600, Ruchika wrote:
> Hi,
> I am working with an p4080 based board. I am trying to get 2 PCIE
> controllers probed properly.
>
> In uboot I have no problems scanning and discovering what is connected
> to both controllers/PCI bridges.
>
> For both PCIE1/2 uboot set
Any ideas/pointers anyone ?
Thank you
On 12/6/2013 6:48 PM, Ruchika wrote:
Hi,
I am working with an p4080 based board. I am trying to get 2 PCIE
controllers probed properly.
In uboot I have no problems scanning and discovering what is connected
to both controllers/PCI bridges.
For both PCIE1/
Hi,
I am working with an p4080 based board. I am trying to get 2 PCIE
controllers probed properly.
In uboot I have no problems scanning and discovering what is connected
to both controllers/PCI bridges.
For both PCIE1/2 uboot sets up the Primary, secondary and Subordinate
bus numbers to 0,
traced causes
> an exception.
That code is a mess and it wouldn't surprise me if it was broken...
At this point, the people who care the most about it are FSL, so
that's where you have the most chance to find a satisfactory answer.
Cheers,
Ben.
> I have a few questions though:
oking around looking for answers to my previous questions I seem
to have stumbled over a bug in branch tracing for 64-bit Book-E.
Commit ec097c8 added support for branch tracing for 32-bit code, but
didn't do the 64-bit path. As it stands, debug_crit/debug_debug in
exceptions-64e.S only che
Hi,
I'm trying to wrap my head around how linux handles branch tracing on
Book III-E. I think I understand how we set MSR[DE] and DBCR0[IDM|BT],
and how we handle fixing things up if an instruction being traced causes
an exception.
I have a few questions though:
1)
Hi all,
Sorry for the bunch of emails, I'm working on some new stuff and running
into issues.
For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP
but not DBCR0_BRT. Is that just because none of the code paths
currently using DBCR0_ACTIVE_EVENTS need to check DBCR0_BT?
On 11/28/2012 03:39:22 AM, Frans Meulenbroeks wrote:
Hi,
I've been playing with spi on mpc8313e and have some things on
spi-fsl-spi.c:
Is QE useful on 8313?
I've tried it (using cpu-qe in my dts file) and see in the boot log
that it
is used, but I do not really see any effect when it comes to
Hi,
I've been playing with spi on mpc8313e and have some things on
spi-fsl-spi.c:
Is QE useful on 8313?
I've tried it (using cpu-qe in my dts file) and see in the boot log that it
is used, but I do not really see any effect when it comes to performance or
cpu usage.
Furthermore:
In the fsl_spi_c
On 09.11.12 11:26:26, Stephane Eranian wrote:
> On Thu, Nov 8, 2012 at 2:10 AM, Sukadev Bhattiprolu
> wrote:
> > 2. Can we allow hyphens in the {name} token (please see my change to
> >util/parse-events.l below). With this change, I can run:
> >
> The current code does not support this but A
On Thu, Nov 8, 2012 at 2:10 AM, Sukadev Bhattiprolu
wrote:
>
>
> Looking for feedback on this prototype for making POWER-specific event
> translations available in sysfs. It is based on the patchset:
>
> https://lkml.org/lkml/2012/11/7/402
>
> which makes the translations for _generic_ eve
Looking for feedback on this prototype for making POWER-specific event
translations available in sysfs. It is based on the patchset:
https://lkml.org/lkml/2012/11/7/402
which makes the translations for _generic_ events in POWER available in sysfs:
Since this is in POWER7 specific code
On Jun 15, 2012, at 1:11 PM, Scott Wood wrote:
> On 06/15/2012 09:43 AM, telenn barz wrote:
>> Hi all,
>>
>> CONFIG_PHYS_64BIT enables kernel support for larger than 32-bit physical
>> addresses. Is it this configuration option we have to enable for the
>> support of 36-bit real memory (as are c
On 06/15/2012 09:43 AM, telenn barz wrote:
> Hi all,
>
> CONFIG_PHYS_64BIT enables kernel support for larger than 32-bit physical
> addresses. Is it this configuration option we have to enable for the
> support of 36-bit real memory (as are capable the Freescale e500v2 or
> e500mc cores family) ?
Hi all,
CONFIG_PHYS_64BIT enables kernel support for larger than 32-bit physical
addresses. Is it this configuration option we have to enable for the
support of 36-bit real memory (as are capable the Freescale e500v2 or
e500mc cores family) ?
The Hugetlb patch for BookE (
https://lists.ozlabs.org
I don't see the
> ISR being called. I'm currently checking if it can be a hardware problem
> before coming back here for more questions !
Great!
> BTW, is errno/strerror used within the kernel ?
Nope.
cheers
signature.asc
Description: This is a digitally signed message part
nto the
probe function and can now register my interrupt, yeah!, but I don't see the
ISR being called. I'm currently checking if it can be a hardware problem
before coming back here for more questions !
BTW, is errno/strerror used within the kernel ?
On Wed, 2010-12-08 at 16:52 +0100, Guillaume Dargaud wrote:
> > Sorry I assumed you were working on mainline. In 2.6.35 you still need
> > to use an of_platform_driver, I'll describe below.
>
> > So basically you need to change all occurrences of platform_driver to
> > of_platform_driver.
>
> OK,
Hi Guillaume,
Michael Ellerman wrote:
> On Wed, 2010-12-08 at 11:18 +0100, Guillaume Dargaud wrote:
>> ///
>> // Called on insmod
>> static int __init xad_init(void) {
>> int rc=0;
>> printk(KERN_INFO SD "Module %s: lo
> Sorry I assumed you were working on mainline. In 2.6.35 you still need
> to use an of_platform_driver, I'll describe below.
> So basically you need to change all occurrences of platform_driver to
> of_platform_driver.
OK, thanks, I did that, compiled and ran the driver and its test prog... no
On Wed, 2010-12-08 at 11:18 +0100, Guillaume Dargaud wrote:
> Thanks again for your detailed answer,
> I'm learning, but not as fast as my colleagues with a deadline want me to !
:)
> > The platform code does that. That function create devices on the
> > platform bus by examining the device tree.
Thanks again for your detailed answer,
I'm learning, but not as fast as my colleagues with a deadline want me to !
> The platform code does that. That function create devices on the
> platform bus by examining the device tree. It looks for nodes that are
> compatible with the compatible strings yo
On Mon, 2010-12-06 at 15:44 +0100, Guillaume Dargaud wrote:
> Hello all,
>
> > OK, that should be all pretty straight forward, and covered by the
> > material in LDD and similar references. You just need to get your device
> > probed.
>
> I'm not sure what you mean with that term: simply identif
On Tue, 2010-12-07 at 13:46 +0100, Guillaume Dargaud wrote:
> Michael,
> in your example, when is foo_driver_probe() actually called ?
> It's not being called when I do an insmod.
It should be called when the driver core finds a device that matches
your match table.
When you register your driver
Michael,
in your example, when is foo_driver_probe() actually called ?
It's not being called when I do an insmod.
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
> Another question: I just spent 10 minutes trying to find
> where "struct device" was defined.
Dirty trick #4:
At the top of a source file (before the first include) add:
struct device { int fubar; };
Then try to compile it.
The compiler will the tell where it is defined!
David
Hello all,
> OK, that should be all pretty straight forward, and covered by the
> material in LDD and similar references. You just need to get your device
> probed.
I'm not sure what you mean with that term: simply identifying that the device
works using device specific code ?
I've looked at sev
> That's the idea. Communication between usermode and the driver is
limited to
> simple ioctl calls and the driver receives an interrupt when certain
data has
> been placed in memory blocks by the hardware (like a DMA).
> Then the user prog figures out where that latest data buffer is (mmap)
On Mon, 2010-12-06 at 10:58 +0100, Guillaume Dargaud wrote:
> Thank you for the detailed answer. I'm trying to digest it...
>
> > > What's a good source, besides grepping the kernel to no end ?
> >
> > Nothing really I'm afraid.
> 8-|
>
> > So you have a device, it appears in your device tree, a
On Mon, 2010-12-06 at 14:35 +0800, Jeremy Kerr wrote:
> Hi Michael,
>
> > So you have a device, it appears in your device tree, and you want to
> > write a driver for it.
>
> Nice write up, mind if I steal this for the devicetree.org wiki?
Sure thing, feel free to correct any mistakes too ;D
ch
Thank you for the detailed answer. I'm trying to digest it...
> > What's a good source, besides grepping the kernel to no end ?
>
> Nothing really I'm afraid.
8-|
> So you have a device, it appears in your device tree, and you want to
> write a driver for it.
That's the idea. Communication betwe
Hi Michael,
> So you have a device, it appears in your device tree, and you want to
> write a driver for it.
Nice write up, mind if I steal this for the devicetree.org wiki?
Cheers,
Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
h
On Fri, 2010-12-03 at 15:58 +0100, Guillaume Dargaud wrote:
> > No. of_platform_drivers are more/less obsolete. Normal platform drivers
> > can now be associated with a device-tree node just fine.
>
> OK.
>
> If my dts definition is thus:
> xps_acqui_data_0: xps-acqui-d...@c980
On 03/12/10 14:58, Guillaume Dargaud wrote:
> Why is there not a word about the functions platform_*_register in my various
> driver books ? LDD 3rd ed (O'Reilly), Writing LDD (Cooperstein) or LKD
> (Love)... Is it something specific to powerpc and the books are oriented x86
> ?
> What's a good
> No. of_platform_drivers are more/less obsolete. Normal platform drivers
> can now be associated with a device-tree node just fine.
OK.
If my dts definition is thus:
xps_acqui_data_0: xps-acqui-d...@c980 {
compatible = "xlnx,xps-acqui-data-3.00.a";
On Thu, 2010-12-02 at 18:47 +0100, Guillaume Dargaud wrote:
>
> OK, learning by example then.
>
> Another basic question:
> what's the difference between of_register_platform_driver() and
> platform_driver_register() ?
> I assume I must use the first one if I want to use
> irq_of_parse_and_map.
> grep -r irq_of_parse_and_map *
>
> will give you plenty of examples.
OK, learning by example then.
Another basic question:
what's the difference between of_register_platform_driver() and
platform_driver_register() ?
I assume I must use the first one if I want to use irq_of_parse_and_map
On Thu, Dec 2, 2010 at 9:36 AM, Guillaume Dargaud wrote:
> Sounds like what I need... But I don't find irq_of_parse_and_map() in LDD 3rd
> ed and very few info in google. Are there some examples of use somewhere ?
grep -r irq_of_parse_and_map *
will give you plenty of examples.
--
Timur
> How was your driver probed? If you can get a pointer to the device
> node, use irq_of_parse_and_map() to get a virtual irq that you can pass
> to request_irq().
Sounds like what I need... But I don't find irq_of_parse_and_map() in LDD 3rd
ed and very few info in google. Are there some examples
On Wed, 1 Dec 2010 17:35:58 +0100
Guillaume Dargaud wrote:
> OK, here goes then: how do I get the IRQ number so that I can install an
> interrupt handler on it ?
>
> In my dts file I have:
> xps_acqui_data_0: xps-acqui-d...@c980 {
> compatible = "xlnx,xps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/01/2010 05:35 PM, Guillaume Dargaud wrote:
> Now how do I connect the dots between the hardware definitions from the dts
> and
> my driver ?
You can get the interrupt number from the dt by calling
irq_of_parse_and_map(). Be sure to pass the no
> I guess it depends how basic they are :)
>
> If they're basic _powerpc_ driver questions then this is probably the
> right place.
>
> But I'd say just ask and maybe someone will be able to help, or maybe
> they'll point you somewhere else.
OK, here goes
On Wed, 2010-12-01 at 11:15 +0100, Guillaume Dargaud wrote:
> Hello all,
> is it OK if I ask basic driver development questions here ?
> Could you recommend a better forum for that maybe ?
Hi Guillaume,
I guess it depends how basic they are :)
If they're basic _powerpc_ driver
Hello all,
is it OK if I ask basic driver development questions here ?
Could you recommend a better forum for that maybe ?
Thanks
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
Scott Wood wrote:
> On Thu, 14 Oct 2010 11:27:09 +0800
> "tiejun.chen" wrote:
>
>> tiejun.chen wrote:
>>> Scott Wood wrote:
On Wed, 13 Oct 2010 09:17:01 +0800
"tiejun.chen" wrote:
> Scott Wood wrote:
>> The crash is happening somewhere in mpic_set_irq_type():
> Agreed.
> Well, it was a coworker who added the workaround, so I assume we're
> already aware of the issue.
>
> The description of NIRQ is vague enough that it's hard to argue that
> Linux's expectations of what it means are justified.
>
Well, I now can actually interrupt the PPC from my host processor!
On Thu, 14 Oct 2010 12:20:55 -0500
wrote:
> > It comes from FRR[NIRQ]. It seems that this chip takes a
> > less-than-useful interpretation of what that field means -- it gives
> > the actual number of sources, not the size of the sparsely populated
> > array.
> Perhaps you might want to have a t
Hallelujah and Huzzah! I finally got my vector!
I back-ported the MPIC_BROKEN_FRR_NIRQS flag and code to our kernel, and
the kernel is now letting me have my vector! Now I can actually see if the
dang thing works!
THANK YOU EVERYBODY for putting up with me on this!
> It comes from FRR[NIRQ]. It
On Thu, 14 Oct 2010 11:22:45 -0500
wrote:
> As I read the code:
> /* Read feature register, calculate num CPUs and, for non-ISU
>* MPICs, num sources as well. On ISU MPICs, sources are counted
>* as ISUs are added
>*/
> greg_feature = mpic_read(mpic->gregs, M
I may have a clue (you might not think so, but...):
I've configured the init thusly:
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN ,
0, 256,
" MPIC ");
Which, as I read the code, should disable the ISU stuff.
I've seeing this on b
On Thu, 14 Oct 2010 11:27:09 +0800
"tiejun.chen" wrote:
> tiejun.chen wrote:
> > Scott Wood wrote:
> >> On Wed, 13 Oct 2010 09:17:01 +0800
> >> "tiejun.chen" wrote:
> >>
> >>> Scott Wood wrote:
> The crash is happening somewhere in mpic_set_irq_type():
> >>> Agreed. That is just where I poi
tiejun.chen wrote:
> Scott Wood wrote:
>> On Wed, 13 Oct 2010 09:17:01 +0800
>> "tiejun.chen" wrote:
>>
>>> Scott Wood wrote:
The crash is happening somewhere in mpic_set_irq_type():
>>> Agreed. That is just where I pointed out on my email replied for OOPS. To
>>> enable
>>> DBG to figure ou
Scott Wood wrote:
> On Wed, 13 Oct 2010 09:17:01 +0800
> "tiejun.chen" wrote:
>
>> Scott Wood wrote:
>>> The crash is happening somewhere in mpic_set_irq_type():
>> Agreed. That is just where I pointed out on my email replied for OOPS. To
>> enable
>> DBG to figure out 'src' and 'mpic->irq_count
> On Wed, 13 Oct 2010 12:08:16 -0500
> I'd just rip the whole thing out of the board code, and pass zero in
> isu_size to mpic_alloc(), if you can undo whatever is depending on the
> remapping.
OK, what I did was to change
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | M
1 - 100 of 190 matches
Mail list logo
