From: Andrew Lunn <andrew@lunn.ch>
To: Chen-Yu Tsai <wens@csie.org>
Cc: "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
Gregory Clement <gregory.clement@bootlin.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Maxime Ripard <mripard@kernel.org>
Subject: Re: No master_xfer_atomic for i2c-mv64xxx.c
Date: Tue, 21 Jan 2020 15:40:19 +0100 [thread overview]
Message-ID: <20200121144019.GD16902@lunn.ch> (raw)
In-Reply-To: <CAGb2v65Kz0ymDapbyJ_WTebEGOs5=wkqMXUZV-mQJhdKr8ZGhA@mail.gmail.com>
> > However, I'm not entirely sure how we could implement it without
> > sleeping. The controller is basically a state machine that triggers an
> > interrupt on each state change, so you first set the address, get an
> > interrupt, then set the direction, then you get an interrupt, etc.
> >
> > I guess we could implement it using polling, but I'm not sure if
> > that's wise in an interrupt context either.
>
> I believe that is actually how some of the other drivers handle it,
> using polling. You can mask or disable the interrupts while in the
> xfer_atomic callback, and the i2c core won't schedule two transfers
> at the same time anyway.
The ocore driver is similar to the Marvell driver, a big state
machine. It implements polling for atomic transfers. It needs polling
support anyway, because some instantiations of the hardware have
broken interrupts :-(
Maybe there is some code which can be copied from the ocore driver?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Maxime Ripard <mripard@kernel.org>,
Gregory Clement <gregory.clement@bootlin.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: No master_xfer_atomic for i2c-mv64xxx.c
Date: Tue, 21 Jan 2020 15:40:19 +0100 [thread overview]
Message-ID: <20200121144019.GD16902@lunn.ch> (raw)
In-Reply-To: <CAGb2v65Kz0ymDapbyJ_WTebEGOs5=wkqMXUZV-mQJhdKr8ZGhA@mail.gmail.com>
> > However, I'm not entirely sure how we could implement it without
> > sleeping. The controller is basically a state machine that triggers an
> > interrupt on each state change, so you first set the address, get an
> > interrupt, then set the direction, then you get an interrupt, etc.
> >
> > I guess we could implement it using polling, but I'm not sure if
> > that's wise in an interrupt context either.
>
> I believe that is actually how some of the other drivers handle it,
> using polling. You can mask or disable the interrupts while in the
> xfer_atomic callback, and the i2c core won't schedule two transfers
> at the same time anyway.
The ocore driver is similar to the Marvell driver, a big state
machine. It implements polling for atomic transfers. It needs polling
support anyway, because some instantiations of the hardware have
broken interrupts :-(
Maybe there is some code which can be copied from the ocore driver?
Andrew
next prev parent reply other threads:[~2020-01-21 14:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-19 4:21 No master_xfer_atomic for i2c-mv64xxx.c Florian Fainelli
2020-01-19 4:21 ` Florian Fainelli
2020-01-21 9:40 ` Maxime Ripard
2020-01-21 9:40 ` Maxime Ripard
2020-01-21 9:47 ` Chen-Yu Tsai
2020-01-21 9:47 ` Chen-Yu Tsai
2020-01-21 14:40 ` Andrew Lunn [this message]
2020-01-21 14:40 ` Andrew Lunn
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=20200121144019.GD16902@lunn.ch \
--to=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=gregory.clement@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=wens@csie.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.