On Thu, Sep 09, 2010 at 02:29:22PM +0900, Jassi Brar wrote:
> On Thu, Sep 9, 2010 at 2:11 PM, Grant Likely
> wrote:
> > On Fri, Sep 03, 2010 at 10:37:10AM +0900, Jassi Brar wrote:
> >> Newer SoCs have the SPI clock scaling control in platform's
> >> clock management unit. Inorder for such SoCs to
On Thu, 9 Sep 2010 11:48:22 +0800
David Brownell wrote:
> You know, in retrospect, I shouldn't have put
> most of those SPI device setup params into the
> board setup data.
>
> There's one which MUST be there: polarity of
> the chip select line. The rest seem like they
> could (and arguably sh
Hi Uwe,
On Thu, Sep 02, 2010 at 04:42:02PM +0200, Uwe Kleine-König wrote:
> From: Sascha Hauer
>
A description of what is required to add imx51 support would be
appreciated by us poor patch reviewers.
> Signed-off-by: Sascha Hauer
> ---
> drivers/spi/spi_imx.c | 123
On Thu, Sep 9, 2010 at 2:11 PM, Grant Likely wrote:
> On Fri, Sep 03, 2010 at 10:37:10AM +0900, Jassi Brar wrote:
>> Newer SoCs have the SPI clock scaling control in platform's
>> clock management unit. Inorder for such SoCs to work, we need
>> to check the flag clk_from_cmu before making any cloc
On Wed, Sep 08, 2010 at 10:53:41AM -0600, Grant Likely wrote:
> On Tue, Sep 07, 2010 at 03:27:27PM +0800, Yong Wang wrote:
> > Allow interrupt sharing since exclusive interrupt line for
> > DW SPI controller is not provided on every platform.
> >
> > Signed-off-by: Yong Wang
> > ---
> > drivers/
On Fri, Sep 03, 2010 at 10:36:37AM +0900, Jassi Brar wrote:
> Since we use DMA mode only for xfers bigger than FIFO size,
> do not map/unmap buffers for polling mode transfers.
>
> Signed-off-by: Jassi Brar
I'll pick this one up for the 2.6.37 merge window.
g.
> ---
> drivers/spi/spi_s3c64xx.
On Fri, Sep 03, 2010 at 10:37:10AM +0900, Jassi Brar wrote:
> Newer SoCs have the SPI clock scaling control in platform's
> clock management unit. Inorder for such SoCs to work, we need
> to check the flag clk_from_cmu before making any clock changes.
>
> Signed-off-by: Jassi Brar
Would it not m
On Fri, Sep 03, 2010 at 10:37:02AM +0900, Jassi Brar wrote:
> Since the driver is meant to manage SPI of newer SoCs as well, we
> need to define a new structure member for latest SoC that has the
> SPI clock control/scaling block moved from the controller to the
> platform's clock management unit.
On Fri, Sep 03, 2010 at 10:36:54AM +0900, Jassi Brar wrote:
> We can't do without setting channel and bus width to
> same size.
> Inorder to do that, define a new callback to be used
> to do read/write of appropriate widths.
>
> Signed-off-by: Jassi Brar
> ---
> drivers/spi/spi_s3c64xx.c | 78
On Fri, Sep 03, 2010 at 10:36:46AM +0900, Jassi Brar wrote:
> Instead of, wrongly, reusing the 'val' variable, use a dedicated
> one for reading the status register.
>
> Signed-off-by: Jassi Brar
Applied to spi-merge, thanks.
g.
> ---
> drivers/spi/spi_s3c64xx.c |5 +++--
> 1 files change
On Fri, Sep 03, 2010 at 10:36:26AM +0900, Jassi Brar wrote:
> Fix compilation warning by typecasting the tx_buf pointer.
>
> Signed-off-by: Jassi Brar
Applied to spi-merge, thanks.
g.
> ---
> drivers/spi/spi_s3c64xx.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff
On Mon, Sep 06, 2010 at 11:02:12AM +0200, Linus Walleij wrote:
> The PL022 SPI bus is sometimes used for early stuff like
> regulators that need to be present at module_init() time, so
> we move this to a subsys_initcall().
>
> Cc: Lukasz Baj
> Signed-off-by: Linus Walleij
Applied, thanks.
Not
On Wed, Sep 8, 2010 at 9:48 PM, David Brownell wrote:
> You know, in retrospect, I shouldn't have put
> most of those SPI device setup params into the
> board setup data.
Out of curiosity, what was the reasoning behind registering the spi
board info separately instead of passing it explicitly via
You know, in retrospect, I shouldn't have put
most of those SPI device setup params into the
board setup data.
There's one which MUST be there: polarity of
the chip select line. The rest seem like they
could (and arguably should) all be handled by
driver-specific params. (Possible exception:
cl
On Thu, Sep 09, 2010 at 11:14:45AM +0800, Feng Tang wrote:
> Hi Grant,
>
> On Thu, 9 Sep 2010 04:21:59 +0800
> Grant Likely wrote:
>
> > > >
> > > > Yes, driver itself
> > > > > know the bits_per_word info best in most case, but there
> > > > > is
> > > > > some device (Option GTM501L spi mode
Hi Grant,
On Thu, 9 Sep 2010 04:21:59 +0800
Grant Likely wrote:
> > >
> > > Yes, driver itself
> > > > know the bits_per_word info best in most case, but there
> > > > is
> > > > some device (Option GTM501L spi modem) which supports
> > > > multiple
> > > > bits_per_mode option, and here platf
We can't do without setting channel and bus width to
same size.
Inorder to do that, define a new callback to be used
to do read/write of appropriate widths.
Signed-off-by: Jassi Brar
---
drivers/spi/spi_s3c64xx.c | 78 +---
1 files changed, 65 insertions
Since the driver is meant to manage SPI of newer SoCs as well, we
need to define a new structure member for latest SoC that has the
SPI clock control/scaling block moved from the controller to the
platform's clock management unit.
The flag should be set to 'true' by any SoC that has SPI controller
Hi,
Here come six bug fixes and enhancements to the S3C64XX
spi controller driver.
The first 4 are bug/warning fixes, the last two are to
enable the spi_s3c64xx.c to manage SPI controllers of newer
Samsung SoCs with essentially the same IP but scalar logic
moved into core clock management unit.
On Thu, Sep 9, 2010 at 10:37 AM, Grant Likely wrote:
> Hi Jassi. I've actually been working through these today (I'm not ignoring
> you, just dealing with back-to-school family issues which is why I'm slow).
> You'll get emails as I merge them into my tree.
You didn't appear in the cc list ev
"Jassi Brar" wrote:
>Hi,
> Here come six bug fixes and enhancements to the S3C64XX
>spi controller driver.
> The first 4 are bug/warning fixes, the last two are to
>enable the spi_s3c64xx.c to manage SPI controllers of newer
>Samsung SoCs with essentially the same IP but scalar logic
>moved in
Newer SoCs have the SPI clock scaling control in platform's
clock management unit. Inorder for such SoCs to work, we need
to check the flag clk_from_cmu before making any clock changes.
Signed-off-by: Jassi Brar
---
drivers/spi/spi_s3c64xx.c | 94 +++--
Fix compilation warning by typecasting the tx_buf pointer.
Signed-off-by: Jassi Brar
---
drivers/spi/spi_s3c64xx.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 9736581..774e861 100644
--- a/drivers/spi/sp
Since we use DMA mode only for xfers bigger than FIFO size,
do not map/unmap buffers for polling mode transfers.
Signed-off-by: Jassi Brar
---
drivers/spi/spi_s3c64xx.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c
Instead of, wrongly, reusing the 'val' variable, use a dedicated
one for reading the status register.
Signed-off-by: Jassi Brar
---
drivers/spi/spi_s3c64xx.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi_s3c64xx.c b/drivers/spi/spi_s3c64xx.c
index 1
>
>> This patch changes the way SPI transfers are setup. The previous
>> method uses the pl022_config_chip data for configuration of
>> loopback mode, edge count, clock polarity, number of data bits,
>> and bit transfer order. This change configures these parameters
>> based on spi->mode passed via
On Thu, Sep 02, 2010 at 02:13:48PM +0800, Feng Tang wrote:
> Hi David,
>
>
> > > Grant also asked me the same question.
> >
> >
> > I saw him ask a different question (which
> > I quoted) ...
>
> My mistake, I tried to answer Grant's and your questions in one email to
> keep the discussion in
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
sp
On Mon, Aug 23, 2010 at 10:30:17AM -0700, Kevin Wells wrote:
> > With the introduction of an AMBA PrimeCell per-cell block clock,
> > the pclk was left on after probe() unless explicitly disabled.
> > This clock is wired to the same clock on PL022 causing it to stay
> > always on since.
> >
> > Fix
On Tue, Aug 24, 2010 at 09:06:40AM +0900, Jassi Brar wrote:
> On Tue, Aug 24, 2010 at 1:40 AM, Mark Brown
> wrote:
> > When using PIO we have a timeout for the TX and RX FIFOs to ensure that
> > the data actually gets transferred. Warn if we hit that timeout - it
> > should never happen, but this
On Wed, Sep 08, 2010 at 10:44:32AM -0600, Grant Likely wrote:
> On Wed, Sep 08, 2010 at 05:22:51PM +0100, Mark Brown wrote:
> > Doing dependencies could get pretty complicated, especially once you
> > handle optional dependencies ("is this missing because it didn't probe
> > yet or because it's ju
On Tue, Sep 07, 2010 at 03:27:27PM +0800, Yong Wang wrote:
> Allow interrupt sharing since exclusive interrupt line for
> DW SPI controller is not provided on every platform.
>
> Signed-off-by: Yong Wang
> ---
> drivers/spi/dw_spi.c |7 ++-
> 1 files changed, 6 insertions(+), 1 deletions
On Tue, Sep 07, 2010 at 03:52:06PM +0800, Feng Tang wrote:
> commit 052dc7c45i "spi/dw_spi: conditional transfer mode change"
> introduced cs_control code, which has a bug by using bit offset
> for spi mode to set transfer mode in control register. Also it
> forces devices who don't need cs_control
On Wed, Sep 08, 2010 at 05:22:51PM +0100, Mark Brown wrote:
> On Wed, Sep 08, 2010 at 10:12:45AM -0600, Grant Likely wrote:
>
> [reflowed into 80 columns]
Sorry about that. I'm in the process of switching to mutt+vim for my
mailer. gmail is just not efficient enough when managing patches.
> >
On Wed, Sep 08, 2010 at 06:37:59PM +0900, Jassi Brar wrote:
> On Wed, Sep 8, 2010 at 6:12 PM, Mark Brown
> wrote:
> > On Wed, Sep 08, 2010 at 01:55:39PM +0900, Jassi Brar wrote:
> >> On Tue, Sep 7, 2010 at 7:29 PM, Mark Brown
> >> wrote:
> >> > Allow the use of the S3C64xx SPI controller with thi
On Wed, Sep 08, 2010 at 10:12:45AM -0600, Grant Likely wrote:
[reflowed into 80 columns]
> ... but it seems to me that there is a systemic problem in the way the
> driver model is being used if SPI (and I2C) bus drivers need to be
> 'special' in this regard. What are the ordering requirements on
2010/9/2 :
> This patch changes the way SPI transfers are setup. The previous
> method uses the pl022_config_chip data for configuration of
> loopback mode, edge count, clock polarity, number of data bits,
> and bit transfer order. This change configures these parameters
> based on spi->mode pass
On Wed, Sep 08, 2010 at 10:44:26AM +0900, Jassi Brar wrote:
> On Wed, Sep 8, 2010 at 12:37 AM, Mark Brown
> wrote:
> > For small transfers at high speeds the expected transfer time can easily
> > be well under 1ms, causing the delay in wait_for_xfer() to be only the
> > dead reckoning fudge factor
On Wed, Sep 8, 2010 at 6:12 PM, Mark Brown
wrote:
> On Wed, Sep 08, 2010 at 01:55:39PM +0900, Jassi Brar wrote:
>> On Tue, Sep 7, 2010 at 7:29 PM, Mark Brown
>> wrote:
>> > Allow the use of the S3C64xx SPI controller with things like PMICs by
>> > moving the init up to subsys_initcall().
>
>> Cou
On Wed, Sep 08, 2010 at 01:55:39PM +0900, Jassi Brar wrote:
> On Tue, Sep 7, 2010 at 7:29 PM, Mark Brown
> wrote:
> > Allow the use of the S3C64xx SPI controller with things like PMICs by
> > moving the init up to subsys_initcall().
> Couldn't any user ever need to load it as a module?
> If no, w
On Wed, Sep 08, 2010 at 10:11:59AM +0900, Jassi Brar wrote:
> I have already submitted a patch a few days ago
> https://patchwork.kernel.org/patch/151941/
> (It's strange that Grant's id isn't there in the CC list, despite my writing
> it)
Ah, excellent. Now I see patchwork there look to be som
41 matches
Mail list logo
