Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1301671 > unrolled thread

Re: [RFC] spi: dw: support setting tmode dynamically

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC] spi: dw: support setting tmode dynamically Mark Brown <broonie@kernel.org> - 2016-01-05 17:20 +0100
    Re: [RFC] spi: dw: support setting tmode dynamically Khoa Dang Pham <kpham@apm.com> - 2016-01-06 03:10 +0100
    Re: [RFC] spi: dw: support setting tmode dynamically Jisheng Zhang <jszhang@marvell.com> - 2016-01-06 07:30 +0100
      Re: [RFC] spi: dw: support setting tmode dynamically Khoa Dang Pham <kpham@apm.com> - 2016-01-06 08:10 +0100
        Re: [RFC] spi: dw: support setting tmode dynamically Jisheng Zhang <jszhang@marvell.com> - 2016-01-06 08:30 +0100
          Re: [RFC] spi: dw: support setting tmode dynamically Khoa Dang Pham <kpham@apm.com> - 2016-01-06 08:40 +0100
            Re: [RFC] spi: dw: support setting tmode dynamically Jisheng Zhang <jszhang@marvell.com> - 2016-01-06 08:50 +0100
    Re: [RFC] spi: dw: support setting tmode dynamically Mark Brown <broonie@kernel.org> - 2016-01-06 13:20 +0100

#1301671 — Re: [RFC] spi: dw: support setting tmode dynamically

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:
> On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:
> > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:

> > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is NULL, but we
> > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution is to add and
> > > export one functions to set the tmode, then the nor flash driver call it
> > > before reading and set back to SPI_TMOD_TR after done.  

> > What does this mean - what is TMOD and why do we need to set it to read
> > NOR flash?  I've no information on this controller...

> TMOD is one field of DW_SPI_CTRL0. Its available value could be:

> 0: Transmit and Receive
> 1: Transmit only
> 2: Receive only
> 3: EEPROM Read

> If the one spi nor flash is connected to the SPI host, so far I can only succeed
> to read the nor flash content after setting the TMOD field as 3.

Why?  What does this mean in practical terms at the hardware level, what
is "EEPROM read"?  It sounds like there's some bigger issue here.

[toc] | [next] | [standalone]

#1302338

Hi Mark,

May I provide a bit more info about the "EEPROM read" on this controller?

According to the "DesignWare DW_apb_ssi Databook" (version 3.21b)
provided by Synopsys, the EEPROM read is:

"When TMOD = 2‘b11, the transmit data is used to transmit an opcode
and/or an address to the EEPROM
device. Typically this takes three data frames (8-bit opcode followed
by 8-bit upper address and 8-bit lower
address). During the transmission of the opcode and address, no data
is captured by the receive logic (as
long as the DW_apb_ssi master is transmitting data on its txd line,
data on the rxd line is ignored). The
DW_apb_ssi master continues to transmit data until the transmit FIFO
is empty. Therefore, you should
ONLY have enough data frames in the transmit FIFO to supply the opcode
and address to the EEPROM. If
more data frames are in the transmit FIFO than are needed, then read
data is lost.

When the transmit FIFO becomes empty (all control information has been
sent), data on the receive line
(rxd) is valid and is stored in the receive FIFO; the txd output is
held at a constant logic level. The serial
transfer continues until the number of data frames received by the
DW_apb_ssi master matches the value of
the NDF field in the CTRLR1 register + 1."
Regards,
Khoa Pham


On Wed, Jan 6, 2016 at 8:45 AM, Khoa Dang Pham <kpham@apm.com> wrote:
> Hi Mark,
>
> May I provide a bit more info about the "EEPROM read" on this controller?
>
> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
> by Synopsys, the EEPROM read is:
>
> "When TMOD = 2‘b11, the transmit data is used to transmit an opcode and/or
> an address to the EEPROM
> device. Typically this takes three data frames (8-bit opcode followed by
> 8-bit upper address and 8-bit lower
> address). During the transmission of the opcode and address, no data is
> captured by the receive logic (as
> long as the DW_apb_ssi master is transmitting data on its txd line, data on
> the rxd line is ignored). The
> DW_apb_ssi master continues to transmit data until the transmit FIFO is
> empty. Therefore, you should
> ONLY have enough data frames in the transmit FIFO to supply the opcode and
> address to the EEPROM. If
> more data frames are in the transmit FIFO than are needed, then read data is
> lost.
> When the transmit FIFO becomes empty (all control information has been
> sent), data on the receive line
> (rxd) is valid and is stored in the receive FIFO; the txd output is held at
> a constant logic level. The serial
> transfer continues until the number of data frames received by the
> DW_apb_ssi master matches the value of
> the NDF field in the CTRLR1 register + 1."
>
> Regards,
> Khoa Pham
>
> On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown <broonie@kernel.org> wrote:
>>
>> On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:
>> > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:
>> > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:
>>
>> > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is
>> > > > NULL, but we
>> > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution
>> > > > is to add and
>> > > > export one functions to set the tmode, then the nor flash driver
>> > > > call it
>> > > > before reading and set back to SPI_TMOD_TR after done.
>>
>> > > What does this mean - what is TMOD and why do we need to set it to
>> > > read
>> > > NOR flash?  I've no information on this controller...
>>
>> > TMOD is one field of DW_SPI_CTRL0. Its available value could be:
>>
>> > 0: Transmit and Receive
>> > 1: Transmit only
>> > 2: Receive only
>> > 3: EEPROM Read
>>
>> > If the one spi nor flash is connected to the SPI host, so far I can only
>> > succeed
>> > to read the nor flash content after setting the TMOD field as 3.
>>
>> Why?  What does this mean in practical terms at the hardware level, what
>> is "EEPROM read"?  It sounds like there's some bigger issue here.
>
>

-- 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
for the sole use of the intended recipient(s) and contains information that 
is confidential and proprietary to Applied Micro Circuits Corporation or 
its subsidiaries. It is to be used solely for the purpose of furthering the 
parties' business relationship. All unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302411

Dear Khoa, Mark,

On Wed, 6 Jan 2016 08:45:38 +0700 Khoa Dang Pham wrote:

> Hi Mark,
> 
> May I provide a bit more info about the "EEPROM read" on this controller?
> 
> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
> by Synopsys, the EEPROM read is:
> 
> "When TMOD = 2‘b11, the transmit data is used to transmit an opcode and/or
> an address to the EEPROM
> device. Typically this takes three data frames (8-bit opcode followed by
> 8-bit upper address and 8-bit lower
> address). During the transmission of the opcode and address, no data is
> captured by the receive logic (as
> long as the DW_apb_ssi master is transmitting data on its txd line, data on
> the rxd line is ignored). The
> DW_apb_ssi master continues to transmit data until the transmit FIFO is
> empty. Therefore, you should
> ONLY have enough data frames in the transmit FIFO to supply the opcode and
> address to the EEPROM. If
> more data frames are in the transmit FIFO than are needed, then read data
> is lost.
> When the transmit FIFO becomes empty (all control information has been
> sent), data on the receive line
> (rxd) is valid and is stored in the receive FIFO; the txd output is held at
> a constant logic level. The serial
> transfer continues until the number of data frames received by the
> DW_apb_ssi master matches the value of
> the NDF field in the CTRLR1 register + 1."

I tried the following combinations:

1. "Transmit only" to send opcode and address, "Receive only" to read the
response

2. "Transmit and Receive" to send opcode and address, "Receive only" to read
the response

3. "Transmit and Receive" to send opcode and address, "Transmit and Receive"
to read the response

4. "Transmit and Receive" only to send opcode and address

None of the above succeed. I only succeed when using

5. EEPROM Read to send opcode, address. I can get the correct NOR flash
content from the response.

Thanks,
Jisheng

> 
> Regards,
> Khoa Pham
> 
> On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown  wrote:
> 
> > On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:  
> > > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:  
> > > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:  
> >  
> > > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is  
> > NULL, but we  
> > > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution  
> > is to add and  
> > > > > export one functions to set the tmode, then the nor flash driver  
> > call it  
> > > > > before reading and set back to SPI_TMOD_TR after done.  
> >  
> > > > What does this mean - what is TMOD and why do we need to set it to read
> > > > NOR flash?  I've no information on this controller...  
> >  
> > > TMOD is one field of DW_SPI_CTRL0. Its available value could be:  
> >  
> > > 0: Transmit and Receive
> > > 1: Transmit only
> > > 2: Receive only
> > > 3: EEPROM Read  
> >  
> > > If the one spi nor flash is connected to the SPI host, so far I can only  
> > succeed  
> > > to read the nor flash content after setting the TMOD field as 3.  
> >
> > Why?  What does this mean in practical terms at the hardware level, what
> > is "EEPROM read"?  It sounds like there's some bigger issue here.
> >  
> 

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

[toc] | [prev] | [next] | [standalone]

#1302424

Hi Jisheng,

On Wed, Jan 6, 2016 at 1:23 PM, Jisheng Zhang <jszhang@marvell.com> wrote:
> Dear Khoa, Mark,
>
> On Wed, 6 Jan 2016 08:45:38 +0700 Khoa Dang Pham wrote:
>
>> Hi Mark,
>>
>> May I provide a bit more info about the "EEPROM read" on this controller?
>>
>> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
>> by Synopsys, the EEPROM read is:
>>
>> "When TMOD = 2‘b11, the transmit data is used to transmit an opcode and/or
>> an address to the EEPROM
>> device. Typically this takes three data frames (8-bit opcode followed by
>> 8-bit upper address and 8-bit lower
>> address). During the transmission of the opcode and address, no data is
>> captured by the receive logic (as
>> long as the DW_apb_ssi master is transmitting data on its txd line, data on
>> the rxd line is ignored). The
>> DW_apb_ssi master continues to transmit data until the transmit FIFO is
>> empty. Therefore, you should
>> ONLY have enough data frames in the transmit FIFO to supply the opcode and
>> address to the EEPROM. If
>> more data frames are in the transmit FIFO than are needed, then read data
>> is lost.
>> When the transmit FIFO becomes empty (all control information has been
>> sent), data on the receive line
>> (rxd) is valid and is stored in the receive FIFO; the txd output is held at
>> a constant logic level. The serial
>> transfer continues until the number of data frames received by the
>> DW_apb_ssi master matches the value of
>> the NDF field in the CTRLR1 register + 1."
>
> I tried the following combinations:
>
> 1. "Transmit only" to send opcode and address, "Receive only" to read the
> response
>
> 2. "Transmit and Receive" to send opcode and address, "Receive only" to read
> the response
>
> 3. "Transmit and Receive" to send opcode and address, "Transmit and Receive"
> to read the response
>
> 4. "Transmit and Receive" only to send opcode and address
>
> None of the above succeed. I only succeed when using
>
> 5. EEPROM Read to send opcode, address. I can get the correct NOR flash
> content from the response.
>

I met the same issue before. The issue might be caused by the CS
signal is toggled
when we changed the transfer modes during opcode transmission and data
receiption.

According to the document I referred before:
"The slave select line is held high when the DW_apb_ssi is idle or
disabled."

In your first 4 options, you need to disable this controller to write
to the CTRLR0 register
in order to switch the transfer modes. The CS line changes from low
level (active) to high
level (inactive) during the configuration. The NOR flash sees this CS
toggle as a reset and
stops outputting requested data.

Regards,
Khoa Pham

> Thanks,
> Jisheng
>
>>
>> Regards,
>> Khoa Pham
>>
>> On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown  wrote:
>>
>> > On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:
>> > > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:
>> > > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:
>> >
>> > > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is
>> > NULL, but we
>> > > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution
>> > is to add and
>> > > > > export one functions to set the tmode, then the nor flash driver
>> > call it
>> > > > > before reading and set back to SPI_TMOD_TR after done.
>> >
>> > > > What does this mean - what is TMOD and why do we need to set it to read
>> > > > NOR flash?  I've no information on this controller...
>> >
>> > > TMOD is one field of DW_SPI_CTRL0. Its available value could be:
>> >
>> > > 0: Transmit and Receive
>> > > 1: Transmit only
>> > > 2: Receive only
>> > > 3: EEPROM Read
>> >
>> > > If the one spi nor flash is connected to the SPI host, so far I can only
>> > succeed
>> > > to read the nor flash content after setting the TMOD field as 3.
>> >
>> > Why?  What does this mean in practical terms at the hardware level, what
>> > is "EEPROM read"?  It sounds like there's some bigger issue here.
>> >
>>
>

-- 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
for the sole use of the intended recipient(s) and contains information that 
is confidential and proprietary to Applied Micro Circuits Corporation or 
its subsidiaries. It is to be used solely for the purpose of furthering the 
parties' business relationship. All unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302435

Dear Khoa,

On Wed, 6 Jan 2016 14:04:30 +0700 Khoa Dang Pham wrote:

> Hi Jisheng,
> 
> On Wed, Jan 6, 2016 at 1:23 PM, Jisheng Zhang wrote:
> > Dear Khoa, Mark,
> >
> > On Wed, 6 Jan 2016 08:45:38 +0700 Khoa Dang Pham wrote:
> >  
> >> Hi Mark,
> >>
> >> May I provide a bit more info about the "EEPROM read" on this controller?
> >>
> >> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
> >> by Synopsys, the EEPROM read is:
> >>
> >> "When TMOD = 2‘b11, the transmit data is used to transmit an opcode and/or
> >> an address to the EEPROM
> >> device. Typically this takes three data frames (8-bit opcode followed by
> >> 8-bit upper address and 8-bit lower
> >> address). During the transmission of the opcode and address, no data is
> >> captured by the receive logic (as
> >> long as the DW_apb_ssi master is transmitting data on its txd line, data on
> >> the rxd line is ignored). The
> >> DW_apb_ssi master continues to transmit data until the transmit FIFO is
> >> empty. Therefore, you should
> >> ONLY have enough data frames in the transmit FIFO to supply the opcode and
> >> address to the EEPROM. If
> >> more data frames are in the transmit FIFO than are needed, then read data
> >> is lost.
> >> When the transmit FIFO becomes empty (all control information has been
> >> sent), data on the receive line
> >> (rxd) is valid and is stored in the receive FIFO; the txd output is held at
> >> a constant logic level. The serial
> >> transfer continues until the number of data frames received by the
> >> DW_apb_ssi master matches the value of
> >> the NDF field in the CTRLR1 register + 1."  
> >
> > I tried the following combinations:
> >
> > 1. "Transmit only" to send opcode and address, "Receive only" to read the
> > response
> >
> > 2. "Transmit and Receive" to send opcode and address, "Receive only" to read
> > the response
> >
> > 3. "Transmit and Receive" to send opcode and address, "Transmit and Receive"
> > to read the response
> >
> > 4. "Transmit and Receive" only to send opcode and address
> >
> > None of the above succeed. I only succeed when using
> >
> > 5. EEPROM Read to send opcode, address. I can get the correct NOR flash
> > content from the response.
> >  
> 
> I met the same issue before. The issue might be caused by the CS
> signal is toggled
> when we changed the transfer modes during opcode transmission and data
> receiption.
> 
> According to the document I referred before:
> "The slave select line is held high when the DW_apb_ssi is idle or
> disabled."
> 
> In your first 4 options, you need to disable this controller to write
> to the CTRLR0 register
> in order to switch the transfer modes. The CS line changes from low
> level (active) to high
> level (inactive) during the configuration. The NOR flash sees this CS
> toggle as a reset and
> stops outputting requested data.

Thanks for the information. This could explain what I saw. So how to
patch the spi-dw driver to support reading from NOR flash? Except
configure the tmode dynamically, is there any other solution?

Thanks very much for your input,
Jisheng

> 
> Regards,
> Khoa Pham
> 
> > Thanks,
> > Jisheng
> >  
> >>
> >> Regards,
> >> Khoa Pham
> >>
> >> On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown  wrote:
> >>  
> >> > On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:  
> >> > > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:  
> >> > > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:  
> >> >  
> >> > > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is  
> >> > NULL, but we  
> >> > > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution  
> >> > is to add and  
> >> > > > > export one functions to set the tmode, then the nor flash driver  
> >> > call it  
> >> > > > > before reading and set back to SPI_TMOD_TR after done.  
> >> >  
> >> > > > What does this mean - what is TMOD and why do we need to set it to read
> >> > > > NOR flash?  I've no information on this controller...  
> >> >  
> >> > > TMOD is one field of DW_SPI_CTRL0. Its available value could be:  
> >> >  
> >> > > 0: Transmit and Receive
> >> > > 1: Transmit only
> >> > > 2: Receive only
> >> > > 3: EEPROM Read  
> >> >  
> >> > > If the one spi nor flash is connected to the SPI host, so far I can only  
> >> > succeed  
> >> > > to read the nor flash content after setting the TMOD field as 3.  
> >> >
> >> > Why?  What does this mean in practical terms at the hardware level, what
> >> > is "EEPROM read"?  It sounds like there's some bigger issue here.
> >> >  
> >>  
> >  
> 

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

[toc] | [prev] | [next] | [standalone]

#1302437

Hi Jisheng,

For me, I use the "EEPROM Read" mode as well, but I am not sure if any
other solution. We may need some feedbacks from other experienced
developers.
Could you please provide your solution? Any suggestion would be appreciated.
Regards,
Khoa Pham


On Wed, Jan 6, 2016 at 2:22 PM, Jisheng Zhang <jszhang@marvell.com> wrote:
> Dear Khoa,
>
> On Wed, 6 Jan 2016 14:04:30 +0700 Khoa Dang Pham wrote:
>
>> Hi Jisheng,
>>
>> On Wed, Jan 6, 2016 at 1:23 PM, Jisheng Zhang wrote:
>> > Dear Khoa, Mark,
>> >
>> > On Wed, 6 Jan 2016 08:45:38 +0700 Khoa Dang Pham wrote:
>> >
>> >> Hi Mark,
>> >>
>> >> May I provide a bit more info about the "EEPROM read" on this controller?
>> >>
>> >> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
>> >> by Synopsys, the EEPROM read is:
>> >>
>> >> "When TMOD = 2‘b11, the transmit data is used to transmit an opcode and/or
>> >> an address to the EEPROM
>> >> device. Typically this takes three data frames (8-bit opcode followed by
>> >> 8-bit upper address and 8-bit lower
>> >> address). During the transmission of the opcode and address, no data is
>> >> captured by the receive logic (as
>> >> long as the DW_apb_ssi master is transmitting data on its txd line, data on
>> >> the rxd line is ignored). The
>> >> DW_apb_ssi master continues to transmit data until the transmit FIFO is
>> >> empty. Therefore, you should
>> >> ONLY have enough data frames in the transmit FIFO to supply the opcode and
>> >> address to the EEPROM. If
>> >> more data frames are in the transmit FIFO than are needed, then read data
>> >> is lost.
>> >> When the transmit FIFO becomes empty (all control information has been
>> >> sent), data on the receive line
>> >> (rxd) is valid and is stored in the receive FIFO; the txd output is held at
>> >> a constant logic level. The serial
>> >> transfer continues until the number of data frames received by the
>> >> DW_apb_ssi master matches the value of
>> >> the NDF field in the CTRLR1 register + 1."
>> >
>> > I tried the following combinations:
>> >
>> > 1. "Transmit only" to send opcode and address, "Receive only" to read the
>> > response
>> >
>> > 2. "Transmit and Receive" to send opcode and address, "Receive only" to read
>> > the response
>> >
>> > 3. "Transmit and Receive" to send opcode and address, "Transmit and Receive"
>> > to read the response
>> >
>> > 4. "Transmit and Receive" only to send opcode and address
>> >
>> > None of the above succeed. I only succeed when using
>> >
>> > 5. EEPROM Read to send opcode, address. I can get the correct NOR flash
>> > content from the response.
>> >
>>
>> I met the same issue before. The issue might be caused by the CS
>> signal is toggled
>> when we changed the transfer modes during opcode transmission and data
>> receiption.
>>
>> According to the document I referred before:
>> "The slave select line is held high when the DW_apb_ssi is idle or
>> disabled."
>>
>> In your first 4 options, you need to disable this controller to write
>> to the CTRLR0 register
>> in order to switch the transfer modes. The CS line changes from low
>> level (active) to high
>> level (inactive) during the configuration. The NOR flash sees this CS
>> toggle as a reset and
>> stops outputting requested data.
>
> Thanks for the information. This could explain what I saw. So how to
> patch the spi-dw driver to support reading from NOR flash? Except
> configure the tmode dynamically, is there any other solution?
>
> Thanks very much for your input,
> Jisheng
>
>>
>> Regards,
>> Khoa Pham
>>
>> > Thanks,
>> > Jisheng
>> >
>> >>
>> >> Regards,
>> >> Khoa Pham
>> >>
>> >> On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown  wrote:
>> >>
>> >> > On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:
>> >> > > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:
>> >> > > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:
>> >> >
>> >> > > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is
>> >> > NULL, but we
>> >> > > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution
>> >> > is to add and
>> >> > > > > export one functions to set the tmode, then the nor flash driver
>> >> > call it
>> >> > > > > before reading and set back to SPI_TMOD_TR after done.
>> >> >
>> >> > > > What does this mean - what is TMOD and why do we need to set it to read
>> >> > > > NOR flash?  I've no information on this controller...
>> >> >
>> >> > > TMOD is one field of DW_SPI_CTRL0. Its available value could be:
>> >> >
>> >> > > 0: Transmit and Receive
>> >> > > 1: Transmit only
>> >> > > 2: Receive only
>> >> > > 3: EEPROM Read
>> >> >
>> >> > > If the one spi nor flash is connected to the SPI host, so far I can only
>> >> > succeed
>> >> > > to read the nor flash content after setting the TMOD field as 3.
>> >> >
>> >> > Why?  What does this mean in practical terms at the hardware level, what
>> >> > is "EEPROM read"?  It sounds like there's some bigger issue here.
>> >> >
>> >>
>> >
>>
>

-- 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
for the sole use of the intended recipient(s) and contains information that 
is confidential and proprietary to Applied Micro Circuits Corporation or 
its subsidiaries. It is to be used solely for the purpose of furthering the 
parties' business relationship. All unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302439

+ linux arm kernel

Dear Khoa,

On Wed, 6 Jan 2016 14:36:08 +0700 Khoa Dang Pham  wrote:

> Hi Jisheng,
> 
> For me, I use the "EEPROM Read" mode as well, but I am not sure if any
> other solution. We may need some feedbacks from other experienced
> developers.

Indeed, this is a common issue for spi-dw controllers, all spi-dw users
(FWICT, most users are arm based SoCs) are impacted.

> Could you please provide your solution? Any suggestion would be appreciated.

My solution is: implement and export one function dw_spi_set_mode(),
NOR flash driver call this function before and after transfer.

Thanks,
Jisheng

> Regards,
> Khoa Pham
> 
> 
> On Wed, Jan 6, 2016 at 2:22 PM, Jisheng Zhang <jszhang@marvell.com> wrote:
> > Dear Khoa,
> >
> > On Wed, 6 Jan 2016 14:04:30 +0700 Khoa Dang Pham wrote:
> >  
> >> Hi Jisheng,
> >>
> >> On Wed, Jan 6, 2016 at 1:23 PM, Jisheng Zhang wrote:  
> >> > Dear Khoa, Mark,
> >> >
> >> > On Wed, 6 Jan 2016 08:45:38 +0700 Khoa Dang Pham wrote:
> >> >  
> >> >> Hi Mark,
> >> >>
> >> >> May I provide a bit more info about the "EEPROM read" on this controller?
> >> >>
> >> >> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
> >> >> by Synopsys, the EEPROM read is:
> >> >>
> >> >> "When TMOD = 2‘b11, the transmit data is used to transmit an opcode and/or
> >> >> an address to the EEPROM
> >> >> device. Typically this takes three data frames (8-bit opcode followed by
> >> >> 8-bit upper address and 8-bit lower
> >> >> address). During the transmission of the opcode and address, no data is
> >> >> captured by the receive logic (as
> >> >> long as the DW_apb_ssi master is transmitting data on its txd line, data on
> >> >> the rxd line is ignored). The
> >> >> DW_apb_ssi master continues to transmit data until the transmit FIFO is
> >> >> empty. Therefore, you should
> >> >> ONLY have enough data frames in the transmit FIFO to supply the opcode and
> >> >> address to the EEPROM. If
> >> >> more data frames are in the transmit FIFO than are needed, then read data
> >> >> is lost.
> >> >> When the transmit FIFO becomes empty (all control information has been
> >> >> sent), data on the receive line
> >> >> (rxd) is valid and is stored in the receive FIFO; the txd output is held at
> >> >> a constant logic level. The serial
> >> >> transfer continues until the number of data frames received by the
> >> >> DW_apb_ssi master matches the value of
> >> >> the NDF field in the CTRLR1 register + 1."  
> >> >
> >> > I tried the following combinations:
> >> >
> >> > 1. "Transmit only" to send opcode and address, "Receive only" to read the
> >> > response
> >> >
> >> > 2. "Transmit and Receive" to send opcode and address, "Receive only" to read
> >> > the response
> >> >
> >> > 3. "Transmit and Receive" to send opcode and address, "Transmit and Receive"
> >> > to read the response
> >> >
> >> > 4. "Transmit and Receive" only to send opcode and address
> >> >
> >> > None of the above succeed. I only succeed when using
> >> >
> >> > 5. EEPROM Read to send opcode, address. I can get the correct NOR flash
> >> > content from the response.
> >> >  
> >>
> >> I met the same issue before. The issue might be caused by the CS
> >> signal is toggled
> >> when we changed the transfer modes during opcode transmission and data
> >> receiption.
> >>
> >> According to the document I referred before:
> >> "The slave select line is held high when the DW_apb_ssi is idle or
> >> disabled."
> >>
> >> In your first 4 options, you need to disable this controller to write
> >> to the CTRLR0 register
> >> in order to switch the transfer modes. The CS line changes from low
> >> level (active) to high
> >> level (inactive) during the configuration. The NOR flash sees this CS
> >> toggle as a reset and
> >> stops outputting requested data.  
> >
> > Thanks for the information. This could explain what I saw. So how to
> > patch the spi-dw driver to support reading from NOR flash? Except
> > configure the tmode dynamically, is there any other solution?
> >
> > Thanks very much for your input,
> > Jisheng
> >  
> >>
> >> Regards,
> >> Khoa Pham
> >>  
> >> > Thanks,
> >> > Jisheng
> >> >  
> >> >>
> >> >> Regards,
> >> >> Khoa Pham
> >> >>
> >> >> On Tue, Jan 5, 2016 at 11:12 PM, Mark Brown  wrote:
> >> >>  
> >> >> > On Wed, Dec 23, 2015 at 08:29:52PM +0800, Jisheng Zhang wrote:  
> >> >> > > On Wed, 23 Dec 2015 12:15:12 +0000 Mark Brown wrote:  
> >> >> > > > On Wed, Dec 23, 2015 at 07:23:38PM +0800, Jisheng Zhang wrote:  
> >> >> >  
> >> >> > > > > Currently the spi-dw tmode is fixed to SPI_TMOD_TR if cs_control is  
> >> >> > NULL, but we  
> >> >> > > > > need to set it as SPI_TMOD_EPROMREAD to read nor flash, my solution  
> >> >> > is to add and  
> >> >> > > > > export one functions to set the tmode, then the nor flash driver  
> >> >> > call it  
> >> >> > > > > before reading and set back to SPI_TMOD_TR after done.  
> >> >> >  
> >> >> > > > What does this mean - what is TMOD and why do we need to set it to read
> >> >> > > > NOR flash?  I've no information on this controller...  
> >> >> >  
> >> >> > > TMOD is one field of DW_SPI_CTRL0. Its available value could be:  
> >> >> >  
> >> >> > > 0: Transmit and Receive
> >> >> > > 1: Transmit only
> >> >> > > 2: Receive only
> >> >> > > 3: EEPROM Read  
> >> >> >  
> >> >> > > If the one spi nor flash is connected to the SPI host, so far I can only  
> >> >> > succeed  
> >> >> > > to read the nor flash content after setting the TMOD field as 3.  
> >> >> >
> >> >> > Why?  What does this mean in practical terms at the hardware level, what
> >> >> > is "EEPROM read"?  It sounds like there's some bigger issue here.
> >> >> >  
> >> >>  
> >> >  
> >>  
> >  
> 

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

[toc] | [prev] | [next] | [standalone]

#1302714

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jan 06, 2016 at 08:45:38AM +0700, Khoa Dang Pham wrote:
> Hi Mark,

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> According to the "DesignWare DW_apb_ssi Databook" (version 3.21b) provided
> by Synopsys, the EEPROM read is:

> "When TMOD = 2‘b11, the transmit data is used to transmit an opcode and/or
> an address to the EEPROM
> device. Typically this takes three data frames (8-bit opcode followed by
> 8-bit upper address and 8-bit lower
> address). During the transmission of the opcode and address, no data is
> captured by the receive logic (as
> long as the DW_apb_ssi master is transmitting data on its txd line, data on
> the rxd line is ignored). The

This is just a normal data transfer, if the driver is functioning
correctly this should not be required and requiring it would mean that
we'd need to go round adding workarounds for this to lots of client
drivers.  It seems like you are trying to work around some other bug in
the driver, quite possibly incorrect handling of chip select as was
suggested elsewhere.  If that is the case a common solution is to manage
the chip select as a GPIO rather than with the built in handling in the
block if the block can't cope.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web