All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	"Shawn Guo" <shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	"Fabio Estevam"
	<fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
	"Wolfgang Denk" <wd-ynQEQJNshbs@public.gmane.org>,
	"Detlev Zundel" <dzu-ynQEQJNshbs@public.gmane.org>,
	"Stefano Babic" <sbabic-ynQEQJNshbs@public.gmane.org>,
	"Sascha Hauer" <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Uwe Kleine-König"
	<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	"Dong Aisheng" <b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	pavel-+ZI9xUNit7I@public.gmane.org
Subject: Re: [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c
Date: Sat, 21 Jul 2012 17:54:29 +0200	[thread overview]
Message-ID: <201207211754.29372.marex@denx.de> (raw)
In-Reply-To: <20120721154153.GA25874-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Dear Wolfram Sang,

> > > Yet, if I know the compatible property for the mxs I2C driver, and also
> > > know the CPU type (be it MX23 or MX28), I can deduce from that a lot of
> > > information, including DMA channel. That is fix. Why encode it?
> > 
> > You know the compatible and the "fallback compatible". From the later
> > one, you can deduce nothing if that happens to kick in.
> 
> Even if the driver was matched because of an MX23-I2C "compatible"
> binding, both devicetree and runtime could provide data that it actually
> runs on MX28. That shouldn't be a problem.

You mean like ... cpu_is_mx28() ? We got rid of that in favor of DT.

> > btw. the PIO discussion on DT discuss is completely ignored. How shall we
> > proceed, this driver is stalled for too long.
> 
> IIRC I mentioned that a discussion about the bindings won't make the
> next merge window.

Yet another merge window, I have to mention. And only because very long pauses 
inbetween reviews and very minor nitpicks. I'm being annoyed by this patch so 
much I'm thinking of giving up on this. I wasted too much of my free time on 
this and the result is as is.

> That's why I proposed either module_parameter

Which I explained is not a way to go.

> or
> dropping the binding entirely as possible inbetween options.

Which is not an option either. And this discussion is only further stalling the 
patch.

We're adding fsl,something properties all over the DT all the time, yet this one 
is of concern?

Best regards,
Marek Vasut

WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c
Date: Sat, 21 Jul 2012 17:54:29 +0200	[thread overview]
Message-ID: <201207211754.29372.marex@denx.de> (raw)
In-Reply-To: <20120721154153.GA25874@pengutronix.de>

Dear Wolfram Sang,

> > > Yet, if I know the compatible property for the mxs I2C driver, and also
> > > know the CPU type (be it MX23 or MX28), I can deduce from that a lot of
> > > information, including DMA channel. That is fix. Why encode it?
> > 
> > You know the compatible and the "fallback compatible". From the later
> > one, you can deduce nothing if that happens to kick in.
> 
> Even if the driver was matched because of an MX23-I2C "compatible"
> binding, both devicetree and runtime could provide data that it actually
> runs on MX28. That shouldn't be a problem.

You mean like ... cpu_is_mx28() ? We got rid of that in favor of DT.

> > btw. the PIO discussion on DT discuss is completely ignored. How shall we
> > proceed, this driver is stalled for too long.
> 
> IIRC I mentioned that a discussion about the bindings won't make the
> next merge window.

Yet another merge window, I have to mention. And only because very long pauses 
inbetween reviews and very minor nitpicks. I'm being annoyed by this patch so 
much I'm thinking of giving up on this. I wasted too much of my free time on 
this and the result is as is.

> That's why I proposed either module_parameter

Which I explained is not a way to go.

> or
> dropping the binding entirely as possible inbetween options.

Which is not an option either. And this discussion is only further stalling the 
patch.

We're adding fsl,something properties all over the DT all the time, yet this one 
is of concern?

Best regards,
Marek Vasut

  parent reply	other threads:[~2012-07-21 15:54 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-09 16:22 [PATCH 1/2 V3] MXS: Set I2C timing registers for mxs-i2c Marek Vasut
2012-07-09 16:22 ` Marek Vasut
     [not found] ` <1341850974-11977-1-git-send-email-marex-ynQEQJNshbs@public.gmane.org>
2012-07-09 16:22   ` [PATCH 2/2 V3] MXS: Implement DMA support into mxs-i2c Marek Vasut
2012-07-09 16:22     ` Marek Vasut
     [not found]     ` <1341850974-11977-2-git-send-email-marex-ynQEQJNshbs@public.gmane.org>
2012-07-13  8:22       ` Wolfram Sang
2012-07-13  8:22         ` Wolfram Sang
     [not found]         ` <20120713082249.GF32184-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-13 12:10           ` Marek Vasut
2012-07-13 12:10             ` Marek Vasut
     [not found]             ` <201207131410.29469.marex-ynQEQJNshbs@public.gmane.org>
2012-07-14 11:29               ` Wolfram Sang
2012-07-14 11:29                 ` Wolfram Sang
     [not found]                 ` <20120714112929.GB29529-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-14 12:09                   ` Marek Vasut
2012-07-14 12:09                     ` Marek Vasut
     [not found]                     ` <201207141409.38554.marex-ynQEQJNshbs@public.gmane.org>
2012-07-16 10:21                       ` Wolfram Sang
2012-07-16 10:21                         ` Wolfram Sang
     [not found]                         ` <20120716102151.GC17435-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-16 13:06                           ` Marek Vasut
2012-07-16 13:06                             ` Marek Vasut
     [not found]                             ` <201207161506.08147.marex-ynQEQJNshbs@public.gmane.org>
2012-07-16 13:25                               ` Wolfram Sang
2012-07-16 13:25                                 ` Wolfram Sang
2012-07-15  8:17           ` Shawn Guo
2012-07-15  8:17             ` Shawn Guo
     [not found]             ` <20120715081715.GA2429-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-07-21 12:44               ` Wolfram Sang
2012-07-21 12:44                 ` Wolfram Sang
     [not found]                 ` <20120721124406.GA9946-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-21 14:11                   ` Marek Vasut
2012-07-21 14:11                     ` Marek Vasut
     [not found]                     ` <201207211611.58956.marex-ynQEQJNshbs@public.gmane.org>
2012-07-21 15:41                       ` Wolfram Sang
2012-07-21 15:41                         ` Wolfram Sang
     [not found]                         ` <20120721154153.GA25874-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-07-21 15:54                           ` Marek Vasut [this message]
2012-07-21 15:54                             ` Marek Vasut
     [not found]                             ` <201207211754.29372.marex-ynQEQJNshbs@public.gmane.org>
2012-07-22  8:33                               ` Wolfram Sang
2012-07-22  8:33                                 ` Wolfram Sang
2012-07-28  8:02                   ` Shawn Guo
2012-07-28  8:02                     ` Shawn Guo
2012-07-13  8:07   ` [PATCH 1/2 V3] MXS: Set I2C timing registers for mxs-i2c Wolfram Sang
2012-07-13  8:07     ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201207211754.29372.marex@denx.de \
    --to=marex-ynqeqjnshbs@public.gmane.org \
    --cc=b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
    --cc=dzu-ynQEQJNshbs@public.gmane.org \
    --cc=fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=pavel-+ZI9xUNit7I@public.gmane.org \
    --cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=sbabic-ynQEQJNshbs@public.gmane.org \
    --cc=shawn.guo-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=wd-ynQEQJNshbs@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.