Re: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit

[Arnd Bergmann]

On Wednesday 09 December 2015 10:18:09 Peter Ujfalusi wrote:
> Hi,
> 
> Based on the discussion regarding to (convert am33xx to use the new eDMA
> bindings):
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> 
> This two patch will convert the new eDMA binding to not use 16bit arrays for
> memcpy channel selection and for marking slots reserved.
> The '/bits/ 16' seams to be causing confusion so it is probably better to just
> use standard type for the arrays.
> 
> The new bindings for the eDMA is introduced for 4.4 and we do not have users 
> of
> it, which means that we can still change it w/o the risk of breaking anything
> and we do not need to maintain the compatibility with 16bit arrays.
> 
> The changes in the eDMA driver is local to the DT parsing and should not
> conflict with other changes (like the filter function mapping support). Hrm,
> there might be trivial conflict in the include/linux/platform_data/edma.h with
> the "dmaengine 'universal' API".

Both patches

Acked-by: Arnd Bergmann 

> Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches 
> are
> going to be handled? I would like to send the updated am33xx/am437x conversion
> for 4.5 based on these changes.

I'd suggest you send a pull request with these two patches on top of 4.4-rc1,
and then either Vinod or I send it to Linus, and you base your other changes
on top of the same branch.

I think Vinod's tree is slightly more fitting for the 4.4 merge, but if he
prefers me to take them instead, I will.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for 4.4 1/2] dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type

[Peter Ujfalusi]

This change makes the DT file to be easier to read since the memcpy
channels array does not need the '/bits/ 16' to be specified, which might
confuse some people.

Signed-off-by: Peter Ujfalusi 
---
 Documentation/devicetree/bindings/dma/ti-edma.txt |  5 ++---
 drivers/dma/edma.c| 22 ++
 include/linux/platform_data/edma.h|  2 +-
 3 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index d3d0a4fb1c73..ae8b8f1d6e69 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -22,8 +22,7 @@ Required properties:
 Optional properties:
 - ti,hwmods:   Name of the hwmods associated to the eDMA CC
 - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, 
iow
-   these channels will be SW triggered channels. The list must
-   contain 16 bits numbers, see example.
+   these channels will be SW triggered channels. See example.
 - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
the driver, they are allocated to be used by for example the
DSP. See example.
@@ -56,7 +55,7 @@ edma: edma@4900 {
ti,tptcs = <_tptc0 7>, <_tptc1 7>, <_tptc2 0>;
 
/* Channel 20 and 21 is allocated for memcpy */
-   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+   ti,edma-memcpy-channels = <20 21>;
/* The following PaRAM slots are reserved: 35-45 and 100-110 */
ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
   /bits/ 16 <100 10>;
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2af8f32bba0b..89fc17f3a6ff 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1752,16 +1752,14 @@ static enum dma_status edma_tx_status(struct dma_chan 
*chan,
return ret;
 }
 
-static bool edma_is_memcpy_channel(int ch_num, u16 *memcpy_channels)
+static bool edma_is_memcpy_channel(int ch_num, s32 *memcpy_channels)
 {
-   s16 *memcpy_ch = memcpy_channels;
-
if (!memcpy_channels)
return false;
-   while (*memcpy_ch != -1) {
-   if (*memcpy_ch == ch_num)
+   while (*memcpy_channels != -1) {
+   if (*memcpy_channels == ch_num)
return true;
-   memcpy_ch++;
+   memcpy_channels++;
}
return false;
 }
@@ -1775,7 +1773,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool 
legacy_mode)
 {
struct dma_device *s_ddev = >dma_slave;
struct dma_device *m_ddev = NULL;
-   s16 *memcpy_channels = ecc->info->memcpy_channels;
+   s32 *memcpy_channels = ecc->info->memcpy_channels;
int i, j;
 
dma_cap_zero(s_ddev->cap_mask);
@@ -1996,16 +1994,16 @@ static struct edma_soc_info 
*edma_setup_info_from_dt(struct device *dev,
prop = of_find_property(dev->of_node, "ti,edma-memcpy-channels", );
if (prop) {
const char pname[] = "ti,edma-memcpy-channels";
-   size_t nelm = sz / sizeof(s16);
-   s16 *memcpy_ch;
+   size_t nelm = sz / sizeof(s32);
+   s32 *memcpy_ch;
 
-   memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s16),
+   memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s32),
 GFP_KERNEL);
if (!memcpy_ch)
return ERR_PTR(-ENOMEM);
 
-   ret = of_property_read_u16_array(dev->of_node, pname,
-(u16 *)memcpy_ch, nelm);
+   ret = of_property_read_u32_array(dev->of_node, pname,
+(u32 *)memcpy_ch, nelm);
if (ret)
return ERR_PTR(ret);
 
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index 105700e62ea1..0a533f94438f 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -76,7 +76,7 @@ struct edma_soc_info {
struct edma_rsv_info*rsv;
 
/* List of channels allocated for memcpy, terminated with -1 */
-   s16 *memcpy_channels;
+   s32 *memcpy_channels;
 
s8  (*queue_priority_mapping)[2];
const s16   (*xbar_chans)[2];
-- 
2.6.3

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

[PATCH for 4.4 2/2] dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type

[Peter Ujfalusi]

This change makes the DT file to be easier to read since the reserved slots
array does not need the '/bits/ 16' to be specified, which might confuse
some people.

Signed-off-by: Peter Ujfalusi 
---
 Documentation/devicetree/bindings/dma/ti-edma.txt |  5 ++--
 drivers/dma/edma.c| 31 ++-
 2 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index ae8b8f1d6e69..079b42a81d7c 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -56,9 +56,8 @@ edma: edma@4900 {
 
/* Channel 20 and 21 is allocated for memcpy */
ti,edma-memcpy-channels = <20 21>;
-   /* The following PaRAM slots are reserved: 35-45 and 100-110 */
-   ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
-  /bits/ 16 <100 10>;
+   /* The following PaRAM slots are reserved: 35-44 and 100-109 */
+   ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
 };
 
 edma_tptc0: tptc@4980 {
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 89fc17f3a6ff..a0f217349c07 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2015,31 +2015,50 @@ static struct edma_soc_info 
*edma_setup_info_from_dt(struct device *dev,
);
if (prop) {
const char pname[] = "ti,edma-reserved-slot-ranges";
+   u32 (*tmp)[2];
s16 (*rsv_slots)[2];
-   size_t nelm = sz / sizeof(*rsv_slots);
+   size_t nelm = sz / sizeof(*tmp);
struct edma_rsv_info *rsv_info;
+   int i;
 
if (!nelm)
return info;
 
+   tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
+   if (!tmp)
+   return ERR_PTR(-ENOMEM);
+
rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
-   if (!rsv_info)
+   if (!rsv_info) {
+   kfree(tmp);
return ERR_PTR(-ENOMEM);
+   }
 
rsv_slots = devm_kcalloc(dev, nelm + 1, sizeof(*rsv_slots),
 GFP_KERNEL);
-   if (!rsv_slots)
+   if (!rsv_slots) {
+   kfree(tmp);
return ERR_PTR(-ENOMEM);
+   }
 
-   ret = of_property_read_u16_array(dev->of_node, pname,
-(u16 *)rsv_slots, nelm * 2);
-   if (ret)
+   ret = of_property_read_u32_array(dev->of_node, pname,
+(u32 *)tmp, nelm * 2);
+   if (ret) {
+   kfree(tmp);
return ERR_PTR(ret);
+   }
 
+   for (i = 0; i < nelm; i++) {
+   rsv_slots[i][0] = tmp[i][0];
+   rsv_slots[i][1] = tmp[i][1];
+   }
rsv_slots[nelm][0] = -1;
rsv_slots[nelm][1] = -1;
+
info->rsv = rsv_info;
info->rsv->rsv_slots = (const s16 (*)[2])rsv_slots;
+
+   kfree(tmp);
}
 
return info;
-- 
2.6.3

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

Re: [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

[Tomi Valkeinen]

On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> Otherwise check_timings fails and we get a "has no modes" message
> from xrandr.
> 
> This fix makes the venc assume PAL and NTSC timings that match the
> timings synthetized by copy_timings_drm_to_omap() from omapdrm
> mode settings so that check_timings() succeeds.
> 
> Tested on: BeagleBoard XM, GTA04 and OpenPandora
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  drivers/video/fbdev/omap2/dss/venc.c | 12 
>  1 file changed, 12 insertions(+)

I've picked this up.

With this patch and the one below I can get tv-out working on my very old
beagleboard, and it seems to work with X also. It doesn't start automatically
as the connection state is unknown, but doing "xrandr --output None-1 --auto"
was all I needed to enable it.

 Tomi

From a4274600a5a67256b91266b0d2624b9c9028909b Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Tue, 8 Dec 2015 18:32:14 +0200
Subject: [PATCH] drm/omap: fix fbdev pix format to support all platforms

omap_fbdev always creates a framebuffer with ARGB pixel format. On
OMAP3 we have VIDEO1 overlay that does not support ARGB, and on
OMAP2 none of the overlays support ARGB888.

This patch changes the omap_fbdev's fb to XRGB, which is supported
by all platforms.

Signed-off-by: Tomi Valkeinen 

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b8e4cdec28c3..24f92bea39c7 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -112,11 +112,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
dma_addr_t paddr;
int ret;
 
-   /* only doing ARGB32 since this is what is needed to alpha-blend
-* with video overlays:
-*/
sizes->surface_bpp = 32;
-   sizes->surface_depth = 32;
+   sizes->surface_depth = 24;
 
DBG("create fbdev: %dx%d@%d (%dx%d)", sizes->surface_width,
sizes->surface_height, sizes->surface_bpp,



signature.asc
Description: OpenPGP digital signature

[PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit

[Peter Ujfalusi]

Hi,

Based on the discussion regarding to (convert am33xx to use the new eDMA
bindings):
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html

This two patch will convert the new eDMA binding to not use 16bit arrays for
memcpy channel selection and for marking slots reserved.
The '/bits/ 16' seams to be causing confusion so it is probably better to just
use standard type for the arrays.

The new bindings for the eDMA is introduced for 4.4 and we do not have users of
it, which means that we can still change it w/o the risk of breaking anything
and we do not need to maintain the compatibility with 16bit arrays.

The changes in the eDMA driver is local to the DT parsing and should not
conflict with other changes (like the filter function mapping support). Hrm,
there might be trivial conflict in the include/linux/platform_data/edma.h with
the "dmaengine 'universal' API".

Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches are
going to be handled? I would like to send the updated am33xx/am437x conversion
for 4.5 based on these changes.

Thanks and regards,
Peter
---
Peter Ujfalusi (2):
  dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit
type
  dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit
type

 Documentation/devicetree/bindings/dma/ti-edma.txt | 10 ++---
 drivers/dma/edma.c| 53 +++
 include/linux/platform_data/edma.h|  2 +-
 3 files changed, 40 insertions(+), 25 deletions(-)

-- 
2.6.3

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

Re: [PATCH v2 00/25] mtd: nand: refactor the NAND subsystem (part 1)

[Boris Brezillon]

Hi Brian,

On Tue, 8 Dec 2015 16:36:24 -0800
Brian Norris  wrote:

> Hi,
> 
> On Tue, Dec 01, 2015 at 12:02:57PM +0100, Boris Brezillon wrote:
> > Hello,
> > 
> > This huge series aims at clarifying the relationship between the mtd and
> > nand_chip structures and hiding NAND framework internals to NAND
> > controller drivers.
> > 
> > The first part of the series provide an mtd_to_nand() helper to hide the
> > way mtd and nand_chip are linked together.
> > 
> > The second part of the series embeds the mtd structure into the nand_chip
> > one so that NAND controller drivers don't have to bother allocating the
> > MTD device and linking it with the NAND chip.
> > 
> > The last part of the series hides accesses to the chip->priv field behind
> > two helper functions.
> > 
> > This allows removal of some of the boilerplate code done in all NAND
> > controller drivers, but most importantly, it unifies a bit the way NAND
> > chip structures are instantiated (even though we still have two different
> > kinds of drivers: those embedding the nand_chip struct into their private
> > nand chip representation, and those allocating two different structures
> > and linking them together with the chip->priv field).
> > 
> > As said in the title, this refactoring is only the first step. I plan to
> > rework the NAND controller / NAND chip separation for pretty much the same
> > reasons: clarifying the separation between the two concepts, and getting
> > rid of more boilerplate code in NAND controller drivers.
> > 
> > Stay tuned ;-).
> > 
> > Best Regards,
> > 
> > Boris
> > 
> > Changes since v1:
> > - dropped already applied patches
> > - fixed some typos
> > - manually fixed some modifications omitted by the coccinelle scripts
> > - manually reworked modifactions done by coccinelle scripts to improve
> >   readability and fix coding style issues
> > 
> > Boris Brezillon (25):
> >   ARM: nand: make use of mtd_to_nand() where appropriate
> 
> I've sent this (+ the introduction of mtd_to_nand()) in a pull request
> to arm-soc, as well as to l2-mtd.git.
> 
> >   blackfin: nand: make use of mtd_to_nand() where appropriate
> >   cris: nand: make use of mtd_to_nand() where appropriate
> >   mips: nand: make use of mtd_to_nand() where appropriate
> 
> I've based these on v4.4-rc1 and brought them into l2-mtd.git, in case
> any arch/{blackfin,cris,mips}/ people want to pull them in too.
> 
> >   sh: nand: make use of mtd_to_nand() where appropriate
> >   mtd: nand: make use of mtd_to_nand() in NAND core code
> >   mtd: nand: make use of mtd_to_nand() in NAND drivers
> >   staging: mt29f_spinand: make use of mtd_to_nand()
> >   mtd: nand: embed an mtd_info structure into nand_chip
> >   mtd: nand: add nand_to_mtd() helper
> 
> Pulled the rest up to here into l2-mtd.git.

Okay, thanks.

> 
> >   coccinelle: nand: detect and correct drivers embedding an mtd_info
> > object
> 
> I believe Julia had comments on this. That probably would go through the
> kbuild tree in the end anyway (?).

Julia proposed to generate this script using sgen, so I guess this will
come later through a different tree.

> 
> >   mtd: nand: use the mtd instance embedded in struct nand_chip
> 
> There's still at least one problem in this patch (commented on the
> patch). It touches a lot of drivers, so any extra review would be great.

Yep, I think I'll resend the series and split the modification so that
you can pick changes independently (as you suggested a few days ago).

Anyway, reviews from other people would be much appreciated. As I said,
most of changes have been automated with coccinelle, but some of them
have been made manually done, and this is the case for all drivers using
the following pattern:

var = kzalloc(sizeof(struct mtd_info) +
  sizeof(struct nand_chip) + ... ,...);

because I failed to find a pattern common enough to match the cases I
had, and manually fixing them was easier for me...

> 
> >   mtd: nand: update the documentation to reflect framework changes
> >   staging: mt29f_spinand: use the mtd instance embedded in struct
> > nand_chip
> >   cris: nand: use the mtd instance embedded in struct nand_chip
> >   mtd: nand: update mtd_to_nand()
> >   mtd: nand: remove useless mtd->priv = chip assignments
> >   cris: nand: remove useless mtd->priv = chip assignments
> >   staging: mt29f_spinand: remove useless mtd->priv = chip assignment
> >   mtd: nand: simplify nand_dt_init() usage
> >   mtd: nand: kill the chip->flash_node field
> >   mtd: nand: add helpers to access ->priv
> >   ARM: make use of nand_set/get_controller_data() helpers
> >   mtd: nand: make use of nand_set/get_controller_data() helpers
> >   staging: mt29f_spinand: make use of nand_set/get_controller_data()
> > helpers
> 
> All the rest look good to me. I'll wait until I get a good copy of patch
> 12 before taking them.

Sure.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel 

Re: [PATCH v3 bis 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip

[Boris Brezillon]

Hi Brian,

On Tue, 8 Dec 2015 16:17:41 -0800
Brian Norris  wrote:

> 
> > diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
> > index 43bded6..84d027e 100644
> > --- a/drivers/mtd/nand/cmx270_nand.c
> > +++ b/drivers/mtd/nand/cmx270_nand.c
> > @@ -160,10 +160,8 @@ static int __init cmx270_init(void)
> > gpio_direction_input(GPIO_NAND_RB);
> >  
> > /* Allocate memory for MTD device structure and private data */
> > -   cmx270_nand_mtd = kzalloc(sizeof(struct mtd_info) +
> > - sizeof(struct nand_chip),
> > - GFP_KERNEL);
> > -   if (!cmx270_nand_mtd) {
> > +   this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
> > +   if (!this) {
> > ret = -ENOMEM;
> > goto err_kzalloc;
> > }
> > @@ -175,8 +173,7 @@ static int __init cmx270_init(void)
> > goto err_ioremap;
> > }
> >  
> > -   /* Get pointer to private data */
> > -   this = (struct nand_chip *)(_nand_mtd[1]);
> > +   cmx270_nand_mtd = nand_to_mtd(this);
> 
> So, you make cmx270_nand_mtd no longer kzalloc()'d, but I still see the
> cmx270_init() function end with:
> 
> err_scan:
> iounmap(cmx270_nand_io);
> err_ioremap:
> kfree(cmx270_nand_mtd);  <- *** this! ***

Oh, crap.

> err_kzalloc:
> gpio_free(GPIO_NAND_RB);
> err_gpio_request:
>   gpio_free(GPIO_NAND_CS);
> 
>   return ret;
> 
> }
> 
> I have a feeling there's a failing in your coccinelle script somewhere.

These changes are not automated, because it's kind of hard to address
all the different cases where the following pattern is employed;

var = kzalloc(sizeof(struct mtd_info) +
  sizeof(struct nand_chip) + ..., ...);

Sometime var is an mtd_info pointer, sometime it's a nand_chip pointer
or directly a pointer to the private struct.

I'm pretty sure we could come up with a valid coccinelle script, but
given the number of drivers using this approach I'm not sure it is
worth it...

> 
> Given that I was only through 10 of 49 files changes, I think you might
> need to take a comb over your patch better.

I'll go over those changes one more time, but from my experience, these
kind of bugs are spotted more easily by people who didn't write the
code, so other reviews are more than welcome.

Also, as you suggested, I'll split the changes in several commits (one
per driver) so that you can pick them independently.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL for 4.4] DT/dmaengine: edma: Update for the new bindings

[Peter Ujfalusi]

Hi Arnd, Vinod,

As Arnd suggested, the two patch from the following series:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122201.html

plus Acked-by from Arnd is available for pull if you prefer that way.


Regards,
Péter

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  https://github.com/omap-audio/linux-audio.git 
for-4.4/peter/edma_binding_update

for you to fetch changes up to af9089852e0ecd6ae7336992d29b04d7d82b404a:

  dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type 
(2015-12-09 11:56:56 +0200)


Peter Ujfalusi (2):
  dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type
  dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type

 Documentation/devicetree/bindings/dma/ti-edma.txt | 10 --
 drivers/dma/edma.c| 53 
+++--
 include/linux/platform_data/edma.h|  2 +-
 3 files changed, 40 insertions(+), 25 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Linus Walleij]

The separate struct bgpio_chip has been a pain to handle, both
by being confusingly similar in name to struct gpio_chip and
for being contained inside a struct so that struct gpio_chip
is contained in a struct contained in a struct, making several
steps of dereferencing necessary.

Make things simpler: include the fields directly into
, #ifdef:ed for CONFIG_GENERIC_GPIO, and
get rid of the  altogether. Prefix
some of the member variables with bgpio_* and add proper
kerneldoc while we're at it.

Modify all users to handle the change and use a struct
gpio_chip directly. And while we're at it: replace all
container_of() dereferencing by gpiochip_get_data() and
registering the gpio_chip with gpiochip_add_data().

Cc: a...@kernel.org
Cc: Lee Jones 
Cc: Alexander Shiyan 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Tony Lindgren 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Alexandre Courbot 
Cc: Gregory Fong 
Cc: Brian Norris 
Cc: Florian Fainelli 
Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Nicolas Pitre 
Cc: Olof Johansson 
Cc: Vladimir Zapolskiy 
Cc: Rabin Vincent 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: bcm-kernel-feedback-l...@broadcom.com
Signed-off-by: Linus Walleij 
---
ARM SoC folks and Lee: it would be great if you could
ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
so I can take it through the GPIO tree.
---
 arch/arm/mach-clps711x/board-autcpu12.c |   2 +-
 arch/arm/mach-clps711x/board-p720t.c|   2 +-
 arch/arm/mach-imx/mach-mx21ads.c|   2 +-
 arch/arm/mach-omap1/board-ams-delta.c   |   2 +-
 arch/arm/mach-s3c64xx/mach-crag6410.c   |   2 +-
 drivers/gpio/gpio-74xx-mmio.c   |  37 ++--
 drivers/gpio/gpio-brcmstb.c |  80 -
 drivers/gpio/gpio-clps711x.c|  28 +--
 drivers/gpio/gpio-dwapb.c   |  92 +-
 drivers/gpio/gpio-ep93xx.c  |  25 +--
 drivers/gpio/gpio-etraxfs.c |  49 +++---
 drivers/gpio/gpio-ge.c  |  24 +--
 drivers/gpio/gpio-generic.c | 292 +++-
 drivers/gpio/gpio-grgpio.c  |  73 
 drivers/gpio/gpio-moxart.c  |  29 ++--
 drivers/gpio/gpio-mxc.c |  27 ++-
 drivers/gpio/gpio-mxs.c |  33 ++--
 drivers/gpio/gpio-sodaville.c   |  13 +-
 drivers/gpio/gpio-xgene-sb.c|  40 ++---
 drivers/mfd/vexpress-sysreg.c   |   8 +-
 include/linux/basic_mmio_gpio.h |  80 -
 include/linux/gpio/driver.h |  54 ++
 22 files changed, 442 insertions(+), 552 deletions(-)
 delete mode 100644 include/linux/basic_mmio_gpio.h

diff --git a/arch/arm/mach-clps711x/board-autcpu12.c 
b/arch/arm/mach-clps711x/board-autcpu12.c
index c3d964221767..ba3d7d1b28f8 100644
--- a/arch/arm/mach-clps711x/board-autcpu12.c
+++ b/arch/arm/mach-clps711x/board-autcpu12.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-clps711x/board-p720t.c 
b/arch/arm/mach-clps711x/board-p720t.c
index e68dd629bda2..80a16a8b3776 100644
--- a/arch/arm/mach-clps711x/board-p720t.c
+++ b/arch/arm/mach-clps711x/board-p720t.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-imx/mach-mx21ads.c b/arch/arm/mach-imx/mach-mx21ads.c
index 703ce31d7379..9986f9a697c8 100644
--- a/arch/arm/mach-imx/mach-mx21ads.c
+++ b/arch/arm/mach-imx/mach-mx21ads.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index a95499ea8706..97e66558c238 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -11,7 +11,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c 
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index f776adcdaee8..723f47fefc81 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/drivers/gpio/gpio-74xx-mmio.c b/drivers/gpio/gpio-74xx-mmio.c
index 6ed7c0fb3378..464cb57b07c7 100644
--- a/drivers/gpio/gpio-74xx-mmio.c
+++ 

Re: [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init

[Agustí Fontquerni]

> I guess will be interesting cc'ing the ISEE people. Added Agusti and Pau.
>
> Thanks,
> Enric

Thank you.

Ack.
We will try with new versions (wilink8)

Agusti
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

[Bjorn Helgaas]

On Tue, Dec 08, 2015 at 10:05:56AM +0100, Sebastian Andrzej Siewior wrote:
> * Bjorn Helgaas | 2015-12-04 12:46:19 [-0600]:
> 
> >The backtrace might be OK (maybe slightly overkill), but all the
> >stack addresses are certainly irrelevant and distracting.  We only
> >need enough to recognize the problem.  I don't think the modules list
> >is relevant either.
> 
> I would shorten it to the bare minimum. Also the patch description
> itself could be truncated to the required bits…
> 
> >> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> >> index 8c36880..0415192 100644
> >> --- a/drivers/pci/host/pci-dra7xx.c
> >> +++ b/drivers/pci/host/pci-dra7xx.c
> >> @@ -301,8 +301,19 @@ static int __init dra7xx_add_pcie_port(struct 
> >> dra7xx_pcie *dra7xx,
> >>return -EINVAL;
> >>}
> >>  
> >> +  /*
> >> +   * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
> >> +   * On -RT and if kernel is booting with "threadirqs" cmd line parameter
> >> +   * the dra7xx_pcie_msi_irq_handler() will be forced threaded but,
> >> +   * in the same time, it's IRQ dispatcher and calls generic_handle_irq(),
> >> +   * which, in turn, will be resolved to handle_simple_irq() call.
> >> +   * The handle_simple_irq() expected to be called with IRQ disabled, as
> >> +   * result kernle will display warning:
> >> +   * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
> >> +   */
> 
> …not to mention this piece. d7ce4377494a ("powerpc/fsl_msi: mark the msi
> cascade handler IRQF_NO_THREAD") fixes the same bug in arch/ppc so they
> bypassed you fixing it.
> 
> >>ret = devm_request_irq(>dev, pp->irq,
> >> - dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
> >> + dra7xx_pcie_msi_irq_handler,
> >> + IRQF_SHARED | IRQF_NO_THREAD,
> >>   "dra7-pcie-msi", pp);
> >
> >There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
> >and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
> >why not?
> 
> You are right. The request for the handler exynos_pcie_msi_irq_handler(),
> imx6_pcie_msi_handler() and spear13xx_pcie_irq_handler() needs same
> treatment.
> Additionally we have:
> 
> arch/mips/pci/msi-octeon.c: if (request_irq(OCTEON_IRQ_PCI_MSI0, 
> octeon_msi_interrupt0,
> arch/sparc/kernel/pci_msi.c:err = request_irq(irq, 
> sparc64_msiq_interrupt, 0,
> drivers/pci/host/pci-tegra.c:   err = request_irq(msi->irq, 
> tegra_pcie_msi_irq, 0,
> drivers/pci/host/pcie-rcar.c:   err = devm_request_irq(>dev, msi->irq1, 
> rcar_pcie_msi_irq,
> drivers/pci/host/pcie-rcar.c:   err = devm_request_irq(>dev, msi->irq2, 
> rcar_pcie_msi_irq,
> drivers/pci/host/pcie-xilinx.c: err = devm_request_irq(dev, port->irq, 
> xilinx_pcie_intr_handler,
> 
> which require the same kind of fix…
> 
> >I see your discussion about DRA7 hardware design, but my impression is
> >that this problem affects anybody who calls dw_handle_msi_irq() from a
> >handler registered with IRQF_SHARED.
> 
> … brecause all of them invoke generic_handle_irq() from the requsted
> handler. generic_handle_irq grabs raw_locks and this needs to run in
> raw-irq context.
> IRQF_SHARED could probably go away. The IRQ is mostlikely exclusive
> assigned in each SoC for MSI interrupt demux.

It sounds like we should fix all these places at once.  If you
(Grygorii) work up a patch that does them all, with a more generic
changelog, then we can solicit testing and acks.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Liviu Dudau]

On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
> 
> Cc: a...@kernel.org
> Cc: Lee Jones 
> Cc: Alexander Shiyan 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Tony Lindgren 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Alexandre Courbot 
> Cc: Gregory Fong 
> Cc: Brian Norris 
> Cc: Florian Fainelli 
> Cc: Liviu Dudau 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Nicolas Pitre 
> Cc: Olof Johansson 
> Cc: Vladimir Zapolskiy 
> Cc: Rabin Vincent 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-omap@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Linus Walleij 
> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.
> ---

[]

>  drivers/mfd/vexpress-sysreg.c   |   8 +-

[]

> diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
> index 3e628df9280c..855c0204f09a 100644
> --- a/drivers/mfd/vexpress-sysreg.c
> +++ b/drivers/mfd/vexpress-sysreg.c
> @@ -11,7 +11,7 @@
>   * Copyright (C) 2012 ARM Limited
>   */
>  
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -164,7 +164,7 @@ static int vexpress_sysreg_probe(struct platform_device 
> *pdev)
>  {
>   struct resource *mem;
>   void __iomem *base;
> - struct bgpio_chip *mmc_gpio_chip;
> + struct gpio_chip *mmc_gpio_chip;
>   int master;
>   u32 dt_hbi;
>  
> @@ -201,8 +201,8 @@ static int vexpress_sysreg_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   bgpio_init(mmc_gpio_chip, >dev, 0x4, base + SYS_MCI,
>   NULL, NULL, NULL, NULL, 0);
> - mmc_gpio_chip->gc.ngpio = 2;
> - gpiochip_add(_gpio_chip->gc);
> + mmc_gpio_chip->ngpio = 2;
> + gpiochip_add(mmc_gpio_chip);
>  
>   return mfd_add_devices(>dev, PLATFORM_DEVID_AUTO,
>   vexpress_sysreg_cells,

[]

> -- 
> 2.4.3
> 

For the drivers/mfd/vexpress-sysreg.c part:

Acked-by: Liviu Dudau 


-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

debugging

[Ryan]

Hello,

On a custom 4460 board. The x-loader hangs at some place when we
reboot. This happens occasionally on an android port by linaro.

I just want to find out how to debug in this case. How can i get to
know where the hang takes place. After boot rom, i can see the mmc clk
toggling
indicating that xloader is in sram when the hang takes place and not
sure where the hang is.

Do i need Lauterbach to debug - Is it possible to connect the emulator
across reboot. If so, how? or is there any other way i can debug this

Also, i want to check - If i can turn off the dplls? If so, how?

I tried to do a disable on all the clocks in the clock list using
clk_disable call just before reboot and that does not seem to help.

Thank you.
ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Hartley Sweeten]

On Wednesday, December 09, 2015 6:13 AM, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
>
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
>
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
>
> Cc: a...@kernel.org
> Cc: Lee Jones 
> Cc: Alexander Shiyan 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Tony Lindgren 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Alexandre Courbot 
> Cc: Gregory Fong 
> Cc: Brian Norris 
> Cc: Florian Fainelli 
> Cc: Liviu Dudau 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Nicolas Pitre 
> Cc: Olof Johansson 
> Cc: Vladimir Zapolskiy 
> Cc: Rabin Vincent 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-omap@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Linus Walleij 
> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.
> ---



> drivers/gpio/gpio-ep93xx.c  |  25 +--



> diff --git a/drivers/gpio/gpio-ep93xx.c b/drivers/gpio/gpio-ep93xx.c
> index 3e3947b35c83..ad279078fed7 100644
> --- a/drivers/gpio/gpio-ep93xx.c
> +++ b/drivers/gpio/gpio-ep93xx.c
> @@ -16,10 +16,11 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> -#include 
> +#include 
> +/* FIXME: this is here for gpio_to_irq() - get rid of this! */
> +#include 
>  
>  #include 
>  #include 
> @@ -28,7 +29,7 @@
>  
>  struct ep93xx_gpio {
>   void __iomem*mmio_base;
> - struct bgpio_chip   bgc[8];
> + struct gpio_chipgc[8];
>  };
>  
>  /*
> @@ -319,26 +320,26 @@ static int ep93xx_gpio_to_irq(struct gpio_chip *chip, 
> unsigned offset)
>   return 64 + gpio;
>  }
>  
> -static int ep93xx_gpio_add_bank(struct bgpio_chip *bgc, struct device *dev,
> +static int ep93xx_gpio_add_bank(struct gpio_chip *gc, struct device *dev,
>   void __iomem *mmio_base, struct ep93xx_gpio_bank *bank)
>  {
>   void __iomem *data = mmio_base + bank->data;
>   void __iomem *dir =  mmio_base + bank->dir;
>   int err;
>  
> - err = bgpio_init(bgc, dev, 1, data, NULL, NULL, dir, NULL, 0);
> + err = bgpio_init(gc, dev, 1, data, NULL, NULL, dir, NULL, 0);
>   if (err)
>   return err;
>  
> - bgc->gc.label = bank->label;
> - bgc->gc.base = bank->base;
> + gc->label = bank->label;
> + gc->base = bank->base;
>  
>   if (bank->has_debounce) {
> - bgc->gc.set_debounce = ep93xx_gpio_set_debounce;
> - bgc->gc.to_irq = ep93xx_gpio_to_irq;
> + gc->set_debounce = ep93xx_gpio_set_debounce;
> + gc->to_irq = ep93xx_gpio_to_irq;
>   }
>  
> - return gpiochip_add(>gc);
> + return gpiochip_add_data(gc, NULL);
>  }
>  
>  static int ep93xx_gpio_probe(struct platform_device *pdev)
> @@ -358,10 +359,10 @@ static int ep93xx_gpio_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(ep93xx_gpio->mmio_base);
>  
>   for (i = 0; i < ARRAY_SIZE(ep93xx_gpio_banks); i++) {
> - struct bgpio_chip *bgc = _gpio->bgc[i];
> + struct gpio_chip *gc = _gpio->gc[i];
>   struct ep93xx_gpio_bank *bank = _gpio_banks[i];
>  
> - if (ep93xx_gpio_add_bank(bgc, >dev,
> + if (ep93xx_gpio_add_bank(gc, >dev,
>ep93xx_gpio->mmio_base, bank))
>   dev_warn(>dev, "Unable to add gpio bank %s\n",
>   bank->label);

For the drivers/gpio/gpio-ep93xx.c part:

Acked-by: H Hartley Sweeten 

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

Re: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit

[Tony Lindgren]

* Peter Ujfalusi  [151209 00:19]:
> Hi,
> 
> Based on the discussion regarding to (convert am33xx to use the new eDMA
> bindings):
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> 
> This two patch will convert the new eDMA binding to not use 16bit arrays for
> memcpy channel selection and for marking slots reserved.
> The '/bits/ 16' seams to be causing confusion so it is probably better to just
> use standard type for the arrays.
> 
> The new bindings for the eDMA is introduced for 4.4 and we do not have users 
> of
> it, which means that we can still change it w/o the risk of breaking anything
> and we do not need to maintain the compatibility with 16bit arrays.
> 
> The changes in the eDMA driver is local to the DT parsing and should not
> conflict with other changes (like the filter function mapping support). Hrm,
> there might be trivial conflict in the include/linux/platform_data/edma.h with
> the "dmaengine 'universal' API".
> 
> Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches 
> are
> going to be handled? I would like to send the updated am33xx/am437x conversion
> for 4.5 based on these changes.

Yes this should go into v4.4 as discussed, otherwise it will be a mess.
For both, please feel free to add:

Acked-by: Tony Lindgren 

I suggest Vinod sets up an immutable branch against v4.4-rc1 with just these
two patches. Then it can get merged into whichever branch needs it, I
certainly will need it as most of my v4.5 branches are v4.4-rc1 or -rc2
based.

Then the immutable branch can be merged into v4.4 by Vinod or Arnd.

Regards,

Tony

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

Re: [PATCH for 4.4 2/2] dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type

[Rob Herring]

On Wed, Dec 09, 2015 at 10:18:11AM +0200, Peter Ujfalusi wrote:
> This change makes the DT file to be easier to read since the reserved slots
> array does not need the '/bits/ 16' to be specified, which might confuse
> some people.
> 
> Signed-off-by: Peter Ujfalusi 

This too should have info on why you are breaking compatibility.

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/dma/ti-edma.txt |  5 ++--
>  drivers/dma/edma.c| 31 
> ++-
>  2 files changed, 27 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> index ae8b8f1d6e69..079b42a81d7c 100644
> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -56,9 +56,8 @@ edma: edma@4900 {
>  
>   /* Channel 20 and 21 is allocated for memcpy */
>   ti,edma-memcpy-channels = <20 21>;
> - /* The following PaRAM slots are reserved: 35-45 and 100-110 */
> - ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
> -/bits/ 16 <100 10>;
> + /* The following PaRAM slots are reserved: 35-44 and 100-109 */
> + ti,edma-reserved-slot-ranges = <35 10>, <100 10>;
>  };
>  
>  edma_tptc0: tptc@4980 {
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 89fc17f3a6ff..a0f217349c07 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -2015,31 +2015,50 @@ static struct edma_soc_info 
> *edma_setup_info_from_dt(struct device *dev,
>   );
>   if (prop) {
>   const char pname[] = "ti,edma-reserved-slot-ranges";
> + u32 (*tmp)[2];
>   s16 (*rsv_slots)[2];
> - size_t nelm = sz / sizeof(*rsv_slots);
> + size_t nelm = sz / sizeof(*tmp);
>   struct edma_rsv_info *rsv_info;
> + int i;
>  
>   if (!nelm)
>   return info;
>  
> + tmp = kcalloc(nelm, sizeof(*tmp), GFP_KERNEL);
> + if (!tmp)
> + return ERR_PTR(-ENOMEM);
> +
>   rsv_info = devm_kzalloc(dev, sizeof(*rsv_info), GFP_KERNEL);
> - if (!rsv_info)
> + if (!rsv_info) {
> + kfree(tmp);
>   return ERR_PTR(-ENOMEM);
> + }
>  
>   rsv_slots = devm_kcalloc(dev, nelm + 1, sizeof(*rsv_slots),
>GFP_KERNEL);
> - if (!rsv_slots)
> + if (!rsv_slots) {
> + kfree(tmp);
>   return ERR_PTR(-ENOMEM);
> + }
>  
> - ret = of_property_read_u16_array(dev->of_node, pname,
> -  (u16 *)rsv_slots, nelm * 2);
> - if (ret)
> + ret = of_property_read_u32_array(dev->of_node, pname,
> +  (u32 *)tmp, nelm * 2);
> + if (ret) {
> + kfree(tmp);
>   return ERR_PTR(ret);
> + }
>  
> + for (i = 0; i < nelm; i++) {
> + rsv_slots[i][0] = tmp[i][0];
> + rsv_slots[i][1] = tmp[i][1];
> + }
>   rsv_slots[nelm][0] = -1;
>   rsv_slots[nelm][1] = -1;
> +
>   info->rsv = rsv_info;
>   info->rsv->rsv_slots = (const s16 (*)[2])rsv_slots;
> +
> + kfree(tmp);
>   }
>  
>   return info;
> -- 
> 2.6.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: debugging

[Ryan]

Hi Tony,

Thanks for your response. I dont see any prints. I suspect that it
might be hanging before the serial port is initialized
All i see is after arch_reset is called. I can see that is mmc clk and
data signals toggling. This makes me think that
 boot rom has loaded the xloader into sram.

Thanks,



On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
> * Ryan  [151209 09:03]:
>> Hello,
>>
>> On a custom 4460 board. The x-loader hangs at some place when we
>> reboot. This happens occasionally on an android port by linaro.
>>
>> I just want to find out how to debug in this case. How can i get to
>> know where the hang takes place. After boot rom, i can see the mmc clk
>> toggling
>> indicating that xloader is in sram when the hang takes place and not
>> sure where the hang is.
>>
>> Do i need Lauterbach to debug - Is it possible to connect the emulator
>> across reboot. If so, how? or is there any other way i can debug this
>>
>> Also, i want to check - If i can turn off the dplls? If so, how?
>>
>> I tried to do a disable on all the clocks in the clock list using
>> clk_disable call just before reboot and that does not seem to help.
>
> You can add selected serial print statements very early into u-boot
> MLO (and probably x-loader). You need to keep them down to minimum
> so the image still fits into SRAM. If you enable debug, then that also
> needs to be limited to selected files only as enabling debug for the
> whole MLO/x-loader in the Makefile will make it too big.
>
> Regards,
>
> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: debugging

[Felipe Balbi]

Hi,

(please avoid top-posting)

Ryan  writes:
> Hi Tony,
>
> Thanks for your response. I dont see any prints. I suspect that it
> might be hanging before the serial port is initialized
>
> All i see is after arch_reset is called. I can see that is mmc clk and
> data signals toggling. This makes me think that boot rom has loaded
> the xloader into sram.

you might wanna consider openocd if your jtag interface is available
somewhere on your pcb. Just keep in mind that you might have to fiddle a
bit with some TCL config files to get openocd to behave correctly with
your board.

cheers

> On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
>> * Ryan  [151209 09:03]:
>>> Hello,
>>>
>>> On a custom 4460 board. The x-loader hangs at some place when we
>>> reboot. This happens occasionally on an android port by linaro.
>>>
>>> I just want to find out how to debug in this case. How can i get to
>>> know where the hang takes place. After boot rom, i can see the mmc clk
>>> toggling
>>> indicating that xloader is in sram when the hang takes place and not
>>> sure where the hang is.
>>>
>>> Do i need Lauterbach to debug - Is it possible to connect the emulator
>>> across reboot. If so, how? or is there any other way i can debug this
>>>
>>> Also, i want to check - If i can turn off the dplls? If so, how?
>>>
>>> I tried to do a disable on all the clocks in the clock list using
>>> clk_disable call just before reboot and that does not seem to help.
>>
>> You can add selected serial print statements very early into u-boot
>> MLO (and probably x-loader). You need to keep them down to minimum
>> so the image still fits into SRAM. If you enable debug, then that also
>> needs to be limited to selected files only as enabling debug for the
>> whole MLO/x-loader in the Makefile will make it too big.
>>
>> Regards,
>>
>> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH for 4.4 1/2] dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type

[Rob Herring]

On Wed, Dec 09, 2015 at 10:18:10AM +0200, Peter Ujfalusi wrote:
> This change makes the DT file to be easier to read since the memcpy
> channels array does not need the '/bits/ 16' to be specified, which might
> confuse some people.

Why? I don't see the point of this change and plus you are breaking 
compatibility with the change. There was little reason to do 16-bit 
values to start with, but that's now the ABI.
 
Rob

> Signed-off-by: Peter Ujfalusi 
> ---
>  Documentation/devicetree/bindings/dma/ti-edma.txt |  5 ++---
>  drivers/dma/edma.c| 22 ++
>  include/linux/platform_data/edma.h|  2 +-
>  3 files changed, 13 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> index d3d0a4fb1c73..ae8b8f1d6e69 100644
> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -22,8 +22,7 @@ Required properties:
>  Optional properties:
>  - ti,hwmods: Name of the hwmods associated to the eDMA CC
>  - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, 
> iow
> - these channels will be SW triggered channels. The list must
> - contain 16 bits numbers, see example.
> + these channels will be SW triggered channels. See example.
>  - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
>   the driver, they are allocated to be used by for example the
>   DSP. See example.
> @@ -56,7 +55,7 @@ edma: edma@4900 {
>   ti,tptcs = <_tptc0 7>, <_tptc1 7>, <_tptc2 0>;
>  
>   /* Channel 20 and 21 is allocated for memcpy */
> - ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> + ti,edma-memcpy-channels = <20 21>;
>   /* The following PaRAM slots are reserved: 35-45 and 100-110 */
>   ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
>  /bits/ 16 <100 10>;
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 2af8f32bba0b..89fc17f3a6ff 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -1752,16 +1752,14 @@ static enum dma_status edma_tx_status(struct dma_chan 
> *chan,
>   return ret;
>  }
>  
> -static bool edma_is_memcpy_channel(int ch_num, u16 *memcpy_channels)
> +static bool edma_is_memcpy_channel(int ch_num, s32 *memcpy_channels)
>  {
> - s16 *memcpy_ch = memcpy_channels;
> -
>   if (!memcpy_channels)
>   return false;
> - while (*memcpy_ch != -1) {
> - if (*memcpy_ch == ch_num)
> + while (*memcpy_channels != -1) {
> + if (*memcpy_channels == ch_num)
>   return true;
> - memcpy_ch++;
> + memcpy_channels++;
>   }
>   return false;
>  }
> @@ -1775,7 +1773,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool 
> legacy_mode)
>  {
>   struct dma_device *s_ddev = >dma_slave;
>   struct dma_device *m_ddev = NULL;
> - s16 *memcpy_channels = ecc->info->memcpy_channels;
> + s32 *memcpy_channels = ecc->info->memcpy_channels;
>   int i, j;
>  
>   dma_cap_zero(s_ddev->cap_mask);
> @@ -1996,16 +1994,16 @@ static struct edma_soc_info 
> *edma_setup_info_from_dt(struct device *dev,
>   prop = of_find_property(dev->of_node, "ti,edma-memcpy-channels", );
>   if (prop) {
>   const char pname[] = "ti,edma-memcpy-channels";
> - size_t nelm = sz / sizeof(s16);
> - s16 *memcpy_ch;
> + size_t nelm = sz / sizeof(s32);
> + s32 *memcpy_ch;
>  
> - memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s16),
> + memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s32),
>GFP_KERNEL);
>   if (!memcpy_ch)
>   return ERR_PTR(-ENOMEM);
>  
> - ret = of_property_read_u16_array(dev->of_node, pname,
> -  (u16 *)memcpy_ch, nelm);
> + ret = of_property_read_u32_array(dev->of_node, pname,
> +  (u32 *)memcpy_ch, nelm);
>   if (ret)
>   return ERR_PTR(ret);
>  
> diff --git a/include/linux/platform_data/edma.h 
> b/include/linux/platform_data/edma.h
> index 105700e62ea1..0a533f94438f 100644
> --- a/include/linux/platform_data/edma.h
> +++ b/include/linux/platform_data/edma.h
> @@ -76,7 +76,7 @@ struct edma_soc_info {
>   struct edma_rsv_info*rsv;
>  
>   /* List of channels allocated for memcpy, terminated with -1 */
> - s16 *memcpy_channels;
> + s32 *memcpy_channels;
>  
>   s8  (*queue_priority_mapping)[2];
>   const s16   (*xbar_chans)[2];
> -- 
> 2.6.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH for 4.4 1/2] dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit type

[Rob Herring]

On Wed, Dec 09, 2015 at 02:02:00PM -0600, Rob Herring wrote:
> On Wed, Dec 09, 2015 at 10:18:10AM +0200, Peter Ujfalusi wrote:
> > This change makes the DT file to be easier to read since the memcpy
> > channels array does not need the '/bits/ 16' to be specified, which might
> > confuse some people.
> 
> Why? I don't see the point of this change and plus you are breaking 
> compatibility with the change. There was little reason to do 16-bit 
> values to start with, but that's now the ABI.

Okay, I now see the explanation in cover letter. That should be part of 
this commit message.

Acked-by: Rob Herring 

>  
> Rob
> 
> > Signed-off-by: Peter Ujfalusi 
> > ---
> >  Documentation/devicetree/bindings/dma/ti-edma.txt |  5 ++---
> >  drivers/dma/edma.c| 22 
> > ++
> >  include/linux/platform_data/edma.h|  2 +-
> >  3 files changed, 13 insertions(+), 16 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
> > b/Documentation/devicetree/bindings/dma/ti-edma.txt
> > index d3d0a4fb1c73..ae8b8f1d6e69 100644
> > --- a/Documentation/devicetree/bindings/dma/ti-edma.txt
> > +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> > @@ -22,8 +22,7 @@ Required properties:
> >  Optional properties:
> >  - ti,hwmods:   Name of the hwmods associated to the eDMA CC
> >  - ti,edma-memcpy-channels: List of channels allocated to be used for 
> > memcpy, iow
> > -   these channels will be SW triggered channels. The list must
> > -   contain 16 bits numbers, see example.
> > +   these channels will be SW triggered channels. See example.
> >  - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used 
> > by
> > the driver, they are allocated to be used by for example the
> > DSP. See example.
> > @@ -56,7 +55,7 @@ edma: edma@4900 {
> > ti,tptcs = <_tptc0 7>, <_tptc1 7>, <_tptc2 0>;
> >  
> > /* Channel 20 and 21 is allocated for memcpy */
> > -   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> > +   ti,edma-memcpy-channels = <20 21>;
> > /* The following PaRAM slots are reserved: 35-45 and 100-110 */
> > ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>,
> >/bits/ 16 <100 10>;
> > diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> > index 2af8f32bba0b..89fc17f3a6ff 100644
> > --- a/drivers/dma/edma.c
> > +++ b/drivers/dma/edma.c
> > @@ -1752,16 +1752,14 @@ static enum dma_status edma_tx_status(struct 
> > dma_chan *chan,
> > return ret;
> >  }
> >  
> > -static bool edma_is_memcpy_channel(int ch_num, u16 *memcpy_channels)
> > +static bool edma_is_memcpy_channel(int ch_num, s32 *memcpy_channels)
> >  {
> > -   s16 *memcpy_ch = memcpy_channels;
> > -
> > if (!memcpy_channels)
> > return false;
> > -   while (*memcpy_ch != -1) {
> > -   if (*memcpy_ch == ch_num)
> > +   while (*memcpy_channels != -1) {
> > +   if (*memcpy_channels == ch_num)
> > return true;
> > -   memcpy_ch++;
> > +   memcpy_channels++;
> > }
> > return false;
> >  }
> > @@ -1775,7 +1773,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool 
> > legacy_mode)
> >  {
> > struct dma_device *s_ddev = >dma_slave;
> > struct dma_device *m_ddev = NULL;
> > -   s16 *memcpy_channels = ecc->info->memcpy_channels;
> > +   s32 *memcpy_channels = ecc->info->memcpy_channels;
> > int i, j;
> >  
> > dma_cap_zero(s_ddev->cap_mask);
> > @@ -1996,16 +1994,16 @@ static struct edma_soc_info 
> > *edma_setup_info_from_dt(struct device *dev,
> > prop = of_find_property(dev->of_node, "ti,edma-memcpy-channels", );
> > if (prop) {
> > const char pname[] = "ti,edma-memcpy-channels";
> > -   size_t nelm = sz / sizeof(s16);
> > -   s16 *memcpy_ch;
> > +   size_t nelm = sz / sizeof(s32);
> > +   s32 *memcpy_ch;
> >  
> > -   memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s16),
> > +   memcpy_ch = devm_kcalloc(dev, nelm + 1, sizeof(s32),
> >  GFP_KERNEL);
> > if (!memcpy_ch)
> > return ERR_PTR(-ENOMEM);
> >  
> > -   ret = of_property_read_u16_array(dev->of_node, pname,
> > -(u16 *)memcpy_ch, nelm);
> > +   ret = of_property_read_u32_array(dev->of_node, pname,
> > +(u32 *)memcpy_ch, nelm);
> > if (ret)
> > return ERR_PTR(ret);
> >  
> > diff --git a/include/linux/platform_data/edma.h 
> > b/include/linux/platform_data/edma.h
> > index 105700e62ea1..0a533f94438f 100644
> > --- a/include/linux/platform_data/edma.h
> > +++ b/include/linux/platform_data/edma.h
> > @@ -76,7 +76,7 @@ struct edma_soc_info {
> > struct edma_rsv_info*rsv;
> >  
> > /* List of 

Re: debugging

[Tony Lindgren]

* Ryan  [151209 09:03]:
> Hello,
> 
> On a custom 4460 board. The x-loader hangs at some place when we
> reboot. This happens occasionally on an android port by linaro.
> 
> I just want to find out how to debug in this case. How can i get to
> know where the hang takes place. After boot rom, i can see the mmc clk
> toggling
> indicating that xloader is in sram when the hang takes place and not
> sure where the hang is.
> 
> Do i need Lauterbach to debug - Is it possible to connect the emulator
> across reboot. If so, how? or is there any other way i can debug this
> 
> Also, i want to check - If i can turn off the dplls? If so, how?
> 
> I tried to do a disable on all the clocks in the clock list using
> clk_disable call just before reboot and that does not seem to help.

You can add selected serial print statements very early into u-boot
MLO (and probably x-loader). You need to keep them down to minimum
so the image still fits into SRAM. If you enable debug, then that also
needs to be limited to selected files only as enabling debug for the
whole MLO/x-loader in the Makefile will make it too big.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers

[Tony Lindgren]

* Felipe Balbi  [151208 10:05]:
> 
> Hi,
> 
> Grygorii Strashko  writes:
> > ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
> > But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
> > Timekeeping core misbehaves. For example, execution of command
> > "sleep 5" will take 10 sec instead of 5.
> >
> > Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
> > it for clocking ARM TWD and Global timer (same way as on OMAP4).
> >
> > Cc: Tony Lindgren 
> > Cc: Felipe Balbi 
> > Cc: Tero Kristo 
> > Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
> > nodes")
> > Signed-off-by: Grygorii Strashko 
> 
> this seems to be the best fix for this problem, yeah.
> 
> Reviewed-by: Felipe Balbi 

OK applying into omap-for-v4.4/fixes thanks.

Tony


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

Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Michael Welling]

On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
...
> @@ -55,16 +54,16 @@ static int moxart_gpio_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - bgc->gc.label = "moxart-gpio";
> - bgc->gc.request = gpiochip_generic_request;
> - bgc->gc.free = gpiochip_generic_free;
> - bgc->data = bgc->read_reg(bgc->reg_set);
> - bgc->gc.base = 0;
> - bgc->gc.ngpio = 32;
> - bgc->gc.parent = dev;
> - bgc->gc.owner = THIS_MODULE;
> + gc->label = "moxart-gpio";
> + gc->request = gpiochip_generic_request;
> + gc->free = gpiochip_generic_free;
> + gc->bgpio_data = bgc->read_reg(bgc->reg_set);
> + gc->base = 0;
> + gc->ngpio = 32;
> + gc->parent = dev;
> + gc->owner = THIS_MODULE;
>  
> - ret = gpiochip_add(>gc);
> + ret = gpiochip_add_data(gc, NULL);
>   if (ret) {

gpiochip_add is still mentioned in the dev_err below.

>   dev_err(dev, "%s: gpiochip_add failed\n",
>   dev->of_node->full_name);
...

> @@ -226,14 +225,14 @@ static int sdv_gpio_probe(struct pci_dev *pdev,
>   writel(mux_val, sd->gpio_pub_base + GPMUXCTL);
>   }
>  
> - ret = bgpio_init(>bgpio, >dev, 4,
> + ret = bgpio_init(>chip, >dev, 4,
>   sd->gpio_pub_base + GPINR, sd->gpio_pub_base + GPOUTR,
>   NULL, sd->gpio_pub_base + GPOER, NULL, 0);
>   if (ret)
>   goto unmap;
> - sd->bgpio.gc.ngpio = SDV_NUM_PUB_GPIOS;
> + sd->chip.ngpio = SDV_NUM_PUB_GPIOS;
>  
> - ret = gpiochip_add(>bgpio.gc);
> + ret = gpiochip_add_data(>chip, sd);
>   if (ret < 0) {

Also still mentioned here in the dev_err.

>   dev_err(>dev, "gpiochip_add() failed.\n");
>   goto unmap;
...
 
> @@ -201,8 +201,8 @@ static int vexpress_sysreg_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   bgpio_init(mmc_gpio_chip, >dev, 0x4, base + SYS_MCI,
>   NULL, NULL, NULL, NULL, 0);

Was going to complain about this one not switching to _data but it was
addressed in a follow up patch.

> - mmc_gpio_chip->gc.ngpio = 2;
> - gpiochip_add(_gpio_chip->gc);
> + mmc_gpio_chip->ngpio = 2;
> + gpiochip_add(mmc_gpio_chip);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Krzysztof Kozlowski]

On 09.12.2015 22:12, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
> 
> Cc: a...@kernel.org
> Cc: Lee Jones 
> Cc: Alexander Shiyan 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Tony Lindgren 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Alexandre Courbot 
> Cc: Gregory Fong 
> Cc: Brian Norris 
> Cc: Florian Fainelli 
> Cc: Liviu Dudau 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Nicolas Pitre 
> Cc: Olof Johansson 
> Cc: Vladimir Zapolskiy 
> Cc: Rabin Vincent 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-omap@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Signed-off-by: Linus Walleij 
> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.
> ---
>  arch/arm/mach-clps711x/board-autcpu12.c |   2 +-
>  arch/arm/mach-clps711x/board-p720t.c|   2 +-
>  arch/arm/mach-imx/mach-mx21ads.c|   2 +-
>  arch/arm/mach-omap1/board-ams-delta.c   |   2 +-
>  arch/arm/mach-s3c64xx/mach-crag6410.c   |   2 +-

For s3c64xx:
Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

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

Re: [PATCH 02/10] clk: ti: Add few dm814x clock aliases

[Tony Lindgren]

* Tero Kristo  [151208 23:50]:
> On 12/08/2015 10:11 PM, Tony Lindgren wrote:
> >* Tero Kristo  [151208 11:25]:
> >>On 12/08/2015 06:57 PM, Tony Lindgren wrote:
> >>>
> >>>Anybody from the clock department care to ack this one?
> >>
> >>Sorry been rather busy lately...
> >>
> >>>I'd like to
> >>>get this series into Linux next as it fixes some some issues.
> >>
> >>Yeah looks good to me, don't have access to dm814x so can't test.
> >>
> >>Acked-by: Tero Kristo 
> >
> >Thanks.
> >
> >>Are you planning to push this via omap tree if this is critical for you?
> >
> >Yes this series needs to be merged in certain order to keep t410
> >booting. Should not conflict with anything else AFAIK.
> 
> Ok at least I am fine with that. The dm81xx clock alias file is pretty
> independent of anything else.

Pushing this series except for the GPIO reset change into
omap-for-v4.5/81xx-fixes.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit

[Vinod Koul]

On Wed, Dec 09, 2015 at 12:12:27PM -0800, Tony Lindgren wrote:
> * Peter Ujfalusi  [151209 00:19]:
> > Hi,
> > 
> > Based on the discussion regarding to (convert am33xx to use the new eDMA
> > bindings):
> > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> > 
> > This two patch will convert the new eDMA binding to not use 16bit arrays for
> > memcpy channel selection and for marking slots reserved.
> > The '/bits/ 16' seams to be causing confusion so it is probably better to 
> > just
> > use standard type for the arrays.
> > 
> > The new bindings for the eDMA is introduced for 4.4 and we do not have 
> > users of
> > it, which means that we can still change it w/o the risk of breaking 
> > anything
> > and we do not need to maintain the compatibility with 16bit arrays.
> > 
> > The changes in the eDMA driver is local to the DT parsing and should not
> > conflict with other changes (like the filter function mapping support). Hrm,
> > there might be trivial conflict in the include/linux/platform_data/edma.h 
> > with
> > the "dmaengine 'universal' API".
> > 
> > Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches 
> > are
> > going to be handled? I would like to send the updated am33xx/am437x 
> > conversion
> > for 4.5 based on these changes.
> 
> Yes this should go into v4.4 as discussed, otherwise it will be a mess.
> For both, please feel free to add:
> 
> Acked-by: Tony Lindgren 
> 
> I suggest Vinod sets up an immutable branch against v4.4-rc1 with just these
> two patches. Then it can get merged into whichever branch needs it, I
> certainly will need it as most of my v4.5 branches are v4.4-rc1 or -rc2
> based.
> 
> Then the immutable branch can be merged into v4.4 by Vinod or Arnd.

Applied to fix/edma. This is based on -rc1 and will not rebase.

I am merging this to my fixes and will send to Linus in couple of days

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Vignesh R]

On 12/03/2015 03:51 PM, Vignesh R wrote:
> 
> 
> On 12/01/2015 10:09 PM, Tony Lindgren wrote:
>> * Vignesh R  [151130 20:46]:
>>> On 12/01/2015 04:04 AM, Tony Lindgren wrote:

...
>>
>> OK. They are both on L3 main so that won't cause any issues for separate
>> interconnect driver instances. As they are still separate targets flushing
>> a posted write to one area will not flush anything to the other.
>>
> 
> I didn't quite understand what you meant by interconnect driver instance.
> qspi_base and qspi_mmap region are tightly bound to each other and both
> needs to be accessed by ti-qspi driver (though different targets).
> Besides qspi_mmap region is only used to read data, there will not be
> any write accesses to this target. Are you saying this binding is not
> viable?
> 

As I stated above qspi_base and qspi_mmap region are tightly bound,
there is no way to use qspi_mmap region w/o accessing qspi_base. So I am
planning to keep them as it is. I will move qspi_ctrlmod to use syscon.
Something like:

qspi: qspi@4b30 {
   compatible = "ti,dra7xxx-qspi";
   reg = <0x4b30 0x100>,
 <0x5c00 0x400>,
   reg-names = "qspi_base", "qspi_mmap";
   syscon-chipselects = <_conf 0x558>;
   #address-cells = <1>;
   #size-cells = <0>;
   spi-max-frequency = <4800>;
   ti,hwmods = "qspi";
};

Do you think this is not viable in future?


-- 
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

[Grygorii Strashko]

On 12/09/2015 05:24 PM, Bjorn Helgaas wrote:

On Tue, Dec 08, 2015 at 10:05:56AM +0100, Sebastian Andrzej Siewior wrote:

* Bjorn Helgaas | 2015-12-04 12:46:19 [-0600]:


The backtrace might be OK (maybe slightly overkill), but all the
stack addresses are certainly irrelevant and distracting.  We only
need enough to recognize the problem.  I don't think the modules list
is relevant either.


I would shorten it to the bare minimum. Also the patch description
itself could be truncated to the required bits…


diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 8c36880..0415192 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -301,8 +301,19 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie 
*dra7xx,
return -EINVAL;
}

+   /*
+* Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
+* On -RT and if kernel is booting with "threadirqs" cmd line parameter
+* the dra7xx_pcie_msi_irq_handler() will be forced threaded but,
+* in the same time, it's IRQ dispatcher and calls generic_handle_irq(),
+* which, in turn, will be resolved to handle_simple_irq() call.
+* The handle_simple_irq() expected to be called with IRQ disabled, as
+* result kernle will display warning:
+* "irq XXX handler YYY+0x0/0x14 enabled interrupts".
+*/


…not to mention this piece. d7ce4377494a ("powerpc/fsl_msi: mark the msi
cascade handler IRQF_NO_THREAD") fixes the same bug in arch/ppc so they
bypassed you fixing it.


ret = devm_request_irq(>dev, pp->irq,
-  dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
+  dra7xx_pcie_msi_irq_handler,
+  IRQF_SHARED | IRQF_NO_THREAD,
   "dra7-pcie-msi",   pp);


There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
why not?


You are right. The request for the handler exynos_pcie_msi_irq_handler(),
imx6_pcie_msi_handler() and spear13xx_pcie_irq_handler() needs same
treatment.
Additionally we have:

arch/mips/pci/msi-octeon.c: if (request_irq(OCTEON_IRQ_PCI_MSI0, 
octeon_msi_interrupt0,
arch/sparc/kernel/pci_msi.c:err = request_irq(irq, sparc64_msiq_interrupt, 
0,
drivers/pci/host/pci-tegra.c:   err = request_irq(msi->irq, tegra_pcie_msi_irq, 
0,
drivers/pci/host/pcie-rcar.c:   err = devm_request_irq(>dev, msi->irq1, 
rcar_pcie_msi_irq,
drivers/pci/host/pcie-rcar.c:   err = devm_request_irq(>dev, msi->irq2, 
rcar_pcie_msi_irq,
drivers/pci/host/pcie-xilinx.c: err = devm_request_irq(dev, port->irq, 
xilinx_pcie_intr_handler,

which require the same kind of fix…


I see your discussion about DRA7 hardware design, but my impression is
that this problem affects anybody who calls dw_handle_msi_irq() from a
handler registered with IRQF_SHARED.


… brecause all of them invoke generic_handle_irq() from the requsted
handler. generic_handle_irq grabs raw_locks and this needs to run in
raw-irq context.
IRQF_SHARED could probably go away. The IRQ is mostlikely exclusive
assigned in each SoC for MSI interrupt demux.


It sounds like we should fix all these places at once.  If you
(Grygorii) work up a patch that does them all, with a more generic
changelog, then we can solicit testing and acks.


Sure, will do:
- change will be applied for files listed in this thread only
- IRQF_SHARED will be left unchanged
- commit message will be made more generic
- i prefer to keep comment in code for dra7 as is.
Is it ok?


--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 004/182] gpio: generic: factor into gpio_chip struct

[Tony Lindgren]

* Linus Walleij  [151209 05:14]:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of dereferencing necessary.
> 
> Make things simpler: include the fields directly into
> , #ifdef:ed for CONFIG_GENERIC_GPIO, and
> get rid of the  altogether. Prefix
> some of the member variables with bgpio_* and add proper
> kerneldoc while we're at it.
> 
> Modify all users to handle the change and use a struct
> gpio_chip directly. And while we're at it: replace all
> container_of() dereferencing by gpiochip_get_data() and
> registering the gpio_chip with gpiochip_add_data().
...

> ---
> ARM SoC folks and Lee: it would be great if you could
> ACK the few lines hitting arch/arm/* and drivers/mfd/* in this
> so I can take it through the GPIO tree.

For omap:

Acked-by: Tony Lindgren 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html