Messages in this thread | | | From | Martin Blumenstingl <> | Date | Tue, 26 Mar 2019 21:16:44 +0100 | Subject | Re: [PATCH 0/1] pwm: meson: fix scheduling while atomic issue |
| |
Hi Jerome,
On Tue, Mar 26, 2019 at 9:37 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > On Mon, 2019-03-25 at 19:04 +0100, Martin Blumenstingl wrote: > > > Thanks for fixing this Martin. > > you're welcome! > > > > > As for the future enhancement, I'd like to know what you have in mind. > > > As I have told you previously, I think the clock bindings of this driver are > > > not great. > > > > > > The global name of the input clocks are hard coded in this driver and it > > > sucks. CCF is evolving to rely less on these global names. > > I fully agree with you on the clock setup, but I'm not sure if we have > > to break the dt-bindings for it. > > > > the datasheet notes: "Each PWM is driven by a programmable divider > > driven by a 4:1 clock selector". > > In my own words this means that each PWM controller has up to 8 clock inputs: > > - up to 4 inputs for the first channel (PWM_A) > > - up to 4 inputs for the second channel (PWM_B) > > Not from the pwm device POV. there is one device (PWM_AB) with 4 (max) input > clocks. Those are consumed by two internal muxes. There would be 8 if the > input was different between path A and B. > > > > > the current pwm-meson driver assumes that both the inputs for both > > channels are identical. > > the "clock trees" section of the public S912 datasheet (page 65) > > clearly documents the clock inputs per PWM channel, not per PWM > > controller. > > > > Thus I believe we should name our clock-names (the inputs to the PWM > > controller) "pwm-a-clkin0", "pwm-a-clkin1", "pwm-b-clkin0", ... > > That way we don't have a conflict with the existing bindings (which > > already reserve "clkin0" and "clkin1"). > > I think this is overkill an inaccurate. The experience of all the soc we have > seen so far (meson8, gxbb, gxl, gxm, axg and g12) confirms the sources the are > the same input clock for both path. > > The documentation just shows the clock src of each pwm. That just how the the > table is presented. That does not change the fact the pwms are organized in > modules (pairs) and the that the clock source are the same for each pwm of the > module. IOW, there is only 4 lines of clocks getting to the IP, not 8. Feel > free to ask amlogic if you want to make sure. interesting, the way you describe it also seems valid.
I don't want to implement either way and find out that we have to change the bindings again later on.
Bichao, Jianxin, can you answer the question whether each PWM controller has: - up to four clock inputs. clock parents for channels PWM_A and PWM_B are always the same - up to eight clock inputs. four parents for channel PWM_A and four more parents for PWM_B, where the parents of PWM_A and PWM_B could be different (for all known SoCs the parents of the channels PWM_A and PWM_B are identical, so we don't know how the hardware is modelled)
> The name clash is not really my point. The purpose of the clock binding would > be different (from stating a setting to describing hw connection) OK, so your main concern is that we're breaking the DT bindings - so instead of coming up with a "quick fix" we might as well take the long but proper route?
> > > > > In addition, the 'clock' binding should be used to refer to the clock > > > 'consumed' by the device, not to define a setting (as done now). 'assigned- > > > clock' binding can be used for that. > > using the assigned-clock* properties requires self-referencing the PWM > > controller (which I'm not used to), for example: > > &pwm_ab { > > #clock-cells = <1>; > > assigned-clocks = <&pwm_ab 0>, <&pwm_ab 1>; /* references itself */ > > assigned-clock-parents = <&xtal>, <&clkc CLKID_FCLK_DIV5>; > > }; > > > > if we want to auto-detect the parent clock (like you suggested below) > > we need to consider if we can detect whether a .dts-author assigned a > > specific parent. > > I (personally) don't want to keep supporting the manual assignment of the > parent. If the driver can guarantee than it will pick the most appropriate > parent, there is no reason to have that. > > > I know that it's easy to detect this when the clock is passed in the > > "clocks" property, but I'm not sure if it's easy to parse it from the > > assigned-clocks/assigned-clock-parents properties. > > Assigned parent is the poor man solution and not necessarily easier to > implement (the pwm device would have to export its own clocks) ... I have just > mentioned it to make the point that current method is not ideal > > > > > [...] > > > Last, instead of specifying the parent to be used, I think we should come up > > > with some code to let the driver pick the most appropriate parent for the period/duty requested. > > that will make it easier for .dts authors. > > I would like to postpone this until we have solved the other topics though. > > I much prefer this last solution. Since the algorithm and the bindings would > change, I think it would be easier (in DT) to just make v2 driver with a new > compatible, progressively transition dts to it and finally remove the old > driver. Neil has already raised the question whether clock jitter may be relevant.
what also came to my mind is the "system suspend" use-case: I'm not sure if the fixed_pll (and it's post-dividers) are enabled during system suspend. in that case we probably need clock the PWM channel off the main XTAL. (I don't know if this use-case really exists, I want to bring it up so we can discuss it)
Regards Martin
| |