On Wed, Dec 06, 2017 at 07:32:43AM -0600, Pierre-Louis Bossart wrote:
> On 12/5/17 11:58 PM, Vinod Koul wrote:
> >On Tue, Dec 05, 2017 at 08:48:03AM -0600, Pierre-Louis Bossart wrote:
> >>On 12/5/17 7:43 AM, Pierre-Louis Bossart wrote:
> >>>On 12/5/17 12:31 AM, Vinod Koul wrote:
> >>>>On Sun, Dec 03, 2017 at 09:01:41PM -0600, Pierre-Louis Bossart wrote:
> >
> >>>>>>>>+static inline int do_transfer(struct sdw_bus *bus, struct
> >>>>>>>>sdw_msg *msg)
> >>>>>>>>+{
> >>>>>>>>+ int retry = bus->prop.err_threshold;
> >>>>>>>>+ enum sdw_command_response resp;
> >>>>>>>>+ int ret = 0, i;
> >>>>>>>>+
> >>>>>>>>+ for (i = 0; i <= retry; i++) {
> >>>>>>>>+ resp = bus->ops->xfer_msg(bus, msg);
> >>>>>>>>+ ret = find_response_code(resp);
> >>>>>>>>+
> >>>>>>>>+ /* if cmd is ok or ignored return */
> >>>>>>>>+ if (ret == 0 || ret == -ENODATA)
> >>>>>>>
> >>>>>>>Can you document why you don't retry on a CMD_IGNORED? I know
> >>>>>>>there was a
> >>>>>>>reason, I just can't remember it.
> >>>>>>
> >>>>>>CMD_IGNORED can be okay on broadcast. User of this API can retry all
> >>>>>>they
> >>>>>>want!
> >>>>>
> >>>>>So you retry if this is a CMD_FAILED but let higher levels retry for
> >>>>>CMD_IGNORED, sorry I don't see the logic.
> >>>>
> >>>>Yes that is right.
> >>>>
> >>>>If I am doing a broadcast read, lets say for Device Id registers, why in
> >>>>the
> >>>>world would I want to retry? CMD_IGNORED is a valid response and
> >>>>required to
> >>>>stop enumeration cycle in that case.
> >
> >Above is the clarfication
> >
> >>>>But if I am not expecting a CMD_IGNORED response, I can very well go
> >>>>ahead
> >>>>and retry from caller. The context is with caller and they can choose to
> >>>>do
> >>>>appropriate handling.
> >>>>
> >>>>And I have clarified this couple of times to you already, not sure how
> >>>>many
> >>>>more times I would have to do that.
> >>>
> >>>Until you clarify what you are doing.
> >
> >Let me try again, I think u missed that part of my reply above
> >
> >If I am doing a broadcast read, lets say for Device Id registers,
> >why in the world would I want to retry? CMD_IGNORED is a valid response
> >and required to stop enumeration cycle in that case.
> >
> >>>There is ONE case where IGNORED is a valid answer (reading the Prepare not
> >>>finished bits), and it should not only be documented but analyzed in more
> >>>details.
> >>I meant Read SCP_DevID registers from Device0... prepare bits should never
> >>return a CMD_IGNORED
> >
> >Precisely as I pointed out above.
> >
> >>>For a write an IGNORED is never OK.
> >
> >Agreed, but then transfer does both read and write. Write call can treat it
> >as error and read call leaves it upto caller.
> >
> >Does that sound okay for you?
>
> Not really.
> You have one case where it's ok and all others are not ok, to me this sounds
> like you should avoid the retry at the lowest level rather than pushing this
> to the caller
> And now that I think of it, the definitions for the DisCo spec were really
> meant for hardware-based retries available in some master IPs. If this is
> enabled, then the loops in software are not really needed at all. Can you
> please check this point?
Sure I will check that
--
~Vinod
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
