On Mon, Jan 25, 2016 at 07:32:16PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> writes:
> > This should allow the core driver to drop handling of
> > platform data and expect the platform specific details to
> > always come from properties.
> >
> > Signed-off-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
> > Cc: Huang Rui <ray.huang@xxxxxxx>
> > CC: John Youn <John.Youn@xxxxxxxxxxxx>
> > ---
> > drivers/usb/dwc3/dwc3-pci.c | 81 +++++++++++++++++++++++----------------------
> > 1 file changed, 41 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> > index 23d4f10..ff6488a 100644
> > --- a/drivers/usb/dwc3/dwc3-pci.c
> > +++ b/drivers/usb/dwc3/dwc3-pci.c
> > @@ -23,8 +23,7 @@
> > #include <linux/platform_device.h>
> > #include <linux/gpio/consumer.h>
> > #include <linux/acpi.h>
> > -
> > -#include "platform_data.h"
> > +#include <linux/delay.h>
> >
> > #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 0xabcd
> > #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3_AXI 0xabce
> > @@ -46,38 +45,42 @@ static const struct acpi_gpio_mapping acpi_dwc3_byt_gpios[] = {
> > { },
> > };
> >
> > +static inline int
> > +dwc3_pci_add_pset(struct platform_device *dwc3, struct property_entry *ent)
> > +{
> > + struct property_set pset;
> > +
> > + pset.properties = ent;
> > + return platform_device_add_properties(dwc3, &pset);
> > +}
> > +
> > static int dwc3_pci_quirks(struct pci_dev *pdev)
> > {
> > if (pdev->vendor == PCI_VENDOR_ID_AMD &&
> > pdev->device == PCI_DEVICE_ID_AMD_NL_USB) {
> > - struct dwc3_platform_data pdata;
> > -
> > - memset(&pdata, 0, sizeof(pdata));
> > -
> > - pdata.has_lpm_erratum = true;
> > - pdata.lpm_nyet_threshold = 0xf;
> > -
> > - pdata.u2exit_lfps_quirk = true;
> > - pdata.u2ss_inp3_quirk = true;
> > - pdata.req_p1p2p3_quirk = true;
> > - pdata.del_p1p2p3_quirk = true;
> > - pdata.del_phy_power_chg_quirk = true;
> > - pdata.lfps_filter_quirk = true;
> > - pdata.rx_detect_poll_quirk = true;
> > -
> > - pdata.tx_de_emphasis_quirk = true;
> > - pdata.tx_de_emphasis = 1;
> > -
> > - /*
> > - * FIXME these quirks should be removed when AMD NL
> > - * taps out
> > - */
> > - pdata.disable_scramble_quirk = true;
> > - pdata.dis_u3_susphy_quirk = true;
> > - pdata.dis_u2_susphy_quirk = true;
> > -
> > - return platform_device_add_data(pci_get_drvdata(pdev), &pdata,
> > - sizeof(pdata));
> > + struct property_entry pentry[] = {
> > + PROPERTY_ENTRY_BOOL("snps,has-lpm-erratum"),
> > + PROPERTY_ENTRY_U8("snps,lpm-nyet-threshold", 0xf),
> > + PROPERTY_ENTRY_BOOL("snps,u2exit_lfps_quirk"),
> > + PROPERTY_ENTRY_BOOL("snps,u2ss_inp3_quirk"),
> > + PROPERTY_ENTRY_BOOL("snps,req_p1p2p3_quirk"),
> > + PROPERTY_ENTRY_BOOL("snps,del_p1p2p3_quirk"),
> > + PROPERTY_ENTRY_BOOL("snps,del_phy_power_chg_quirk"),
> > + PROPERTY_ENTRY_BOOL("snps ,lfps_filter_quirk"),
> > + PROPERTY_ENTRY_BOOL("snps,rx_detect_poll_quirk"),
> > + PROPERTY_ENTRY_BOOL("snps,tx_de_emphasis_quirk"),
> > + PROPERTY_ENTRY_U8("snps,tx_de_emphasis", 1),
> > + /*
> > + * FIXME these quirks should be removed when AMD NL
> > + * taps out
>
> while at that, do you mind fixing this typo here (taps -> tapes) ?
Sure thing.
> Another thing, it looks like we're DT-fying ACPI. Is this what's
> happening here ? All DT properties will also become ACPI properties, or
> is this kernel-only knowledge ?
I probably didn't quite understand your question. I'm not sure in this
case we should be talking about DT-fying ACPI as we are now dealing
with the build-in properties instead of ACPI properties. I'll write
what I know about the background with the unified device property
interface. Perhaps that answers your question..
With the introduction of _DSD (device specific data), the method
that returns package of properties in ACPI v5.1, the idea apparently
was to have possibility to describe the properties more or less
exactly like they are described in DT also in ACPI tables. That in
turn allowed the guys to create the unified device property interface
which allows the drivers to ignore the type of HW description and
request the properties using always the same API.
In this case we are dealing with build-in property type which was
added to the unified device property interface to allow also
information that is usually passed to the drivers with custom platform
data to be extracted with the same API in the drivers. The build-in
properties were recently changed to be the secondary source for
properties in cases where there is a primary source (DT or ACPI), but
when the primary source does not provide the requested property.
I hope that explains at least something.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
