100 capsules compatibles Nespresso a 21 euros
Si le message ne s'affiche pas correctement merci de suivre ce lien: http://news.teradoo.com/re?l=BD0Iqgrb85I7gfk57dIhlxgskppIu=http%3A%2F%2Fnews.teradoo.com%2Fpublic%2Fread_message.jsp%3Ftsp%3D1379926809587%26custid%3D16444%26uid%3D16231069273%26sig%3DFKKJBKIEBEDAMMHI%26mid%3D1600268693s=JFKEGKMHODPFEKCN 100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros100 capsules compatibles Nespresso a 21 euros Si vous ne souhaitez plus recevoir de newsletter de notre part, veuillez accéder à la page: http://news.teradoo.com/public/unsubscribe.jsp?gid=1600034637uid=16231069273mid=1600268693sig=KANDNCEBMFLFFFHO -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
Re: [RESEND] spi/tegra114: Correct support for cs_change
On 09/23/2013 01:48 PM, Rhyland Klein wrote:
On 9/23/2013 2:51 PM, Stephen Warren wrote:
On 09/18/2013 12:17 PM, Rhyland Klein wrote:
The tegra114 driver wasn't currently handling the cs_change functionality.
It is meant to invert normal behavior, and we were only using it to possibly
delay at the end of a transfer.
...
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
...
@@ -717,7 +718,12 @@ static int tegra_spi_start_transfer_one(struct
spi_device *spi,
else if (req_mode == SPI_MODE_3)
command1 |= SPI_CONTROL_MODE_3;
- tegra_spi_writel(tspi, command1, SPI_COMMAND1);
+ if (tspi-cs_control) {
+ if (tspi-cs_control != spi)
+ tegra_spi_writel(tspi, command1, SPI_COMMAND1);
Do you really need a separate write call there? The value of command1
isn't fully set up there (the CS bits are all set up immediately after),
so won't that glitch the CS lines in some cases?
On our hardware (as far as I've seen), the CS line is normally low. We
I assume you meant normally *active* low, not normally low?
need to generate a falling-edge to trigger the beginning of a SPI
transaction. Doing this write with the default value of SPI_COMMAND1
causes a brief rise and fall of CS, giving us our falling-edge.
That sounds like exactly the glitch I was talking about.
Assuming CS isn't held constantly asserted (low), isn't CS de-asserted
(rises) at the end of transaction n-1, and re-asserted (falls) at the
start of transaction n? If so, I'm not sure why the setup for
transaction n needs to both de-assert and then re-assert it? It seems
like cs_control should be handled at the end of a transaction, not at
the start of the next one.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [RESEND] spi/tegra114: Correct support for cs_change
On 9/23/2013 2:51 PM, Stephen Warren wrote:
On 09/18/2013 12:17 PM, Rhyland Klein wrote:
The tegra114 driver wasn't currently handling the cs_change functionality.
It is meant to invert normal behavior, and we were only using it to possibly
delay at the end of a transfer.
I don't really follow this patch description well. It may help if you
fully spelled out the definition of normal behaviour, what the driver
was doing, and what it should be doing (which is presumable what it does
do after this patch).
Yah, I'll explain the cs_change logic a little clearer in the next
version, but for now:
cs_change is meant to invert the normal behavior of the CS line during a
SPI transfer. Normally, the CS line stays asserted from the beginning of
the first transfer until the last is completed within the same
spi_message, and then it is deasserted. There can be any number of
spi_transfers within a spi_message. When cs_change is asserted for a
spi_transfer that is not the last one in the message, this means that
after that transfer is completed, the CS line should be deasserted
(where normally it would stay asserted). Then when the next transfer
starts, it will assert CS again. If the last spi_transfer in a
spi_message has cs_change set, then it means that instead of deasserted
CS at the end of the transaction (spi_message) then it leaves CS asserted.
This patch modifies the logic so that the cs state will be toggled after
every individual transfer or NOT toggled at the end of the last transfer
if cs_change is set in that transfer struct.
Also, this builds in logic so that if a different device tries to start
a transfer while CS is active from a different device, it will abort the
previous transfer and start a new one for the new device.
What user-visible impact does this patch have. Does it solve a bug, or
improve performance, or ...? In other words, how would I test this
patch, other that testing for regressions in SPI functionality that I
know already works.
This allows a spi client to send a write, and then any number of reads
as a single spi transaction, but separated into separate spi_messages. I
tested this for ChromeOS where our platform has an embedded controller
which communicates over SPI. It has some quirks, namely when we read
back data, we maybe need to do multiple reads before we start getting
valid data. This means we need to be able to control when the CS line is
deasserted which would be after we know we finally received all the data
we were expecting.
I don't know of any other hardware currently that is good for exercising
this logic on our reference boards.
BTW, I don't think you're using get_maintainer.pl, since Mark Brown is
the SPI maintainer now, not Grant Likely.
I could have sworn I ran it, but I didn't see Mark come up, I'll
definitely add him for the next revision.
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 145dd43..a9973de 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -182,6 +182,7 @@ struct tegra_spi_data {
u32 cur_speed;
struct spi_device *cur_spi;
+struct spi_device *cs_control;
unsignedcur_pos;
unsignedcur_len;
unsignedwords_per_32bit;
@@ -717,7 +718,12 @@ static int tegra_spi_start_transfer_one(struct
spi_device *spi,
else if (req_mode == SPI_MODE_3)
command1 |= SPI_CONTROL_MODE_3;
-tegra_spi_writel(tspi, command1, SPI_COMMAND1);
+if (tspi-cs_control) {
+if (tspi-cs_control != spi)
+tegra_spi_writel(tspi, command1, SPI_COMMAND1);
Do you really need a separate write call there? The value of command1
isn't fully set up there (the CS bits are all set up immediately after),
so won't that glitch the CS lines in some cases?
On our hardware (as far as I've seen), the CS line is normally low. We
need to generate a falling-edge to trigger the beginning of a SPI
transaction. Doing this write with the default value of SPI_COMMAND1
causes a brief rise and fall of CS, giving us our falling-edge.
+tspi-cs_control = NULL;
+} else
+tegra_spi_writel(tspi, command1, SPI_COMMAND1);
command1 |= SPI_CS_SW_HW;
if (spi-mode SPI_CS_HIGH)
@@ -732,6 +738,9 @@ static int tegra_spi_start_transfer_one(struct
spi_device *spi,
command1 |= SPI_BIT_LENGTH(bits_per_word - 1);
}
+if (t-len == 0 !t-tx_buf !t-rx_buf)
+return 0;
What if !t-len, but t-tx_buf || t-rx_buf ?
This code is also duplicated in tegra_spi_transfer_one_message() after
this patch. Instead, perhaps the first N lines of
tegra_spi_start_transfer_one() should be split out into
Re: [RESEND] spi/tegra114: Correct support for cs_change
Hi,
On Mon, Sep 23, 2013 at 3:14 PM, Stephen Warren swar...@wwwdotorg.orgwrote:
On 09/23/2013 03:01 PM, Rhyland Klein wrote:
On 9/23/2013 3:58 PM, Stephen Warren wrote:
On 09/23/2013 01:48 PM, Rhyland Klein wrote:
On 9/23/2013 2:51 PM, Stephen Warren wrote:
On 09/18/2013 12:17 PM, Rhyland Klein wrote:
The tegra114 driver wasn't currently handling the cs_change
functionality.
It is meant to invert normal behavior, and we were only using it to
possibly
delay at the end of a transfer.
...
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
...
@@ -717,7 +718,12 @@ static int tegra_spi_start_transfer_one(struct
spi_device *spi,
else if (req_mode == SPI_MODE_3)
command1 |= SPI_CONTROL_MODE_3;
- tegra_spi_writel(tspi, command1, SPI_COMMAND1);
+ if (tspi-cs_control) {
+ if (tspi-cs_control != spi)
+ tegra_spi_writel(tspi, command1,
SPI_COMMAND1);
Do you really need a separate write call there? The value of command1
isn't fully set up there (the CS bits are all set up immediately
after),
so won't that glitch the CS lines in some cases?
On our hardware (as far as I've seen), the CS line is normally low. We
I assume you meant normally *active* low, not normally low?
I mean that when I look at CS, before a transaction starts, the line is
low. Then we do a write like this (default SPI_COMMAND1) you see CS rise
and fall very soon after. This is purely how we generate the edge
triggers (as far as I can tell on all Tegra hw, though Laxman can
correct me if I am wrong).
That sounds broken. Normally, shouldn't CS assert before a transaction,
stay asserted during a transaction, then deassert after the transaction?
It shouldn't rise and fall very quickly in between parts of the
transaction.
need to generate a falling-edge to trigger the beginning of a SPI
transaction. Doing this write with the default value of SPI_COMMAND1
causes a brief rise and fall of CS, giving us our falling-edge.
That sounds like exactly the glitch I was talking about.
Assuming CS isn't held constantly asserted (low), isn't CS de-asserted
(rises) at the end of transaction n-1, and re-asserted (falls) at the
start of transaction n? If so, I'm not sure why the setup for
transaction n needs to both de-assert and then re-assert it? It seems
like cs_control should be handled at the end of a transaction, not at
the start of the next one.
cs_change has to maintain state over spi_message boundries, not just
between spi_transfers within a spi_message.
In this specific case, this is a safe guard.
+ if (tspi-cs_control) {
This sees that the previous transfer stored its spi_device pointer,
meaning it had cs_change set on the last part of the last spi_message
(I.E. CS hasn't been deasserted, so the SPI transaction is still
on-going).
+ if (tspi-cs_control != spi)
This however finds that the device trying to send a SPI message isn't
the same one that was in the middle of its transaction. This is a
collision between 2 clients on 1 bus. This simply ends the previous
transaction (the ongoing one) in favor of starting a new transaction.
Otherwise, this logic allows us to skip the spi of COMMAND1 which would
normally be used to create the falling edge to start a new transaction,
leaving the previous one open for more transfers.
This sounds like something the SPI core should be managing. If a driver
is using the SPI bus to communicate with a device in a way that needs CS
left active while outside a transaction, it shouldn't be possible for
another driver to come along and communicate with another device before
the first transaction is all complete. The bus should be locked.
Allowing anything else could corrupt the protocol that required specific
CS states outside the transaction.
Perhaps the client driver should use spi_sync_locked() instead if it wants
to avoid this problem? To me this driver code seems reasonable in the
circumstances.
Note: at present the Chrome OS EC driver does not support sharing a SPI bus
with anything else, and neither does the EC.
Regards,
Simon
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [RESEND] spi/tegra114: Correct support for cs_change
[trying again]
Hi,
On Mon, Sep 23, 2013 at 3:14 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 09/23/2013 03:01 PM, Rhyland Klein wrote:
On 9/23/2013 3:58 PM, Stephen Warren wrote:
On 09/23/2013 01:48 PM, Rhyland Klein wrote:
On 9/23/2013 2:51 PM, Stephen Warren wrote:
On 09/18/2013 12:17 PM, Rhyland Klein wrote:
The tegra114 driver wasn't currently handling the cs_change
functionality.
It is meant to invert normal behavior, and we were only using it to
possibly
delay at the end of a transfer.
...
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
...
@@ -717,7 +718,12 @@ static int tegra_spi_start_transfer_one(struct
spi_device *spi,
else if (req_mode == SPI_MODE_3)
command1 |= SPI_CONTROL_MODE_3;
- tegra_spi_writel(tspi, command1, SPI_COMMAND1);
+ if (tspi-cs_control) {
+ if (tspi-cs_control != spi)
+ tegra_spi_writel(tspi, command1, SPI_COMMAND1);
Do you really need a separate write call there? The value of command1
isn't fully set up there (the CS bits are all set up immediately after),
so won't that glitch the CS lines in some cases?
On our hardware (as far as I've seen), the CS line is normally low. We
I assume you meant normally *active* low, not normally low?
I mean that when I look at CS, before a transaction starts, the line is
low. Then we do a write like this (default SPI_COMMAND1) you see CS rise
and fall very soon after. This is purely how we generate the edge
triggers (as far as I can tell on all Tegra hw, though Laxman can
correct me if I am wrong).
That sounds broken. Normally, shouldn't CS assert before a transaction,
stay asserted during a transaction, then deassert after the transaction?
It shouldn't rise and fall very quickly in between parts of the transaction.
need to generate a falling-edge to trigger the beginning of a SPI
transaction. Doing this write with the default value of SPI_COMMAND1
causes a brief rise and fall of CS, giving us our falling-edge.
That sounds like exactly the glitch I was talking about.
Assuming CS isn't held constantly asserted (low), isn't CS de-asserted
(rises) at the end of transaction n-1, and re-asserted (falls) at the
start of transaction n? If so, I'm not sure why the setup for
transaction n needs to both de-assert and then re-assert it? It seems
like cs_control should be handled at the end of a transaction, not at
the start of the next one.
cs_change has to maintain state over spi_message boundries, not just
between spi_transfers within a spi_message.
In this specific case, this is a safe guard.
+ if (tspi-cs_control) {
This sees that the previous transfer stored its spi_device pointer,
meaning it had cs_change set on the last part of the last spi_message
(I.E. CS hasn't been deasserted, so the SPI transaction is still on-going).
+ if (tspi-cs_control != spi)
This however finds that the device trying to send a SPI message isn't
the same one that was in the middle of its transaction. This is a
collision between 2 clients on 1 bus. This simply ends the previous
transaction (the ongoing one) in favor of starting a new transaction.
Otherwise, this logic allows us to skip the spi of COMMAND1 which would
normally be used to create the falling edge to start a new transaction,
leaving the previous one open for more transfers.
This sounds like something the SPI core should be managing. If a driver
is using the SPI bus to communicate with a device in a way that needs CS
left active while outside a transaction, it shouldn't be possible for
another driver to come along and communicate with another device before
the first transaction is all complete. The bus should be locked.
Allowing anything else could corrupt the protocol that required specific
CS states outside the transaction.
Perhaps the client driver should use spi_sync_locked() instead if it
wants to avoid this problem? To me this driver code seems reasonable
in the circumstances.
Note: at present the Chrome OS EC driver does not support sharing a
SPI bus with anything else, and neither does the EC.
Regards,
Simon
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
