From: "Natarajan, Sugumar" <sugumar-l0cyMroinI0@public.gmane.org>
To: Bill Gatliff <bgat-uPd5UNENI//N9NzbbXoYwQ@public.gmane.org>,
sugumar
<sugumar.embedded-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org"
<davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>,
"linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: Generic PWM git tree rebased; please resend me your patches
Date: Thu, 27 Jan 2011 18:40:24 +0530 [thread overview]
Message-ID: <B85A65D85D7EB246BE421B3FB0FBB593024863E66C@dbde02.ent.ti.com> (raw)
In-Reply-To: <AANLkTin=BvOXfQcrUvjmRzJ416TbJ1KsMVtZSrh0TFy=@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 5159 bytes --]
Hi Bill,
I am working on the driver for eHRPWM module. I have completed the initial implementation and looking forward for your support to make it as complete driver. There are few design issues that needs to be addressed. Block diagram of the eHRPWM module is presented below for clear understanding.
[cid:image001.png-0+Gm3E7YfSJjdIJ4uHzgADRmByFHzeGd@public.gmane.org]
Fig 1 eHRPWM Module
[cid:image002.png@01CBBE4C.C2818090]
Fig 2 Dead Band (Sub Module)
The major difference between Atmel controller and eHRPWM controller is that though eHRPWM module has two channels, they are not independent. There are no separate hardware registers for each channel as in the case of Atmel. Independent control of two channels is achieved in the driver only by means of software. eHRPWM is registered as a character device and for the reason that the channels are not independent, the system calls, open and IOCTL are written in such as way that they operate on the device and not the channels. Initially, the IOCTL interface was designed to be based on the channel request. But, there are features such as Trip zone and Dead Band which can source any of the channel output from the previous stage. For Eg. Let say, channel A is stopped and channel B is running or in other words the output of A at the Action Qualifier stage(Fig 1)is 0. Using the Dead Band feature, output of B from the previous stage can be sourced to override both outputs A and B of the next and subsequent stages(As seen from Fig 2 Dead Band). Hence, the design was modified to be based on the device request. To be more specific, there is no concept of channels. There are two independent outputs which can be overriden by any eHRPWM feature.
Considering the above, I am facing the below design issue.
1. IOCTL interface provides the user with an option to set the frequency and duty cycle by means of Set_Period and Set_Duty IOCTL calls. User has to pass the device id and the channel no. to be controlled. As said above, user accesses the device and not the channels. As of now, these commands internally call the pwm_set_period in the PWM framework. For the function call to be successful, pwm_request function should have been invoked before for each channel(Otherwise flag test will fail) since user might set period/duty for any of the channels. Is it the right way to do? Or Would it make sense to implement the set_period and set_duty function internal to the driver so that PWM request is used only by the kernel Subsystem such as Backlight interface and not the driver. In other words, Can the user be given access to the device irrespective of whether it is being used or not by the kernel subsystem such as Back light interface? Is there any other better way of implementation so that it coexists with the PWM framework?
Apart from the above design issue, I find the following to be limitations in the PWM framework
2. eHRPWM module has high resolution feature which operates on the fractional value of cycles. The PWM channel structure should have the field to store the duty value in ns so that the driver can calculate the fractional cycle value.
3. pwm_find_device function needs to have global access. The open function call uses this function to search for the pwm device.
Can the above limitation be avoided?
I have attached the patches for your review. The patches have been tested against the pwm git repository.
Please review the design and give your valuable comments/feedback.
Regards,
N.sugumar
On Thu, Oct 21, 2010 at 18:44:48, Bill Gatliff wrote:
> Guys:
>
>
> I have a public git tree of my generic PWM framework code here:
>
> git://git.billgatliff.com/pwm.git
>
> I have rebased my series against linux-2.6.36, and also cleaned up a bunch of stuff based on reviewer feedback. I think I have also make things such that the existing PWM kernel code can coexist with my framework, giving us less breakage and more time to migrate things to the new API.
>
> Many of you have been sending me code against the patch series I posted here a few weeks ago, and I really do appreciate that. Please rebase your patches against the above repository and resend (or send me a pull request). I'm trying to get all of your patches merged, but many of them aren't going in without conflicts. Sorry for the extra work.
>
> Thanks very much!
>
>
> b.g.
> --
> Bill Gatliff
> bgat-uPd5UNENI//N9NzbbXoYwQ@public.gmane.org<mailto:bgat-uPd5UNENI//N9NzbbXoYwQ@public.gmane.org>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org<mailto:majordomo@vger.kernel.org> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #1.1.2: Type: text/html, Size: 13016 bytes --]
[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 60676 bytes --]
[-- Attachment #1.3: image002.png --]
[-- Type: image/png, Size: 35390 bytes --]
[-- Attachment #2: ehrpwm_patch.zip --]
[-- Type: application/x-zip-compressed, Size: 17940 bytes --]
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
prev parent reply other threads:[~2011-01-27 13:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-21 13:14 Generic PWM git tree rebased; please resend me your patches Bill Gatliff
2011-01-27 13:10 ` Natarajan, Sugumar [this message]
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=B85A65D85D7EB246BE421B3FB0FBB593024863E66C@dbde02.ent.ti.com \
--to=sugumar-l0cymroini0@public.gmane.org \
--cc=bgat-uPd5UNENI//N9NzbbXoYwQ@public.gmane.org \
--cc=davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org \
--cc=linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sugumar.embedded-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).