From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Olliver Schinagl <oliver@schinagl.nl>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>,
Thierry Reding <thierry.reding@gmail.com>,
Simon <longsleep@gmail.com>,
linux-pwm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCHv9 0/2] Add Allwinner SoCs PWM support
Date: Tue, 18 Nov 2014 14:54:54 +0100 [thread overview]
Message-ID: <20141118135454.GD6414@lukather> (raw)
In-Reply-To: <546B4DF5.9020100@schinagl.nl>
[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]
On Tue, Nov 18, 2014 at 02:47:33PM +0100, Olliver Schinagl wrote:
> Hey Alexandre,
>
> On 05-11-14 16:15, Alexandre Belloni wrote:
> >Hi,
> >
> >This patch series adds support for the PWM controller found on the Allwinner
> >SoCs.
> >
> >The first patch adds the driver itself.
> >The second patch adds the DT binding documentation
> >
> >Changes in v8:
> > - renamed the driver sun4i as the PWM IP is different in the next sunxi SoCs
> Why did you decide to rename it to sun4i? From your bindings document I
> understand you still support sun4i and sun7i, what happened to sun5i?
>
> I went over the datasheets of sun4i, sun5i and sun7i and the disp_lcd.c from
> the latest linux-sunxi kernels and have to agree, they are all 4
> inconsistent and messy, but I'm not sure what you mean with PWM IP is
> different in next sunxi soc's. is sun5i different to sun4i? is sun7i
> different? or is sun6i (A31), sun8i (a80) and sun9i (A23) different?
>
> What I get from the datasheet is, that sun4i and sun5i are exactly the same,
> with the exception that sun5i only has 1 PWM (~exposed~). I belive that is
> easily solved with the bindings by having allwinner-sun4i and allwinner
> sun5i bindings if I'm not mistaken.
>
> As for sun7i compared to the other ones, according to disp_lcd.c sun5i and
> sun7i should behave exactly the same. This is contradicting to the
> datasheet, where sun4i and sun5i are the same.
>
> So what are the major differences that I can see between the 3? sun4i
> defines the PWM prescaler register value 0b1111 as being undefined, and
> sun5i and sun7i as /1? Did you verify this (I haven't I admit, i bumped into
> this while looking for your patch ;-) )? I wouldn't be supprised if it where
> a typo on allwinners end in the datasheet ... disp_lcd.c stops at 72000 for
> the last entry. We should just check sun4i, sun5i and sun7i hardware to see
> if it behaves the same with a prescaler of 0b1111, which I would not be
> totally surprised if it did.
>
> The other difference I notice is that sun7i and sun5i use 16bit period
> register where sun4i uses a 8bit register. This is probably the only reason
> why they put a #ifdef in disp_lcd.c, calculations turn out differently. I
> don't recognize this behavior at all in your driver however. I do think they
> that there is a difference here, since they did split up the original driver
> here because of this difference.
>
> The pre-scaler bypass bit and pwm ready bit you all ready take care of :)
A31 and later are using a different IP, that is not supported by this
driver.
This driver only support the controller introduced with the A10, that
only saw minor differences between SoCs, like you have shown.
> Finally, though I'm sure I should have replied to it inline in the actual
> code, but hoping i can let it slip through here is that you define your
> local data as:
>
> + static const struct sun4i_pwm_data sun4i_pwm_data_a20 = {
>
> which looks really strange to me, since there is no a20 using the sun4i
> architecture :) I know it's just nitpicking, it just looks really odd. Maybe
> the compatible naming works just as well? sun4i_pwm_data; sun7i_pwm_data
> (and sun5i_pwm_data if you want to take care of only pwm0, only pwm1 (if we
> ever encounter such a configuration, disabled pwm0, enabled pwm1) or both to
> be used?)
This driver is name sun4i_pwm, hence the prefix.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv9 0/2] Add Allwinner SoCs PWM support
Date: Tue, 18 Nov 2014 14:54:54 +0100 [thread overview]
Message-ID: <20141118135454.GD6414@lukather> (raw)
In-Reply-To: <546B4DF5.9020100@schinagl.nl>
On Tue, Nov 18, 2014 at 02:47:33PM +0100, Olliver Schinagl wrote:
> Hey Alexandre,
>
> On 05-11-14 16:15, Alexandre Belloni wrote:
> >Hi,
> >
> >This patch series adds support for the PWM controller found on the Allwinner
> >SoCs.
> >
> >The first patch adds the driver itself.
> >The second patch adds the DT binding documentation
> >
> >Changes in v8:
> > - renamed the driver sun4i as the PWM IP is different in the next sunxi SoCs
> Why did you decide to rename it to sun4i? From your bindings document I
> understand you still support sun4i and sun7i, what happened to sun5i?
>
> I went over the datasheets of sun4i, sun5i and sun7i and the disp_lcd.c from
> the latest linux-sunxi kernels and have to agree, they are all 4
> inconsistent and messy, but I'm not sure what you mean with PWM IP is
> different in next sunxi soc's. is sun5i different to sun4i? is sun7i
> different? or is sun6i (A31), sun8i (a80) and sun9i (A23) different?
>
> What I get from the datasheet is, that sun4i and sun5i are exactly the same,
> with the exception that sun5i only has 1 PWM (~exposed~). I belive that is
> easily solved with the bindings by having allwinner-sun4i and allwinner
> sun5i bindings if I'm not mistaken.
>
> As for sun7i compared to the other ones, according to disp_lcd.c sun5i and
> sun7i should behave exactly the same. This is contradicting to the
> datasheet, where sun4i and sun5i are the same.
>
> So what are the major differences that I can see between the 3? sun4i
> defines the PWM prescaler register value 0b1111 as being undefined, and
> sun5i and sun7i as /1? Did you verify this (I haven't I admit, i bumped into
> this while looking for your patch ;-) )? I wouldn't be supprised if it where
> a typo on allwinners end in the datasheet ... disp_lcd.c stops at 72000 for
> the last entry. We should just check sun4i, sun5i and sun7i hardware to see
> if it behaves the same with a prescaler of 0b1111, which I would not be
> totally surprised if it did.
>
> The other difference I notice is that sun7i and sun5i use 16bit period
> register where sun4i uses a 8bit register. This is probably the only reason
> why they put a #ifdef in disp_lcd.c, calculations turn out differently. I
> don't recognize this behavior at all in your driver however. I do think they
> that there is a difference here, since they did split up the original driver
> here because of this difference.
>
> The pre-scaler bypass bit and pwm ready bit you all ready take care of :)
A31 and later are using a different IP, that is not supported by this
driver.
This driver only support the controller introduced with the A10, that
only saw minor differences between SoCs, like you have shown.
> Finally, though I'm sure I should have replied to it inline in the actual
> code, but hoping i can let it slip through here is that you define your
> local data as:
>
> + static const struct sun4i_pwm_data sun4i_pwm_data_a20 = {
>
> which looks really strange to me, since there is no a20 using the sun4i
> architecture :) I know it's just nitpicking, it just looks really odd. Maybe
> the compatible naming works just as well? sun4i_pwm_data; sun7i_pwm_data
> (and sun5i_pwm_data if you want to take care of only pwm0, only pwm1 (if we
> ever encounter such a configuration, disabled pwm0, enabled pwm1) or both to
> be used?)
This driver is name sun4i_pwm, hence the prefix.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141118/a7ac8abd/attachment.sig>
next prev parent reply other threads:[~2014-11-18 13:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 15:15 [PATCHv9 0/2] Add Allwinner SoCs PWM support Alexandre Belloni
2014-11-05 15:15 ` Alexandre Belloni
2014-11-05 15:15 ` [PATCHv9 1/2] pwm: Add Allwinner SoC support Alexandre Belloni
2014-11-05 15:15 ` Alexandre Belloni
2014-11-17 12:23 ` Thierry Reding
2014-11-17 12:23 ` Thierry Reding
2014-11-05 15:15 ` [PATCHv9 2/2] pwm: sunxi: document OF bindings Alexandre Belloni
2014-11-05 15:15 ` Alexandre Belloni
2014-11-18 13:47 ` [PATCHv9 0/2] Add Allwinner SoCs PWM support Olliver Schinagl
2014-11-18 13:47 ` Olliver Schinagl
2014-11-18 13:47 ` Olliver Schinagl
2014-11-18 13:54 ` Maxime Ripard [this message]
2014-11-18 13:54 ` Maxime Ripard
2014-11-18 14:11 ` Olliver Schinagl
2014-11-18 14:11 ` Olliver Schinagl
2014-11-18 14:55 ` Maxime Ripard
2014-11-18 14:55 ` Maxime Ripard
2014-11-18 15:11 ` Olliver Schinagl
2014-11-18 15:11 ` Olliver Schinagl
2014-12-17 19:58 ` Alexandre Belloni
2014-12-17 19:58 ` Alexandre Belloni
2014-12-19 9:04 ` Olliver Schinagl
2014-12-19 9:04 ` Olliver Schinagl
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=20141118135454.GD6414@lukather \
--to=maxime.ripard@free-electrons.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=longsleep@gmail.com \
--cc=oliver@schinagl.nl \
--cc=thierry.reding@gmail.com \
/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.