Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

[Andy Green]

On July 22, 2016 12:18:48 AM GMT+08:00, John Stultz <john.stu...@linaro.org> 
wrote:
>On Wed, Jul 20, 2016 at 11:27 PM, Andy Green <a...@warmcat.com> wrote:
>> On July 21, 2016 1:22:02 PM GMT+08:00, John Stultz
><john.stu...@linaro.org> wrote:
>>>On Wed, Jul 20, 2016 at 9:26 PM, zhangfei <zhangfei@linaro.org>
>>>wrote:
>>>>
>>>>
>>>> On 07/21/2016 11:53 AM, John Stultz wrote:
>>>>>
>>>>> After lots of debugging on an occasional DMA ERR issue, I realized
>>>>> that the desc structures which we point the dma hardware are being
>>>>> allocated out of regular memory. This means when we fill the desc
>>>>> structures, that data doesn't always get flushed out to memory by
>>>>> the time we start the dma transfer, resulting in the dma engine
>>>getting
>>>>> some null values, resulting in a DMA ERR on the first irq.
>>>>
>>>>
>>>> How about using wmb() flush before start dma to sync desc?
>>>
>>>So I'm not going to pretend to be an expert here, but my
>understanding
>>>is that wmb() syncrhonizes cpu write ordering operations across cpus,
>>
>> IIUI what the memory barrier does is tell the *compiler* to actually
>do any writes that the code asked for, but which otherwise might
>actually be deferred past that point.  The compiler doesn't know that
>buffer area has other hardware snooping it, so by default it feels it
>can play tricks with what seems to it like just generally deferring
>spilling registers to memory.  wmb makes sure the compiler's pending
>writes actually happen right there.  (writel() etc definitions have one
>built-in, so they always do what you asked when you asked).
>>
>> That can be of interest when syncing with other cores but also to
>other IPs that intend to use the written-to area immediately, which is
>what's happening here.  Without the barrier the write may not be issued
>anywhere, even to local cpu cache, until after the hw is asked to go
>read the buffer, corrupting what the hw sees.
>>
>>>so the cpus see all the changes before the wmb() before they see any
>>>changes after.  But I'm not sure what effect wmb() has across cpu
>>>cache to device ordering.   I don't think it works as a cache flush
>to
>>>memory.
>>>
>>>Andy's patch introducing the cyclic support actually had a wmb() in
>it
>>>that I removed as I couldn't understand clearly why it was there (and
>>>there wasn't a comment explaining, as required by checkpatch :).  
>But
>>>even with that wmb(), the DMA ERR was still seen.
>>
>> The rule about the comment is there partially because there's a
>general tendancy for throwing voodoo smbs on broken things in case it
>helps.  But writing out memory descriptors that other hw is going to
>read is a legit use for it I think.  If the compiler you use wasn't
>deferring the write, you won't notice any difference removing it, but
>that doesn't mean it shouldn't be there.
>>
>
>Though from your comments above, wouldn't using writel() instead of
>writel_relaxed(), followed by a wmb() be sufficient?

Yes, since on Arm writel() sticks a wmb (ultimately a dsb instruction + 
outer_sync()) after every write it does. 

-Andy

>thanks
>-john

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

[Andy Green]

On July 22, 2016 12:18:48 AM GMT+08:00, John Stultz  
wrote:
>On Wed, Jul 20, 2016 at 11:27 PM, Andy Green  wrote:
>> On July 21, 2016 1:22:02 PM GMT+08:00, John Stultz
> wrote:
>>>On Wed, Jul 20, 2016 at 9:26 PM, zhangfei 
>>>wrote:
>>>>
>>>>
>>>> On 07/21/2016 11:53 AM, John Stultz wrote:
>>>>>
>>>>> After lots of debugging on an occasional DMA ERR issue, I realized
>>>>> that the desc structures which we point the dma hardware are being
>>>>> allocated out of regular memory. This means when we fill the desc
>>>>> structures, that data doesn't always get flushed out to memory by
>>>>> the time we start the dma transfer, resulting in the dma engine
>>>getting
>>>>> some null values, resulting in a DMA ERR on the first irq.
>>>>
>>>>
>>>> How about using wmb() flush before start dma to sync desc?
>>>
>>>So I'm not going to pretend to be an expert here, but my
>understanding
>>>is that wmb() syncrhonizes cpu write ordering operations across cpus,
>>
>> IIUI what the memory barrier does is tell the *compiler* to actually
>do any writes that the code asked for, but which otherwise might
>actually be deferred past that point.  The compiler doesn't know that
>buffer area has other hardware snooping it, so by default it feels it
>can play tricks with what seems to it like just generally deferring
>spilling registers to memory.  wmb makes sure the compiler's pending
>writes actually happen right there.  (writel() etc definitions have one
>built-in, so they always do what you asked when you asked).
>>
>> That can be of interest when syncing with other cores but also to
>other IPs that intend to use the written-to area immediately, which is
>what's happening here.  Without the barrier the write may not be issued
>anywhere, even to local cpu cache, until after the hw is asked to go
>read the buffer, corrupting what the hw sees.
>>
>>>so the cpus see all the changes before the wmb() before they see any
>>>changes after.  But I'm not sure what effect wmb() has across cpu
>>>cache to device ordering.   I don't think it works as a cache flush
>to
>>>memory.
>>>
>>>Andy's patch introducing the cyclic support actually had a wmb() in
>it
>>>that I removed as I couldn't understand clearly why it was there (and
>>>there wasn't a comment explaining, as required by checkpatch :).  
>But
>>>even with that wmb(), the DMA ERR was still seen.
>>
>> The rule about the comment is there partially because there's a
>general tendancy for throwing voodoo smbs on broken things in case it
>helps.  But writing out memory descriptors that other hw is going to
>read is a legit use for it I think.  If the compiler you use wasn't
>deferring the write, you won't notice any difference removing it, but
>that doesn't mean it shouldn't be there.
>>
>
>Though from your comments above, wouldn't using writel() instead of
>writel_relaxed(), followed by a wmb() be sufficient?

Yes, since on Arm writel() sticks a wmb (ultimately a dsb instruction + 
outer_sync()) after every write it does. 

-Andy

>thanks
>-john

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

[Andy Green]

On Thu, 2016-07-21 at 11:40 +0100, Mark Brown wrote:
> On Thu, Jul 21, 2016 at 02:27:02PM +0800, Andy Green wrote:
> > 
> > On July 21, 2016 1:22:02 PM GMT+08:00, John Stultz <john.stultz@lin
> > aro.org> wrote:
> > > 
> > > On Wed, Jul 20, 2016 at 9:26 PM, zhangfei <zhangfei@linaro.or
> > > g>
> 
> Please fix your mail client to word wrap within paragraphs at
> something
> substantially less than 80 columns.  Doing this makes your messages
> much
> easier to read and reply to.
> 
> > 
> > > 
> > > > 
> > > > How about using wmb() flush before start dma to sync desc?
> 
> > 
> > > 
> > > So I'm not going to pretend to be an expert here, but my
> > > understanding
> > > is that wmb() syncrhonizes cpu write ordering operations across
> > > cpus,
> 
> > 
> > IIUI what the memory barrier does is tell the *compiler* to
> > actually
> > do any writes that the code asked for, but which otherwise might
> > actually be deferred past that point.  The compiler doesn't know
> > that
> > buffer area has other hardware snooping it, so by default it feels
> > it
> > can play tricks with what seems to it like just generally deferring
> > spilling registers to memory.  wmb makes sure the compiler's
> > pending
> > writes actually happen right there.  (writel() etc definitions have
> > one built-in, so they always do what you asked when you asked).
> 
> You might be interested in Mark Rutland's talk from ELC (Stale data,
> or
> how we (mis-)manage modern caches):
> 
> http://events.linuxfoundation.org/sites/events/files/slides/slide
> s_17.pdf

Thanks for the pointer.

That is a somewhat different animal to wmb though: wmb is about
managing when the initiator of the write actualizes it, prior to that
the write does not instantenously exist anywhere and so is not subject
to these coherency nightmares [1].

Also the presentation is from the hw POV only, at the Linux driver
level most of the considerations can be made moot if you just use the
generic Linux DMA or related apis, which thanks to the work of the Arm
Linux gods already knows how to deal with / wrap the issues, plus or
minus.  So it's not as dire as it sounds.

-Andy

[1] The details of some of those nightmares are unfortunately very
familiar to me, since I spent many months where Linux was being blamed
for Mali breakage via CCI on a platform that ultimately had its
problems resolved by tweaks in its secure world...

> https://www.youtube.com/watch?v=F0SlIMHRnLk

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

[Andy Green]

On Thu, 2016-07-21 at 11:40 +0100, Mark Brown wrote:
> On Thu, Jul 21, 2016 at 02:27:02PM +0800, Andy Green wrote:
> > 
> > On July 21, 2016 1:22:02 PM GMT+08:00, John Stultz  > aro.org> wrote:
> > > 
> > > On Wed, Jul 20, 2016 at 9:26 PM, zhangfei  > > g>
> 
> Please fix your mail client to word wrap within paragraphs at
> something
> substantially less than 80 columns.  Doing this makes your messages
> much
> easier to read and reply to.
> 
> > 
> > > 
> > > > 
> > > > How about using wmb() flush before start dma to sync desc?
> 
> > 
> > > 
> > > So I'm not going to pretend to be an expert here, but my
> > > understanding
> > > is that wmb() syncrhonizes cpu write ordering operations across
> > > cpus,
> 
> > 
> > IIUI what the memory barrier does is tell the *compiler* to
> > actually
> > do any writes that the code asked for, but which otherwise might
> > actually be deferred past that point.  The compiler doesn't know
> > that
> > buffer area has other hardware snooping it, so by default it feels
> > it
> > can play tricks with what seems to it like just generally deferring
> > spilling registers to memory.  wmb makes sure the compiler's
> > pending
> > writes actually happen right there.  (writel() etc definitions have
> > one built-in, so they always do what you asked when you asked).
> 
> You might be interested in Mark Rutland's talk from ELC (Stale data,
> or
> how we (mis-)manage modern caches):
> 
> http://events.linuxfoundation.org/sites/events/files/slides/slide
> s_17.pdf

Thanks for the pointer.

That is a somewhat different animal to wmb though: wmb is about
managing when the initiator of the write actualizes it, prior to that
the write does not instantenously exist anywhere and so is not subject
to these coherency nightmares [1].

Also the presentation is from the hw POV only, at the Linux driver
level most of the considerations can be made moot if you just use the
generic Linux DMA or related apis, which thanks to the work of the Arm
Linux gods already knows how to deal with / wrap the issues, plus or
minus.  So it's not as dire as it sounds.

-Andy

[1] The details of some of those nightmares are unfortunately very
familiar to me, since I spent many months where Linux was being blamed
for Mali breakage via CCI on a platform that ultimately had its
problems resolved by tweaks in its secure world...

> https://www.youtube.com/watch?v=F0SlIMHRnLk

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

[Andy Green]

On July 21, 2016 1:22:02 PM GMT+08:00, John Stultz  
wrote:
>On Wed, Jul 20, 2016 at 9:26 PM, zhangfei 
>wrote:
>>
>>
>> On 07/21/2016 11:53 AM, John Stultz wrote:
>>>
>>> After lots of debugging on an occasional DMA ERR issue, I realized
>>> that the desc structures which we point the dma hardware are being
>>> allocated out of regular memory. This means when we fill the desc
>>> structures, that data doesn't always get flushed out to memory by
>>> the time we start the dma transfer, resulting in the dma engine
>getting
>>> some null values, resulting in a DMA ERR on the first irq.
>>
>>
>> How about using wmb() flush before start dma to sync desc?
>
>So I'm not going to pretend to be an expert here, but my understanding
>is that wmb() syncrhonizes cpu write ordering operations across cpus,

IIUI what the memory barrier does is tell the *compiler* to actually do any 
writes that the code asked for, but which otherwise might actually be deferred 
past that point.  The compiler doesn't know that buffer area has other hardware 
snooping it, so by default it feels it can play tricks with what seems to it 
like just generally deferring spilling registers to memory.  wmb makes sure the 
compiler's pending writes actually happen right there.  (writel() etc 
definitions have one built-in, so they always do what you asked when you asked).

That can be of interest when syncing with other cores but also to other IPs 
that intend to use the written-to area immediately, which is what's happening 
here.  Without the barrier the write may not be issued anywhere, even to local 
cpu cache, until after the hw is asked to go read the buffer, corrupting what 
the hw sees.

>so the cpus see all the changes before the wmb() before they see any
>changes after.  But I'm not sure what effect wmb() has across cpu
>cache to device ordering.   I don't think it works as a cache flush to
>memory.
>
>Andy's patch introducing the cyclic support actually had a wmb() in it
>that I removed as I couldn't understand clearly why it was there (and
>there wasn't a comment explaining, as required by checkpatch :).   But
>even with that wmb(), the DMA ERR was still seen.

The rule about the comment is there partially because there's a general 
tendancy for throwing voodoo smbs on broken things in case it helps.  But 
writing out memory descriptors that other hw is going to read is a legit use 
for it I think.  If the compiler you use wasn't deferring the write, you won't 
notice any difference removing it, but that doesn't mean it shouldn't be there.

>Only with these two new changes have I gotten to the point where I
>can't seem to trigger the DMA error.

Sounds good...

-Andy

>thanks
>-john

Re: [PATCH 6/7] k3dma: Fix occasional DMA ERR issue by using proper dma api

[Andy Green]

On July 21, 2016 1:22:02 PM GMT+08:00, John Stultz  
wrote:
>On Wed, Jul 20, 2016 at 9:26 PM, zhangfei 
>wrote:
>>
>>
>> On 07/21/2016 11:53 AM, John Stultz wrote:
>>>
>>> After lots of debugging on an occasional DMA ERR issue, I realized
>>> that the desc structures which we point the dma hardware are being
>>> allocated out of regular memory. This means when we fill the desc
>>> structures, that data doesn't always get flushed out to memory by
>>> the time we start the dma transfer, resulting in the dma engine
>getting
>>> some null values, resulting in a DMA ERR on the first irq.
>>
>>
>> How about using wmb() flush before start dma to sync desc?
>
>So I'm not going to pretend to be an expert here, but my understanding
>is that wmb() syncrhonizes cpu write ordering operations across cpus,

IIUI what the memory barrier does is tell the *compiler* to actually do any 
writes that the code asked for, but which otherwise might actually be deferred 
past that point.  The compiler doesn't know that buffer area has other hardware 
snooping it, so by default it feels it can play tricks with what seems to it 
like just generally deferring spilling registers to memory.  wmb makes sure the 
compiler's pending writes actually happen right there.  (writel() etc 
definitions have one built-in, so they always do what you asked when you asked).

That can be of interest when syncing with other cores but also to other IPs 
that intend to use the written-to area immediately, which is what's happening 
here.  Without the barrier the write may not be issued anywhere, even to local 
cpu cache, until after the hw is asked to go read the buffer, corrupting what 
the hw sees.

>so the cpus see all the changes before the wmb() before they see any
>changes after.  But I'm not sure what effect wmb() has across cpu
>cache to device ordering.   I don't think it works as a cache flush to
>memory.
>
>Andy's patch introducing the cyclic support actually had a wmb() in it
>that I removed as I couldn't understand clearly why it was there (and
>there wasn't a comment explaining, as required by checkpatch :).   But
>even with that wmb(), the DMA ERR was still seen.

The rule about the comment is there partially because there's a general 
tendancy for throwing voodoo smbs on broken things in case it helps.  But 
writing out memory descriptors that other hw is going to read is a legit use 
for it I think.  If the compiler you use wasn't deferring the write, you won't 
notice any difference removing it, but that doesn't mean it shouldn't be there.

>Only with these two new changes have I gotten to the point where I
>can't seem to trigger the DMA error.

Sounds good...

-Andy

>thanks
>-john

Re: [RFC][PATCH 0/7] Add HDMI audio support for HiKey

[Andy Green]

On Fri, 2016-07-15 at 19:13 -0700, John Stultz wrote:
> This patch set is required for HDMI audio support on HiKey.
> 
> This patchset hasn't yet seen the light of lkml, so I suspect
> there will be a few revisions, but I wanted to send it out for
> an initial review.
> 
> The work is mostly that of Andy Green's, but I've taking a swing
> at forward porting and cleaning it up where I saw fit. So credit
> to Andy and blame to me. Apologies in advance, as I'm not super
> familiar with either DMA or ASoC driver.
> 
> The one bit missing to have audio fully working is changes to the
> adv7511 driver, but most of those changes are still out of tree, so
> I'll submit those changes once they land.
> 
> Feedback would be very much appreicated!

Thanks John, it's good to know that work didn't go to waste.

The linaro.org email in the patches is dead, since I resigned from
Linaro a few months ago.  If the goal of adding it to the kernel is to
make it possible to contact the author, it should change to
<a...@warmcat.com>.
There are (were) a couple of limitations with it that should be
commented somewhere:

 1) The cyclic DMA, at least going into the I2S FIFO, had what appeared
to be hw bugs when I left it, I had asked hisilicon about it but got no
useful reply.  The DMA worked well generally, but there were audible
clicks and pops at intervals even though the DMA really is cyclic.  I
dunno whether they got around to looking at it or not: if not, there
should probably be a comment in the driver about it.  There were notes
in the I2S FIFO docs (it seemed the likely culprit) about needing to
take care about FIFO trigger levels but didn't seem to change anything.

 2) The driver only exposes 48kHz / 2ch.

Otherwise it worked well.

Thanks again for upstreaming it.

-Andy

> thanks
> -john
> 
> Cc: Zhangfei Gao <zhangfei@linaro.org>
> Cc: Jingoo Han <jg1@samsung.com>
> Cc: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
> Cc: Vinod Koul <vinod.k...@intel.com>
> Cc: Dan Williams <dan.j.willi...@intel.com>
> Cc: Liam Girdwood <lgirdw...@gmail.com>
> Cc: Mark Brown <broo...@kernel.org>
> Cc: Jaroslav Kysela <pe...@perex.cz>
> Cc: Takashi Iwai <ti...@suse.com>
> Cc: Wei Xu <xuw...@hisilicon.com>
> Cc: Rob Herring <robh...@kernel.org>
> Cc: Andy Green <a...@warmcat.com>
> Cc: Dave Long <dave.l...@linaro.org>
> Cc: Guodong Xu <guodong...@linaro.org>
> 
> Andy Green (5):
>   k3dma: Fix hisi burst clipping
>   k3dma: Fix dma err offsets
>   k3dma: Fix "nobody cared" message seen on any error
>   k3dma: Add cyclic mode for audio
>   ASoC: hisilicon:  Add hi6210 i2s audio driver for hdmi audio
> 
> John Stultz (2):
>   Kconfig: Allow k3dma driver to be selected for more then HISI3xx
> platforms
>   dts: hi6220: Add k3-dma and i2s/hdmi audio support
> 
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi |  36 ++
>  drivers/dma/Kconfig   |   1 -
>  drivers/dma/k3dma.c   | 149 ++-
>  sound/soc/Kconfig |   1 +
>  sound/soc/Makefile|   1 +
>  sound/soc/hisilicon/Kconfig   |   5 +
>  sound/soc/hisilicon/Makefile  |   2 +
>  sound/soc/hisilicon/hi6210-hdmi-card.c| 131 ++
>  sound/soc/hisilicon/hi6210-i2s.c  | 641
> ++
>  sound/soc/hisilicon/hi6210-i2s.h  | 276 +
>  10 files changed, 1222 insertions(+), 21 deletions(-)
>  create mode 100644 sound/soc/hisilicon/Kconfig
>  create mode 100644 sound/soc/hisilicon/Makefile
>  create mode 100644 sound/soc/hisilicon/hi6210-hdmi-card.c
>  create mode 100644 sound/soc/hisilicon/hi6210-i2s.c
>  create mode 100644 sound/soc/hisilicon/hi6210-i2s.h
> 

Re: [RFC][PATCH 0/7] Add HDMI audio support for HiKey

[Andy Green]

On Fri, 2016-07-15 at 19:13 -0700, John Stultz wrote:
> This patch set is required for HDMI audio support on HiKey.
> 
> This patchset hasn't yet seen the light of lkml, so I suspect
> there will be a few revisions, but I wanted to send it out for
> an initial review.
> 
> The work is mostly that of Andy Green's, but I've taking a swing
> at forward porting and cleaning it up where I saw fit. So credit
> to Andy and blame to me. Apologies in advance, as I'm not super
> familiar with either DMA or ASoC driver.
> 
> The one bit missing to have audio fully working is changes to the
> adv7511 driver, but most of those changes are still out of tree, so
> I'll submit those changes once they land.
> 
> Feedback would be very much appreicated!

Thanks John, it's good to know that work didn't go to waste.

The linaro.org email in the patches is dead, since I resigned from
Linaro a few months ago.  If the goal of adding it to the kernel is to
make it possible to contact the author, it should change to
.
There are (were) a couple of limitations with it that should be
commented somewhere:

 1) The cyclic DMA, at least going into the I2S FIFO, had what appeared
to be hw bugs when I left it, I had asked hisilicon about it but got no
useful reply.  The DMA worked well generally, but there were audible
clicks and pops at intervals even though the DMA really is cyclic.  I
dunno whether they got around to looking at it or not: if not, there
should probably be a comment in the driver about it.  There were notes
in the I2S FIFO docs (it seemed the likely culprit) about needing to
take care about FIFO trigger levels but didn't seem to change anything.

 2) The driver only exposes 48kHz / 2ch.

Otherwise it worked well.

Thanks again for upstreaming it.

-Andy

> thanks
> -john
> 
> Cc: Zhangfei Gao 
> Cc: Jingoo Han 
> Cc: Krzysztof Kozlowski 
> Cc: Maxime Ripard 
> Cc: Vinod Koul 
> Cc: Dan Williams 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: Wei Xu 
> Cc: Rob Herring 
> Cc: Andy Green 
> Cc: Dave Long 
> Cc: Guodong Xu 
> 
> Andy Green (5):
>   k3dma: Fix hisi burst clipping
>   k3dma: Fix dma err offsets
>   k3dma: Fix "nobody cared" message seen on any error
>   k3dma: Add cyclic mode for audio
>   ASoC: hisilicon:  Add hi6210 i2s audio driver for hdmi audio
> 
> John Stultz (2):
>   Kconfig: Allow k3dma driver to be selected for more then HISI3xx
> platforms
>   dts: hi6220: Add k3-dma and i2s/hdmi audio support
> 
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi |  36 ++
>  drivers/dma/Kconfig   |   1 -
>  drivers/dma/k3dma.c   | 149 ++-
>  sound/soc/Kconfig |   1 +
>  sound/soc/Makefile|   1 +
>  sound/soc/hisilicon/Kconfig   |   5 +
>  sound/soc/hisilicon/Makefile  |   2 +
>  sound/soc/hisilicon/hi6210-hdmi-card.c| 131 ++
>  sound/soc/hisilicon/hi6210-i2s.c  | 641
> ++
>  sound/soc/hisilicon/hi6210-i2s.h  | 276 +
>  10 files changed, 1222 insertions(+), 21 deletions(-)
>  create mode 100644 sound/soc/hisilicon/Kconfig
>  create mode 100644 sound/soc/hisilicon/Makefile
>  create mode 100644 sound/soc/hisilicon/hi6210-hdmi-card.c
>  create mode 100644 sound/soc/hisilicon/hi6210-i2s.c
>  create mode 100644 sound/soc/hisilicon/hi6210-i2s.h
> 

Re: [PATCH v2 12/14] mmc: sdhci-pic32: Add PIC32 SDHCI host controller driver

[Andy Green]

Hi... looks good, just some small general comments.

On 15 December 2015 at 06:42, Joshua Henderson
 wrote:
> From: Andrei Pistirica 
>
> This driver supports the SDHCI host controller found on a PIC32.
>
> Signed-off-by: Andrei Pistirica 
> Signed-off-by: Joshua Henderson 
> Cc: Ralf Baechle 
> ---
>  drivers/mmc/host/Kconfig   |   11 ++
>  drivers/mmc/host/Makefile  |1 +
>  drivers/mmc/host/sdhci-pic32.c |  291 
> 
>  3 files changed, 303 insertions(+)
>  create mode 100644 drivers/mmc/host/sdhci-pic32.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 1dee533..1a3a42b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -785,3 +785,14 @@ config MMC_MTK
>   If you have a machine with a integrated SD/MMC card reader, say Y 
> or M here.
>   This is needed if support for any SD/SDIO/MMC devices is required.
>   If unsure, say N.
> +
> +config MMC_SDHCI_MICROCHIP_PIC32
> +tristate "Microchip PIC32MZDA SDHCI support"
> +depends on MMC_SDHCI && PIC32MZDA
> +help
> +  This selects the Secure Digital Host Controller Interface (SDHCI)
> +  for PIC32MZDA platform.
> +
> +  If you have a controller with this interface, say Y or M here.
> +
> +  If unsure, say N.
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 3595f83..af918d2 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -75,6 +75,7 @@ obj-$(CONFIG_MMC_SDHCI_BCM2835)   += 
> sdhci-bcm2835.o
>  obj-$(CONFIG_MMC_SDHCI_IPROC)  += sdhci-iproc.o
>  obj-$(CONFIG_MMC_SDHCI_MSM)+= sdhci-msm.o
>  obj-$(CONFIG_MMC_SDHCI_ST) += sdhci-st.o
> +obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32)+= sdhci-pic32.o
>
>  ifeq ($(CONFIG_CB710_DEBUG),y)
> CFLAGS-cb710-mmc+= -DDEBUG
> diff --git a/drivers/mmc/host/sdhci-pic32.c b/drivers/mmc/host/sdhci-pic32.c
> new file mode 100644
> index 000..b7d7da2
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-pic32.c
> @@ -0,0 +1,291 @@
> +/*
> + * Support of SDHCI platform devices for Microchip PIC32.
> + *
> + * Copyright (C) 2015 Microchip
> + * Andrei Pistirica, Paul Thacker
> + *
> + * Inspired by sdhci-pltfm.c
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "sdhci.h"
> +#include 
> +
> +#define SDH_SHARED_BUS_CTRL0x00E0
> +#define SDH_SHARED_BUS_NR_CLK_PINS_MASK0x7
> +#define SDH_SHARED_BUS_NR_IRQ_PINS_MASK0x30
> +#define SDH_SHARED_BUS_CLK_PINS0x10
> +#define SDH_SHARED_BUS_IRQ_PINS0x14
> +#define SDH_CAPS_SDH_SLOT_TYPE_MASK0xC000
> +#define SDH_SLOT_TYPE_REMOVABLE0x0
> +#define SDH_SLOT_TYPE_EMBEDDED 0x1
> +#define SDH_SLOT_TYPE_SHARED_BUS   0x2
> +#define SDHCI_CTRL_CDSSEL  0x80
> +#define SDHCI_CTRL_CDTLVL  0x40
> +
> +#define ADMA_FIFO_RD_THSHLD512
> +#define ADMA_FIFO_WR_THSHLD512
> +
> +#define DEV_NAME "pic32-sdhci"

Is there any point defining this when it only has one use in the driver?

> +struct pic32_sdhci_pdata {
> +   struct platform_device  *pdev;
> +   struct clk *sys_clk;
> +   struct clk *base_clk;
> +};
> +
> +static unsigned int pic32_sdhci_get_max_clock(struct sdhci_host *host)
> +{
> +   struct pic32_sdhci_pdata *sdhci_pdata = sdhci_priv(host);
> +
> +   return clk_get_rate(sdhci_pdata->base_clk);
> +}
> +
> +static void pic32_sdhci_set_bus_width(struct sdhci_host *host, int width)
> +{
> +   u8 ctrl;
> +
> +   ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> +   if (width == MMC_BUS_WIDTH_8) {
> +   ctrl &= ~SDHCI_CTRL_4BITBUS;
> +   if (host->version >= SDHCI_SPEC_300)
> +   ctrl |= SDHCI_CTRL_8BITBUS;
> +   } else {
> +   if (host->version >= SDHCI_SPEC_300)
> +   ctrl &= ~SDHCI_CTRL_8BITBUS;
> +   if (width == MMC_BUS_WIDTH_4)
> +   ctrl |= SDHCI_CTRL_4BITBUS;
> +   else
> +   ctrl &= ~SDHCI_CTRL_4BITBUS;
> +   }
> +   /*
> +* SDHCI will not work if JTAG is not Connected.As a workaround fix,
> +* set Card Detect Signal Selection bit in SDHCI Host Control
> +* register and clear Card Detect Test Level bit in SDHCI Host
> +* Control register.
> +*/

Isn't this a clearer explanation, if I understood?

"Without setting CD select and test bits now, SDHCI only works with
JTAG connected."

> +   ctrl &= ~SDHCI_CTRL_CDTLVL;
> +   ctrl 

Re: [PATCH v2 12/14] mmc: sdhci-pic32: Add PIC32 SDHCI host controller driver

[Andy Green]

Hi... looks good, just some small general comments.

On 15 December 2015 at 06:42, Joshua Henderson
 wrote:
> From: Andrei Pistirica 
>
> This driver supports the SDHCI host controller found on a PIC32.
>
> Signed-off-by: Andrei Pistirica 
> Signed-off-by: Joshua Henderson 
> Cc: Ralf Baechle 
> ---
>  drivers/mmc/host/Kconfig   |   11 ++
>  drivers/mmc/host/Makefile  |1 +
>  drivers/mmc/host/sdhci-pic32.c |  291 
> 
>  3 files changed, 303 insertions(+)
>  create mode 100644 drivers/mmc/host/sdhci-pic32.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 1dee533..1a3a42b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -785,3 +785,14 @@ config MMC_MTK
>   If you have a machine with a integrated SD/MMC card reader, say Y 
> or M here.
>   This is needed if support for any SD/SDIO/MMC devices is required.
>   If unsure, say N.
> +
> +config MMC_SDHCI_MICROCHIP_PIC32
> +tristate "Microchip PIC32MZDA SDHCI support"
> +depends on MMC_SDHCI && PIC32MZDA
> +help
> +  This selects the Secure Digital Host Controller Interface (SDHCI)
> +  for PIC32MZDA platform.
> +
> +  If you have a controller with this interface, say Y or M here.
> +
> +  If unsure, say N.
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 3595f83..af918d2 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -75,6 +75,7 @@ obj-$(CONFIG_MMC_SDHCI_BCM2835)   += 
> sdhci-bcm2835.o
>  obj-$(CONFIG_MMC_SDHCI_IPROC)  += sdhci-iproc.o
>  obj-$(CONFIG_MMC_SDHCI_MSM)+= sdhci-msm.o
>  obj-$(CONFIG_MMC_SDHCI_ST) += sdhci-st.o
> +obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32)+= sdhci-pic32.o
>
>  ifeq ($(CONFIG_CB710_DEBUG),y)
> CFLAGS-cb710-mmc+= -DDEBUG
> diff --git a/drivers/mmc/host/sdhci-pic32.c b/drivers/mmc/host/sdhci-pic32.c
> new file mode 100644
> index 000..b7d7da2
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-pic32.c
> @@ -0,0 +1,291 @@
> +/*
> + * Support of SDHCI platform devices for Microchip PIC32.
> + *
> + * Copyright (C) 2015 Microchip
> + * Andrei Pistirica, Paul Thacker
> + *
> + * Inspired by sdhci-pltfm.c
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "sdhci.h"
> +#include 
> +
> +#define SDH_SHARED_BUS_CTRL0x00E0
> +#define SDH_SHARED_BUS_NR_CLK_PINS_MASK0x7
> +#define SDH_SHARED_BUS_NR_IRQ_PINS_MASK0x30
> +#define SDH_SHARED_BUS_CLK_PINS0x10
> +#define SDH_SHARED_BUS_IRQ_PINS0x14
> +#define SDH_CAPS_SDH_SLOT_TYPE_MASK0xC000
> +#define SDH_SLOT_TYPE_REMOVABLE0x0
> +#define SDH_SLOT_TYPE_EMBEDDED 0x1
> +#define SDH_SLOT_TYPE_SHARED_BUS   0x2
> +#define SDHCI_CTRL_CDSSEL  0x80
> +#define SDHCI_CTRL_CDTLVL  0x40
> +
> +#define ADMA_FIFO_RD_THSHLD512
> +#define ADMA_FIFO_WR_THSHLD512
> +
> +#define DEV_NAME "pic32-sdhci"

Is there any point defining this when it only has one use in the driver?

> +struct pic32_sdhci_pdata {
> +   struct platform_device  *pdev;
> +   struct clk *sys_clk;
> +   struct clk *base_clk;
> +};
> +
> +static unsigned int pic32_sdhci_get_max_clock(struct sdhci_host *host)
> +{
> +   struct pic32_sdhci_pdata *sdhci_pdata = sdhci_priv(host);
> +
> +   return clk_get_rate(sdhci_pdata->base_clk);
> +}
> +
> +static void pic32_sdhci_set_bus_width(struct sdhci_host *host, int width)
> +{
> +   u8 ctrl;
> +
> +   ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> +   if (width == MMC_BUS_WIDTH_8) {
> +   ctrl &= ~SDHCI_CTRL_4BITBUS;
> +   if (host->version >= SDHCI_SPEC_300)
> +   ctrl |= SDHCI_CTRL_8BITBUS;
> +   } else {
> +   if (host->version >= SDHCI_SPEC_300)
> +   ctrl &= ~SDHCI_CTRL_8BITBUS;
> +   if (width == MMC_BUS_WIDTH_4)
> +   ctrl |= SDHCI_CTRL_4BITBUS;
> +   else
> +   ctrl &= ~SDHCI_CTRL_4BITBUS;
> +   }
> +   /*
> +* SDHCI will not work if JTAG is not Connected.As a workaround fix,
> +* set Card Detect Signal Selection bit in SDHCI Host Control
> +* register and clear Card Detect Test Level bit in SDHCI Host
> +* Control register.
> +*/

Isn't this a clearer explanation, if I 

[PATCH] warning-elimination: android: binder

[Andy Green]

From: Andy Green 

warning-elimination: android: binder

This commit in mainline (now) causes a couple of warnings

commit 975a1ac9a9fe65d66ee1726c0db6dc58e53d232a
Author: Arve Hjønnevåg 
Date:   Tue Oct 16 15:29:53 2012 -0700

Staging: android: binder: Add some tracepoints

This patch fixes them

Signed-off-by: Andy Green 
---

diff --git a/drivers/staging/android/binder_trace.h
b/drivers/staging/android/binder_trace.h
index 82a567c..c661e37 100644
--- a/drivers/staging/android/binder_trace.h
+++ b/drivers/staging/android/binder_trace.h
@@ -159,7 +159,7 @@ TRACE_EVENT(binder_transaction_node_to_ref,
  TP_fast_assign(
  __entry->debug_id = t->debug_id;
  __entry->node_debug_id = node->debug_id;
- __entry->node_ptr = node->ptr;
+ __entry->node_ptr = (void __user *)node->ptr;
  __entry->ref_debug_id = ref->debug_id;
  __entry->ref_desc = ref->desc;
  ),
@@ -184,7 +184,7 @@ TRACE_EVENT(binder_transaction_ref_to_node,
  __entry->ref_debug_id = ref->debug_id;
  __entry->ref_desc = ref->desc;
  __entry->node_debug_id = ref->node->debug_id;
- __entry->node_ptr = ref->node->ptr;
+ __entry->node_ptr = (void __user *)ref->node->ptr;
  ),
  TP_printk("transaction=%d node=%d src_ref=%d src_desc=%d ==> dest_ptr=0x%p",
   __entry->debug_id, __entry->node_debug_id,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] warning-elimination: android: binder

[Andy Green]

From: Andy Green andy.gr...@linaro.org

warning-elimination: android: binder

This commit in mainline (now) causes a couple of warnings

commit 975a1ac9a9fe65d66ee1726c0db6dc58e53d232a
Author: Arve Hjønnevåg a...@android.com
Date:   Tue Oct 16 15:29:53 2012 -0700

Staging: android: binder: Add some tracepoints

This patch fixes them

Signed-off-by: Andy Green andy.gr...@linaro.org
---

diff --git a/drivers/staging/android/binder_trace.h
b/drivers/staging/android/binder_trace.h
index 82a567c..c661e37 100644
--- a/drivers/staging/android/binder_trace.h
+++ b/drivers/staging/android/binder_trace.h
@@ -159,7 +159,7 @@ TRACE_EVENT(binder_transaction_node_to_ref,
  TP_fast_assign(
  __entry-debug_id = t-debug_id;
  __entry-node_debug_id = node-debug_id;
- __entry-node_ptr = node-ptr;
+ __entry-node_ptr = (void __user *)node-ptr;
  __entry-ref_debug_id = ref-debug_id;
  __entry-ref_desc = ref-desc;
  ),
@@ -184,7 +184,7 @@ TRACE_EVENT(binder_transaction_ref_to_node,
  __entry-ref_debug_id = ref-debug_id;
  __entry-ref_desc = ref-desc;
  __entry-node_debug_id = ref-node-debug_id;
- __entry-node_ptr = ref-node-ptr;
+ __entry-node_ptr = (void __user *)ref-node-ptr;
  ),
  TP_printk(transaction=%d node=%d src_ref=%d src_desc=%d == dest_ptr=0x%p,
   __entry-debug_id, __entry-node_debug_id,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.10-rc6 "perf test" seems unhappy

[Andy Green]

On 26 June 2013 21:39, Prabhat Kumar Ravi  wrote:
> Hi,
>
> On Wed, Jun 26, 2013 at 4:39 PM, Andy Green  wrote:
>> Hi -
>>
>> Running perf test on 3.10-rc6 gives some unexpected behaviours.
>>
>> This is on a dual Cortex A9 board with perf userland cross-built from
>> same tree as the kernel.
>>
>> root@aa9-eb:~# perf test
>>  1: vmlinux symtab matches kallsyms: FAILED!
>
>> I started tracing the first failure... it stops because it can't find
>> "_stext" in /proc/kallsyms.  But it is there
>>
>> root@aa9-eb:~# cat /proc/kallsyms | grep _stext
>> 800081c0 T _stext
>>
>
>>
>> The others may be due to missing some config somewhere.
>>
>> Any ideas what I am (or perf is) doing wrong?
>>
>
> I Think your Perf test is failing at dso__find_symbol_by_name
> where in perf test we have something like:
>
> kallsyms_map = machine__kernel_map(, type);
>
> sym = map__find_symbol_by_name(kallsyms_map, ref_reloc_sym.name, 
> NULL);
> if (sym == NULL) {
> pr_debug("dso__find_symbol_by_name ");
> goto out;
> }
>
> Here sym is search for "_stext" which is NULL here so perf test fails here 
> only,

Hi Prabhat -

> Here _stext having same address as some other, like
>
> c00081c0 T asm_do_IRQ
> c00081c0 T _stext
> c00081c0 T __exception_text_start
>
> Function call is like this:
> machine__load_kallsyms
> --> dso__load_kallsyms
> --> symbols__fixup_duplicate
>
> So, it getting deleted, I think we should disable symbols__fixup_duplicate.

That does indeed work around the first problem, thanks.

It succeeds to find _stext and then tries to load the vmlinux.

 1: vmlinux symtab matches kallsyms:trying
/root/.debug/.build-id/47/93c412145cb348574991bf4075995805175367
failed in symsrc__init
trying vmlinux
failed in symsrc__init
trying /boot/vmlinux
failed in symsrc__init
trying /boot/vmlinux-3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+
failed in symsrc__init
trying /lib/modules/3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+/build/vmlinux
failed in symsrc__init
trying 
/usr/lib/debug/lib/modules/3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+/vmlinux
do_load_sym result 0
 Skip

Actually I put the correct vmlinux in the last place,
/usr/lib/debug/...  it's able to find it but do_load_sym is returning
0, which is taken as fail, because it's unable to confirm the vintage
of the vmlinux is correct for the running kernel.

As a side note I also copied ./lib, ./tools and ./include to the
target and built perf there.  The results are the same.

# perf test
 1: vmlinux symtab matches kallsyms:trying
/root/.debug/.build-id/47/93c412145cb348574991bf4075995805175367
failed in symsrc__init
trying vmlinux
failed in symsrc__init
trying /boot/vmlinux
failed in symsrc__init
trying /boot/vmlinux-3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+
failed in symsrc__init
trying /lib/modules/3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+/build/vmlinux
failed in symsrc__init
trying 
/usr/lib/debug/lib/modules/3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+/vmlinux
do_load_sym result 0
 Skip
 2: detect open syscall event  : Ok
 3: detect open syscall event on all cpus  : Ok
 4: read samples using the mmap interface  : Ok
 5: parse events tests :  Warning:
function sizeof not defined
  Warning: function sizeof not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function jiffies_to_msecs not defined
  Warning: function jiffies_to_msecs not defined
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: Error: expected type 4 but read 0
  Warning: bad op token {
  Warning: Error: expected type 4 but read 0
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: unknown op '{'
  Warning: unknown op '{'
 Ok
 6: Validate PERF_RECORD_* events & perf_sample fields : FAILED!
 7: Test perf pmu format parsing   : Ok
 8: Test dso data interface: Ok
 9: roundtrip evsel->name check: Ok
10: Check parsing of sched tracepoints fields  : FAILED!
11: Generate and check syscalls:sys_enter_open event fields: Ok
12: struct perf_event_attr setup   : (omitted) Ok
13: Test matching and linking mutliple hists   : Ok
14: Try 'use perf' in python, checking link problems   : FAILED!
15:

Re: 3.10-rc6 perf test seems unhappy

[Andy Green]

On 26 June 2013 21:39, Prabhat Kumar Ravi prabhatrav...@gmail.com wrote:
 Hi,

 On Wed, Jun 26, 2013 at 4:39 PM, Andy Green andy.gr...@linaro.org wrote:
 Hi -

 Running perf test on 3.10-rc6 gives some unexpected behaviours.

 This is on a dual Cortex A9 board with perf userland cross-built from
 same tree as the kernel.

 root@aa9-eb:~# perf test
  1: vmlinux symtab matches kallsyms: FAILED!

 I started tracing the first failure... it stops because it can't find
 _stext in /proc/kallsyms.  But it is there

 root@aa9-eb:~# cat /proc/kallsyms | grep _stext
 800081c0 T _stext



 The others may be due to missing some config somewhere.

 Any ideas what I am (or perf is) doing wrong?


 I Think your Perf test is failing at dso__find_symbol_by_name
 where in perf test we have something like:

 kallsyms_map = machine__kernel_map(kallsyms, type);

 sym = map__find_symbol_by_name(kallsyms_map, ref_reloc_sym.name, 
 NULL);
 if (sym == NULL) {
 pr_debug(dso__find_symbol_by_name );
 goto out;
 }

 Here sym is search for _stext which is NULL here so perf test fails here 
 only,

Hi Prabhat -

 Here _stext having same address as some other, like

 c00081c0 T asm_do_IRQ
 c00081c0 T _stext
 c00081c0 T __exception_text_start

 Function call is like this:
 machine__load_kallsyms
 -- dso__load_kallsyms
 -- symbols__fixup_duplicate

 So, it getting deleted, I think we should disable symbols__fixup_duplicate.

That does indeed work around the first problem, thanks.

It succeeds to find _stext and then tries to load the vmlinux.

 1: vmlinux symtab matches kallsyms:trying
/root/.debug/.build-id/47/93c412145cb348574991bf4075995805175367
failed in symsrc__init
trying vmlinux
failed in symsrc__init
trying /boot/vmlinux
failed in symsrc__init
trying /boot/vmlinux-3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+
failed in symsrc__init
trying /lib/modules/3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+/build/vmlinux
failed in symsrc__init
trying 
/usr/lib/debug/lib/modules/3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+/vmlinux
do_load_sym result 0
 Skip

Actually I put the correct vmlinux in the last place,
/usr/lib/debug/...  it's able to find it but do_load_sym is returning
0, which is taken as fail, because it's unable to confirm the vintage
of the vmlinux is correct for the running kernel.

As a side note I also copied ./lib, ./tools and ./include to the
target and built perf there.  The results are the same.

# perf test
 1: vmlinux symtab matches kallsyms:trying
/root/.debug/.build-id/47/93c412145cb348574991bf4075995805175367
failed in symsrc__init
trying vmlinux
failed in symsrc__init
trying /boot/vmlinux
failed in symsrc__init
trying /boot/vmlinux-3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+
failed in symsrc__init
trying /lib/modules/3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+/build/vmlinux
failed in symsrc__init
trying 
/usr/lib/debug/lib/modules/3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+/vmlinux
do_load_sym result 0
 Skip
 2: detect open syscall event  : Ok
 3: detect open syscall event on all cpus  : Ok
 4: read samples using the mmap interface  : Ok
 5: parse events tests :  Warning:
function sizeof not defined
  Warning: function sizeof not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function jiffies_to_msecs not defined
  Warning: function jiffies_to_msecs not defined
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: Error: expected type 4 but read 0
  Warning: bad op token {
  Warning: Error: expected type 4 but read 0
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: unknown op '{'
  Warning: unknown op '{'
 Ok
 6: Validate PERF_RECORD_* events  perf_sample fields : FAILED!
 7: Test perf pmu format parsing   : Ok
 8: Test dso data interface: Ok
 9: roundtrip evsel-name check: Ok
10: Check parsing of sched tracepoints fields  : FAILED!
11: Generate and check syscalls:sys_enter_open event fields: Ok
12: struct perf_event_attr setup   : (omitted) Ok
13: Test matching and linking mutliple hists   : Ok
14: Try 'use perf' in python, checking link problems   : FAILED!
15: Test breakpoint overflow signal handler: FAILED!
16: Test breakpoint overflow sampling  : FAILED!
17: Test number of exit event of a simple workload : FAILED!
18: Test software clock events have valid period values: Ok

-Andy
--
To unsubscribe

3.10-rc6 "perf test" seems unhappy

[Andy Green]

Hi -

Running perf test on 3.10-rc6 gives some unexpected behaviours.

This is on a dual Cortex A9 board with perf userland cross-built from
same tree as the kernel.

root@aa9-eb:~# perf test
 1: vmlinux symtab matches kallsyms: FAILED!
 2: detect open syscall event  : Ok
 3: detect open syscall event on all cpus  : Ok
 4: read samples using the mmap interface  : Ok
 5: parse events tests :  Warning:
function sizeof not defined
  Warning: function sizeof not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function jiffies_to_msecs not defined
  Warning: function jiffies_to_msecs not defined
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: Error: expected type 4 but read 0
  Warning: bad op token {
  Warning: Error: expected type 4 but read 0
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: unknown op '{'
  Warning: unknown op '{'
 Ok
 6: Validate PERF_RECORD_* events & perf_sample fields : FAILED!
 7: Test perf pmu format parsing   : Ok
 8: Test dso data interface: Ok
 9: roundtrip evsel->name check: Ok
10: Check parsing of sched tracepoints fields  : FAILED!
11: Generate and check syscalls:sys_enter_open event fields: Ok
12: struct perf_event_attr setup   : (omitted) Ok
13: Test matching and linking mutliple hists   : Ok
14: Try 'use perf' in python, checking link problems   : FAILED!
15: Test breakpoint overflow signal handler: FAILED!
16: Test breakpoint overflow sampling  : FAILED!
17: Test number of exit event of a simple workload : FAILED!
18: Test software clock events have valid period values: Ok


I started tracing the first failure... it stops because it can't find
"_stext" in /proc/kallsyms.  But it is there

root@aa9-eb:~# cat /proc/kallsyms | grep _stext
800081c0 T _stext

test 5 (parse event tests) seems to be badly broken.

The others may be due to missing some config somewhere.

Any ideas what I am (or perf is) doing wrong?

-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

3.10-rc6 perf test seems unhappy

[Andy Green]

Hi -

Running perf test on 3.10-rc6 gives some unexpected behaviours.

This is on a dual Cortex A9 board with perf userland cross-built from
same tree as the kernel.

root@aa9-eb:~# perf test
 1: vmlinux symtab matches kallsyms: FAILED!
 2: detect open syscall event  : Ok
 3: detect open syscall event on all cpus  : Ok
 4: read samples using the mmap interface  : Ok
 5: parse events tests :  Warning:
function sizeof not defined
  Warning: function sizeof not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function jiffies_to_msecs not defined
  Warning: function jiffies_to_msecs not defined
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: Error: expected type 4 but read 0
  Warning: bad op token {
  Warning: Error: expected type 4 but read 0
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: unknown op '{'
  Warning: unknown op '{'
 Ok
 6: Validate PERF_RECORD_* events  perf_sample fields : FAILED!
 7: Test perf pmu format parsing   : Ok
 8: Test dso data interface: Ok
 9: roundtrip evsel-name check: Ok
10: Check parsing of sched tracepoints fields  : FAILED!
11: Generate and check syscalls:sys_enter_open event fields: Ok
12: struct perf_event_attr setup   : (omitted) Ok
13: Test matching and linking mutliple hists   : Ok
14: Try 'use perf' in python, checking link problems   : FAILED!
15: Test breakpoint overflow signal handler: FAILED!
16: Test breakpoint overflow sampling  : FAILED!
17: Test number of exit event of a simple workload : FAILED!
18: Test software clock events have valid period values: Ok


I started tracing the first failure... it stops because it can't find
_stext in /proc/kallsyms.  But it is there

root@aa9-eb:~# cat /proc/kallsyms | grep _stext
800081c0 T _stext

test 5 (parse event tests) seems to be badly broken.

The others may be due to missing some config somewhere.

Any ideas what I am (or perf is) doing wrong?

-Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 00/14] drivers: mailbox: framework creation

[Andy Green]

On 27/04/13 09:04, the mail apparently from Suman Anna included:

Hi Suman -


Even though both the scenarios look very similar, I believe there are
some slight differences. All the devices belonging to a controller may
not be of the same type (meaning, intended towards the same remote or be
used interchangeably with one another). It is definitely possible if you
have a similar scenario to the DMA physical channels and your remote
rx interrupt can identify the device/channel to process. This would be
very much dependent on the architecture of a controller. The particular
example that I have in mind is s/w clients between the same set of
remote and host entities using the same device - the send part is anyway
arbitrated by the controller, and the same received message can be
delivered to the clients, with the clients making the decision whether
the packet belongs to them or not. I agree that all remote-ends will not
be able to cope up intermixed requests, but isn't this again a
controller architecture dependent?


Maybe it's helpful to describe our situation more concretely, because 
the problem is not coming from "the architecture of the [mailbox] 
controller".


In the SoC we work on clock and subsystem power control registers, a 
serial bus, and some other assets are not directly accessible from 
Linux.  We must ask a coprocessor to operate these for us, using the 
mailbox.


So at any one time, the clock driver or voltagedomain driver for the SoC 
may want to own the mailbox and perform one or more operations over it 
synchronously, in some cases on the remote side involving transactions 
on a serial bus.  We don't want other transactions to be occurring while 
we wait for the serial bus to complete what the driver who started that 
asked for, for example.


We can cope with this by having an outer driver mediate access to the 
mailbox.  But then there are multiple sync primitives like completions 
and notifiers per operation, because your core already does this.


In short the FIFO + sync operations approach your core implements 
doesn't fit our use case.  That can be our problem, in which case we'll 
live with the outer mediation driver on top of the mailbox, or it can be 
a sign the fixed choice of FIFO + sync operations in your core did not 
quite hit the nail on the head to really model all the facets of legit 
mailbox usage.


At least, this real scenario should be interesting to think about before 
rejecting ^^


-Andy

--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 00/14] drivers: mailbox: framework creation

[Andy Green]

On 27/04/13 09:04, the mail apparently from Suman Anna included:

Hi Suman -


Even though both the scenarios look very similar, I believe there are
some slight differences. All the devices belonging to a controller may
not be of the same type (meaning, intended towards the same remote or be
used interchangeably with one another). It is definitely possible if you
have a similar scenario to the DMA physical channels and your remote
rx interrupt can identify the device/channel to process. This would be
very much dependent on the architecture of a controller. The particular
example that I have in mind is s/w clients between the same set of
remote and host entities using the same device - the send part is anyway
arbitrated by the controller, and the same received message can be
delivered to the clients, with the clients making the decision whether
the packet belongs to them or not. I agree that all remote-ends will not
be able to cope up intermixed requests, but isn't this again a
controller architecture dependent?


Maybe it's helpful to describe our situation more concretely, because 
the problem is not coming from the architecture of the [mailbox] 
controller.


In the SoC we work on clock and subsystem power control registers, a 
serial bus, and some other assets are not directly accessible from 
Linux.  We must ask a coprocessor to operate these for us, using the 
mailbox.


So at any one time, the clock driver or voltagedomain driver for the SoC 
may want to own the mailbox and perform one or more operations over it 
synchronously, in some cases on the remote side involving transactions 
on a serial bus.  We don't want other transactions to be occurring while 
we wait for the serial bus to complete what the driver who started that 
asked for, for example.


We can cope with this by having an outer driver mediate access to the 
mailbox.  But then there are multiple sync primitives like completions 
and notifiers per operation, because your core already does this.


In short the FIFO + sync operations approach your core implements 
doesn't fit our use case.  That can be our problem, in which case we'll 
live with the outer mediation driver on top of the mailbox, or it can be 
a sign the fixed choice of FIFO + sync operations in your core did not 
quite hit the nail on the head to really model all the facets of legit 
mailbox usage.


At least, this real scenario should be interesting to think about before 
rejecting ^^


-Andy

--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 00/14] drivers: mailbox: framework creation

[Andy Green]

On 26/04/13 06:29, the mail apparently from Suman Anna included:

Hi -


3. Shareable/exclusive nature of a mailbox. If it is shareable, then
duplicating the behavior between clients is not worth it, and this
should be absorbed into the respective controller driver.


I think the mailbox should be exclusively held by a client. That makes
many things simpler. Also remote firmwares won't be always robust
enough to handle commands from different subsystems intermixed. The
API only has to make sure the mailbox_get/put operations are very
thin.


This might be the case for specific remotes where we expect only one
client driver to be responsible for talking to it, but for generic
offloading, you do not want to have this restriction. You do not want
peer clients to go through a single main client, as the latencies or the
infrastructure imposed by the main client may not be suitable for the
other clients. The stricter usecase here would be the shareable mailbox,
and if it is exclusive, as dictated by a controller or device property,
then so be it and things would get simplified for that controller/device.


Knowing why Jassi mentioned this, the situation is a bit different than 
what you replied to.  There are in fact multiple client drivers that can 
asynchronously decide to initiate communication on the same mailbox. 
Some of the client need to perform multi-step sequencing and lock the 
mailbox for the duration.


Right now we can implement that by having a driver on top to mediate, 
Jassi is suggesting being able to do the client locking at your layer as 
a primitive will simplify things, not least get rid of the mediation 
driver.  Your layer has concept of completion and notifier already so it 
seems it wouldn't take much more.


-Andy

--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 00/14] drivers: mailbox: framework creation

[Andy Green]

On 26/04/13 06:29, the mail apparently from Suman Anna included:

Hi -


3. Shareable/exclusive nature of a mailbox. If it is shareable, then
duplicating the behavior between clients is not worth it, and this
should be absorbed into the respective controller driver.


I think the mailbox should be exclusively held by a client. That makes
many things simpler. Also remote firmwares won't be always robust
enough to handle commands from different subsystems intermixed. The
API only has to make sure the mailbox_get/put operations are very
thin.


This might be the case for specific remotes where we expect only one
client driver to be responsible for talking to it, but for generic
offloading, you do not want to have this restriction. You do not want
peer clients to go through a single main client, as the latencies or the
infrastructure imposed by the main client may not be suitable for the
other clients. The stricter usecase here would be the shareable mailbox,
and if it is exclusive, as dictated by a controller or device property,
then so be it and things would get simplified for that controller/device.


Knowing why Jassi mentioned this, the situation is a bit different than 
what you replied to.  There are in fact multiple client drivers that can 
asynchronously decide to initiate communication on the same mailbox. 
Some of the client need to perform multi-step sequencing and lock the 
mailbox for the duration.


Right now we can implement that by having a driver on top to mediate, 
Jassi is suggesting being able to do the client locking at your layer as 
a primitive will simplify things, not least get rid of the mediation 
driver.  Your layer has concept of completion and notifier already so it 
seems it wouldn't take much more.


-Andy

--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 00/14] drivers: mailbox: framework creation

[Andy Green]

On 24/04/13 03:20, the mail apparently from Anna, Suman included:

Hi Suman -


This series missed the 3.9 merge window, and is currently slated for
getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't
aware of it until I saw it in mainline) and created the
drivers/mailbox folder.  I would think it would be relatively
straight-forward to adopt it to the mailbox API, as it has only 3
API. We should be doing incremental changes on top of this series, as
most of the base API would still be the same. The current series is
helping out with couple of efforts, the breaking up of the PRCMU code
and on the multiplatform support for OMAP with mailbox enabled. We
can definitely collaborate on the improvements. Andy Green would also
be interested, as he is also looking into adopting the mailbox API.


To clarify Jassi works on my team, after I wrote two Mailbox drivers for 
two different IP on the chips we're working on, I handed them off to him 
and Jassi's working on further integration using those drivers.  So 
we're both doing the same thing.


From my POV I am very happy you made the new API - before that there 
was only PL320 sitting there and nothing you could call an API.  Once I 
understood the approach (no docs was a bit painful) I was able to 
implement both drivers we needed with what you have.


The main problem I have with it we discussed in direct mail previously, 
since we have two different mailbox IP, we need to improve the register 
/ unregister so it can cope, right now it's unnecessarily limited to one 
mailbox driver.


That "there can only be one" approach also leaked out into the drivers 
having filescope statics for things that should have been instantiated 
per-mailbox device (including device naming as literals, rather than 
mbox%d needed if there can be multiple drivers).  In my driver 
implementations I moved them to live in the per-device priv struct and 
stored the names in there too.


The other point I mentioned before was the FIFO, it's always there and 
size set by CONFIG_ stuff.  Actually it would be better if it was set 
per mailbox or per mailbox driver at runtime.  For one of the IPs, we 
will have another driver mediating access to the mailbox that enforces a 
single client access covering possibly multiple mailbox messages.  Under 
those conditions, a fifo isn't really meaningful.  But that's less of a 
problem.


As I say I was very happy to see you addressing the lack of an API, 
Jassi though is working deeper with it than just making the mailbox 
drivers as I did; he's using the API from other consumer drivers so he 
may have a different set of concerns or, looking at what he's written 
here, opportunities.


-Andy

--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 00/14] drivers: mailbox: framework creation

[Andy Green]

On 24/04/13 03:20, the mail apparently from Anna, Suman included:

Hi Suman -


This series missed the 3.9 merge window, and is currently slated for
getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't
aware of it until I saw it in mainline) and created the
drivers/mailbox folder.  I would think it would be relatively
straight-forward to adopt it to the mailbox API, as it has only 3
API. We should be doing incremental changes on top of this series, as
most of the base API would still be the same. The current series is
helping out with couple of efforts, the breaking up of the PRCMU code
and on the multiplatform support for OMAP with mailbox enabled. We
can definitely collaborate on the improvements. Andy Green would also
be interested, as he is also looking into adopting the mailbox API.


To clarify Jassi works on my team, after I wrote two Mailbox drivers for 
two different IP on the chips we're working on, I handed them off to him 
and Jassi's working on further integration using those drivers.  So 
we're both doing the same thing.


From my POV I am very happy you made the new API - before that there 
was only PL320 sitting there and nothing you could call an API.  Once I 
understood the approach (no docs was a bit painful) I was able to 
implement both drivers we needed with what you have.


The main problem I have with it we discussed in direct mail previously, 
since we have two different mailbox IP, we need to improve the register 
/ unregister so it can cope, right now it's unnecessarily limited to one 
mailbox driver.


That there can only be one approach also leaked out into the drivers 
having filescope statics for things that should have been instantiated 
per-mailbox device (including device naming as literals, rather than 
mbox%d needed if there can be multiple drivers).  In my driver 
implementations I moved them to live in the per-device priv struct and 
stored the names in there too.


The other point I mentioned before was the FIFO, it's always there and 
size set by CONFIG_ stuff.  Actually it would be better if it was set 
per mailbox or per mailbox driver at runtime.  For one of the IPs, we 
will have another driver mediating access to the mailbox that enforces a 
single client access covering possibly multiple mailbox messages.  Under 
those conditions, a fifo isn't really meaningful.  But that's less of a 
problem.


As I say I was very happy to see you addressing the lack of an API, 
Jassi though is working deeper with it than just making the mailbox 
drivers as I did; he's using the API from other consumer drivers so he 
may have a different set of concerns or, looking at what he's written 
here, opportunities.


-Andy

--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Energy/power monitoring within the kernel

[Andy Green]

ample DDR power and 
rails involved with other IP units on the SoC such as 3D graphics unit. 
 So tying one number to specifically a CPU core does not sound like 
it's enough.



=== Option 2: hwmon perf PMU ===

Although the trace event makes it possible to obtain interesting
information using perf, the user wouldn't be able to treat the
energy meter as a normal data source. In particular there would
be no way of creating a group of events consisting eg. of a
"normal" leader (eg. cache miss event) triggering energy meter
read. The only way to get this done is to implement a perf PMU
backend providing "environmental data" to the user.


In terms of like perf top don't think it'll be possible to know when to 
sample the acquisition hardware to tie the result to a particular line 
of code, even if it had the bandwidth to do that.  Power readings are 
likely to lag activities on the cpu somewhat, considering sub-ns core 
clocks, especially if it's actually measuring the input side of a regulator.



= High-level hwmon API and PMU =

Current hwmon subsystem does not provide any abstraction for the
measured values and requires particular drivers to create specified
sysfs attributes than used by userspace libsensors. This makes
the framework ultimately flexible and ultimately hard to access
from within the kernel...

What could be done here is some (simple) API to register the
measured values with the hwmon core which would result in creating
equivalent sysfs attributes automagically, but also allow a
in-kernel API for values enumeration and access. That way the core
could also register a "hwmon PMU" with the perf framework providing
data from all "compliant" drivers.

= A driver-specific PMU =

Of course a particular driver could register its own perf PMU on its
own. It's certainly an option, just very suboptimal in my opinion.
Or maybe not? Maybe the task is so specialized that it makes sense?



=== Option 3: CPU power(energy) monitoring framework ===

And last but not least, maybe the problem deserves some dedicated
API? Something that would take providers and feed their data into
interested parties, in particular a perf PMU implementation and
cpufreq governors?

Maybe it could be an extension to the thermal framework? It already
gives some meaning to a physical phenomena. Adding other, related ones
like energy, and relating it to cpu cores could make some sense.


If you turn the problem upside down to solve the representation question 
first, maybe there's a way forward defining the "power tree" in terms of 
regulators, and then adding something in struct regulator that spams 
readers with timestamped results if the regulator has a power monitoring 
capability.


Then you can map the regulators in the power tree to real devices by the 
names or the supply stuff.  Just a thought.


-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Energy/power monitoring within the kernel

[Andy Green]

 ===

Although the trace event makes it possible to obtain interesting
information using perf, the user wouldn't be able to treat the
energy meter as a normal data source. In particular there would
be no way of creating a group of events consisting eg. of a
normal leader (eg. cache miss event) triggering energy meter
read. The only way to get this done is to implement a perf PMU
backend providing environmental data to the user.


In terms of like perf top don't think it'll be possible to know when to 
sample the acquisition hardware to tie the result to a particular line 
of code, even if it had the bandwidth to do that.  Power readings are 
likely to lag activities on the cpu somewhat, considering sub-ns core 
clocks, especially if it's actually measuring the input side of a regulator.



= High-level hwmon API and PMU =

Current hwmon subsystem does not provide any abstraction for the
measured values and requires particular drivers to create specified
sysfs attributes than used by userspace libsensors. This makes
the framework ultimately flexible and ultimately hard to access
from within the kernel...

What could be done here is some (simple) API to register the
measured values with the hwmon core which would result in creating
equivalent sysfs attributes automagically, but also allow a
in-kernel API for values enumeration and access. That way the core
could also register a hwmon PMU with the perf framework providing
data from all compliant drivers.

= A driver-specific PMU =

Of course a particular driver could register its own perf PMU on its
own. It's certainly an option, just very suboptimal in my opinion.
Or maybe not? Maybe the task is so specialized that it makes sense?



=== Option 3: CPU power(energy) monitoring framework ===

And last but not least, maybe the problem deserves some dedicated
API? Something that would take providers and feed their data into
interested parties, in particular a perf PMU implementation and
cpufreq governors?

Maybe it could be an extension to the thermal framework? It already
gives some meaning to a physical phenomena. Adding other, related ones
like energy, and relating it to cpu cores could make some sense.


If you turn the problem upside down to solve the representation question 
first, maybe there's a way forward defining the power tree in terms of 
regulators, and then adding something in struct regulator that spams 
readers with timestamped results if the regulator has a power monitoring 
capability.


Then you can map the regulators in the power tree to real devices by the 
names or the supply stuff.  Just a thought.


-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Andy Green (林安廸)]

On 10/07/12 20:37, the mail apparently from Florian Fainelli included:

Hi -


Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit :

The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet taking care of accepting device path / MAC mapping
registrations and running a notifier to enforce the requested MAC when the
matching network device turns up.


This looks like something you can solve by user-space entirely. Expose the


That might seem so from a openwrt perspective, where you custom cook the 
whole userland thing per-device, but it ain't so from a generic rootfs 
perspective.


Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
workarounds?  And Panda is not the only device with this issue.


-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Andy Green (林安廸)]

On 10/07/12 20:37, the mail apparently from Florian Fainelli included:

Hi -


Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit :

The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet taking care of accepting device path / MAC mapping
registrations and running a notifier to enforce the requested MAC when the
matching network device turns up.


This looks like something you can solve by user-space entirely. Expose the


That might seem so from a openwrt perspective, where you custom cook the 
whole userland thing per-device, but it ain't so from a generic rootfs 
perspective.


Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
workarounds?  And Panda is not the only device with this issue.


-Andy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] scripts/basic/fixdep segfault on pathological string-o-death

[Andy Green]

build scripts: fixdep blows segfault on string CONFIG_MODULE seen

The string "CONFIG_MODULE" appearing anywhere in a source file causes
fixdep to segfault.  This string appeared in the wild in the current
mISDN sources (I think they meant CONFIG_MODULES).  But it shouldn't
segfault (esp as CONFIG_MODULE appeared in a quoted string).

Signed-off-by: Andy Green <[EMAIL PROTECTED]>
---
 scripts/basic/fixdep.c |2 ++
 1 file changed, 2 insertions(+)

Index: 2.6.21-1.3116.fc7-i686/scripts/basic/fixdep.c
===
--- 2.6.21-1.3116.fc7-i686.orig/scripts/basic/fixdep.c
+++ 2.6.21-1.3116.fc7-i686/scripts/basic/fixdep.c
@@ -249,6 +249,8 @@ void parse_config_file(char *map, size_t
found:
if (!memcmp(q - 7, "_MODULE", 7))
q -= 7;
+   if( (q-p-7) < 0 )
+   continue;
use_config(p+7, q-p-7);
}
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] scripts/basic/fixdep segfault on pathological string-o-death

[Andy Green]

build scripts: fixdep blows segfault on string CONFIG_MODULE seen

The string CONFIG_MODULE appearing anywhere in a source file causes
fixdep to segfault.  This string appeared in the wild in the current
mISDN sources (I think they meant CONFIG_MODULES).  But it shouldn't
segfault (esp as CONFIG_MODULE appeared in a quoted string).

Signed-off-by: Andy Green [EMAIL PROTECTED]
---
 scripts/basic/fixdep.c |2 ++
 1 file changed, 2 insertions(+)

Index: 2.6.21-1.3116.fc7-i686/scripts/basic/fixdep.c
===
--- 2.6.21-1.3116.fc7-i686.orig/scripts/basic/fixdep.c
+++ 2.6.21-1.3116.fc7-i686/scripts/basic/fixdep.c
@@ -249,6 +249,8 @@ void parse_config_file(char *map, size_t
found:
if (!memcmp(q - 7, _MODULE, 7))
q -= 7;
+   if( (q-p-7)  0 )
+   continue;
use_config(p+7, q-p-7);
}
 }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/