On Mon, Jul 8, 2024 at 11:10 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 08/07/2024 10:21, Yang Li wrote:
> >
> > On 2024/7/8 15:32, Krzysztof Kozlowski wrote:
> >> On 08/07/2024 08:32, Yang Li wrote:
> >>> 在 2024/7/8 14:11, Krzysztof Kozlowski wrote:
> >>>> On 08/07/2024 08:04, Yang Li wrote:
> >>>>>>> +
> >>>>>>> +required:
> >>>>>>> + - compatible
> >>>>>>> + - clocks
> >>>>>>> + - clock-names
> >>>>>>> + - amlogic,chip-enable-gpios
> >>>>>>> + - amlogic,bt-enable-gpios
> >>>>>>> +
> >>>>>>> +additionalProperties: false
> >>>>>>> +
> >>>>>>> +examples:
> >>>>>>> + - |
> >>>>>>> + #include <dt-bindings/gpio/gpio.h>
> >>>>>>> + wcn_pwrseq {
> >>>>>> No underscores in node names, generic node names.
> >>>>>>
> >>>>>> There is no device as "pwrseq". I also do not get what "wcn" means here.
> >>>>> Yes, I understand.
> >>>>>
> >>>>> Can I change "wcn_pwrseq" to "pmu", and do I need to change the binding
> >>>> What is pmu for your device? What is this device in the first place you
> >>>> are documenting? Where is the datasheet?
> >>> ^_^ Well, You are right, the "pmu" wasn't really fit in here.
>
> So no datasheet? Then you are on your own.
>
> >>>
> >>> I'd like to explain the current usage first, and could you please give
> >>> me a suggestion?
> >>>
> >>> This module(pwrseq) used to power on Bluetooth & Wi-Fi combo chip, both
> >>> Bluetooth and
> >>>
> >>> Wi-Fi driver need to control "chip-en-gpios" pins, so we introduced the
> >>> power sequence module.
> >>>
> >>> What should we call it in this case?
> >> Sorry, you describe driver, not a device.
> >>
> >> That would be a no-go for entire binding. Please describe the hardware,
> >> not what you want to achieve in Linux drivers.
> > W155s2 is a Bluetooth and WiFi combination chip. Bluetooth requires the
>
> I asked about this device here.
>
> You speak now about W155s2 but everywhere else you were using "WCN".
> What is that WCN?
>
> > bt-en pin to be pulled up, the chip-en pin to be pulled up, and the
> > 32.768KHz clock. WiFi requires the chip-en pin to be pulled up, and the
> > 32.768KHz clock. It can be seen that Bluetooth and WiFi are coupled to
> > the chip-en pin and the 32.768KHz clock. When Bluetooth and WiFi are
> > working at the same time, no matter which one is turned off, it will
> > affect the other device. Therefore, a pwrseq device is now abstracted to
>
> It is the first time you mention pwrseq device from above paragraph.
> Nothing above describes pwrseq.
>
> Stop describing your problem, we all know it exactly if you follow the
> discussions about power sequencing. Instead describe this particular
> device you add binding for. What is this pwrseq in hardware? How does it
> look? Where is it located? What are its pins? What are its supplies?
>
> > manage the chip-en pin, bt-en pin, and the 32.768KHz clock.
>
> >
> > There is currently no matching device name for the pwrseq composite device.
>
> ? No clue what does this mean.
> >
> > Could you please give me some advice?
>
> Again, you do not describe the device for the binding but something
> else. Something for your drivers, sorry. No.
>
> If you disagree, respond accurately to all questions above, not to only
> some of them...
>
> Best regards,
> Krzysztof
>
Yang, please look at the existing pwrseq-qcom-wcn.c driver and its
bindings. They do exactly what you most likely want to do here. They
describe the power management unit of the chipset, its inputs from
host and outputs consumed by the WLAN and BT modules. Please try to
follow it for your device.
Bart
